A picture is one thousand words!!!



Excuse the picture low quality but the camera ran out of battery immediately after! I promise I'll take more picture tomorrow! :)

Stay tuned!

So, all udebs were available in the debian-ports server, so I decided to run the d-i image build process. It all worked fine, until there was a segfault by mklibs.

What's mklibs? It's basically a script that does a similar job of ldd and creates a minimal list of shared libs for the d-i image.

I found -and eventually fixed- a bug in mklibs-readelf, which caused it to segfault -I actually find it strange that this bug wasn't found before, as I could also reproduce it on amd64 and Ubuntu armel. Anyways, patch send and I'm now proceeding with the rest of the d-i build process.

More later.

I decided to give java a rest for a while and tackle something more important to actually get the port established: the Debian Installer.

I've done a few patches to some d-i udebs (#604688 and 605013 to build for armhf, but I was missing the kernel udebs to actually attempt to build d-i. And I was waiting for a recent kernel (>2.6.32 or better, 2.6.35) to build the proper kernel udebs. But this was waiting a long time and it was about time to have an installer for armhf so that people can actually play with it on the EfikaMX and use it themselves.

So, I got Matt's latest efikasb kernel (2.6.31.14.12 from gitorius), I build the image, using a patched kernel-package -this patch will soon go to a proper bug report) and then used that to an again patched linux-kernel-di-armhf-2.6 (a modified version of linux-kernel-di-armel-2.6) which will also be uploaded soon, and which builds the actual kernel udebs. So, not to leave you waiting, here they are:



Note that this is for efikasb (the smartbook), this is because there are two kernels flavours, efikasb/efikamx, the entries are going to be very similar, but for now I'll do the testing on the smartbook.

Next step is to put them in the repository and create the d-i actual image. This will need also some patches -I have most of those in d-i, but it's likely it will need some more tinkering as I haven't actually tested booting from the resulting images. It's most likely I'll have to add extra code in there to create the uImages/uInitrds -like it's done in flash-kernel- and perhaps prepare an SD card image from there. If all goes well, I hope to have a test image tomorrow :)

Stay tuned!

Slow progress as I'm stuck with a java problem. gcj-4.4 is now built for armhf, but it also depends on ecj-gcj, which I also built and uploaded but apparently there is a bug somewhere and java interpreter does not work properly -and neither does the compiler, as gcj now uses the ecj compiler (which is used on eclipse). If you see the build-attempted packages, most of those are java-related or include some java compilation there, and since those fail, we can't proceed to build the remaining 200 remaining java packages for armhf.

Working on a bug fix, stay tuned.

PS. I'm also doing a cross-compilation of gnat-4.4 which should be finished in a couple of days.

Well, it's done, armhf is self-contained in debian-ports.org only, no reason to keep freevec.org repository anymore in your apt/sources.list!

We hit 85% and are closing the other ports. We still have some trouble with gcj -the package is built, gcj works but gij+ecj fails to run any java binaries. This explains the java package failures we see in the architecture status.

On the other hand, ruby1.8/1.9 are built and so is most of kde4 now -some packages still building but the majority is there. Major missing packages are openjdk (~90 packages wait on it), and ghc6 (~200 packages waiting) and r-base (~140 packages waiting).

Work on d-i progresses, still lots of build failures, but we'll get there eventually.

Stay tuned.

After some delays with some packages (boost, gcj, ruby, etc), which stalled the port, I managed to get some of those fixed. In fact, all those three were fixed and uploaded, which means ~300 packages are in the process of being unlocked for the autobuilders.

What's more, those packages are the last in the freevec.org repository. Once all of them are uploaded (ruby1.9 in the build queue at the time of writing, subversion and aptitude are next in line), the freevec.org repo will be obsoleted and the port can be self-contained in debian-ports.org!

This means that debootstrap can work out of the box without special tricks to use 2 repos (or use multistrap)!

I'm also half-done with debian-installer, I believe I'll have an image to test by the end of the month.

Stay tuned.

It's been a few days since I have returned from my trip to Linaro@UDS conference at Orlando and from San Antonio where I visited the Genesi USA headquarters, I think it's high time that I blogged about the visits and more importantly the results!

Linaro@UDS

So, initially the reason for my invitation to the UDS conference was exactly the debian-armhf port, and in particular sharing my experience in building an arm hardfloat port, what are the problems in the process, what's the gain, etc.

I attended many talks mostly about Linaro/ARM but also about codecs/NEON and Qt.
UDS 'talks' depart a lot from the traditional powerpoint presentation, in that it's mostly a discussion and a set of decisions regarding the tasks one or more particular teams have to complete in the next 6 months (that is, until the next UDS event). Of course there is always the danger of having the discussion travel elsewhere and waste time on, but it didn't happen on most talks I had the pleasure of attending. All in all, it was a very productive experience. You can see the list of talks in this link:

http://summit.ubuntu.com/uds-n/

On my last day I initiated a discussion myself:

https://blueprints.edge.launchpad.net/ubuntu/+spec/hardware-linaro-n-arm-hard-float

and a wiki page:

https://wiki.linaro.org/Linaro-arm-hardfloat

After the event it took only a few days to get the proceedings online:

https://wiki.ubuntu.com/UDSProceedings/N/

(the results of the hardfloat discussion is the last entry in the 'Hardware' trait).

Suffice to say, we'll be tracking Linaro progress very closely, and it's very likely that our presence in the next Linaro conference (May 2010 in Budapest!) will be bigger -let's get the whole Genesi team there!

Genesi presence at UDS

Of course we could not let this opportunity go past just like that! I had contacted the Linaro guys if they would like some Smartbooks to be given to specific developers during the conference and they sent me a list of 15. Bill then sent me those to give away in the first day even -actually they were given right after the first Linaro roundtable talk :).

The response and the interest was huge! You could see all those developers drool over those sexy smartbooks -I know I was too! After the 15 were given away, there was a queue of ~40-45 people waiting to add their names on the list!

Anyway, given Genesi's past record of supporting developers, let's assume that it was an fast decision and in just 3 days -Thursday- there were ~40 more developers with Smartbooks and some Smarttops even! You can see the happiness on their faces on the picture I sent to Bill for his blog!!!



After UDS, at San Antonio

Right after UDS, I took a flight to San Antonio (via Houston) and met again with Raquel, Bill and Matt -after 6 years, no less! Last time we met in person was in SNDF 2004 in Frankfurt!

San Antonio is beautiful -I didn't see much of it, but from what I saw I loved it! Esp. the River Walk and the mexican restaurant were awesome (thanks to Maurizio and his wife for taking us there!). Business wise, there were some very interesting discussions -which I cannot talk about yet!- and some very very nice interesting new prototype hardware -which again I cannot talk about yet! :)

I did not do much coding apart the fact that I got one of the long standing problems in my TO2-based debian-armhf compile-farm fixed. Basically, TO2 is problematic with some thumb2 code, which is used on armhf, and as a symptom I was experiencing segfaults/stalls with cc1plus or even complete machine lockups on the buildds, in a totally non-deterministic fashion. This slowed down the buildds, but thankfully with new binutils -from experimental- and new debian gcc 4.4.5 which includes all the Linaro gcc patches, the problem was fixed (for those interested it's the --fix-cortexa8 option on ld).

All in all it was a very interesting experience, I'm positive that many good things will come out of that!

Debian-armhf port's progress report

Well, as mentioned above the cc1plus problem was fixed and the buildds are happily compiling all the time, we've just hit ~7100 packages (~82% of the archive) and it's increasing all the time!

There are some important packages left to fix yet like ghc6, boost1.42, gcj-4.4 (and from that bootstrap openjdk) and a few more, you can check the actual progress here:

http://buildd.debian-ports.org/status/architecture.php?a=armhf&suite=unstable

and the wiki page shows a very very nice graph (armhf is the green line, that's fast, right?):



Well, that's about it for now, I'll post more news as they come :)