Living in France? Not an April member? You are WRONG.

I’ve been a member of April, the french association for promotion and defense of Free Software, for a bit more than a year, and I often regret not becoming a member earlier. (I was feeling so guilty and shameful about not being a member that I actually postponed becoming a member.)

Stop feeling guilty and shameful, become an April member today!

Why Is becoming an April member so important?

  • Clearly, April doesn’t address the same problems as your local LUG. April is a country-wide organization, and it works on country-wide problems. It’s the only group able to work on such problems at this scale (I’m not sure of the situation in other countries, but I think CCC shares a similar role in Germany for example).
  • Each time I talk to people really involved in April (which I’m not), I’m amazed by how powerful they have become. They are able to talk to french or european deputies or ministers’ cabinets, and are considered important. They are doing a fantastic job spreading what matters to us to legislative and executive powers in France and Europe.

Some of the things they worked on recently (from the top of my head):

  • Lobbying on :
    • OOXML
    • General announcements about politics (Plan France Numérique 2012, aka Plan Besson).
    • European telecom package and HADOPI law (french graduated response) law, through Quadrature du net. (OK, it doesn’t have anything to do with April, but most of the people involved in Quadrature du Net are also involved in April :-)
    • vente liée : the fact that it’s not possible to buy a computer without a Windows license. It’s illegal in French law, but still the de facto situation almost everywhere.
  • Organization of a campaign where candidates to elections in France where asked questions, or asked to sign a declaration about Free Software. In 2007, 8 out of the 12 candidates of the french presidential election answered April’s questions.

So, really, become a member today. It’s only 10 EUR, and you already know they will be well used. April is trying to reach 5000 members by the end of 2008.

(Apparently, if you use that address, April will now that you came from me. No benefit for me at all.)

Cool stats about Debian bugs

Now that bug #500000 has been reported, let’s have a look at all our other bugs, using UDD.

Number of archived bugs:

select count(*) from archived_bugs;

Number of unarchived bugs marked done:

select count(*) from bugs where status = 'done';

Status of unarchived bugs (“pending” doesn’t mean “tagged pending” here):

select status, count(*) from bugs group by status;
    status     | count 
 pending       | 53587
 pending-fixed |  1195
 forwarded     |  6778
 done          |  8267
 fixed         |   167

The sum isn’t even close to 500000. That’s because quite a lot of bugs disappeared:

select id from bugs union select id from archived_bugs order by id limit 10;

Now, let’s look at our open bugs.
Oldest open bugs:

select id, package, title, arrival from bugs where status != 'done' order by id limit 10;
  id  |    package     |                                   title                                    |       arrival       
  825 | trn            | trn warning messages corrupt thread selector display                       | 1995-04-22 18:33:01
 1555 | dselect        | dselect per-screen-half focus request                                      | 1995-10-06 15:48:04
 2297 | xterm          | xterm: xterm sometimes gets mouse-paste and RETURN keypress in wrong order | 1996-02-07 21:33:01
 2298 | trn            | trn bug with shell escaping                                                | 1996-02-07 21:48:01
 3175 | xonix          | xonix colors bad for colorblind                                            | 1996-05-31 23:18:04
 3180 | linuxdoc-tools | linuxdoc-sgml semantics and formatting problems                            | 1996-06-02 05:18:03
 3251 | acct           | accounting file corruption                                                 | 1996-06-12 17:44:10
 3773 | xless          | xless default window too thin and won't go away when asked nicely          | 1996-07-14 00:03:09
 4073 | make           | make pattern rules delete intermediate files                               | 1996-08-08 20:18:01
 4448 | dselect        | [PERF] dselect performance gripe (disk method doing dpkg -iGROEB)          | 1996-09-09 03:33:05

Breakdown by severity:

select severity, count(*) from bugs where status != 'done' group by severity;
 severity  | count 
 normal    | 27680
 important |  7606
 minor     |  6921
 wishlist  | 18898
 critical  |    29
 grave     |   209
 serious   |   384

Top 10 submitters for open bugs:

select submitter, count(*) from bugs where status != 'done' group by submitter order by count desc limit 10;
submitter                      | count 
 Dan Jacobson                  |  1455
 martin f krafft                |   667
 Raphael Geissert                |   422
 Joey Hess                        |   392
 Marc Haber            |   368
 Julien Danjou                     |   342
 Josh Triplett                |   331
 Vincent Lefevre                |   296                                |   260
 Justin Pryzby  |   245

Top bugs reporters ever:

select submitter, count(*) from (select * from bugs union select * from archived_bugs) as all_bugs
group by submitter order by count desc limit 10;
                  submitter                   | count 
 Martin Michlmayr             |  4279
 Dan Jacobson            |  3652
 Daniel Schepler  |  3045
 Joey Hess                  |  2836
 Lucas Nussbaum     |  2701
 Andreas Jochens                |  2605
 Matthias Klose         |  2442
 Christian Perrier        |  2302
 James Troup                |  2198
 Matt Zimmerman               |  2027

You want more data? Connect to UDD (from master.d.o or alioth.d.o, more info here), run your own queries, and post them with the results in the comments!

Exporting logs from Suunto X6HR watches on Linux

I’m the happy owner of a nice geeky toy: a Suunto X6HR watch, that includes an altimeter and an heart rate monitor, which I use mainly for moutain biking and hiking.

During outings, the watch can log the altitude and heart rate every 2, 10 or 60 seconds, and the data can be transfered to a PC using a serial interface. The problem is that Suunto only provides software for Windows. I got tired of using virtualbox to connect to the watch (qemu doesn’t work, Suunto Activity Manager apparently does strange things with the serial port), so I reverse-engineered the protocol (using skimanager and Jérome Kieffer’s work as a basis) and implemented a script to fetch the logs, and export them in a format suitable for gnuplot.

Of course, Suuntux is publicly available. I’d be happy to hear from you if it works for you too. Also, if you own a Suunto X6 (similar watch, without HRM), I’d be interested in supporting it too (if it’s not supported already).

Below is a example graph, from a short mountain bike ride just before leaving for Debconf.

example suuntux output

Things you should know before buying an Asus EEE PC

I’ve been using an EEE PC since december, and people keep asking me if they should buy one. So here are some things you should know before making a decision.


The screen is small, but that’s OK. I couldn’t find many applications that didn’t work in 800×480. And for the remaining ones, you can usually use hacks such as running the app in a larger virtual desktop. Not ideal, but it works. Regarding usability, it’s not a too big problem. Jut expect to use many apps maximized, and use scrolling and virtual desktops a lot. (Important note: Xmoto doesn’t work!!)


The keyboard is probably a bigger problem than the screen (I hadn’t expected it to be a so big problem before buying the laptop). Every other keyboard seems to have HUGE keys after typing on the EEE PC keyboard. But with some training, you can type quite fast, even if probably not as fast as with a full size keyboard. The layout of the “special” keys is quite good (esp. the PgUp/Down, Home and End keys on the arrows. I should remap my other keyboard like that).

Battery, power consumption

One big problem with the EEE PC is that it consumes a lot of power while sleeping (using suspend to RAM). If you leave it sleeping for more than a few hours, expect the battery to be empty. That really sucks, especially since suspend to disk isn’t really a good option on such a device. Another problem related to power is that charging the battery is quite slow.

SDHC card reader

If you want to expand the storage capacity of your EEE PC with the SDHC port, choose your SDHC card carefully. There are only a few cards that work. The other ones will cause write error (they will work in read-only mode, so I’m using an external card reader to write, which sucks). A list of supported cards is available in the EEE PC manual.

Random Q&A

Q: I don’t have a laptop. Should I buy it?

A: If you want to do a lot of real work on it, it’s probably not a very good idea. There are faster (but bigger) laptops at around 450-500 EUR. They are probably a much better option. The EEE PC is perfect as a the second laptop you only bring to places where you want to stay connected, read email and surf on the web (like conferences and meetings).

Q: Does the VGA output works well?

A: Yes. And it uses an Intel video card which works like a charm with xrandr. I already gave several presentations and classes using it. The laptop can output 1280×1024 (maybe 1600×1200, not sure). The only problem is that you will only have the top-left part of your slides on the laptop’s screen, because of the smaller resolution there. Annoying if you plan to read your slides.


So, should you buy one? If you can’t wait, go ahead. If you can wait, it might be a good idea to wait until Asus fixes some of the problems (the SDHC card reader and the power consumption while sleeping are the most annoying ones).

Tele2 sucks (or “QoS for dummies”)

I just discovered that, since I enabled the TV over DSL option, Tele2 limited my downstream bandwidth to 8mbps (instead of 20 mbps). All the time. Even when I don’t use the TV. Because allowing 20 mbps could have affected the quality of TV reception (when the TV is off?).

They proudly advertise that offer as:

  • unlimited DSL up to 20 mbps
  • 41 TV channels and 32 radio channels included

It seems that they forgot the “OR” in between.

mailing list for cross-distributions collaboration

A few months ago, I asked a set of questions on development mailing lists of a few GNU/Linux distributions. This resulted in very interesting discussions. As promised back then, all the answers from all distros I contacted can be read on the web or as an mbox file.

Also, kindly agreed to host a mailing list to ease discussions between distributions, and act as a central point of contact. You can subscribe, and post to distributions at lists dot freedesktop dot org.

This mailing list is for people involved (or interested) in the development of distributions. Questions that are on-topic are both technical and social/organizational issues, like:

  • How do you achieve graphical boot in your distro? Do you use some kind of dependancy-based or events-based boot?
  • How do you package both ruby 1.8, ruby 1.9 and jruby, or handle KDE vs KDE4?
  • Do you use a system that gives a limited set of rights to new contributors?

Off-topic stuff obviously include trolling about which distribution is the best one, or user support.

Don’t hesitate to forward this announcement to all interested parties. Let’s make this mailing list something useful together!

Also, I really apologize for procastinating announcing this list for sooo long. I’m really good at procastinating interesting stuff, it seems.

back from FOSDEM

I was at FOSDEM last week-end. As usual there, I spent an excellent week-end. It was really nice to see all those friends again (and even meet some friends for the first time, hi gaston/carxwol/atmaniak!) Only problem is, FOSDEM is definitely too short ;-)

To make this post a bit more interesting, I did some homework. The opening talk about FreeBSD had those stats about developers’ age, so I made the same ones for Debian (using the birthDate LDAP field, which was filled in by 340 DDs). Here is the graph. It would be interesting to compare that with other communities, which are sometimes perceived as “younger”.

DD years of birth

dd + /dev/random fun

From Adrien Lebre, who seems to be having fun working on kDFS:

$ dd if=/dev/random of=file bs=1024 count=2
0+2 records in
0+2 records out
256 bytes (256 B) copied, 0.000705717 s, 363 kB/s
$ ls -l file
-rw-r--r-- 1 lucas lucas 256 2008-02-08 17:53 file

Can be easily explained using strace:

open("/dev/random", O_RDONLY|O_LARGEFILE) = 0
open("file", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1
read(0, "p(\361\241,\360-\330~M\245y\10=\274U\201c\207\v\336a\273"..., 1024) = 128
write(1, "p(\361\241,\360-\330~M\245y\10=\274U\201c\207\v\336a\273"..., 128) = 128
read(0, "\362,LW5l.?\242\22\252\223\206\375\10\326\335\316\374\372"..., 1024) = 128
write(1, "\362,LW5l.?\242\22\252\223\206\375\10\326\335\316\374\372"..., 128) = 128
close(0)                                = 0
close(1)                                = 0

Re: a problem with tools

Joey has a problem with tools used over dpkg-dev’s core tools to help maintainers maintain their debian packages.

I was wondering about the adoption of those tools, so I simply grepped the logs from my last rebuild for “^Setting up $TOOL “, which is more accurate than looking at build-deps, since someteam-pkg-tools could depend on cdbs, and hide cdbs usage.

Results, with lists of packages “affected”:

Tool Packages
debhelper 11434 (95.8%)
cdbs 2665 (22.3%)
dpatch 1714 (14.4%)
quilt 935 (7.8%)
dbs 57 (0.47%)
yada 32 (0.27%)
debmake 2 (0.017%)

(if you want me to check the logs for another tool, just tell me)

My personal opinion on this is that tools that make sense are slowly getting adopted (that probably includes debhelper, cdbs, dpatch and quilt). The main difference between debhelper and the other tools is that the other tools don’t try to solve a problem for everybody. cdbs perfectly makes sense for some packages: the simple ones, where you only have to modify 4-5 lines in the output from dh_make to build properly.

Patch systems are also a good way to track changes made to upstream source, and probably encourage giving back patches to upstream. Note that my stats don’t include packages using cdbs’ simple-patchsys, so there are probably really close to 1/4 or 1/3 of our packages using some sort of patch system. How course, having simple-patchsys, dpatch and quilt sounds a bit stupid. But last time I checked, nobody took the time to blog a comparison of those tools, saying why {quilt,dpatch} is better than {simple-patchsys,dpatch,quilt}. Also, simple-patchsys probably makes a good-enough job for its users, so they don’t see the point in changing.

Of course, it’s easier to bury your head in the sand, and ignore the fact that those tools solve real problems for so many people and packages, and make their lives easier. :-)

Help us get rid of dash build failures in Debian!

Following my rebuild of all packages using /bin/dash as /bin/sh, we now have a nice list of bugs.

Those bugs are cool:

  • The relaxed NMU rules apply to them, since they are part of the dash release goal. Which means that they can all be fixed using 0-day NMUs.
  • Most of them are really easy to fix. (for many of them, a patch is already provided by Ubuntu)

So, if you want to get involved in Debian development, try to submit NMU patches for those bugs. If you want me to sponsor the upload, please Cc me when you submit the patch.

And even if you don’t care about Debian, but only about Ubuntu (which is fondamentally wrong, as everybody knows that Ubuntu is based on Debian), fixing these bugs also helps Ubuntu a lot: all those bugs hurt Ubuntu, since Ubuntu uses dash as /bin/sh by default, and, even if the packages in Ubuntu have been patched, it’s still causing additional work every time a new package is uploaded to Debian, and has to imported in Ubuntu.

If you have questions with the process, please ask them using the comments below.

I use the following process on those bugs, and it’s probably a good idea that you do the same if you intent to submit patches:

  • build the package with a chroot using bash
  • build the package with a chroot using dash (you can just use a different pbuilder tarball for that). Check that the problem can be reproduced.
  • fix the package
  • build the new package with a chroot using bash
  • build the new package with a chroot using dash
  • compare the built packages using debdiff for old_package_using_bash, new_package_using_bash, and new_package_using_dash. If the content doesn’t match, we have a problem.

If you submit NMU patches, please also have a look at the other bugs in the package, or at the lintian output. I don’t mind sponsoring small fixes for non-cosmetic/non-wishlist stuff at the same time.