How old are our packages?

Debian’s binary packages are only built when they are uploaded (or when a binNMU is requested, but that doesn’t happen frequently). They are never rebuilt later. This means that some binary packages in etch weren’t build in an up-to-date etch environment, but possibly in a much older environment.

Is this a problem? It depends. Old packages don’t benefit from the improvements introduced in Debian after they were built. Like new compiler optimizations, or other changes in the toolchain that could induce changes in binary packages.

For example, some files used to be at some place, but are now put at another place. Also, some parts of maintainers scripts are automatically generated, and would be different if the package was rebuilt today.

But is it really a problem? Are our packages _that_ old? Also, when a big change is made in the way we generate our binary packages (like Raphael Hertzog’s new dpkg-shlibdeps), when can we expect that the change will be effective in all packages?

I went through all binary packages in unstable (as on 24/06/2007) (both main, contrib and non-free packages) on i386. Using dpkg-deb –contents, I extracted the most recent date of each package (which can reasonably be taken as the date of the package’s creation). And here are the results.

Most packages are actually quite recent. 9008 packages (43%) were built after the release of etch. And 19857 packages (94%) were built after the release of sarge. But that still leaves us with 1265 packages that were built before sarge was released, and even one package (exim-doc-html) that was built before the release of woody! (the removal of this package has been requested, so we will soon be woody-clean :-)

Now, what could we do with this data? We could review the older packages, to determine if:

  • They would benefit from a rebuild (by comparing them the result of a fresh build) <= I'm planning to work on that
  • Integrate that data with other sources of data (popcon, for example), to see if the package should be removed. Such old packages are probably good candidates for removal.

Here is the full sorted list of packages.

debconf7

DebConf7 finished today. This was my first DebConf, and probably not my last one :-) I had a really interesting time in Edinburgh, despite the weather (but at least we are prepared for DebConf8 now!). The organization team really did a fantastic work, the venue was gorgeous, etc, etc, etc.

Again, I was positively surprised by how nice everybody was at DebConf. It’s weird to think that the same people are part of the regular flames on the mailing lists. Which proves that most flames are just caused by people being passionate about Debian, and looking for the best for the project, and not by people trying to be annoying, like one could think :)

I gave a talk about the usual QA stuff I’m doing: archive-wide rebuilds, piuparts runs, and how to make all this more efficient by working inside the collab-qa project. So far, it’s not like a lot of people have been joining the project, which is kind of a failure. But at least everybody seem to think that the idea is good.

I also gave a lightning talk about Debian Package of the Day, which I didn’t plan to give originally (I think I never prepared slides in such a short time). I think it was well received, and we even got a new submission half an hour after the talk.

I even managed to clear some tasks on my TODO list during Debconf, the most visible one being the “automated monthly mails to maintainers of packages with serious problems”. I was quite afraid of being flamed, but I sent 250 mails, and only one person replied aggressively. I also got a lot of positive feedback, so the next batch will probably use slightly less strict criterias.

And of course, the most important result of debconf was the numerous discussions, that resulted in a lot of good and interesting ideas.

maintainer wanted for next generation tetrinet server!

You probably all know tetrinet – if you don’t, you should really try that game. There are several servers for that game out there, and one of them is tetrinetx. It is packaged in Debian, but it has several problems:

  • It doesn’t support tetrifast mode. So you have to deal with that stupid 1-second delay before the next block appears.
  • The code is truly horrible. From main.c:
    #include "dns.c"
    #include "utils.c"
    #include "net.c"
    #include "crack.c"
    #include "game.c"

    That gives you an idea, right ?

A few years ago, I worked with a few friends on improving tetrinetx. This resulted in:

  • Massive code cleanup
  • Tetrifast support
  • Stats stored in an MySQL DB, so you can compute nice stuff (time wasted per day, etc)
  • More stats: blocks drop rate, etc.

This is hosted on sourceforge under the name tetrinetx-ng, but it hasn’t seen any activity for the last two years.

It would really be great if a tetrinet fan could take over the project and start making it alive again. Then tetrinet.debian.net could support tetrifast ;)

Also, I could try to setup a server with tetrinetx-ng. Someone wants to host tetrifast.debian.net for me ? Needed: MySQL DB + Apache (for the stats), + not being afraid of insecure code (doesn’t need to run as root)

Distributed SCM and branching a sub-directory ?

I am considering switching from SVN to a distributed SCM for my personal stuff. I had a look at git and mercurial, but neither really support branching a sub-directory:

Often, I am working on a big private project, and, while working on a sub-project (stored inside the project’s repository), I’d like to share that sub-project with others. So there are actually two problems:

  • being able to checkout/branch/clone a sub-directory
  • possibility to control access on a per-directory basis

SVN only partially meets my needs with that (it’s possible to checkout a sub-directory directly, for example with svn co svn://svn.debian.org/svn/pkg-ruby-extras/tools/ruby-pkg-tools). I think that it’s possible to do fine-grained access control
using libapache2-svn, but I haven’t tried yet.

It seems that mercurial can do that, using the forest extension. But you have to convert the specific directory into a repository, with a complex step to keep the history.

Amongst the distributed SCM, is there one that supports that ? (at least the sub-directory branching part)

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})

Condorcet method and the french presidential election

The french presidential election (in april/may 2007) will use plurality voting with two rounds (voters will choose 1 amongst 11 or 12 candidates during the first round. The two candidates with the most votes will be qualified for the second round).

The latest polls clearly show how this election method fails to satisfy the Condorcet criterion. Using the second round results from this poll (only considering the 3 main candidates, since the other don’t have any chance to win the presidential election), we get this:

2007 elect results

So Francois Bayrou is the Condorcet winner, and should win the election. However, the first round results, according to the same poll, could be:

  1. Sarkozy 31%
  2. Royal 24%
  3. Bayrou 22%
  4. Le Pen 12%

Since only the two first candidates are qualified to second round, Bayrou wouldn’t be elected. It will be interesting to see how those scores evolves until the first round (April 22nd).

Most broken spam protection ever

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

This email is from X.

My email address (X@Y.com) 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.
http://192.168.0.252/v/?C8BEF10E72C&tmstp=20070316084314&tk=message_confirm&tkid=7951&lang=2

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

Thank you for your understanding.

X

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 im.apinc.org, jabber.fr, 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).

Systems:

  • 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%)

Clients:

  • 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 jabber.ubuntu-fr.org, 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.