ARM for Kubuntu and KDE

Recently the Kubuntu developers received a donation of some terrific Genesi Efika MX devices featuring an ARM CPU.

Some of them will be devoted to Kubuntu related porting work with regards to the ARM CPU, and others to continuously test build KDE trunk. Getting a KDE buildbot for ARM is very important because most KDE developers do not have access to an ARM device (or they would not want to test building their software on it, because it would be tediously slow), so we try our best to provide KDE the means to get notified about changes that are not compatible with the ARM architecture, so that it can be fixed.

This is also very important to Kubuntu, since we have a great interest in providing the Kubuntu KDE experience also on ARM devices (such as netbooks or mobile phones), yet we have to spend a vast amount of time each development cycle on resolving ARM specific build issues in KDE software, and all of these fixes could have been done in the KDE source base right away, if only the issues had been known before the release. With an ARM buildbot we can easily hunt down build issues before KDE release a new version and thus make KDE software itself more compatible with ARM and reduce the amount of patches we need to carry in Kubuntu.

Now, since builds on ARM are usually not of the fastest kind and we want to make the most out of the available resources, Scott Kitterman (who kindly provides hosting) and yours truly worked on improving resource usage.

First off. How long do you think it takes to build Qt on one Genesi Efika MX?

— About a day! —

So we started to hook the machines up with each other, sharing CPU resources through distributed compiling using the excellent Icecream software (thanks to our dear colleagues at openSUSE). Here is what we have learned so far…

Somebody who knows a thing or two about Ubuntu development, probably has heard about pbuilder. It is a tool that makes it fairly trivial to test build software in a clean chroot setup. Suffice to say the building on our ARM boxes is also executed using pbuilder. This however caused a bit of a problem with regards to distributed compiling. While Icecream takes perfect care of distributing the stuff that needs compiling along with files that are needed to make that happen, it does not distribute the tool chain itself (most importantly the compiler). Distributing the tool chain along with the build jobs is however crucial to the reliability of the test build (e.g. to find issues in a particular GCC version of Ubuntu). Fortunately enough Icecream also got a solution for that. You just need to pack a tar of the tool chain (or let icecc –build-native handle it) and export the resulting tarball as ICECC_VERSION to the environment. Then Icecream on every cluster node will only use this toolchain for building. truly awesome.

Though, I am a bit lazy and taring the tool chain every time I want to build something is not very practical. Hence I improved the Kubuntu certified pbuilder hooks to support aforementioned use case by exporting the tool chain.

Those of you who are using pbuilder and have not yet checked out the pbuilder hooks, I highly recommend you to do so. They are going to make your life much easier 🙂

Finally. How long do you think it takes to build Qt on three Genesi Efika MX?

— Half a day! —

Quite an improvement, huh? I still see ways to improve this, especially for the upcoming KDE trunk builds.

In related news: Since I got asked when Kubuntu will be able to run on the N900.
Our current target is to have Kubuntu Mobile working on the N900 in time for the 11.04 release. A truely amazing team is working on this, so I am reasonable confident this is going to happen.

Stay friendly 🙂

Qt Graphics System KCM

Long we have waited for it. A way to set the Qt graphics system backend without recompiling Qt. In Qt 4.7 this is finally available.

You can configure the backend using the environment variable QT_GRAPHICSSYSTEM.

Now, since the topic of switching graphics backend in Qt is coming up now and then, I thought it would be a good idea to create a nice graphical interface. Actually I wanted something nicer to use for me personally 😛

So I created a really simple KCM. You have 3 switches, of which two will write a .sh file to $HOME/.kde/env/. The content of this folder gets loaded at startup (via startkde), and that way you will globally end up with another graphics backend. That said, since the environment variable has lowest priority, it is still possible to override this on a per-application level (e.g. kolourpaint has problems with the raster backend I have been told).

Have fun!

Project Neon – Ask Harald (FAQ)

Note to me, myself and I: FAQs should be listed somewhere to save me the daily headache….

Is amarok-nightly for openSUSE published yet?
No, I’ll try to get a repository outside of my personal home one and build for openSUSE 11.0, after a couple of tests amarok-nightly for openSUSE can go live.

Why is there no amarok-nightly for openSUSE 11.0 to be tested?
Because I am preparing for exams, so I have no time for build-dependency magic, and because I will only build for openSUSE 11.0 once the above stated reason is sorted out. However, apparently the 10.3 packages work just fine on 11.0 as well (hooray for good packagin 😉

Why is amarok-nightly for openSUSE not built nightly?
No neon package gets built nightly as long as it is being tested. Nightly builds will start once openSUSE packages are published in an own repository.

Does kde-nightly for Kubuntu include debug symbols?
No, neither does amarok-nightly. The packages are built with debugging enabled, a packaging script however strips them for some reason I forgot. In fact I tried adding -dbg packages earlier on, but that didn’t work for some strange reason. The good news however is: I will digg into this soonish. After all a good description on how to reproduce is almost as good as a good backtrace 😉

Can we get a foobar package for kde-nightly?
Feel free to drop ideas at the mailing list, but keep in mind that the build resources on Launchpad are pretty limited, so kdepim or koffice are probably not going to get in… at least for now. In general the current amount of packages is not going to grow a lot – I might only add kdeplasmoids some time soon, but that’s about it.

Do you plan to integrate more applications into kde-nightly?
See above.

How do I compile stuff against kde-nightly?
This is a bit tricky – you can take a look at the neonmake script in amarok-nightly-tools to get an idea. I will include some proper buildscripts later on for use with kde-nightly and amarok-nightly.

Why is there no kde-nightly for openSUSE?
The openSUSE KDE guys do a great job on maintaining their own KDE snapshot packages. So launching a kde-nightly stack would be rather pointless, right? Duplicated effort and all..