Along with that, we decided to change the overlay from qting-edge to just qt. Layman list is alreay updated, so if you still have the old one, you should remove it and add the new one:

# layman -f
# layman -d qting-edge
# layman -a qt

Keep in mind that this overlay contains mostly live ebuilds of Qt (branches 4.7 and master), so make sure that you really need it before blindly adding it (the same applies for the kde overlay). Enjoy!

johu, hwoarang, pesa, tampakrap, wired

2. Qt 4.8

* cairo fails to build, patched ebuild available in qting-edge, #380013

Cairo build issue is fixed in qting-edge overlay, will be moved together with Qt 4.8.0 to tree.

* qt now defaults to the raster graphicssystem, we should remove raster USE flag, #398283

Wired created a eselect module to choose the Qt graphicsystem. Raster is default, other selectable are opengl, openvg and native. Raster use flag is not needed anymore, qt-gui depends on the new eselect module.

* do we really want to keep qpa USE flag?

qpa and c++0x will be masked in tree.

* are we going to fix #363939 for 4.8?

Wired fixed this bug in qt 4.8.0. Qt 4.8 will be moved to tree on next weekend. Dilfridge prepares kde-base/kstyles-4.7.4 to be rebuild together with Qt 4.8.0 to prevent crashes in KDE apps with Oxygen style.

3. Minor arches and Qt >= 4.7

Upstream supports official amd64, arm and x86, but other arches also considered in configure script. Keep stable keywords for minor arches in Qt 4.6. Wait for minor arches arm, ppc, ppc64 in current stabilization in Qt 4.7.4. Drop sparc keywords in Qt 4.8.0.

4. Overlay migration to git.overlays.gentoo.org

Tampakrap will set up overlay on git.overlays.gentoo.org on next weekend. The new overlay will be renamed to qt instead of qting-edge.

5. Open bugs

* #398885 qdoc3 broken on arm

We will ask the reporter if it works when he builds manually by providing him a configure command to make sure he tries the proper build.

* #394533 Libreoffice crashes in qt on exit

Can’t be reproduced with Libreoffice 3.5.0.1, seems to be resolved by upstream.

* #392433 desktop file name issues

Will be fixed in Qt 4.8.0, so that qt-gui and qt-assistant no longer pass absolute paths to make_desktop_entry().

* #388551 qt-gui[gtkstyle] should depend on gnome-base/libgnomeui-2

We will add a elog message in qt-gui[gtkstyle] saying that for things to work you either need libgnomeui or that variable set properly in your env.

* #382559 qt_mkspecs_dir() returns bad spec directory

The bug will be marked as RESOLVED WORKSFORME, because we can’t reproduce it. Additionally we change the eclass not to use LIBDIR in favor of get_libdir() after Qt 4.8 hits the portage tree.

* #359391 qt4-build.eclass should check for —buildpkgonly before downgrade sanity check

Resolution will be RESOLVED WONTFIX. Sanity check is there for a reason. It’s not a matter of source or binary downgrade.

alexxy, jmbsvicetto, dilfridge, johu, mschiff, tampakrap, Thev00d00

2) Electing a new team leader

Since one year is not over yet, it will be skipped for the next meeting.

3) What shall we do with kdepim-4.4

KDEPIM 4.4 is not supported any more by upstream, but on the other hand KDEPIM2 is still too buggy. We had a discussion if we should remove it completely or if we should continue maintain it, despite the compatibility bugs that started to emerge with newer KDE versions. Final decision is that we will continue support it as long it works with newer KDE SC releases. We’ll keep the kdepim-l10n split package to provide the translations for it.

4) kdeenablefinal revisited

Since upstream doesn’t seem to care about it much, plus it doesn’t make much sense now that there are many split tarballs, we decided to remove it the next day after the meeting.

5) phonon-xine removal

KDE upstream acknowledged that this is not maintained anymore. It’s already masked since 2011/12/01. Will be last rited and removed 15 days afterwards.

6) Qt 4.8

We expect no big issues with it. Kdenlive is the only known application that does not build at the moment and will be patched. kde-base/kstyles-4.7.* needs to be rebuilt after the upgrade, which we’ll solve with a combination of revbump/dependencies (otherwise KDE apps using oxygen style crash).

7) Dropping RPATH from installed binaries

Postponed for next meeting, need more info from reavertm and/or hardened herd.

To eselect Boost or not to eselect boost

No final decision was taken, discussion will be moved to -dev mailing list.

9) Bugs

* dev-util/cmake picks always the latest boost. Fix in overlay since 13. Dec. Move to tree? https://bugs.gentoo.org/show_bug.cgi?id=335108

see 8.

* cmake-utils.eclass PREFIX is not defined, any progress? https://bugs.gentoo.org/show_bug.cgi?id=358059

Postponed for next meeting

* Remove hard dep on media-libs/phonon from kde-base/kdelibs https://bugs.gentoo.org/show_bug.cgi?id=356681 https://bugs.gentoo.org/show_bug.cgi?id=388041

Although it is possible to build kdelibs against qt-phonon, it is not recommended by upstream. Decision postponed for next meeting.

* Eclass problem with handbook without LINGUAS. https://bugs.gentoo.org/show_bug.cgi?id=372457

Needs more analysis. Postponed.

* MacOSX request for cmake-utils.eclass: Remove force of  CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE https://bugs.gentoo.org/show_bug.cgi?id=398437

That was a request by the Gentoo Prefix team, and got accepted

* Revise the change “semantic-desktop? -> semantic-desktop=”. Why was the change needed. https://bugs.gentoo.org/show_bug.cgi?id=396491

We had split opinions on this. Skipped for next meeting, as we need reavertm’s input on this.

10) Open floor

• Tampakrap will make a KDE SC 4.8 release party in Prague, more info coming soon.
• Qt meeting on Thursday 26th Jan.
• See you at fosdem

Okupy is a Django CMS, with a full LDAP frontend, XML to HTML (and the opposite) converter and a WYSIWYG editor, Beacon, to edit the XML files. Ultimate goal is to fully replace current Gentoo website, and Gorg, the web server that does the XML to HTML convertion currently. In the future I’d like to see more gentoo websites being provided by Okupy.

Summary:

The application has a fully working and fully configurable LDAP backend. It can work with any LDAP configuration file, but it will need accordingly some setup in Okupy’s settings files. It currently supports:

• Creation of a new user, which means that the Gentoo LDAP server can now be enabled for non-developers
• Log in of current users, using any of their verified emails
• Adding new email, along with email verification
• Password reset
• View someone’s account data (based on the privileges, the according attributes will show up)
• Edit own account data (again, based on privileges, the according attributes will be available for editing)
• An addressbook

In order to support all users and not only developers, I had to do some internal infra discussions about which OU will be used for them. Plus, a few new values were needed for the GentooAccess attribute, such as user.group, docs.group and other privileged groups. Most LDAP backends were using an administrator account for performing both queries and changes in the data, which could easily lead to a security issue. This problem was solved by using a secondary password for the user, which is encrypted and stored in the session variable. The secondary password is available for only one session, and gets destroyed by using itself. Django uses a database to store users, but it also supports other backends for the authentication part. When the user logs in for the first time, the data gets transfered in the database, which is a significant time improvement. Anonymous common LDAP Queries are performed either by using a minimal privileged (anon) account, or they should be available to anyone (which could lead to a security issue). I used some wrappers to cover that easily. The administrator can use a lot of options in the settings files, to cover the ACL part, the initial user creation and many other aspects.

As I said in my previous post, Beacon didn’t work out as expected. It became too complex, consisting of lots of JS and XSLT, for reading the XML files and printing them. It even stores accounts in its own DB to keep track of the documents that users edit. This was way out of our needs, we just need the WYSIWYG part only and plug it in in a separate web app. Obviously in its current state it is not a workable solution without significant additional effort. I tried to split some parts of its code, like the python scripts for converting XML to HTML and the opposite, but the time was not sufficient.

The future:

I am really happy to have such an interesting pet project now. I created an ebuild in my personal overlay, and an alias (okupy at gentoo dot org) to easily contact me for future issues. I plan to make it more accessible to some people soon, but not before Robin ACKs it first, since the LDAP server he gave me for testing is full of real data. I don’t feel very confident on working with that, and I’ll possibly request an empty one.

Before implementing, it will need too much work. Most importantly, people familiar with Web Design are very welcome to help on this. If we are going to redesign the current gentoo.org website, it is a huge step that has to be done very carefully. The LDAP part although finished will need too much testing, in order to assure we are not opening any security holes here. As for the Beacon part, it will need better approach, and most of the work has to be done upstream, which is what I intend to do from now on. It should become a single JS WYSIWYG editor that we should be able to plug in directly, since it currently is a full web application, which is using its own DB to store users and documents.

If you are interested in testing it, please contact me directly for now. The installation is not very easy at the moment, due to the need of both a database and an LDAP server, but it can work with minimal configuration for development purposes. I also added some config files in a separate branch for that reason.

Many thanks to my mentor, Matthew Summers, my co-mentor Robin Johnson, and the Gentoo GSoC admin Donnie Berkholz for all their help and support. Also, special thanks to Ben Cooksley, KDE Sysadmin, for his precious suggestions.

We’re going to:

• Nerdy chit chat
• Distribute KDE SC 4.7 LiveCDs, stickers, pins
• Eat the Kake (KDE Cake)
• Drink beers
• Discuss about creating a greek KDE community
• Lottery!! (Prizes include T-Shirts and USB sticks)

And of course… Have lots of fun!!!

I’m writing a CMS for the Gentoo website, that will offer an LDAP web interface, plus it will replace Gorg and provide Beacon as WYSIWYG editor to edit the XML file

There were some serious bugs in the edit account page. The ACL is very complex there, since there are public attributes (accessed by everyone), semi-private attributes (accessed by the user only and the admins (eg. birthday)), and private ones (accessed only by admins). Keep in mind that everything is configurable, but there is some duplication between the Django and LDAP ACL, since there is no easy way to parse the LDAP slapd.conf yet, we need to migrate our infra to cn=config first, which is a not easy long term task. The bug was not in the LDAP part, remember that the user changes his/others’ (in case he has the right privs) attributes with his own account, not by using a global admin account. The bug was in the Django part, where the system expected to be able to change some data, and weird error messages/exceptions were thrown out. Unfortunately this is not complete yet, it needs more investigation in order to ensure we are not opening any security holes here. The good news is that I tested with our current official configuration, and various tweaks on it, and seems to perform fine. Plus, it seems ready for the improvements I intend to do (for adding regular users in LDAP etc).

I was also able to plug in some CSS/JS written by my mentor. It is just some preliminary work, nothing complete yet, we’ll need more help on this, especially from people with some experience in web design stuff.

Beacon didn’t work out as expected. It became too complex, consisting of lots of JS and XSLT, for reading the XML files and printing them. It even stores accounts in its own DB to keep track of the documents that users edit. This was way out of our needs, we just need the WYSIWYG part only and plug it in in a separate web app. Obviously in its current state it is not a workable solution without significant additional effort. What we could do for now is to split some parts of its code, like the python scripts for converting XML to HTML and the opposite, which is also not an easy task.

I must admit that I am really happy that the GSoC is coming to its end, and the real fun begins

This is a fully-featured web platform for everyone’s favorite scripting language: bash. Because, you know, we can.
Written using ADD (API driven development)

While it is really cool and funny, the project is still taking its first steps, which means no documentation yet (at least there is a ticket for it though). I’ve also added a live ebuild in my overlay (gentoo-el in layman). Time to leave behind your favorite python/ruby/php framework. Have fun!

As a KDE packager, I usually have to write and test patches, especially build system related (Examples: Choqok, Amarok, Plasma and happy KStatusNotifierItem’d Akregator and Kaffeine, they don’t look ancient any more ). Gentoo, as a source based distro, has the ability to provide packages that clone/checkout the source from upstream’s SCM and compile it directly (called live ebuilds). For KDE, it provides live ebuilds from KDE SC master/trunk and the branch(es) (currently 4.7), plus live ebuilds for many extragear/playground and other packages (all of the above are available in the kde overlay). Also, we provide Qt live ebuilds both from master and many branches, in the qting-edge overlay. I wanted to use our Gentoo live ebuilds in order to test patches, but there were multiple problems. Emerge downloads the sources in $DISTDIR and stores them as the portage user. Plus, the git eclass was using bare repos, and it would reset the repo to master before each emerge. In order to solve those problems, I created a few scripts and wrappers, and convinced Tomas to introduce two new variables in the new git-2 eclass to fit my needs (thanks a lot bro, you owe me a beer).

Define the needs

In short, what I want is:

• download the sources somewhere in my homedir
• my everyday user to have write permissions to them
• non-bare clones
• url = anongit.kde.org AND pushUrl = git.kde.org, if possible directly on initial clone
• if possible, have a live and a regular release side by side

The last dot was solvable, but not any more. We used to provide a kdeprefix USE flag, that allowed us to do exactly this (install multiple KDE versions using different prefix (eg /usr/kde/4.7 /usr/kde/live). It had many problems though, that forced us to remove it. The problems it had were mostly in non-KDE packages, eg Sip, which also needed to be prefixed, which was too much workload. Anyway, a chroot could solve that issue.

As for the permission issue, I asked Zac if portage itself could provide something like this (using my user instead of the portage user), and he suggested that creating a git wrapper would be a clean solution.

After a while I was able to extend the above for my gentoo overlays (unofficial ebuild git repositories), since I have write access to most of the ones I use in my system.

Configuration

All the scripts mentioned can be found here. Although well tested here for the past few months, use them at your own risk. In the following examples I’m going to use the configurations for both the KDE and Gentoo git repos. Of course, you can ignore them (“Gentoo repos” blocks in the following scripts).

First, we need to set the following in /etc/make.conf:

# Needed by the Git wrapper
KDE_DEVELOPER=1 # For the KDE repos
GENTOO_DEVELOPER=1 # For the Gentoo repos
EGIT_NONBARE=1 # This one sets the git-2 eclass to clone non-bare repos

Next, we set up some git aliases in ~/.gitconfig, as suggested here:

# KDE Repos
[url "git://anongit.kde.org/"]
    insteadOf = kde:
[url "git@git.kde.org:"]
    pushInsteadOf = kde:
# Gentoo Repos
[url "git://git.overlays.gentoo.org/"]
    insteadOf = gentoo:
[url "git@git.overlays.gentoo.org:"]
    pushInsteadOf = gentoo:

And the git wrapper, which should be put in /usr/local/sbin/git:

#!/bin/bash
source /etc/make.conf
USER="tampakrap"
GROUP="tampakrap"
GIT="/usr/bin/git"
 
if [[ $1 == 'clone' ]]; then
    # KDE Repos
    if [[ $2 == "git://anongit.kde.org/"* ]] && [[ $KDE_DEVELOPER == 1 ]]; then
        KDE_REPO=$(echo $2 | sed 's:git\://anongit.kde.org/::')
        $GIT "$@"
        chown -R $USER:$USER $DISTDIR/egit-src/$KDE_REPO
    # Gentoo Repos
    elif [[ $2 == "git://git.overlays.gentoo.org/"* ]] && [[ $GENTOO_DEVELOPER == 1 ]];then
        GENTOO_REPO=$(echo $2 | sed 's:git\://git.overlays.gentoo.org/::')
        $GIT "$@"
        chown -R $USER:$GROUP $DISTDIR/egit-src/$GENTOO_REPO
    else
        $GIT "$@"
    fi
else 
    if [[ ${PWD%/*} == $DISTDIR/egit-src ]] && ( grep -s -q gentoo .git/config || grep -s -q kde .git/config ); then
        sudo -u $USER $GIT "$@"
    else
        $GIT "$@"
    fi
fi

The above script consists of two parts: if the git argument is clone, it checks if the URL is a KDE or Gentoo one and chowns the repo after cloning. If it is something else (eg pull), it checks again if the URL is a KDE or Gentoo one, and uses sudo -u $USER:$GROUP to preserve the permissions of the repo. The repos are still in the $DISTDIR/egit-src dir ($DISTDIR is usually /usr/portage/distfiles, but it can be changed in /etc/make.conf), so the following script creates symlinks of those somewhere in the homedir (put it in /usr/local/bin/create_repolinks):

#!/bin/bash
 
# Headers
source /etc/make.conf
. /etc/init.d/functions.sh
 
# Variables
REPO_DIR="/home/tampakrap/Source_Code/" # Where to store the symlinks of the repos
GENTOO_REPO_DIR="${REPO_DIR}gentoo/"  # Gentoo repos
KDE_REPO_DIR="${REPO_DIR}kde/" # KDE repos
OVERLAY_DIR="/var/lib/layman"
 
# No root
if [[ $UID == 0 ]]; then
	   eerror 'root is forbidden'
	   exit 1
fi
 
# Gentoo Overlays
cd $OVERLAY_DIR
for repo in `ls -d */`
do
	   pushd $repo > /dev/null
	   einfo "Checking $repo overlay"
	   if [[ ! -z `grep git.overlays.gentoo.org .git/config` ]]; then
		      sed -i -e 's:git\://git.overlays.gentoo.org/:gentoo\::' .git/config
		      ewarn "gentoo git url corrected for $repo overlay"
	   fi
	   [[ -L ${GENTOO_REPO_DIR}${repo%/*} ]] || (ln -s /var/lib/layman/$repo ${GENTOO_REPO_DIR} && ewarn "New symlink for $repo overlay")
	   popd > /dev/null
done
 
# KDE Repositories
cd $DISTDIR/egit-src
for repo in `ls -d */`
do
	   pushd $repo > /dev/null
	   einfo "Checking $repo repository"
	   if [[ ! -z `grep anongit.kde.org .git/config` ]]; then
		      sed -i -e 's:git\://anongit.kde.org:kde\::' .git/config
		      ewarn "kde git url corrected for $repo"
	   fi
	   if [[ ! -z `grep kde: .git/config` ]]; then
		      [[ -L ${KDE_REPO_DIR}${repo%/*} ]] || (ln -s ${DISTDIR}/egit-src/$repo ${KDE_REPO_DIR} && ewarn "New symlink for $repo")
	   fi
	   popd > /dev/null
done

Last but not least, we need the kde overlay, to get the live ebuilds:

layman -f -a kde

For more information on this, take a look at the Gentoo KDE Guide

Usage

With the above configuration, we can use:

emerge -av =amarok-9999
create_repolinks

and get the amarok repository in our homedir, ready to patch it. As I said, in case we modified the code and tried to re-emerge the ebuild to get our patch in action, emerge will reset our repo to master again. Thus, we need to use the following variable:

EVCS_OFFLINE=1 emerge -av1 amarok

This will prevet the reset of the repo. In case we want to use a full live environment, we can even put that var in make.conf, but it is not recommended, better to use it in single emerge runs like the above.

That’s it. I plan to write a PyKDE UI for easy installation of the scripts, and maybe write a proper techbase article for it. Any feedback is appreciated.

I’m writing a CMS for the Gentoo website, that will offer an LDAP web interface, plus it will replace Gorg and provide Beacon as WYSIWYG editor to edit the XML file

Two important things hapenned: 1) I passed the midterm (thanks to my mentor and everyone involved) 2) I graduated YEY!

I’ve left the LDAP bits behind for now (apart from bugfixing here and there). It is working fine, and supports:

• login (with any of user’s mail)
• registration (the admin can specify which OU will be used for initial user creation) (for development purposes, it can even create top O and OU in an empty LDAP server)
• map LDAP ACL to Django ACL
• view some user’s data (in settings we can specify which attrs the user himself can see, and which ones privileged users can see)
• edit own data (again, only specific attrs based on perms)
• edit other user’s data (if the logged in user has the correct permissions for that)
• An addressbook (list of users, separated in developers, exdevs, others (the lists are configurable))

I’m still working on the UI, and started messing around with Beacon. It is a very interesting project, which is getting more love again, through a Fedora GSoC project (it even started as a GSoC project). It has two backends, a PHP and a Django one. I already talked to the upstream guys, they showed me their TODO list [1]. Some of those are needed for me as well, which is very nice, since my patches can go upstream directly. I was going to write a custom script to export the generated XML output, which is one of the things Beacon itself needs as well. Another important thing is to load external files in order to edit them. Finally, the git integration I was going to implement also sounded like a nice feature. Really glad to see that we are on the same road, my plan was to not fork the project but keep the changes there as possible. Matt, my mentor, was helping Beacon with the Django part since the beginning. I plan to work on those three features for the next week (weekend included).

Apart from the above, I’m working on our XSLT and Python’s decorators to create Django templates based on our XML files.

Okupy is deployed in the server, I need a final review from my mentor and will open it to some people for testing really soon (target: this weekend).

[1] http://tinyurl.com/3g4424o

I’m writing a CMS for the Gentoo website, that will offer an LDAP web interface, plus it will replace Gorg and provide Beacon as WYSIWYG editor to edit the XML files.

This is going to be small but really important. Robin set up for me an LDAP instance in vulture for me, plus reviewed my cfengine patches for OpenLDAP, Django and the various depedencies, thanks a lot for this! I’m in the process of deploying the web application to the server, and will move development fully there. I plan to open it for a few people for more beta testing in the following week. There has also been some internal Infra discussion on whether to use multiple OUs (OU=users, OU=developers etc), without an agreement yet, but my code works either way. Also I need to expand our LDAP configs and add a few more groups there, like a user.group, and some other privileged groups like devrel, pr (currently we have only infra, recruiters and devrel I think).

As for the development of the app itself, the past days I’ve been doing various bugfixing in the LDAP frontend and playing around with the UI mostly. It is very configurable, the admin can choose which LDAP values to print, and in which form (eg human readable: username / first name / last name OR keep the LDAP names: uid / givenName / sn). The user can view his own attributes or someone else’s public attributes. A privileged user can see more attributes from other users, plus add/remove another user from some groups. There has been some ACL duplication here, but unfortunately there isn’t a better way to do it at the moment. Robin proposed another long term solution: if we move our LDAP configs to the new cn=Config style, the app then could parse that config and generate the ACL accordingly to Django settings. It can’t be done now though, since Infra needs to migrate LDAP to that style first, which I know it’s going to be painful (I’ve done it already for a uni server about a year ago). I’m working on the UI of the edit view now, which is a generated form by the user profile model. Although it works (user can edit his data successfully, admins (eg infra/recruiters in Gentoo case) can edit other users’ data as well), there has been some pain in printin nice the multivalued attributes of LDAP. Currently, the multivalued attrs are transfered to a TextField in the DB, and the values are separated with :: for easy split-desplit. With the help of Matt I wrote a form widget, but it still needs to look prettier when the user wants to add or delete a new value.

Apart from the above, I’ve also started working in general on the UI, and the front page. Matt gave me some some CSS to plug in to my templates, but my overall goal would be to create an easy way to create new themes to the app, instead of having to touch the templates (should be easy in Django). The UI and the front page is what I’m going to do for the next few days, and then start working on the Beacon and XSLT/XML parts. Last but not least, I wrote an addressbook as a replacement to userinfo.xml.