Some stats about packages build times

I rebuilt all the packages in etch inside an i386 etch chroot on bi-Opteron systems with 2 Go of RAM. Here is some data about the build times for each package. They include the time needed to fetch the dependencies from a Debian mirror over NFS, so might have been overloaded during some builds, so it the build times might not be totally accurate, especially for the very short builds.
Two packages are excluded from the following stats because their didn’t complete their build: libmail-mboxparser-perl and camas.

17 packages took more than 1 hour to build. They are:

Package Build time (seconds) 21537
linux-2.6.16 17859
linux-2.6 14833
gcc-4.0 9142
gcj-4.1 9062
gcc-4.1 7111
gnat-4.1 6910
installation-guide 6337
gcc-3.4 6022
octaviz 5735
gcj-4.0 5300
k3d 5294
openscenegraph 4851
ghc6 4670
glibc 4504
vtk 3954
atlas3 3759

The full list is available.

Most packages build very quickly:

Build time (s) Number of packages Total
< 30 5389 5389
30 – 59 2354 7743
60 – 119 1304 9047
120 – 499 873 9920
600 – 1799 92 10012
> 1800 40 10052

The total build time is 220.4 hours (that’s 9.2 days), the mean build time is 78.9s, the median build time is 27s.

Debian, Ubuntu, Mozilla® Firefox®, wearing hats, and Epiphany

With my Ubuntu hat, I strongly regret that no Ubuntu developer (to my knowledge) stepped forward to point out the inaccuracies in Chris Beard’s (Mozilla Vice President of Products) Q&A on Mozilla Firefox in Ubuntu. Letting people bash Debian when Ubuntu gets so much stuff from Debian isn’t nice at all.

With my Debian hat, I really like how Mike Hommey chose to discuss facts, with references, in his reply to Chris Beard’s post. When it is possible, going back to the facts is really the best thing to do to avoid the usual FUD. It’s not really a surprise that this intelligent behaviour came from the Debian side.

I have been a very happy user of Epiphany since I made the switch from Firefox 3 months ago. I would recommend it to anyone still using Firefox who is tired of its slow startup times, and its lack of integration in the Gnome desktop.

Discussion about moving Ubuntu IRC channels to Jabber

The Ubuntu GNU/Linux distribution is using IRC channels as a central place for its development. This week-end, Samir van de Sand proposed to move from IRC to Jabber on the ubuntu-devel@ mailing list. A discussion started, with lots of good arguments on both sides, and Samir started a specification summarizing its proposal.

Even if I’m not sure if I would like to use MUC rooms instead of IRC for Ubuntu-related discussions (mainly because I don’t think there are Jabber clients allowing to join 10 rooms with the same user experience I get with XChat), this might be a good opportunity to work on our argumentation regarding the IRC vs MUC debate.

Now, something totally different for my readers from I usually blog my Jabber entries in english, because I’m syndicated on as well. Somebody argued that I should not post stuff written in english to So, should I:

  1. Continue to post entries in english to
  2. Stop posting entries in english to (I’m not going to translate my entries, so my posts to will be limited to stuff which is not relevant to

Version française: mes billets sur Jabber sont généralement écrits en anglais, car je suis également syndiqué sur Quelqu’un m’a fait remarquer que je ne devrais pas publier de billets en anglais sur Que dois-je faire :

  1. Continuer à poster des billets en anglais sur
  2. Arrêter de poster des billets en anglais sur (Je ne vais pas traduire mes billets, donc mes billets sur se limiteraient aux sujets qui ne concernent pas

Mozilla, Debian and Iceweasel: the Mozillian point of view

During the Journées du Logiciel Libre 2006 (an excellent event, thanks to the organizers), I had long chats with people from Mozilla Europe (in a more constructive way than what others did). This is mostly second-hand information, since the well-informed guys from Mozilla Europe I talked with got their info from other Mozilla developers, so it might be slightly inaccurate, but still help to understand the issue. More details welcomed in comments.

The Mozilla Foundation goal is to prevent the web from becoming a proprietary web, by ensuring that Firefox, their product, has a big-enough market-share. I find it a bit disturbing to hear free software people speak about product and market-share, but well, OK. Of course, it’s quite difficult to achieve >20% market-share only with GNU/Linux users. :-)

They put a very high emphasis on the User experience. They want Firefox to look exactly the same on all platforms, even if some features (automatic plugin installation, automatic upgrades) do not fit well on a GNU/Linux system (such features don’t work with the Debian build).

They want to enforce their trademark to prevent attempts to ruin their reputation to succeed. After a question asked by Dave Neary (GNOME) to Tristan Nitot (president of Mozilla Europe), Tristan gave the example of this hacker who said he found critical security bugs in Firefox before admitting it was a joke. He also gave the example of Microsoft indirectly founding SCO. Dave Neary remarked that some people could probably be trusted (like distro maintainers). But, if I remember correctly, Tristan said that it was difficult to allow some people to use the trademark without allowing everybody to do so. Also, allowing Debian to use the trademark without allowing derivatives to do so is not possible (DFSG#8).

Iceweasel is considered a good thing inside Mozilla Europe (“It’s what we have asked them to do for a long time!“). However, some people are bitter about the fact that Debian seems to have chosen to use a fork instead of just renaming the package to iceweasel.

During Tristan Nitot’s conference, I asked a question about length of security support (only 18 months for the 1.0 branch). The answer was that distros were supposed to upgrade to newer Firefox releases even on their stable releases (!) or to come and help with security support for stable releases. Also, the fact that Debian chooses to package Firefox following the FHS is considered a source of problems. Somebody claimed that Debian was the only distribution to package Firefox this way (seems strange, but I did not checked this claim). I’m not sure how this fits with other Mozilla-based browsers such as epiphany.

On a more technical side, they also claimed that Debian wasn’t properly collaborating with Mozilla, sending unusable 100000-lines patches for validation just before releases (haven’t checked this claim). It’s interesting to note that the same problem exists on the other side, with Mozilla releasing “security and stability” releases instead of just providing patches for the security bugs.

My personal conclusion is that Iceweasel is really a good thing, and is quite unavoidable, even if it seems that the Debian/Mozilla collaboration could maybe have been better. Let’s advertise the use of Iceweasel, Epiphany, and other Web browsers! :-)

Note : comments open for people willing to fix inaccuracies or provide references, not for a stupid childish flame-war like the one in the comment of this post. Please write your own blog entry and use a trackback if you want to provide a detailed answer!


  • I forgot to mention that the Mozilla people talked about Debian-specific changes that changed frozen APIs, breaking extensions, and causing bug reports on b.m.o or misleading forum posts. (again, not verified)
  • Interesting blog post about the trademark issue here
  • Mike Hommey addressed most of the points I reported in this blog entry.

Unintrusive Instant Messaging

Most IM clients have a big problem: they seem to think they are the most important application on the desktop, or that their users always consider IM as top priority. Problem is, some users don’t! It would be great if IM clients where dealing better with two use cases :

  • Joe is working intensively on something, and doesn’t really want to be disturbed, except, of course, if the chat he would have is of extremely high importance (knowing who just sent him a message would probably help in determining how important the chat is going to be). He can’t rely on setting himself “Busy” on jabber, because people then write to him saying “ok, you are busy, answer me later, but here is my question: ….”.
  • Joe is working with Jack (a colleague) in front of his workstation. Since he has a mix of both professional and personal contacts, he needs to check if the message he just received is from his boss or from his girlfriend. (Opening a message from his girlfriend while Jack is watching might not be a good idea).

Typical stuff clients do:

  • Display incoming messages using notification-daemon (see picture below), but do not provide a way to disable this behaviour (I don’t think many clients fail this test).
  • The tooltip of the notification area icon (“system tray”) provides a fast way to be informed of important information. However, some clients (e.g Gajim) only give the number of unread messages, but don’t say who they are from (see picture below). The tooltip would be a perfect place to say “3 unread messages, 1 is from Boss, 2 are from ” in a Jack-safe way. When working intensively, it also allows you to make a quick decision about whether you want to read the messages and maybe start a chat now, or reply to them later.
  • Some clients (e.g Gajim) do not provide a way to easily read a specific unread message (and not all of them) (see picture below). Adding something event-specific in addition to “Show All Pending Events” would allow to read the message from Boss without reading the message from Girlfriend in front of Jack.

So, how does your client behave in regard to this ? I don’t really like the way Gajim behaves because it doesn’t provide much info in the tooltip, and doesn’t allow you to read a specific event (you have to open the roster and select the contact). Is your client doing better ?