i.MX515 Project
Kubuntu Desktop/Netbook/Mobile Armel Porting Supportin category Linux Distributions
proposed by kitterma on 20th September 2010 (accepted on 26th September 2010)
Project Summary
The Kubuntu project has been leading the way for KDE to move to smaller platforms. In 2009 we produced the first distro release of Plasma Netbook (it was a technical preview release) and followed it up with a production release in April 2010. We are about to do the same with a technical preview release of "Kubuntu Mobile" similarly featuring Plasma Mobile.Unfortunately, while packages are built on the Ubuntu build farm for armel, community developers have no access to hardware to work on correcting porting issues or optimizing for specific armel platforms. Additionally, as distribution packagers, we often suffer from late detection of programming errors introduced during upstream by developers who are not familiar with armel.
Even with only indirect access to hardware, Kubuntu developers have managed (with support from Canonical employees, when available) to produce at least minimally functioning armel images the last two release cycles. In order to take this to the next level, it would be extremely helpful to have direct hardware access.
This resource would be managed through Kubuntu's existing community leadership team, the Kubuntu Council.
We would like to request 5 machines (two general porter, one upstream KDE porter, one installer porter, one upstream buildbot)
The general porter machines would be used by community developers to resolve general armel porting issues. The upstream KDE porter box would be used to focus on KDE specific performance improvement on armel. The installer porter box would be used to support armel specific small form factor system installer work. The upstream buildbot would be used to build KDE trunk to enable armel porting errors to be detected earlier in the development cycle (KDE has expressed interest in this service, but to date, no resources are available for this).
Project Blog Entries
The router that was in front of the Efika boxes died and had to be replaced. The new one is up and configured, so the systems are accessible again.
Soon I hope to convert them to Debian armhf.
We've been regularly building kdelibs from trunk for about a week now and are expanding coverage to other core KDE SC modules. It won't be long until we're building all of KDE trunk (what will eventually be KDE 4.7).
http://my.cdash.org/viewSite.php?siteid=2793
I've made some local improvements to the KDE nightly build scripts that I'll start contributing back upstream as well.
Once we got a GCC that would build Qt/KDE packages we got the whole KDE SC release ported and built in record time thanks to hardware access from this project.
http://skitterman.wordpress.com/2010/12/14/current-kde-sc-development-release-built-on-armel/
http://apachelog.wordpress.com/2010/11/21/arm-for-kubuntu-and-kde
Yesterday was the first day on this part of the project. Box score for the day isn't horrible:
kdelibs: Succeeded after 8 hours, 4 minutes, and 29 seconds.
kdemultimedia: Succeeded after 42 minutes, and 57 seconds.
kdegames: Succeeded after 2 hours, 56 minutes, and 16 seconds.
Unfortunately kdelibs needs rebuilding with Soprano. kdepimlibs requires Nepomuk support, so this has to be compiled into kdelibs.
Today, got the rest of kdesupport updated (kdebuild-src doesn't seem to handle the case of kdesupport elements that have moved to Git already, but that may just be my unfamiliarity with the tool). With that done, kdelibs is building again and kdepimlibs is next up. The dependency relationships between the different KDE SC modules is comples. It's charted (current for KDE 4.5) here: https://wiki.kubuntu.org/Kubuntu/Ninjas/DependencyGraph.
Now I know. Building Qt 4 takes ~23.5 hours with one box. Less than 12 with three using http://en.opensuse.org/Icecream.
Currently working on test Qt builds using three networked smarttops sharing the build effort using icecc. If I could get it to finish, I'd let you know how much faster this is....
Progress continues - https://launchpad.net/ubuntu/+source/akonadi/1.4.1-0ubuntu2/+build/2026254
Thanks to access to this hardware we are well ahead of previous releases in getting arm well supported.
We are up and running and have our first porting fix in the Natty development archive: https://launchpad.net/ubuntu/+source/phonon/4:4.7.0really4.4.2-1ubuntu2/+build/2020221