Aurelien’s weblog

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:

• callisto.debian.net (kfreebsd-amd64)
  2 x Opteron 1.4GHZ, 1GB RAM
  Hosted by The Positive Internet Company
• shockley.aurel32.net (kfreebsd-amd64)
  Sempron 2600+, 1GB RAM
  Hosted by Aurelien Jarno (ADSL)
• hagrid.debian.net (kfreebsd-i386)
  PIII 800 MHz, 512MB RAM
  Hosted by ETH Zürich
• maxwell.aurel32.net (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.

Christian, this is the percentage of your blog entries concerning translation ratios in the last two weeks.

I am sure you can do better

The NEW queue is almost empty with 7 packages only. Thanks a lot Joerg.

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…

As others I am very unhappy with the outcome of the release meeting. This “proposal” has been made by people that have key responsabilities in Debian, and without asking other people, except the DPL candidates. By the way, I feel silly that such persons sign this “proposal” as DPL candidates, whatever is their opinion.

In short the proposal says: “We’ve got problems to release with 11 architectures, let’s drop 8 of them.” A lot of users who choose Debian because it was the only distribution out of there to provide serious support for the architectures they care for, for various reasons. That’s the end of the Universal OS, and that’s sad.

It’s seems that the actual teams found they are overloaded, so as they don’t want to share their powers and call for help (even worse, they refuse help), they prefer to drop architectures.

The criteria given to keep architectures seems to have been choosen after the list of architectures itself. And actually none of the architectures in Debian fulfill them (all the four proposed architectures, i.e. i386, ppc, amd64 and ia64, only have one build daemon). And when you ask the technical point behind each criterion, nobody answers…

I don’t say there isn’t any problems, but there is a difference between a reasonable answer to these problems, and dropping most of architectures we support. If they are problems with build daemons, the solution is to solve them (hint: more build daemons and more admins would be a good start).

But actually I doubt the number of architectures is the real problem for Sarge. One of the main problems since August (at least that is what is announced in every “Bits from the release manager”), is the testing build daemons. Why it lasts so long? Why offers for help have been refused?

And don’t forget the social contract: “Our priorities are our users and free software”

I have just uploaded a new version of simulpic. This software is a simulator for Microchip PIC16F84 microcontrollers. The initial version was a student project of the University of Pisa, and the development has stopped 8 years ago. Well, not really stopped as they were some patches in the Debian package.

Recently, a new upstream has decided to continue this project and to add some functionalities. He has just released a new version, the first one for more than 8 years! That demonstrates the power of Free Software.

Over the last few months, it seems that the number of silly bugs is increasing. Of course, in most of the cases, the severity of such silly bugs is set to critical. I won’t list all that silly bugs (it would take too long ), but I’ll take two examples, that are very recent as they occured today yesterday.

The first one is the bug #289666 titled “sane only work as root on 2.6.10 (2.6.*)”. The bug reporter explains that the module scanner.o has been removed from the kernel and thus he, and all other users, should use the root account to scan a document. He think it is a critical security bug. I don’t know why Julien Blache wrote a README to explain how to be able to scan as user! The command is very simple: adduser user scanner.

The second annoying bug was filled today on OpenOffice.org. It is bug #289800 and is titled “openoffice.org: please enable autosave per default”. Basically, the user was writting a text on OpenOffice.org, and its machine crashed. As he hasn’t saved the document, and as autosave was not enabled, he lost it. Surely not a critical bug. Maybe the user should learn all to click on the save icon instead of sending bug reports!

Maybe we should do something to avoid these annoying bugs. A kind of greylisting, which first sends back an email to the bug reporters (asking them if they have read the documentation, if they have verified that the bug has not been already reported, if they are using the latest version) and then that waits for a key contained in the email to be returned to validate the bug. This could also avoid people using invalid email addresses.

Yes, such a system looks like a bit silly… just as some of the bug reporters.

Yesterday I switched all of my machines but one to kernel 2.6. The last one to migrate is a SparcStation 4. It is a little bit complicated as the BIOS refuse to recognize my hard-drive since I changed it from a 2.1GB one to a 9.1GB. After an afternoon of tests, I decided to boot this workstation via the network, as the Linux kernel recognizes it.

Using a 2.4 kernel was very easy, you just have to convert the Debian kernel in aout format using zcat and elftoaout. For a 2.6 kernel, it is a little more complicated as Debian ships them with an initrd image. After a few minutes searching google, I found the solution:


zcat /boot/vmlinuz > vmlinux
elftoaout -o netboot.img vmlinux
piggyback netboot.img /boot/System.map /boot/initrd.img


It seems to work well, however the image is 271,654,944 bytes long. I still don’t understand why.

I decided to switch all my machines to kernel 2.6. I now consider the kernel 2.6 stable enough, at least for the use of my machines. Except for my workstation on which I like to add some patches, I am using Debian kernels for my other machines. Moreover some of them are very slow (a parisc@60 MHz and a sparc@110 MHz), and building a kernel on such machines takes very long time.

I started with my a backup server, it was very easy, apt-get install and voilà!

Then I switched my firewall. It was not so easy as for my backup server, as I only have a 256 MB disk (actually a compact flash card). Because of its size, it was not possible to have two kernels at the same time on the disk. I decided to remove the old 2.4 kernel (/boot and /lib/modules), to install the new 2.6 kernel. Then I typed reboot, and started to pray. As I don’t have neither a display nor a keyboard on that machine, I started to look both at the hard disk’s LED and at a console on my workstation on which I started ping fourier. After a some time (I don’t know exactly how much, in such situations seconds are like minutes), there was some echo reply. Wonderful!

After such successes, I decided to continue and to switch my hppa machine. Again apt-get, then a quick look at the palo’s documentation to know how to specify an initrd image, and then reboot. After a lot of time, it was still not possible to ping the machine. Shit! PALO has the possibilty to specify an alternate kernel in case of a problem, however in that case it seems it has failed… or the boot was mabe successfull. Half an hour later, after I plugged a screen, a keyboard and a null-modem serial cable, I understood the problem: the module for the network card was not loaded (whereas it was directly binded into the 2.4 kernel). And hotplug doesn’t load it as it is not on a PCI bus. I tooked my keyboard and started to write my login. Nothing. The keyboard’s module was also not loaded. I switched back to the 2.4 kernel, I put a lot of modules into /etc/modules (network card, keyboard, mouse, sound card, parallel port, serial port, etc.). And it worked!

Moral: Don’t change your kernel when you only have very few time to do that. It always take a lot longer than expected.