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 🙂


9 thoughts on “ARM for Kubuntu and KDE

  1. Is there any reason you can’t corss-compile on a coupe of PCs instead of the Efikas ?
    That would have been my first thought with this kind of build time.

  2. Do I understand it correct:
    You don’t cross-compile? You compile on the target?
    What’s the reason?
    Compiling on the target takes ages (or at least half a day 😉

    • It is much cooler this way, is it not? With multiple machines compiling also does not take incredibly long.

      One of the more sensible reasons is that developers do not have to setup a xcompile environment. Also it allows for runtime testing, which is rather important from a portation POV and one of the primary use cases.

  3. Hi,

    I’m a developer at OLPC. You may or may not know that the latest version of our machine (XO 1.75) is an ARM based around the Marvell Armada 610. We have our A1 prototypes up and running.

    I’m a KDE user and this post caught my eye. OLPC bases our stack on gtk and gnome but I’d love to see KDE up an going on the XO 1.75. In the process of development I end up with a lot of machines that aren’t otherwise distributable due to small hardware bugs or a functional change in the hardware. Most of these machines would work fine in a build farm or as a machine to build packages on.

    Right now there are only a small number of machines in existence but early next year we will be building more for our A2 prototype.

    We already run a small build setup for building fedora packages on and I’ll be happy to help extend that to KDE. Send me some email if you are interested.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s