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 🙂