armhf port, repo and simple image available
After a LOT of compiling and patching around, I have a armhf repo ready 
and a simple tarball from debootstrap in case one wants to try the stuff .
In short, I have ~3000 packages built at the time of writing this, and more
are building as we speak. Though it will not cover (yet) a full gui, it does
have most gnome libs, X.org, metacity, qt3/4, emacs23, vim, and of course most
stuff one would need for compiling *except* java-related packages and binutils
(see below). I still haven't managed to build gcj and I don't think I can
bootstrap openjdk another way. Mono seems to build though
Also, there is a list of packages I had to modify to work with armv7/thumb.
Some I was lucky enough to find fixes elsewhere -eg. Ubuntu has already fixed
many packages and I just adopted the patches found on Launchpad- and others I
had to fix on my own, but nothing fancy. Here's a list of packages modified -
in ~3000 packages the list is surprising small:
* dpkg: I added support for quads, internally it will always use quads, but it
works normally with current triplets -eg. arm-linux-gnueabi- right now. Patch
* gcc-4.4: added linaro hardfp patches -plus some to fix some problems, and
more coming along the way, Linaro folks sure are busy :)
* eglibc: added armhf support, really small patch
* libmad: incorporated armv7 patches found on Ubuntu LP: #513734, #534287
* oprofile: incorporated armv7 patches found on Ubuntu LP: #591862
* mysql-5.1: incorporated gcc fix as it FTBFS on newer compilers (4.5 also has
this bug, so this in fact has to be fixed when Debian moves to 4.5). LP:
#579909, this probably is the only patch that's not relevant to armhf.
* qt4-x11: incorporated qt4 arm thumb patch as found in #490371 and modified
rules file to build with -arch armv6 for armhf.
* openssl: added a line for armhf in debian-targets.patch (clone of armel line
* qca2: Follow Ubuntu and disable libqca2-dbg as it makes the package FTBFS
And for those package I just had to add an armhf entry in Architecture field
(or modify build-deps restrictions to add armhf as well)
* python2.5, python2.6, python3.1 (well I just disabled testing for armhf like
Also, I had to fix the following packages and add d-shlibdeps overrides as ld-
linux3-dev doesn't resolve on armel (and not on armhf as well):
Sources to these packages will be also uploaded soon on the same repository.
There are a few things left to do yet:
1. binutils, I'm using the ubuntu package right now as the debian one doesn't
yet compile, I guess I'll need some CodeSourcery arm hardfp backports to make
it work. This is the only important package missing right now -well, you won't
be able to build stuff without it :-/
2. gcj-4.4, same, it fails to build
3. libtheora, well that's a known issue in gcc LP: #605255, I'm rebuilding gcc
today probably and I'll retry again
4. ffmpeg, also seems to break on some fPIC stuff, I'll check it again later.
This means that I can't get xine-lib to build properly, and hence, gst-
plugins-base, and so phonon, kdelibs5, python-qt4 all wait on ffmpeg :)
5. python-twisted-core, well this one builds ok, but it hangs on install
always, no idea why. foolscap and apt-xapian-index depend on it. Also ipython
depends on these and from there matplotlib and python-numpy (I had to build it
without matplotlib support to satisfy dependencies and move on).
6. jinja2, it FTBFS, some weird python error, I'll definitely need help here
as I don't speak python. This is a problem as it's required by a ton of other
python packages -incl. sphinx.
7. ruby1.8/1.9. These have a buggy arch_name detection (well buggy in that
they didn't expect quads), the binaries build fine, but package fails on
movefiles due to it expecting dirs named "arm-linux-eabi" (it actually
replaces linux-gnu with linux, so I guess even the -eabi part is superfluous).
8. subversion is built without kde support for that reason, I had to build it
as it is to satisfy git's build-deps, which gettext depends upon. I'll do a
full rebuild when kdelibs5 is built.
9. elinks build breaks with this error: http://paste.debian.net/82207/
I can't build aptitude without elinks, so if anyone has an idea about that I'd
10. gpgme also fails to build: http://paste.debian.net/82206/
11. klibc: I modified the source to tune for armv7-a but it still fails to
build: http://paste.debian.net/82212/ (which as I found, used to occur with
klibc in ubuntu, LP: #534281). This probably has to do with my older version
of linux-libc-dev however, so I won't worry about it much until I upgrade to a
12. isc-dhcp fails to build, I didn't patch it at all but it fails with this
13. libproxy was built without kdelibs5 as libsoup depended on it. I'll do a
full rebuild soon.
14. linux-libc-dev is not available as I haven't worked on kernel builds yet.
When needed I used the ubuntu version I already had on the system before
(karmic 2.6.31-21.59, should work for most stuff except for the klibc
I'd greatly appreciate any help on these issues, there are some I have no idea
how to solve them. I might have forgotten some packages here in the list, if I
find something else, I'll post another mail.
Now, is there anything else I need to do before I start sending bug
reports/patches about all these packages with support for armhf -or even more
intrusive, the quad support in dpkg? Especially without the dpkg patch, the
armhf port is useless -ie. dpkg doesn't recognize the architecture. So, if
things are to proceed with the port, Debian DPKG maintainers actually have to
accept the patch -well, the essence of it, if they don't like the way I do
things, and I try to be as least intrusive as possible, they can do it another
way, or just dump my patch altogether and do it themselves, the important
thing is that we _need_ quad support in dpkg. But I think I did an adequate
job, patch available .
Thanks to Hector Oron and Loic Minier for their help these days. Still, it's
not over yet, we're just at a point where we're ready to setup a buildd using
the w-b on debian-ports (<cough>Aurelien?</cough>) :)
 deb http://freevec.org/repository main
(no kernel or modules, but works fine in a chroot).
(I've left the print debugging statements for help, feel free to remove them).