Feb 01

As discussed in the last Gentoo Qt meeting, we moved our overlay from gitorious to git.overlays.gentoo.org. This is going to be the final move, I promise :)

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!

Feb 01

1. Roll call

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.

Jan 21

1) Roll call

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.

8) 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 :)
Meeting Log can be found here
I'm going to FOSDEM, the Free and Open Source Software Developers' European Meeting
Aug 18

Come celebrate with us the new releae of the graphical interface KDE SC 4.7 on Friday, 19 August at 21:00 in Thessaloniki at Dolly’s (Map, KDE Community Wiki).

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!!!

Jul 30

Introduction

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.

Jul 28

Quick summary:

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

Jul 02

Summer in Greece! Is the weather too hot for you to code or contribute to your favorite FOSS project? Do you need some motivation and a refreshing swim? Come to our Summer Camp! The Greek openSUSE community is organizing its first openSUSE Summer Camp, in central Greece at Grand Platon Hotel at Olympiaki akti. This is is the beach of the city of Katerini. The doors will be open from the 15th to the 17th of July 2011, at the Heart of Summer!

Sounds awesome, I’ll book my tickets.

So, you’ll be there. What can you expect? Our goal is to bring FOSS communities closer and encourage people to contribute to their favorite projects. A lot of people, with little to a lot of experience can benefit from the workshops included in our program, during which we will work on things like translation, wiki usage, coding, packaging and much more, showing how to work inside a community and how to collaborate with others!

Hmmm. But I could go swimming…

There will be relaxing and swimming of course! But hey, we have a common passion, don’t we? We love what we do, we are having fun contributing to FOSS and we hate doing it alone in our rooms during Summer time. Besides coding, translating and all other ‘working stuff’ there will also be plenty of sun and beach, a large swimming pool and plenty of beers – all paid by you since we only sponsor the sun, the fun and all the other free stuff…

We are looking forward to seeing you at the openSUSE Summer Camp Greece!

Please use info@os-el.gr to contact the team organizing the event.

PS I’ll be there too, and I’ll do a Python/Django workshop. My brother will also do a workshop about Vim (everyday use plus for development). Both are going to be long and boring, the attendees are adviced to get into the sea instead.

Jun 03

1) KDE SC 4.6.80 aka 4.7 beta 1 bump

jmbsvicetto and alexxy did a great job so far about it, with ABCD forward-porting the commits to the live ebuilds. It is not ready yet though, and we’d not recommended to users yet, unless they know what they are doing. Upstream split some of the tarballs in order to follow the repos for 4.7. We were very lucky so far, and upstream’s split was very similar to ours, apart from kdebindings, which we’ll have to re-package to follow them.

2) Drop of kdeprefix useflag

The kdeprefix USE flag is announced to be dropped this Monday. As a result, we’ll have to move all ebuilds to slot 4. We could move them to 0 as well in order to drop the slotting entirely, but since most of them are already 4 it will prevent us from doing another massive slotmove.

3) Useflags in kde profile

It was decided these useflags to be added to the kde profile: declarative, dri, kipi, phonon, plasma, semantic-desktop, xcomposite, xinerama, xscreensaver

4) KDE SC 4.6.3 stabilization

First of all, dilfridge deserves congratulations for taking care the heavy job of doing the 4.6.2 stabilization, along with Qt 4.7 and a large number of other Qt and KDE applications. Keep in mind that this was a really hard job to do, since the previous stable version was 4.4.5. Things are now back in order now, with 4.6.2 fully stabilized and 4.4 completely removed (finally). 4.6.3 is the next stabilization target, to keep stable tree up to date.

*) Open floor

dilfridge said he is interested in doing some cups work, which we hope to affect KDE and desktop users in general.

We lost scarabeus, one of our top developers. Thus, we’d like to remind anyone that we always appreciate the help of new people. If you are one of the guys that already has access to the overlay, time to complete your ebuild and end quiz then!

Jun 02

Planet KDE readers: this is not a KDE GSoC project, feel free to skip it

I’ve been accepted for this year’s GSoC yey!! Many thanks to my mentor, Matthew Summers, for all the help. I’ll do a complete rewrite of the gentoo.org website using Django. The project actually consists basically of three parts: 1) create a django web frontend for our LDAP server 2) Create a django CMS replacement for the current website that will be able to read the XML files 3) Plug in the Beacon Editor, a WYSIWYG GuideXML editor, to the web app. Below is a part of my full proposal, which can be found at google-melange and has more technical information.

Currently Gentoo employs a number of websites with separate user accounts. LDAP servers are used for the developers only. Developers update their LDAP data through a perl script. Complaints about difficult handling of forgotten passwords occur frequently. A web interface around LDAP will make LDAP more user friendly, plus it can be easily extended to support non-developers, just by adding a new schema and OU (organizational unit) for them. The choice of Django was made for several reasons. It is a web framework based on Python, that is a programming language very easy to learn and maintain. A Django project is equally easy to maintain and extend. In Django parlance, the term “project” refers to a collection of pluggable, modular applications, that together form a more complex web application, the project. This modularity will let the Gentoo Community easily write new Django applications on top of the main instance, in order to enhance its features. Apart from the above, the Django and Python upstream communities are doing a great job, notably by releasing often, especially for security reasons.

Today, documentation is stored in XML files in a CVS repository. An XML to HTML converter (wrapped up with Ruby), called Gorg, is currently used to display the actual result. People who want to contribute to documentation or translations have to locally install a Gorg instance and check out the CVS repository, which can be rather cumbersome. Having a WYSIWYG editor embedded in the gentoo.org website would be preferred, as it will make it really easy to contribute to documentation, or even send improvements through bugzilla to the appropriate documentation or translation team. By all appearances Gorg has been abandoned as a project. This has resulted in difficulty in maintaining the Gentoo website, and also makes the work of updating the website’s design or functionality all the more troublesome. Therefore, a complete redesign is easier than resurrecting the old system. The overall end result of the new system will be a complete rewrite of the old Gentoo website, including everything under www.gentoo.org

  • A new user registration system, that will import the data in the LDAP server.
  • A System Admin, with support of different group permissions, based on the current LDAP ACL, e.g. recruiters, sysadmins, documentation moderators, Gentoo developers, users. For more strict LDAP related operations, the Django Admin will be used, as it will be better especially for following the LDAP ACL. The Django Admin will be used mainly by privileged users, like Infra and Recruiters. Anyone else will be able to view and edit his data through his account profile page and a custom made System Admin. There will be no required data for users apart from a primary email address and a nickname/password.
  • A syndicator-like frontpage, that will display recent GLSAs, planet posts, PR team’s news.
  • A continuous integration testing model. There will be automated regression testing, by using Portage to build and test the package on a regular basis.
  • Support for viewing XML documents.
  • Beacon, a WYSIWYG editor, for easily editing those XML documents.
  • Git backend support for storing the XML files, using a dummy Git account.
  • An easy to translate interface. Translators will be able to select a document and translate it using Beacon.
  • Statistics for translators.
  • A “send for review” button, so that end users will be able to file a bug to Gentoo Documentation team attaching the XML diff. It needs a custom pybugz script to file the bug. The same system will be used for translations.
  • A new improved look, using JavaScript/jQuery. On this area, there will be strict adherence to web standards and accessibility best practices, since the Gentoo website and Documentation pages are being viewed by too many people every day.
  • An improved devmap, where developers will be able to click their position on the map.

The name I chose is okupy (you know, k instead of c, and py because it is a python app :P ) Well, it is not related to KDE, but I am :) Not to mention the new fashion in KDE apps not having K-names. I’m bringing a new fashion to the world, non-KDE apps with K-names.

Robin Johnson, the Gentoo Infra lead, will co-mentor me on the LDAP specific parts. Matt will be my guide for the django parts. The idea of this project was mine, inspired by both my Django/LDAP thesis project and the identity.kde.org work. I came in touch with the KDE sysadmins as well, and especially Ben Cooksley, who’s been great help so far and gave me lots of ideas already based on his experience maintaining the identity website. I’d be really happy to provide a Django LDAP that could suit both my favorite projects. I created a gsoc tag, where I’ll be posting weekly updates in Planet Gentoo, and the gentoo-soc mailing list. That’s it, time to get back to work.

Apr 01

The KDE meeting had the usual monthly meeting yesterday. After a long discussion we decided to switch to add Trinity ebuilds finally in tree. There has been a lot of time we were working on those ebuilds, we consider them mature enough now for end users. Since we lack the manpower to provide support for two DE’s, we will have to move KDE 4 ebuilds in a user-maintained overlay, called kde4-sunset. A Gentoo KDE 4 team may suffice of course, but until that happens, we are obliged by our QA team’s policy to remove any non-maintained / obsolete ebuilds away from our users, especially for security reasons. The following actions will take place in the following days:

  • Add Trinity ebuilds in tree
  • Create a portage news announcement and front page announcement, making their removal official and 
  • Mask KDE 4 ebuilds for removal in 30 days
  • Create the kde4-sunset overlay
  • Move KDE 4 ebuilds in that overlay
  • Call again for help (blog posts, forums etc)
The Trinity project is a very promising project, since it is built on top of KDE 3, the only working KDE version. We wish the KDE 4 developers all the best on their effort, and we hope that other distros will follow our steps.