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.

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…

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.

During the recent weeks, we started to hunt and hint large batches of packages together to testing (and this blog is just to show a bit of what is part of the tasks of release team members). This started with a large jasper hint, continued with a very large poppler / texlive / jack / abiword-hint (which moved about 75% of the packages that were ready for testing migration in at the same time), then moved a more recent linux-2.6 version in, and now finally ghc6 / haskell. However, now we reached a point where a few more release teamisch hints don't help anymore: The next large blocker is gcj-4.1 / gccdefaults / ecj. This is now blocked by different bugs on different architecture:

• mips* needs to have xulrunner built first to build gcj-4.1. This is discussed in bug #428582, and the porters are busy working on it.
• hppa fails for unknown reasons - probably it needs some porting. That should be discussed in bug #431865 but until now there was no answer from the hppa porters.
• arm already reached the state of being out-of-date to a degree that it needs bootstraping by hand - see http://lists.debian.org/debian-arm/2007/07/msg00014.html for reference.

Update: Aurelien Jarno informed me that gcj-4.1 had to be bootstrapped on all architectures, but it hasn't happened yet on arm due to bugs in gcj.

All doom and gloom? far away from that.

The good:

* Arm port is now third most popular port according to popcon.
* This mostly thanks to the popularity of Linksys NSLU-2, a tiny 80 computer able to run Debian. Do you have a old pentium sucking up electricity in your closet? Do a service to earth and replace it with a NSLU-2!
* Armel (Arm EABI) is now at "63.41% up-to-date. That's 4515 packages built out of 7121". See the fancy Graph for the progress. Catching up sid has been achieved with just two buildd's (Thecus N2100) in my apartment and Aurelien Jarno building selected packages. Plus of course pioneering work from Lennert Buytenhek and people who created EABI in upstream.
* All core packages except apt (which hasn't seen a upload to sid since etch) have now armel support in official Debian packages.
* the old arm port has started catching up in up-to-dateness again, now that all buildd's have a recent enough kernel for glibc 2.5 (2.6.12+)

The bad:

* We need someone to take responsibility on the toolchain for arm. Java is semi broken on arm, Fortran, Java and objc need work for armel.
* There is still communications problems. It took quite a while to find out why glibc 2.5 doesn't work on some buildd's.
* People have lost interest in Bigendian arm port after nslu-2 started working with the regular Little-Endian arm port. General consensus is that bigendian port would only matter for highend networking gear.

The future:

* More supported devices. Now we support NSLU-2, Thecus N2100 and a few related IOP based devices plus netwinders. Arm boasts their partners shipped 2450 Million units based Arm technology in 2006. Would you like to run Debian on your brand new scsi RAID card? mp3 player? Cellphone? Internet Tablet? Washing machine? Your choice!
* Better recovery options. Many arm devices are headless, and if it crashes or doesn't boot, figuring out what went wrong is tricky. This is not really arm specific, but comes up often enough in debian-arm list.
* Anti-bloat festival. Many arm devices have very little storage and RAM available. To run debian on these, we need to figure out who to get rid of extra FAT. Less bloated software is everyones advantage.


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.

Christian, this is the percentage of your blog entries concerning translation ratios in the last two weeks. I am sure you can do better

Aurelien Jarno asked me to add another arm port to Buildd.Net, namely armel - a new ABI version for newer little endian based arm boxes. Read more about that new arch in the Debian Wiki.Anyway, here it is: armel page on Buildd.Net - have fun!

Welcome to this 6th issue of the DeFuBu contest, the monthly (even if I'm late) championship of the funniest bug reported to the Debian BTS. The challengers

• G rkan Seng n with #270877 (wmaker: I can't swallow windows)
• Christoph Berg with #402976 (espdiff: useless manpage)
• Cyril Brulebois with #403379 (mplayer: segfault while reading an mpeg file)
• Sune Vuorela with #405464 (qt3-dev-tools: QMAKE_INCDIR_QT is wrong in qmake.conf files)

How the vote has been done Three Debian related people voted for these bugs, Mohammed Adn ne Trojette, Pierre Habouzit and Florent Bayle Full ranking Bugs

• #403379 (mplayer: segfault while reading an mpeg file) (6 points)
• #402976 (espdiff: useless manpage) (5 points)
• #405464 (qt3-dev-tools: QMAKE_INCDIR_QT is wrong in qmake.conf files) (4 points)
• #270877 (wmaker: I can't swallow windows) (3 points)

Challengers

• Cyril Brulebois (6 points with 1 bug)
• Christoph Berg (5 points with 1 bug)
• Sune Vuorela (4 points with 1 bug)
• G rkan Seng n (3 points with 1 bug)

The winners

• Bug: #403379 (mplayer: segfault while reading an mpeg file) (6 points)
• Challenger: Cyril Brulebois
• Bug reporter: Aurelien Jarno
• Voter: Florent Bayle with the full good order !

Notes To participate, simply drop me an email with a bug number. About DeFuBu

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 arm@buildd.debian.org. 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 arm@buildd.debian.org 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.

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

According to Aurelien Jarno, it's possible to run Debian/ARM and both Debian/MIPS platforms inside an emulator that itself is packaged and runs on Debian. Since fairly recently (about a month or two, I guess), the same is true for Debian/m68k. Granted, the emulator you need to install isn't called "qemu", but with ARAnyM (short for 'Atari Running on Any Machine') it is now possible to run Debian/m68k. And it's fairly easy to do, too:

• Download the installer images for Debian/m68k
• Install the aranym package
• Run aranym once. This will create a directory .aranym with a default config file.
• create a file to be used as a disk image: dd if=/dev/zero of=./disk.img bs=1k seek=2M count=1.
• Edit the configuration file. The important bits are the section [IDE0] and [LILO]. It's pretty self-explanatory.
• Run aranym-mmu -N -l.

There, you have a free m68k development machine! Note, however, that there might be issues with the network interface; the NIC in the emulated machine is unlike any real, actual Atari hardware. There is a driver for Linux, but I'm not 100% sure whether it's been integrated in the Debian kernels yet. I'm sure Christian will kick me awake on this, though ;-)

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

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 debian.org machines. Concerning alpha, the debian porting machine, ie escher.debian.org, 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.

Directed by jd & adn Genre: Action / Adventure / Sci-Fi / Thriller / Horror / Drama / Humor
Runtime: several weeks
Country: A lot
Language: English
Color: Color (Technicolor, QT, GTK and ncurses) Tagline: They stole their project, now they want it back. Plot Outline: In September 2006, a group of developpers from the Debian planet rise against the corruption leading the government.
User Comments: Great action, great suspense, great cultural satire, and a great mind-bender. Awards: Waiting for nomination. Quotes:

• Bah, if you don't want to read me, just don't , Sven Luther
• Oh my. , Clint Adams
• Or maybe I'm withdrawing my support because I'm busy with my chainsaw. , Josselin Mouette
• "I'm withdrawing my support because the developers might agree with AJ rather than me"? Come on. , Matthew Garett
• OH NO YOU DON'T. This thread is _not_ about you, it is _not_ about Frans Pop, and it is _not_ about debian-installer. , Peter Samuelson

Cast overview

	Anthony Towns (aj), as the Debian Project Leader		Denis Barbier (bouz), as The Recaller
	Aurelien Jarno (aurel32), as one Seconder		Clint Adams (schizo), as one Seconder
	MJ Ray (mjr), as one Seconder		Pierre Habouzit (madcoder), as one Seconder
	Martin Schulze (joey), as one Seconder		Marc Dequ nes (duck), as one Seconder

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.

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 you may have read it in the latest DWN, Xen is now (almost) supported by Debian. Actually, it is currently stucked in the NEW queue since yesterday. The packages are also available on our Alioth webspace.
Special flavor of glibc, libc6-xen, is also upcoming, thanks to Aurelien Jarno ! Err, what else to say ?
That the Xen upstream sources are not very clean for now. There's still a lot of tools not needed that are furnished, the sources are a mess, and there is no stable API for now. You may have seen Xen kernels in experimental, but the kernel team has removed them for now. It will probably not be possible to distribute Xen-enabled kernels as long as Xen won't be more stabilized. I really wish that it will be integrated in kernel vanilla sources, since this could calm down a bit big changes, and help having a more stable version. Just see that between 3.0.1 and 3.0.2 version, the way used to compile Xen kernels changed from a special arch xen to a subarch xen. That's better, for sure, but such important changes in the same major branch are quite disappointing. Finally, I would say that Xen is now usable with Debian. I use it for more than 6 months now, and it is quite stable, no huge bug. You will just have to wait that #346387 is fixed to compile your own kernels with patches we provide.

I gave a talk about Debian GNU/kFreeBSD at FOSDEM 2006. It tooks me time, but I finally have made the slides available.