PhD report submitted

Some of you may have noticed that I was mostly unavailable those last weeks. I was finishing writing my PhD report. It is now submitted, so I have more free time again.

I am currently processing the backlog. If you are waiting for an action from my side, you should get some news in the next few days.

MAC address strangeness

Today I upgraded my BIOS in the hope to solve various issues. When I rebooted the machine, it didn’t get an IP address through DHCP: the Ethernet MAC address has been changed by the BIOS upgrade.

Now compare the old and the new Ethernet MAC addresses:

old address: 0:1a:4d:60:72:e0
new address: e0:72:60:4d:1a:0

Time to laugh…

New GNU/kFreeBSD build daemon

We now have a second GNU/kFreeBSD build daemon building the kfreebsd-amd64 architecture. It has been kindly offered and is hosted in UK by The Positive Internet Company Ltd.

It adds redundancy to our buildd network, which is important given that the other kfreebsd-amd64 build daemon machine is on a simple ADSL line, and so less reliable than a machine in a datacenter.

For those who want to know more, here is the current status of the GNU/kFreeBSD buildd network:

  • (kfreebsd-amd64)
    2 x Opteron 1.4GHZ, 1GB RAM
    Hosted by The Positive Internet Company
  • (kfreebsd-amd64)
    Sempron 2600+, 1GB RAM
    Hosted by Aurelien Jarno (ADSL)
  • (kfreebsd-i386)
    PIII 800 MHz, 512MB RAM
    Hosted by ETH Zürich
  • (kfreebsd-i386)
    Sempron 2600+, 1GB RAM
    Hosted by Aurelien Jarno (ADSL)

My goal is to eventually get rid of all build daemons that I am hosting at home on my ADSL line, though that is less critical now.

ARM code of the day

ldmeqib r9!, {r1, r8, ip}^
ldclsl 3, cr14, [r4, #-364]!
stmleda r1, {r0, r2, r6, r7, r9, sl, ip, lr}^
cmppl r6, #12582912

This program does not work, but it still has a meaning.

Hint: Each instruction is 32-bit long, the total length is 128 bits.

New ARM autobuilders

I am really upset by the way the ARM build daemons are managed. The packages are not uploaded regularly, with sometimes three days between two uploads. Well it should not be a problem, if packages that have failed to build due to some packages not uploaded fast enough (see for example python-gnome, or rkward) were requeued, but that’s actually not the case. Also last week, the build daemon named “cats” stopped to upload packages, despite it continued to build them. 11 days later, nothing has changed even after a mail to And I do not speak about build daemons building nothing.

All of that resulted in ARM being the slowest architecture to build packages. It looks like the ARM build daemon maintainer does not know the excellent page made by Jeroen.

As is everything but responsive (well if you can assign a level of responsiveness to /dev/null), I have decided to act. I have installed QEMU on an 8-way Opteron machine, and created 8 emulated ARM machines, which 256MB of RAM and 10GB of disk for each, all running buildd + sbuild. Altogether those 8 emulated ARM machines should be faster than all the Debian ARM build daemons. I have setup a wanna-build database on my server. During the day it has built around 100 packages.

Yes I agree that real machines would be better, but I don’t have a stack of fast ARM machines at home. Anyway when you see random segfaults on the build daemons, or strange failures (that happen for weeks) on the build daemon named “netwinder“, you may think to that again.

Unfortunately the machine I use for that is only available for a few months, and I will have to stop the emulated machine then. I just hope that the situation with respect to the build daemons will improve, so that I can stop them even before.

Cheap MIPS/MIPSEL development machine

In addition to the ARM platform, it is now possible to emulate a MIPS (big endian) or MIPSEL (little endian) machine running Debian under QEMU. It could be used as a cheap MIPS/MIPSEL development machine to test your packages, provided that you have a not to slow i386, AMD64 or PowerPC computer.

Running on an Athlon 64 X2 3800+ the emulated system is around 10% faster than my SGI Indy R4400SC 200MHz and possibly with much more RAM (my emulated system has 512 MB of RAM). Also for the ones who know about the Indy SCSI controller, the transfer rate is around 13 MB/s on the emulated system.

I have written a small howto explaining how to install Debian Etch on such an emulated MIPS or MIPSEL machine, using Debian-Installer RC1, which has just been released.

Thanks to Daniel Jacobowitz who has recently improved QEMU/MIPS a lot, and to Thiemo Seufer who has started the integration of the MIPS QEMU platform in Debian-Installer and in the Debian kernel.

Note 1: I have written this howto very quickly, so there are probably some mistakes. Comments are welcome.
Note 2: I have updated the ARM howto to take in account improvements from Debian-Installer RC1

Experimental is not autobuilt (at least for glibc)

Martin, I can’t let you say that experimental is autobuilt. I have uploaded a few versions of the glibc to experimental in the last few months and only arm, hppa and alpha have tried to build them. Before the summer mips and mipsel also have tried to build the experimental glibc. And the last version has not been tried on alpha, despite the fact it includes a fix and should now build correctly on this architecture.

Hopefully I have most Debian architectures at home, but alpha, m68k and ia64, so I can build the glibc on my own machines. For m68k and ia64, I can use machines. Concerning alpha, the debian porting machine, ie, is locked down since the compromise about 4 months ago. And no answer to my mail to debian-admin… Hopefully a user kindly gave me an access on his machine, thanks. The glibc 2.5 is now building correctly on this machine, but I can’t upload the package because I can’t trust the machine. That really sucks.

What about removing alpha from the release architectures? After all, it fails to comply with the etch candidate release architecture criteria for months.

Update: Some build daemons had glibc in “weak-no-autobuild”. Thanks Martin for fixing that.

Cheap ARM development machine

You want a cheap ARM development machine to test your packages? You can actually have one for free (both as in beer and as in speach :)) provided that you have a not to slow i386, AMD64 or PowerPC computer. The solution is called QEMU, a generic and open source processor emulator which can emulate i386, x86_64, ARM, MIPS, PowerPC and Sparc systems.

Running an Athlon 64 3800+ the emulated system is around 20% faster than the popular NSLU2 and possibly with much more RAM (my emulated system has 256 MB of RAM).

I have written a small howto explaining how to install Debian Etch on such an emulated ARM machine.

Note: I have written this howto very quickly, so there are probably some mistakes. Comments are welcome.

How Ubuntu is slowing down Debian

Today in bug report #369411:

“I do oppose an NMU as you haven’t actually explained why this patch is
necessary. Ubuntu doesn’t have this patch and yet has been building
32-bit alsa for several releases without problems.”

While Ubuntu has this patch included for 3 weeks now. I have written this patch to fix an RC bug in Debian…

kfreebsd-amd64 build daemon

Yesterday I have setup a kfreebsd-amd64 (ie GNU/kFreeBSD on an amd64 CPU) build daemon. Its name is (all my machines are named related to electronics), and it has Sempron 2600+ CPU.

As you can see on the photo, it is still missing a decent case. There are actually two machines on the the photo, the motherboard in the case is maxwell’s one (one of the kfreebsd-i386 build daemon), while the one on the top front is shockley’s one. That’s a bit strange, but the amd64 motherboard needs a power supply with a P4 connector, while the other one only needs a small power supply.

Thanks to Ingo Juergensmann, the kfreebsd-amd64 architecture is now listed on As you can see on the graph, this machine is very fast (it only runs for 24 hours!).

GNU/kFreeBSD build daemons : maxwell (i386) and shockley (amd64)

GNU/kFreeBSD on

Thanks to Ingo Juergensmann, the kfreebsd-i386 architecture is now listed on That means that Debian developers can now easily check the state of their packages, and if they fail to build, to find why.

The requirement to appear on was to use wanna-build and make its output available somewhere on the web. As I was still using a set of (very) ugly shells scripts to handle the build-daemon, I spent a part of the last days to setup wanna-build, and to understand how it works. With wanna-build a lot of thing is automatic, and almost everything could be controled via the mail interface. That would save me some time that I could invest in porting packages to GNU/kFreeBSD.