Bash is weird.

Consider the following command:
echo <(cat /etc/{motd,passwd})

(you can replace "echo" with any command that takes one file as argument and cannot take it as stdin)

It's obvious that the goal is to expand this to:
echo <(cat /etc/motd /etc/passwd)

Then to:
echo /dev/fd/63

However, it doesn't work like this:
$ echo <(cat /etc/{motd,passwd}) ++ cat /etc/motd ++ cat /etc/passwd + echo /dev/fd/63 /dev/fd/62 /dev/fd/63 /dev/fd/62

But bash doesn't work like this. Brace expansion is done first, but inside parameters of the command (that is, <(cat /etc/{motd,passwd})) not words. So when <(cat /etc/{motd,passwd}) is expanded, the prefix is <(cat /etc/, the suffix is ")", so it's expanded to <(cat /etc/motd) <(cat /etc/passwd).

After reporting a bug about that, Chet Ramey gave me the correct way to reach the initial goal:
cat <(eval cat /etc/\{passwd,motd})

Most broken spam protection ever

Just received that, in reply to a mail I sent:

This email is from X.

My email address ( is protected against spam and viruses by MailInBlack.

Please click on the following link in order to identify yourself to me and to allow your message to reach me.

This needs to be done only once, for this email and all future email correspondence.

Thank you for your understanding.


MailInBlack seems to be a french company. No wonder why they guarantee that 100% of spams are stopped. (To be fair, I am not sure yet of who fucked up, it might be the admin)

Jabber clients and OS usage stats (3)

Using XMPP4R, I did some stats about Jabber clients usage on the Apinc Jabber server, which hosts,, and many more using virtual hosting. I already did similar stats in March 2006 and September 2005.

The poll was done by sending jabber:iq:version to online users, around 1:00 PM (french local time, most of the users are french). 1343 clients were pinged, and 1315 answered, which is better than last year (1145 answers). Of the 1145 jids that answered last year, 368 were also part of the poll this year (I don’t know if this is good, or not enough).


  • GNU/Linux: 43% (2006: 38% ; 2005: 34%)
  • Windows: 35% (2006: 37% ; 2005: 34%)
  • Mac OS: 16% (2006: 18% ; 2005: 23%)
  • Unknown: 4 (2006: 5% ; 2005: 6%)
  • Others: 0% (12 clients ; 2006: 0% ; 2005: 1%)


  • Psi: 24% (2006: 28% ; 2005: 28%)
  • gaim: 22% (2006: 25% ; 2005: 25%)
  • Gajim: 12% (2006: 5% ; 2005: 3%)
  • Kopete: 11% (2006: 7% ; 2005: 7%)
  • iChatAgent: 9% (2006: 13% ; 2005: 18%)
  • libgaim (Adium): 5% (2006: 4% ; 2005: 3%)
  • Pandion: 4% (2006: 4% ; 2005: 2%)
  • Miranda: 2% (2006: 2% ; 2005: 1%)
  • BitlBee: 2%
  • neos: 1%
  • Unknown client: 0%
  • Exodus: 0%
  • Imendio Gossip: 0%
  • Jabbin: 0%
  • Spark IM Client: 0%
  • Trillian: 0%
  • JBother: 0%
  • jabber.el: 0%
  • JETI: 0%
  • JAJC: 0%
  • Class.Jabber.PHP: 0%
  • Jabberwocky: 0%
  • Tkabber: 0%
  • Gush: 0%

(all clients with at least one reply are listed here)

I also did some stats on the Linux distros. With 566 Linux users, one can consider that statistically signifiant.

  • Client answers with the kernel version, not including distribution information: 62%
  • Debian: 14%
  • Ubuntu: 12%
  • Gentoo: 2%
  • Unknown distros (not provided by the client): 2%
  • Fedora Core: 1%
  • Arch Linux: 1%
  • Mandriva: 1% (despite the fact that most users are french!)
  • Slackware: 0%

(Other distros are below 5 replies)

The Debian/Ubuntu situation is interesting. Debian is not dying, even on the desktop ! The server is hosting, so the results are biased towards Ubuntu.

Update: it seems that Psi reports “Debian GNU/Linux (testing/unstable)” even when running on Ubuntu. This is the case for ~5% of linux users.

To server admins: if you are running a large jabber server with jabberd 1.6, it’s easy to give me the right to get the list of online users, so contact me if your are interested in me doing your users stats. It would be interesting to see if users from different servers/countries have different behaviours. I’m not sure if it’s possible with ejabberd and other servers.

Slides for my FOSDEM talks about Debian QA

As promised, the slides from my FOSDEM talks about Automated Testing of Debian Packages and Use of Grid Computing for Debian Quality Assurance are available.

Don’t hesite to ask questions or post comments. The videos for both talks should be available so you can laugh at my frenglish, but I haven’t heard of an ETA yet.

Efficient key signing

I just finished signing all the keys from the FOSDEM KSP.

Importing keys I received:
Mutt is nice. You can tag all messages with ‘t’, then use ‘;’ (tag-prefix) and ^K (Ctrl + K) to import all signatures. (Thanks Myon + sam for the tip)

Signing keys:
caff (featured on debaday last week) has some useful info in /usr/share/doc/signing-party/, especially the README.many-keys and README.gpg-agent files.

State of software for Suspend to RAM/Disk ?

Dear readers,

I am the mostly happy owner of a Dell Latitude D610 (the one with the ATI video card), running Debian Etch. I installed the hibernate package to try to get Suspend to RAM and to Disk to work, and Suspend to Disk worked out of the box. But Suspend to RAM didn’t work (garbled screen at resume).

I never bothered to investigate this until today, when I discovered that acpi-support provides the same functionality, and works both for Suspend to RAM and to Disk ! I’m happier now, but I would like to understand, and the world of ACPI and Suspend to RAM/Disk is very difficult to grasp for newcomers.

What is the story behind hibernate and acpi-support ? Why was this duplication of effort needed ? Also, it seems that gnome-power-manager and kpowersave provide the same functionality. Why can’t they just call the relevant acpi-support or hibernate scripts ? How do those different implementations compare (what are their main differences ?) ? Looking at the packages content, it seems that hibernate tries to be generic, while acpi-support gave up, and handles each and every laptop model differently. Correct ? Also, hibernate seems to be handling a few things better, like getting my network interface back up after hibernation.

Finally, the last question: how do one debug Suspend issues, when it fails to work ? Is there a document somewhere explaining that ?

Working evince and poppler in Debian Etch

Evince and poppler (the library used to render PDFs) are quite outdated in etch, and fail to display correctly a number of PDF files (including PDFs generated by latex-beamer). There’s a new poppler version (0.5.x, vs 0.4.5 in etch), but it bumps the soname, so it’s a no-go.

Since I was particularly annoyed by this (I’m an evince fan), I looked at the issue, and found that entry in poppler’s changelog for version 0.5.1:

2006-02-16  Albert Astals Cid

        * qt4/src/
        * qt/
        * poppler/
        * glib/ Update soname as we are not really compatible
        anymore with previous releases that had soname 0.0.0

And I thought that maybe, the soname update was not totally justified. I modified the package in experimental (v.0.5.4) to remove the soname bump, and renamed the binary packages so it becomes a drop-in replace for the version in etch.

It works fine for me with the version of evince in etch, and seems to fix at least #369164, #409758, and #410085.

Packages are available here. Of course, this is totally unsupported, and I have not done any careful testing. But it works for me until now, and I’l update this entry if I discover some problems. Also, I don’t plan to maintain this on the long term, so beware of security bugs.

Update : This breaks tetex (see #356079). Arg. I’ll have to use the experimental version…

Running Debian on your Linksys WRT54G* … sort of

I’m the happy owner of a Linksys WRT54GL. OpenWRT is nice, but … well. Debian is just nicer. And I couldn’t resist the idea of running Debian on this little MIPS system. Since there’s clearly not enough space available on the Linksys, I decided to install etch in a chroot, that I would mount using NFS.

Joey tried that already, the Debian wiki provides some information, but I use another technique.

First, on another system (an i386, I debootstrap’ed a mipsel etch, using --foreign. This tells debootstrap not to run the second stage:
debootstrap --arch mipsel --foreign etch /space/debian-mipsel

Then, I modified /etc/exports to allow the router to mount that chroot:

I mounted it on the router:
ipkg install kmod-nfs
insmod sunrpc
insmod lockd
insmod nfs
mount -t nfs star:/space/debian-mipsel /debian -o nolock
mount -t proc /dev/null /debian/proc

I set up some swap space on the NFS mount (mandatory, or debootstrap’s second stage will fail):
ipkg install losetup
ipkg install kmod-loop
ipkg install swap-utils
dd if=/dev/zero of=/debian/swapfile bs=1M count=100
losetup /dev/loop/0 /debian/swapfile
mkswap /dev/loop/0
swapon /dev/loop/0

I chrooted inside /debian, and ran debootstrap’s second stage:
chroot /debian /bin/bash
debootstrap/debootstrap --second-stage

When you are done playing, you can disable the swap space and umount everything:
swapoff /dev/loop/0
losetup -d /dev/loop/0
umount /debian/proc
sleep 1 # or umount /debian will fail
umount /debian

If you want to re-mount everything, all you need to do is:
insmod sunrpc
insmod lockd
insmod nfs
mount -t nfs star:/space/debian-mipsel /debian -o nolock
mount -t proc /dev/null /debian/proc
losetup /dev/loop/0 /debian/swapfile
swapon /dev/loop/0
chroot /debian /bin/bash

That first stage/second stage split in debootstrap is really cool: it’s an easy way to run Debian anywhere, only requiring to be able to chroot at some point.

Debian Package of the Day is now alive again, and needs your help!

For those who have missed the previous blog entries: Debian Package of the Day (aka Deb-a-day) is now alive again ! There has already been several entries (published 2 times a week, on wednesdays and sundays, until we make sure that we can sustain an higher rate):

Deb-a-day is not syndicated on Planet Debian (because of the “only personal blogs” rule), but it’s syndicated on Planet Ubuntu, and it might be syndicated on Debian Times (negociations are still ongoing :-). Don’t forget to subscribe to the feed !

We (the nice team of editors) have 2 entries ready in the queue, but that’s not enough. If you discovered an interesting package through Deb-a-day, and didn’t submit an entry yet, you should really feel guilty now ! (we are especially looking for cool graphical apps, so Deb-a-day becomes less nerdy, but apps for nerds are welcomed as well, of course.)

Of Debian Etch’s quality and release schedule

The delay of Debian Etch caught some bad press this week. Some articles compare Debian to Ubuntu (which tries hard to have fixed-time releases), and some bloggers are amused by the fact that the next Debian release was delayed “again”. There are some important points though:

  • Etch wasn’t really scheduled to be released on Dec 4th. This target date was mainly used to determine other dates in the release process, like the freeze dates.
  • Ubuntu Dapper was delayed as well, for 6 weeks. Ubuntu Edgy wasn’t delayed, but I don’t think anybody can seriously compare Ubuntu Edgy’s quality with the upcoming Debian etch’s quality: edgy was more like a technology preview.

Now, the question is: how good is Debian Etch compared to Ubuntu Dapper ? It’s difficult to compare distributions: there aren’t a lot of good metrics for this. Of course, one could compare the number of packages that fail to build from source (it’s a good indicator of something seriously wrong in a package). But a lot of work has been done on etch about this, so it wouldn’t really be fair for Ubuntu. A good alternative is debcheck.

debcheck checks that packages can be installed (i.e that their dependancies can be satisfied). It does so by analyzing the content of the Packages files. I compared the results of debcheck on etch as of today (I re-processed it, but the same results are available from qa.d.o), and of debcheck on Dapper (not including dapper-updates – I wanted to compare quality at release date). Included sections were main for etch, and main, restricted and universe for dapper (I didn’t want to consider non-free packages, since their quality tend to be lower).


4 packages have unsatisfiable Depends on etch, on i386. 49 have unsatisfiable Recommends.

In the main section of Dapper, still on i386, only one package has a problem with its Depends (it was psycopg, because its binary package python2.3-psycopg has a dependancy on python2.3-egenix-mxdatetime). 46 packages in main had unsatisfiable Recommends. This is better than Etch, of course, but Ubuntu/main is much smaller than Debian/main.

When restricted and universe are included, the results are much worse. 80 packages have unsatisfiable Depends, and 150 packages have unsatisfiable Recommends. It is worth noting that those numbers are worse than those of Debian unstable as of today (67 packages have unsat Depends, 34 have unsat Recommends).

Conclusions (sort of):

  • Using the debcheck metric (which is actually quite important, since it translates in uninstallable packages for the users), Debian etch is already of better quality than Ubuntu Dapper when it was released (again, I haven’t checked with dapper-updates included).
  • It would be great to integrate such tests into the Ubuntu release process. Fixing bug is good, but such tools help to improve the distribution quality as a whole. I’ll try to work on this for Feisty after the Etch release.