Today I uploaded bash-completion 1:1.3-2 to the experimental branch of Debian. This package uses dpkg triggers to achieve an overdue goal: speedup shell loading by not even looking into completions for unavailable commands. The mechanism is simple: a trigger is activated when a package installs something in one of the usual $PATH directories, and it creates symlinks for the appropriate completions. This upload also features a change in the layout: completions were moved out of /etc/, so you won't be annoyed anymore during upgrades (and, let's say it, they shouldn't have been there since the beginning). However /etc/bash_completion.d/ is still around for compatibility reasons. If you want to enable a completion, just symlink it there from /usr/share/bash-completion/completions/. If there are enough requests, I might do a simple compenable/compdisable script to create them. I'd appreciate if adventurous people could test it, and report bugs (if any, hopefully). And don't be scared by the tons of messages about removed conffiles Please beware that the "detection mechanism" of appropriate completions is not entirely foolproof: it might need some hacking upstream (adding meta-headers to completion files?), so I'll try to improve it in future.

R 2.13.0 will be released tomorrow. It contains a new package by R Core member Luke Tierney: compiler. What a simple and straightforward name, and something that Luke has been working on for several years. The NEWS file says

    o Package compiler is now provided as a standard package.  See
      ?compiler::compile for information on how to use the compiler.
      This package implements a byte code compiler for R: by default
      the compiler is not used in this release.  See the 'R
      Installation and Administration Manual' for how to compile the
      base and recommended packages.

so the compiler is not yet used for R's own base and recommended packages. While working on my slides for the upcoming Rcpp workshop preceding R/Finance 2011, I thought of a nice test example to illustrate the compiler. Last summer and fall, Radford Neal had sent a very nice, long and detailed list of possible patches for R performance improvements to the development list. Some patches were integrated and some more discussion ensued. One strand was on the difference in parsing between normal parens and curly braces. In isolation, these seem too large, but (as I recall) this is due some things 'deep down' in the parser. However, some folks really harped on this topic. And it just doesn't die as a post from last week demonstrated once more. Last year, Christian Robert had whittled it down to a set of functions, and I made a somewhat sarcastic post argueing that I'd rather use Rcpp to get 80-fold speed increase than spend my time argueing over ten percent changes in code that could be made faster so easily. So let us now examine what the compiler package can do for us. The starting point is the same as last year: five variants of computing 1/(1+x) for a scalar x inside an explicit for loop. Real code would never do it this way as vectorisation comes to the rescue. But for (Christian's) argument's sake, it is useful to highlight differences in the parser. We once again use the nice rbenchmark package to run, time and summarise alternatives:

> ## cf http://dirk.eddelbuettel.com/blog/2010/09/07#straight_curly_or_compiled
> f <- function(n, x=1) for (i in 1:n) x=1/(1+x)
> g <- function(n, x=1) for (i in 1:n) x=(1/(1+x))
> h <- function(n, x=1) for (i in 1:n) x=(1+x)^(-1)
> j <- function(n, x=1) for (i in 1:n) x= 1/ 1+x 
> k <- function(n, x=1) for (i in 1:n) x=1/ 1+x 
> ## now load some tools
> library(rbenchmark)
> ## now run the benchmark
> N <- 1e6
> benchmark(f(N,1), g(N,1), h(N,1), j(N,1), k(N,1),
+           columns=c("test", "replications",
+           "elapsed", "relative"),
+           order="relative", replications=10)
     test replications elapsed relative
5 k(N, 1)           10   9.764  1.00000
1 f(N, 1)           10   9.998  1.02397
4 j(N, 1)           10  11.019  1.12853
2 g(N, 1)           10  11.822  1.21077
3 h(N, 1)           10  14.560  1.49119

This replicates Christian's result. We find that function k() is the fastest using curlies, and that explicit exponentiation in function h() is the slowest with a relative penalty of 49%, or an absolute difference of almost five seconds between the 9.7 for the winner and 14.6 for the worst variant. On the other hand, function f(), the normal way of writing things, does pretty well. So what happens when we throw the compiler into the mix? Let's first create compiled variants using the new cmpfun() function and then try again:

> ## R 2.13.0 brings this toy
> library(compiler)
> lf <- cmpfun(f)
> lg <- cmpfun(g)
> lh <- cmpfun(h)
> lj <- cmpfun(j)
> lk <- cmpfun(k)
> # now run the benchmark
> N <- 1e6
> benchmark(f(N,1), g(N,1), h(N,1), j(N,1), k(N,1),
+           lf(N,1), lg(N,1), lh(N,1), lj(N,1), lk(N,1),
+           columns=c("test", "replications",
+           "elapsed", "relative"),
+           order="relative", replications=10)
       test replications elapsed relative
9  lj(N, 1)           10   2.971  1.00000
10 lk(N, 1)           10   2.980  1.00303
6  lf(N, 1)           10   2.998  1.00909
7  lg(N, 1)           10   3.007  1.01212
8  lh(N, 1)           10   4.024  1.35443
1   f(N, 1)           10   9.479  3.19051
5   k(N, 1)           10   9.526  3.20633
4   j(N, 1)           10  10.775  3.62673
2   g(N, 1)           10  11.299  3.80310
3   h(N, 1)           10  14.049  4.72871

Now things have gotten interesting and substantially faster, for very little cost. Usage is straightforward: take your function and compile it, and reap more than a threefold speed gain. Not bad at all. Also of note, the difference between the different expressions essentially vanishes. The explicit exponentiation is still the loser, but there may be an additional explicit function call involved. So we do see the new compiler as a potentially very useful addition. I am sure more folks will jump on this and run more tests to find clearer corner cases. To finish, we have to of course once more go back to Rcpp for some <emph>real</emph> gains, and some comparison between compiled and byte code compiled code.

> ## now with Rcpp and C++
> library(inline)
> ## and define our version in C++
> src <- 'int n = as<int>(ns);
+         double x = as<double>(xs);
+         for (int i=0; i<n; i++) x=1/(1+x);
+         return wrap(x); '
> l <- cxxfunction(signature(ns="integer",
+                            xs="numeric"),
+                  body=src, plugin="Rcpp")
> ## now run the benchmark again
> benchmark(f(N,1), g(N,1), h(N,1), j(N,1), k(N,1),
+           l(N,1),
+           lf(N,1), lg(N,1), lh(N,1), lj(N,1), lk(N,1),
+           columns=c("test", "replications",
+           "elapsed", "relative"),
+           order="relative", replications=10)
       test replications elapsed relative
6   l(N, 1)           10   0.120   1.0000
11 lk(N, 1)           10   2.961  24.6750
7  lf(N, 1)           10   3.128  26.0667
8  lg(N, 1)           10   3.140  26.1667
10 lj(N, 1)           10   3.161  26.3417
9  lh(N, 1)           10   4.212  35.1000
5   k(N, 1)           10   9.500  79.1667
1   f(N, 1)           10   9.621  80.1750
4   j(N, 1)           10  10.868  90.5667
2   g(N, 1)           10  11.409  95.0750
3   h(N, 1)           10  14.077 117.3083

Rcpp still shoots the lights out by a factor of 80 (or even almost 120 to the worst manual implementation) relative to interpreted code. Relative to the compiled byte code, the speed difference is about 25-fold. Now, these are of course entirely unrealistic code examples that are in no way, shape or form representative of real R work. Effective speed gains will be smaller for both the (pretty exciting new) compiler package and also for our C++ integration package Rcpp. Before I close, two more public service announcements. First, if you use Ubuntu see this post by Michael on r-sig-debian announcing his implementation of a suggestion of mine: we now have R alpha/beta/rc builds via his Launchpad PPA. Last Friday, I had the current R-rc snapshot of R 2.13.0 on my Ubuntu box only about six hours after I (as Debian maintainer for R) uploaded the underlying new R-rc package build to Debian unstable. This will be nice for testing of upcoming releases. Second, as I mentioned, the Rcpp workshop on April 28 preceding R/Finance 2011 on April 29 and 30 still has a few slots available, as has the conference itself.

There are rumors that people have successfully integrated ikiwiki with pootle. So where is the code?

All my notebooks till today have been ThinkPads from the T series, sadly Lenovo decided (or, maybe, were persuaded) to go with nVidia GPUs for their current designs (T5xx). That's sad, because nVidia doesn't cooperate with the FLOSS world. I still wanted a ThinkPad with up-to-date parts. That left me with the Edge series, which is designed to be the bridge between consumer and business models. After some searching I settled on the NVLJ6GE model (the last two letters just indicate, that this is the "German" variant). The key specs are Intel Core i5-480M, 4096 MB RAM, AMD Mobility Radeon HD 5145, Intel WLAN module and a non-glare display. Now to the part about running and installing Debian testing on this. Judging from the hardware I was pretty sure, that getting all hardware (i.e. all hardware I'd be using; e.g. I'm not using WiMax or the integrated web cam so far, which means I've dectivated them in the BIOS) up and running. and I'm happy to report, that this is true. The installation was really straight forward (netinstall CD in expert mode (64 bit), running through all steps and booting, that's it). I did the install over a wired network, mainly because this is faster for me, but with an USB stick and the firmware for the Intel Centrino module a installation over the wireless interface should work too. I'm now running a slightly customized setup (e.g. my own 2.6.38.2 kernel and Mesa 7.10.2, the X from experimental), but not because some serious problems with Wheezy. So far I can recommend this ThinkPad for usage with Debian (or Linux in general), though, if you don't want a "big" GPU, you might be happier with a T or L series model. They should run somewhat longer with the default battery (Lenovo 25+ with six cells). As for the service for this line I can't say anything yet, but as it's still a ThinkPad, I hope it'll be as for the other ThinkPad series.

A long list, and you want to process its items n at a time; easy, but how to split that list in sublists of n elements (except the last one, of course)?

I looked a bit into the stdlib but it doesn't seem to exist anything I could use (oh, did I say I'm still on 2.4?) so I directed my research to Google, and found a nice recipe at ActiveState, but it has the problem it discards the last list, if it has less than n items.

Searching again, I got more lucky with this article: it's a generator of tuples from a list, splitting every n elements and optionally return the last semi-full tuple. I slightly modified it to obtain:

def group_iter(iterator, n=2):
    """ Given an iterator, it returns sub-lists made of n items
    (except the last that can have len < n)
    inspired by http://countergram.com/python-group-iterator-list-function"""
    accumulator = []
    for item in iterator:
        accumulator.append(item)
        if len(accumulator) == n: # tested as fast as separate counter
            yield accumulator
            accumulator = [] # tested faster than accumulator[:] = []
            # and tested as fast as re-using one list object
    if len(accumulator) != 0:
        yield accumulator

How would you have done it?

I often see on debian-perl IRC changelog related to e-mail changes. For instance, when a Debian contributor becomes a Debian developer, he often wants to change his old e-mail address in his brand new debian e-mail address. This change is mostly done while updating packages to fix bugs or ship a new upstream releases. Since this change is trivial and mostly boring, forgetting about it is likely. Well, at least, that s true for the author of this blog who did have to change he e-mail address recently. The last version Config::Model Perl module (and its Dpkg model) offers a way to automatically perform this boring update task for you while you work on more interesting problems. Dpkg model now provides a bunch of meta Dpkg parameters. These Meta parameters are used to customize the behavior of the Dpkg editor tool to suit your needs. Among these parameters, the email-updates meta parameters enable you to specify which email address to update and how. Here s a screenshot of config-edit GUI invoked on a package (with config-edit -application dpkg): In this case, all occurrences of the dominique.dumont email will be replaced with the new domi.dumont email in the control and in the copyright file. You can change or add new addresses using the GUI. When the package data (i.e. control, copyright and source) is saved, all meta information is also saved. Meta dpkg data is saved in its own file, so the email change will be applied to all packages you will be working on: E-mail address changes can also be specified in a command line:

$ config-edit -application dpkg \
  'meta email-updates:"domi@old.fr"="dod@new.fr"' \
 -ui none -save

Note: this command must be run in a source package directory. This new address change is stored in ~/.local/share/.dpkg-meta.yml or ~/.local/share/.dpkg-meta.yml:

---
email-updates:
  domi@old.fr: dod@new.fr

From now on, anytime you run config-edit -application dpkg (and save the data) while you work on a package, all occurrences of your old e-mail adress in debian.control will be changed with the new email address. All the best

With all the buzz around GNOME 3, I really wanted to try it out for real on my main laptop. It usually runs Debian Unstable but that s not enough in this case, GNOME 3 is not fully packaged yet and it s only in experimental for now. I asked Josselin Mouette (of the pkg-gnome team) when he expected it to be available and he could not really answer because there s lots of work left. Instead Roland Mas gently answered me Sooner if you help . First steps as a GNOME packager This is pretty common in free software and for once I followed the advice, I spent most of sunday helping out with GNOME 3 packaging. I have no prior experience with GNOME packaging but I m fairly proficient in Debian packaging in general so when I showed up on #debian-gnome (irc.debian.org) on sunday morning, Josselin quickly added me to the team on alioth.debian.org. Still being a pkg-gnome rookie, I started by reading the documentation on pkg-gnome.alioth.debian.org. This is enough to know where to find the code in the SVN repository, and how to do releases, but it doesn t contain much information about what you need to know to be a good GNOME packager. It would have been great to have some words on introspection and what it changes in terms of packaging for instance. Josselin suggested me to start with one of the modules that was not yet updated at all (most packages have a pre-release version usually 2.91 in experimental, but some are still at 2.30). Packages updated and problems encountered (You can skip this section if you re not into GNOME packaging) So I picked up totem. I quickly updated totem-pl-parser as a required build-dependency and made my first mistake by uploading it to unstable (it turns out it s not a problem for this specific package). Totem itself was more complicated even if some preliminary work was already in the subversion repository. It introduces a new library which required a new package and I spent a long time debugging why the package would not build in a minimalistic build environment. Indeed while the package was building fine in my experimental chroot, I took care to build my test packages like the auto-builders would do with sbuild (in sid environment + the required build-dependencies from experimental) and there it was failing. In fact it turns out pkg-config was failing because libquvi-dev was missing (and it was required by totem-pl-parser.pc) but this did not leave any error message in config.log. Next, I decided to take care of gnome-screensaver as it was not working for me (I could not unlock the screen once it was activated). When built in my experimental chroot, it was fine but when built in the minimalistic environment it was failing. Turns out /usr/lib/gnome-screensaver/gnome-screensaver-dialog was loading both libgtk2 and libgtk3 at the same time and was crashing. It s not linked against libgtk2 but it was linked against the unstable version of libgnomekbdui which is still using libgtk2. Bumping the build-dependency on libgnomekbd-dev fixed the problem. In the evening, I took care of mutter and gnome-shell, and did some preliminary work on gnome-menus. Help is still welcome There s still lots of work to do, you re welcome to do like me and join to help. Come on #debian-gnome on irc.debian.org, read the documentation and try to update a package (and ask questions when you don t know). Installation of GNOME 3 from Debian experimental You can also try GNOME 3 on your Debian machine, but at this point I would advise to do it only if you re ready to invest some time in understanding the remaining problems. It s difficult to cherry-pick just the required packages from experimental, I tried it and at the start I ended up with a bad user experience (important packages like gnome-themes-standard or gnome-icon-theme not installed/updated and similar issues). To help you out with this, here s a file that you can put in /etc/apt/preferences.d/gnome to allow APT to upgrade the most important GNOME 3 packages from experimental:

Package: gnome gnome-desktop-environment gnome-core alacarte brasero cheese ekiga empathy gdm3 gcalctool gconf-editor gnome-backgrounds gnome-bluetooth gnome-media gnome-netstatus-applet gnome-nettool gnome-system-monitor gnome-system-tools gnome-user-share baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-system-log gstreamer0.10-tools gucharmap gvfs-bin hamster-applet nautilus-sendto seahorse seahorse-plugins sound-juicer totem-plugins remmina vino gksu xdg-user-dirs-gtk gnome-shell gnome-panel dmz-cursor-theme eog epiphany-browser evince evolution evolution-data-server file-roller gedit gnome-about gnome-applets gnome-control-center gnome-disk-utility gnome-icon-theme gnome-keyring gnome-menus gnome-panel gnome-power-manager gnome-screensaver gnome-session gnome-settings-daemon gnome-terminal gnome-themes gnome-user-guide gvfs gvfs-backends metacity mutter nautilus policykit-1-gnome totem yelp gnome-themes-extras gnome-games libpam-gnome-keyring rhythmbox-plugins banshee rhythmbox-plugin-cdrecorder system-config-printer totem-mozilla epiphany-extensions gedit-plugins evolution-plugins evolution-exchange evolution-webcal gnome-codec-install transmission-gtk avahi-daemon tomboy network-manager-gnome gnome-games-extra-data gnome-office update-notifier shotwell liferea epiphany-browser-data empathy-common nautilus-sendto-empathy brasero-common
Pin: release experimental
Pin-Priority: 500
Package: *
Pin: release experimental
Pin-Priority: 150

The list might not be exhaustive and sometimes you will have to give supplementary hints to apt for the upgrade to succeed, but it s better than nothing. I hope you find this useful. I m enjoying my shiny new GNOME 3 desktop and it s off for a good start. My main complaint is that hamster-applet (time tracker) has not yet been integrated in the shell.

21 comments Liked this article? Click here. My blog is Flattr-enabled.

* Dear Lazyweb, I have Macbook (Late 2008) model running Debian Sid + Mac OS X (sigh!) and I m facing nice issues which prevents me to full use of disk. They re: 1. CD-ROM drive doesn t work. So, if I want to upgrade to Snow Leopard or anything else, there is no other way. 2. Disk is 160 GB, I want to upgrade to better disk (say with better speed, capacity). Is there any way to clone entire disk (with partition preserved) and use it? Remember: I don t have CD-ROM 3. Is there any way to wipe-out Mac OS X and running Debian with hardware acceleration? I ve noticed that if you single boot Debian, it lacks Video acceleration. Any pointers towards above 3 is appreciate. I ll hostname my computer if you help me to fix this

This is the tenth Debian XSF News issue. It is basically meant to be a follow-up to DXN#9.

1. I completed the addition of the Sinhala language, and also dealt with big changes on the xkb-data (a.k.a. xkeyboard-config) side, as explained by Sergey Udaltsov. Protocol:
   • [KiBi] x11proto-core: the upload to experimental was a bit overcautious, so upload again unstable.
   Data:
   • [KiBi] xkb-data 2.1: been in experimental for a while, changes were announced to debian-boot@ unstable.
   • [KiBi] xkb-data 2.2.1: new upstream release, which breaks older libx11-6; also announced to debian-boot@ experimental.
   Library:
   • [KiBi] libx11: new upstream release, adding support for Sinhala unstable.
2. The Graphical Installer started receiving improved portability. There were a few patches floating around adding udebs for generic drivers for non-Linux architectures. I cleaned them up a bit (especially on the vesa side, getting rid of libdrm entirely), got them test-built on a kfreebsd-amd64 box, while Samuel Thibault was doing the same on a hurd-i386 box. I raised the topic on debian-boot@, debian-bsd@, and debian-hurd@, mentioning the remaining steps. Drivers (all accepted by ftpmasters after a tiny trip to the NEW queue):
   • [KiBi] xserver-xorg-input-keyboard experimental.
   • [KiBi] xserver-xorg-input-mouse experimental.
   • [KiBi] xserver-xorg-video-vesa experimental.
3. Here are some other packages which got updated. Applications:
   • [Julien] x11-xserver-utils: Julien did everything for DSA-2213 unstable, squeeze-security, lenny-security.
   Library:
   • [Chris,Julien,KiBi] mesa 7.10.1: long-awaited upload, finally checked, built, and uploaded experimental.
4. Finally, let s mention migration to testing (from now on I ll use testing instead of wheezy so that it s clear it s about week after week migrations to the testing distribution, rather than our final plans for the next stable release). After a while, and thanks to some hand-holding from our nice release managers (hi, Adam!), linux-2.6, libdrm, mesa, xorg-server, and several dozen drivers migrated to testing. Yay!
5. As a consequence, some other packages got updated shortly after the successful britney run (because they were prepared right before, just in case). Libraries:
   • [KiBi] libdrm: replace 2.4.23 with 2.4.24 (which was in experimental previously) unstable.
   • [KiBi] mesa: new stable release, 7.10.2 supersedes both 7.10 in unstable and 7.10.1 in experimental (see above) unstable.
   • [KiBi] pixman: new development snapshot, 0.21.6 comes from experimental and supersedes 0.21.4 unstable.
   Drivers:
   • [KiBi] xserver-xorg-input-vmmouse: new upstream release, functionally the same as the last release candidate unstable.
   • [KiBi] xserver-xorg-video-ati: new upstream release, was waiting for the migration to happen, see second bullet of DXN#9 unstable.
   • [KiBi] xserver-xorg-video-intel: new upstream release, same story as for the ati driver unstable.

As already blogged by Riku, getting replaced by script is really great! Until now, I ve had a crontab fetching my supporting-very-big-mails (up to 100MB or so) mailbox every few minutes, and looking into my =incoming-buildd/ maildir on a very regular fashion. With some simple mutt maildir hooks, replying to a Successful log would trigger extracting the changes file from there, setting some options, like PGP inline signing, and the mail would be ready to go back to the buildd. That part was just about being a GPG-signing monkey, so really not a funny part. Since we no longer have to worry about this boring and time-consuming task, I ve switched to a crontab firing up 4 times a day, and I try to deal with all incoming mails at once. Coupled with the new filters (e.g. on out-of-date packages on the buildd status page), I started using my time to file FTBFS bugs again, so that maintainers notice their packages fail to build without having to wait for a non-happening testing migration. After 10 days, the following mutt filter in =debian-bts/ lists 69 bugs:

~s "Bug#.*FTBFS" ~P ~d 01/04/2011-

(Subject contains Bug#.*FTBFS, mails from me, starting from 01/04/2011.) Figuring out whether that s due to another package s bug, an outdated chroot, a temporary glitch, etc. might take some time; that s why it s a bit hard to stay on top of things; and when the backlog grows up, motivation to go through this tedious task can be pretty low, especially when one sees repeated mistakes. I hope the amount of (possible) use cases for #620686 will decrease over time; instead, I d be very happy if maintainers could at least check what s mentioned in configure.ac/configure.in. Keeping an eye on its diff between upstream versions should be easy enough. ;)

About a week ago, I wrote about doing cross package checks in Lintian. At that time I had only played with looking up manpages in direct dependencies, which I hope will greatly improve the current binary-without-manpage stats (around 677 packages and 2750ish tags incl. overrides). Today, I decided to take on another challenge. Detection of circular dependencies between binary packages (created from the same source). We already have a little library for building dependency relationships; however I ended up not using it, since it has an important limitation. It cannot tell how the circular dependencies relate to each other. Let me demonstrate what I mean with an example. Suppose we have a couple packages that depend on each other like this:
pkg-core => pkg-A, pkg-D
# circle 1: A, B, C
pkg-A => pkg-B
pkg-B => pkg-C
pkg-C => pkg-A # circle 2: D, E, F
pkg-D => pkg-E
pkg-E => pkg-F
pkg-F => pkg-D
In this case, our current tool will be able to tell that all packages (possibly except root I did not check) are in a circular relationship. However, we can find better results by pretending we are trying to find Strongly Connected Components (actually that is exactly what we are trying to do here). So today, I implemented Tarjan s algorithm in Perl to solve this particular issue and committed it to my Lintian branch. If this branch is merged into the Lintian master branch, we can close #316283.

Took a trip to Delamere Forest today for a walk and to get a shot for this week. I got a couple of shots I liked, so I decided to post an extra one this week. The first shot shows a couple of rows of tree stumps in the lake. This image is the first shot I took today just alongside the car park.

Spammer Number 2:Tata Technologies (aka myigetit.com) via Streamsend Again, it looks like Streamsend are being spamming bastards. Guilty of: spamming lots of Debian mailing lists. They claim to offer "Online Self-Paced Training for Engineers". I guess that's training in "how to be obnoxious to people on the internet" then. It looks like it's a good idea to simply drop all connections from machines in the mailengine1.com domain. Following up through whois, that's another domain owned by EZ Publishing, the same folks who own streamsend.com. Spamming bastards all over...

At about 12:45 today, I completed my third Paris Marathon and my 7th marathon overall (incl. 2 unofficial ones, ran alone). As I wrote earlier, the challenge this year was not breaking a record. I wanted to complete two long races in only two week, as a gift for my birthday that happened between both. So, after Paris Paris Ecotrail 55km race, I ran my beloved Paris Marathon. So, I ended up in 3h54'37", 5 minutes more than last year and 14 minutes more than my personal best The heat was the ennemy, today. A wonderful sun was shining over Paris, which is nice....but brings the temperature up to 23 C. So, the solution had to be "drink, drink, drink". I think I drank something like 4 liters, today. I was planning to start around 5'25/km but finally ended up with about 5'20", which I sustained up to km 25 and the terrible Louvre tunnel (1km in a tunnel on the right bank speedway, under Quai du Louvre). That one was a killer this year and many runners blew up in it. I then decided to use the opportunity to walk a little bit, eat my mid-marathon glucides and slow down slightly later on for the upcoming tunnels (two more...though less long). That was in some way the famous 30km wall, which, for me, was moved to km28..:-) Later on, as usual, courage enters the game and I roughly managed to keep a 5'30"-5'45" pace up to the end of the race. Cramps signs appeared around km 35 but, here again, a wise slowdown and some walking, a lot of drinking helped me in controlling them. Finally, the result is about what I intended to do. Over 4h, I would have been disappointed even if happy to finish (as everybody tells me that my challenge was kinda crazy). Abandoning would have been the real defeat. I did not..:-) And, thanks, of course, to my beloved Elizabeth who again managed to deal with his "Kiki" logistics, includiung waking up at 6am on a Sunday. Now, my running schedule will slow down a little with only training for 5 weeks. Next race: Trail des Cerfs, a 35km trail in Rambouillet Forest close to home. I may again schedule a solo marathon, at training pace, end of May, in Versailles Castle park. Next marathon: Berlin, Sept 25th. Here, the goal is breaking the personal best and head up to 3h35.

I d like to paint you a picture of the sorts of things that have been going on around here the past few months, and with growing fervor the past few days. I ll start with church basements. Possibly a little chilly, but with a bunch of women getting together to make some quilts along with some conversation, maybe some snacks. Or perhaps about hundreds of kitchens throughout Kansas, warm with baking pies, cookies, breads, and all sorts of items. Then there are a bunch of wood shops, turning up sawdust, building things from toys to furniture. Or even a body shop donating its time and materials to put some finishing touches on a classic car. I ve also seen around 300 men getting together to practice for a men s chorus concert. I know there was large crowd of people gathering to make verenike. People always wind up running 5km on a particular Saturday morning, rain or shine. Or ride 35 miles on a bicycle on a different Saturday. Or even help build a house using as much volunteer labor and donated materials as possible. And then, of course, comes this week, where Mennonites from all over Kansas start to converge on Hutchinson, KS. I can imagine you might see some odd sights rolling down the road: a vehicle called the borscht buggy for preparing large quantities of the delicious soup. Several old tractors being hauled down the road on trailers. Semi loads of food. Vanloads of pie and cookies. Plants, trees, rugs, quilts, even a lawn mower. And then, yesterday and today, excited people ready to buy all of these things. Families with children excited to get a ride on the largest slide they ve ever seen. And, of course, so many people wanting to eat the famous food that, despite the many parallel serving areas, lines still can extend for blocks. It s all because people are hungry. Not these Kansans with pie-laden kitchens, though it s to help those in need. It s all part of the annual Kansas MCC Relief Sale. The idea is that people make, bake, build, sing, or give things to the sale. The items are then sold, and the proceeds go to Mennonite Central Committee, one of the world s most efficient charities. MCC not only helps with directly bringing people out of hunger, but also supports sustainable projects, such as building hand-operated wells to give those in need a safe source of drinking water. Virtually all of the money you spend on those pies winds up helping someone in poverty. Each year, the relief sale and related events raise around half a million dollars for charity. It s not unusual to see a quilt sell for thousands of dollars. Most of the things sell at more normal prices, but last year someone decided to add a loaf of bread to an auction and it sold for $100. And so it was this that we took the boys to today. We started with the Feeding the Multitude a wonderful meal with some traditional Kansas Mennonite food. Here s a photo: That bread is zwieback, then there is cherry moos, bohne berrogi, verenike, and of course, sausage. Here are Jacob and Oliver enjoying their food: After that, we went over to the giant slide. I m not sure how many stories tall it is, but it s big enough that they have a strip of carpet there at the bottom to slow people down at the end. Here s a photo of Jacob on my lap after going down the slide. If you zoom in, you can see the giant smile on his face. After that, we hopped on the mass transit at the sale: a wagon being pulled by a tractor. We checked out the general auction, with Jacob wanting to be sure to peer under the hood of each car present. Then after a stop to buy some kettle corn for Jacob, we checked out the plants, quilt auction, and then on to buy cheese curds. After another stop at the slide, it was time to head home. And then tomorrow is a concert of the Kansas Mennonite Men s Chorus (motto: We Sing That Others May Live). You get around 300 men on a stage signing together and wow no recording can do it justice. It s amazing to hear the power of the choir at the loud parts, but still more amazing to listen to 300 men signing as softly as they possibly can. I ve been singing with that choir for 3 years, and we ve been practicing for a few months now. If you ever hear some Mennonites boasting about something, it s probably going to be about how much money they ve raised for charity. And on that note, I ll nudge those Indiana folks reading this and point out that you have some catching up to do with the Kansas sale

This is the ninth Debian XSF News issue. As can be seen below, I m not yet decided how to present various items. This time, I ll try to gather all updated packages since the previous issue, grouped by category, with a single line summary. Lengthy comments come after that list of updated packages.

1. Here come the updated packages, with contributors/uploaders between square brackets (Timo = Timo Aaltonen, JVdG = Julien Viard de Galbert, Robert = Robert Hooker). Protocol:
   • [KiBi] x11proto-core: new upstream release, bringing Sinhala support experimental.
   Libraries:
   • [Timo,KiBi] libx11: new upstream release, fixing some hang issues unstable.
   • [KiBi] libxi: new upstream release unstable.
   • [KiBi] libxkbcommon: finally accepted by ftpmasters, needed for wayland experimental.
   Server:
   • [KiBi] xorg-server: stable release 1.9.5, unlikely to cause regressions from the previous release candidate; in other words: a good candidate for testing if the Linux kernel migrates some day unstable.
   • [KiBi] xorg-server: first release candidate for the first stable bugfix release in the 1.10 series, which finally builds experimental.
   Drivers:
   • [KiBi] xserver-xorg-input-mouse: two cherry-picks of upstream commits to fix Hurd support, thanks to Samuel Thibault unstable.
   • [KiBi] xserver-xorg-input-mouse: rebuild of the unstable version against experimental s server experimental.
   • [KiBi] xserver-xorg-video-ati: new upstream release experimental.
   • [KiBi] xserver-xorg-video-intel: new upstream release candidate experimental.
   • [JVdG] xserver-xorg-video-openchrome: new upstream snapshot, and build fix for Hurd unstable.
   Others:
   • [KiBi] xorg: originally a few tweaks to make it possible to install X on Hurd unstable
   • [KiBi] xorg: but wkhtmltopdf failed on several buildds, so I disabled PDF generation, and completed the switch to asciidoc mentioned in DXN#8 unstable.
   • [KiBi] xorg-sgml-doctools: new upstream release, adds support for docbook external references unstable.
   • [Robert,KiBi] xutils-dev: new util-macros release, and a version lookup file unstable.
2. Why am I carefully uploading video driver packages to experimental only? Because bad regressions happen, on a regular basis; so it seems quite nice to keep well-tested versions in unstable for now. Once the X stack has migrated to testing (which as explained in DXN#7 and DXN#8 is waiting for the Linux kernel to migrate), new versions in unstable are welcome, so that one can tell easily whether bugs with those versions are regressions from the versions available in testing. In the meanwhile, one can build packages from the git repositories, using the debian-unstable branch (which is the default).
3. Why am I so rash then, uploading input drivers to unstable as they are released? First of all, our waiting for the kernel means we have no issues on the 10-day delay front. Second of all, input bugs are usually fixed very quickly upstream (you can go there and thank Peter Hutterer in particular). So staying very close to whatever upstream ships makes some sense.
4. Why am I uploading drivers twice? Since it isn t specific to the current situation, but a general question when it comes to supporting two versions of the server in parallel, I decided to document that in an handling multiple server versions thanks to experimental page. The answer to this specific question is available in the note at the bottom of that page.

See you in a few days for a follow-up Debian XSF News issue.

I've released man-db 2.6.0 (announcement, NEWS, ChangeLog), and uploaded it to Debian unstable. Ubuntu is rapidly approaching beta freeze so I'm not going to try to cram this into 11.04; it'll be in 11.10.

Registrations for DebConf11 are now open!

Dear guests, attendees and contributors, we are happy to announce that registrations for this year s Conference are now open. The instructions for registration process can be found under Register page. While the basic registrations will not close until the end of the Conference, sponsored registrations however, have the deadline. If you would like to apply for sponsored attendance, then it is imperative that you do it before 8th May! Should you have any further questions regarding registrations, please mail them at registration@debconf.org.

Call for Contributions!

We invite submissions of proposals for papers, presentations, discussion sessions and tutorials for Debconf11. Submissions don t have to be limited to traditional talks, you could propose a performance, art installation, debate, or anything else. Official submissions will be accepted until May 8th 2011, 23:59 UTC. For more information, please visit Call for contributions page.

I am going to Berlin to give a talk at Re:Publica and will be there from Monday through Thursday (11th-14th of April). I am interested in getting together with Debian developers so please contact me if interested. Feel free to leave a comment about your favorite things to do in Berlin as well as I might have a day or two to check out the sites.