There's nothing better than listening Manu Chao's "Radio Bemba Sound System" during a family meal at home. And, later on, while working on a new font package for Uyghur language. And, I say, Piwet.

Since I m soliciting donations to support my Debian work, the least I can do is explain what I do. You can thus expect to see an article like this one every month. Multi-Arch work I updated the code to use another layout for the control files stored in /var/lib/dpkg/info/. Instead of using a sub-directory per architecture (arch/package.type), we decided to use package:arch.type but only for packages which are Multi-Arch: same. dpkg is taking care to rename the files the first time it is executed with write rights and then updates /var/lib/dpkg/info/format to remember that the upgrade has been done and that we can rely on the new structure. I filed a few bugs on packages that are improperly accessing those internal files instead of using the appropriate dpkg-query interface. I sent a heads-up mail on -devel to make other people aware of those problems in the hope to discover most of them as early as possible. After that, the work stalled because Guillem went away for 2 weeks and thus stopped his review of my work. I hope he will quickly resume the review and that we will get something final this month. With the arrival of dpkg 1.16.0, it s now possible to start converting libraries to multi-arch even if full multi-arch support has not yet landed in dpkg proper. See http://wiki.debian.org/Multiarch/Bootstrapping for the detailed plan. If you re curious about Multi-Arch, you might want to read this article of Steve Langasek as well. Bug triage for dpkg in launchpad At the start of the month, there was close to 500 bugs reported against the dpkg package in Launchpad. Unfortunately most of it is noise many of the reported bugs are misfiled, they show an upgrade problem of a random package and that upgrade problem confuses update-manager which tries to configure an already configured package. This generates a second error that apport attributes to dpkg and the resulting bug report is thus filed on dpkg. There are literally hundreds of those that have to be reclassified. Michael Vogt and Brian Murray did some triaging, and I also spend quite some hours on this task. It s a bit frustrating as I tend to mark many reports Incomplete because there s no way they can be acted upon and many of them are so old that the reporter is unlikely to be able to provide supplementary information. But in the middle of this noise, there are some useful bug reports, like LP#739179 which enabled me to fix a regression even before it reached Debian Unstable (because Ubuntu runs a snapshot of dpkg with multiarch support). I subscribed to the Launchpad bugs for dpkg via the Debian Package Tracking System (thanks to the derivatives-bugs keyword) and will try to keep up with the incoming reports. Misc dpkg work The ftpmasters came up with a request for a new field (see 619131) in source packages. After a quick discussion and a round of review on debian-policy@l.d.o, I implemented the new Package-List field. This should allow the ftpmasters to save some time in NEW processing, but we deferred the change for the next dpkg version (1.16.1) to ponder a bit more on the design of the field. I also fixed a bunch of bugs (#619541, #605719, #598922, #616096) and merged a patch of Mark Hymers to recognize the new Built-Using field. Developers-reference work The review process for changes to the developers-reference is not working as it should. And I suffered from it while trying to integrate the patch I wrote for the Developer duties chapter (see #548867). We purposely changed the maintainer field from debian-doc to debian-policy in the hope to have more reviews of suggested changes and to seek some sort of consensus before committing anything. But we don t get more reviews and deciding to commit a patch is now even harder than it was (except for trivial stuff where personal opinions can t interfere). In my case, I only got the feedback of Charles Plessy which was very mixed to say the least. I tried to improve my patch based on what he expressed but I also clearly disagreed with some of his assertions and was convinced that my wording was in line with the dominant point of view within Debian. We tried to involve the release team in the discussion because most of what I documented was about helping making stable release happen, but nobody of the team answered. Instead of letting the situation (and my patch) rot, I solicited feedback from the DPL and from another developers-reference editor to see whether my patch was an improvement or not. After some more time, I went ahead and committed it. It was not pleasant for anyone. I don t know how we can improve this. Contrary to the policy, the developers-reference is a document that is not normative, I believe the result is better when we put some soul into it. But it s a real challenge when you seek a consensus and that the interest in reviewing changes is so low. DVD shop listed on debian.org In February, I launched a DVD shop whose benefits are used to fund my Debian work. Shortly after the launch I used the official form to be added to the official listing of Debian CD vendors and offered a few suggestions to deal with vendors who are selling unofficial images (with firmware in my case). A few weeks later, I got no answers: neither for my request nor for my suggestions, I mailed the cdvendors@debian.org team directly asking for a status update and quickly got an answer suggesting that Simon Paillard usually does the work and can t process the backlog due to some injury. At this point no concerns had been raised about adding me to the list. To save some time and some work for the team, I added myself to the list since I had commit rights and I informed them that I did it, so that they can review it. Shortly after I did that, Martin Zobel Helas objected to my addition. I cleared some misunderstandings but the discussion also lead to some changes to please everybody: the listing now indicates that some images are unofficial and I have prepared a special landing page for people coming from the Debian website through this listing. Debian column on OMG! Ubuntu I have always been a firm believer that it s important for Debian to reach out to the widest public with its message of freedom. Thus when Benjamin Humphrey contacted the debian-publicity team to find volunteers to write a Debian column on OMG! Ubuntu, I immediately jumped in. I wrote 4 articles over there. The tone is very different from my articles on my blog and I like that duality. Check out Debian is dying! Oh my word!, Debian or Ubuntu, which is the best place to contribute?, Are you contributing your share? and Ubuntu s CTO reveals DEX: an effort to close the gap with Debian. It s a great win-win situation, OMG! Ubuntu benefits from my articles, Debian s values are relayed further, and OMG! Ubuntu s large audience also helps me develop my own blog. Work on my book I had lots of paperwork to do this month (annual accounting stuff for my company) and I did not have as much time as I hoped for my book. Still I have a updated a few more chapters of my French book and I certainly hope to complete the update during April. This means that the work on the English translation could start in may. Work on my blog Just like for my book, it has been relatively difficult for me to cope with my policy of two articles every week. But I still managed to get quite some good stuff out. I interviewed Christian Perrier (Debian s translation coordinator) and also Bdale Garbee (chair of Debian s technical committee). I finished my series of Debian Cleanup Tips with 2 supplementary articles:

• Identify cruft that can be removed from your Debian system
• Remove automatically installed packages

The removal of firmware is causing troubles to quite some users so I wrote an article explaining how to deal with the problem. A regular reader also asked me to write an article about Jigdo, I executed myself because it was a good idea and that he has been very nice with me: Download ISO images of Debian CD/DVD at light speed with Jigdo. Last but not least, I shared my package maintainer pledge which inspired my developers-reference patch (see discussion above). Thanks Many thanks to all the people who showed their appreciation of my work. The 324.37 EUR that you gave me in February represented 2 days and a half of my time that I have spent working on the above projects. See you next month for a new summary of my activities.

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

After getting past a series of silly errors gjay version 0.3.2 is now available. The source code was uploaded to SourceForge and the debian package has been uploaded to the FTP master site. This version fixes the linking bug that have been extensively reported in a lot of Debian packages. This is where you are using symbols of a library from another but not explicitly linking to it. It means some versions of GCC will fail to link. gjay will now create playlists for Music Player Daemon or mpd and get mpd to run them too. It does need for mpd and gjay to be on the same computer, or at least the same directory structure, so both programs know what file is. While gjay has a full view of the filesystem, mpd uses a relative one off its own concept of a root directory. As a result of the two music players, both the audacious and mpd client libraries are not linked to gjay but are linked at runtime using dlsym(). It means you don t need the audacious libraries if you like mpd or vice versa. I m not that experienced in using dlsym so hopefully I ve not stuffed it up; it works for me! In theory, gjay could pass its playlists onto other music players. The problem is knowing how to get the list into the player. After it does its sorting and randomising, gjay ends up with a linked list of file-names. Now for audacious or (with some caveats) mpd it is pretty simple because they use file-names but others don t do this. If you know how it is done with your favourite player then let me know.

... to the degree that you may get unsolicited e-mails from Canonical flunkies, asking about your project timeline and status on an Ubuntu bug that is so crucial that it needs its very own project manager, but which isn't important enough to forward to the Debian bug tracker. At the time I got the e-mail, I had already decided to give up on d-i development, so I had a brief gape at the sheer chutzpah of the thing and deleted it. In retrospect, I shouldn't have done that. I've needed a good laugh a few times since then, and re-reading that e-mail would have done nicely. Anyone got one of these e-mails that they kept, so I can keep the lulz going 4eva? E-mail me.

Inspired by World Backup Day, I decided to take a backup of my laptop. Thanks to using a free operating system I don't have to backup any of my software, just configuration and data files, which fit on a single DVD.

In order to avoid worrying too much about secure storage and disposal of these backups, I have decided to encrypt them using a standard encrypted loopback filesystem.

(Feel free to leave a comment if you can suggest an easier way of doing this.)

Cryptmount setupInstall cryptmount:

apt-get install cryptmount

and setup two encrypted mount points in /etc/cryptmount/cmtab:

backup  
  dev=/backup.dat
  dir=/backup
  fstype=ext2    fsoptions=defaults     cipher=aes

  keyfile=/backup.key
  keyhash=sha1    keycipher=des3
 

testbackup  
  dev=/cdrom/backup.dat
  dir=/backup
  fstype=ext2    fsoptions=defaults    cipher=aes

  keyfile=/cdrom/backup.key
  keyhash=sha1    keycipher=des3
 

Initialize the encrypted filesystemMake sure you have at least 4.3 GB of free disk space on / and then run:

mkdir /backup
dd if=/dev/zero of=/backup.dat bs=1M count=4096
cryptmount --generate-key 32 backup
cryptmount --prepare backup
mkfs.ext2 -m 0 /dev/mapper/backup
cryptmount --release backup

Burn the data to a DVDMount the newly created partition:

cryptmount backup

and then copy the files you want to /backup/ before unmounting that partition:

cryptmount -u backup

Finally, use your favourite DVD-burning program to burn these two files:

• /backup.dat
• /backup.key

Test your backupBefore deleting these two files, test the DVD you've just burned by mounting it:

mount /cdrom
cryptmount testbackup

and looking at a random sampling of the files contained in /backup.

Once you are satisfied that your backup is fine, umount the DVD:

cryptmount -u testbackup
umount /cdrom

and remove the temporary files:

rm /backup.dat /backup.key

Here I write a little bit about my experiences running GRUB2 with a PowerPC Mac (actually, an iBook G4), since the current documentation is lacking in many places (outdated, incorrect, etc.). Some of what I say is platform agnostic, though, and may be of interest to users of GRUB in general.

Basics using GRUB2 with PowerPC First of all, it is important to understand (at least superficially) how botting on a Mac works. One of the first programs that run in your Mac is the OpenFirmware. It works with more or less the same purpose of a BIOS in a regular x86 system. The basic idea is the same: get the computer running with whatever programs you want it to run. The implementation, though, differs quite a bit. First of all, OpenFirmware (OF) usually presents itself as a command-line interface that is programmable, differently from the common day BIOSes from x86 boxes. As it is programmable, it is more flexible, but this flexibility comes at the price of an increased complexity. I may write some things more in a future article, if there is any interest. For now, it just suffices to say that to get to the OF prompt in a Mac, you have to press a combination keys during the time that your Mac gives a chime when you turn it on. At that moment, you have to press (simulaneously) Cmd + Option + O + F. (Note: the Cmd key is the key that has an Apple drawn on it, usually on the side of the space bar).

Limitations of Open Firmware Differently from usual BIOSes of x86 computers, Open Firmware can read the contents of a partition in your HD (or other devices), as long as it is formatted in the original HFS format (not in HFS+ or one of its descendents). This is the reason why some older versions of Linux create an HFS partition in your HD, even if you don't intent to run or use anything besides Linux. The yaboot bootloader consists of, among other things, one binary that is understandable by OpenFirmware. That binary is a file called yaboot, after the name of the booloader. As an aside, you have to indicate to OF what is the file that you want it to load during the boot process, so that it knows what to do. The way to indicate this is to "bless" the file (and the folder that contains it). Some ways to bless a file are to, for example, use the bless command in MacOS X or the hattrib -b command from hfsutils. Files in an HFS filesystem have two attributes that many other filesystems don't: a creator ID (the "application" that created the file) and the type ID (which determines what kind of file it is). OpenFirmware, in particular, looks for files with the type tbxi for the bootstrap process. The yaboot binary is loaded by OF into memory and, then, control is passed to the yaboot program, which then reads its configuration file (yaboot.conf) from the same folder where the binary was in. The file yaboot.conf contains instructions for yaboot to do its job. The file yaboot.conf is very similar in construction to configurations of an older bootloader for x86 computers, lilo.conf. Also, in a way similar to what LILO requires, after you install some new kernel, change some parameter in the configuration file, etc., you have to run a program that will set up everything so that the boot process can know of your new configuration. With LILO, this command was called lilo, while with yaboot the command is called ybin (which, essentially, takes care of putting yaboot.conf in the bootstrap/HFS partition and blesses the yaboot binary).

Going to GRUB2 One of the characteristics of yaboot (which is left as an exercise to the reader to determine if it is a drawback or not) is exactly the way that changes in the configuration have to be copied to the special HFS partition: the step of running ybin. GRUB2 (and its older sibling, GRUB legacy) do away with that: during boot-time, it can understand the filesystems that you have in your computer and interactively load whatever you want from there, also from a command-line like OF, before any (regular) operating system has even been started. But how do you start GRUB2? Well, the way that this is performed is copying a binary to that special HFS partition. Here things start to be hairy, because GRUB2 has a lot of functionality, but it comes at the price of it consuming a lot of space (especially if you are using encrypted partitions or some kind of logical volume managements with some journalling filesystem that allows files to be compressed etc. on top of it). The list goes on. Usually, that special HFS partition only has 800KB, which, BTW, is the size of an old 3.5" floppy used with older Macs (note: due to some contraints on partitions and aligments of such partitions on cylinders, it is not uncommon for disk partitioning software to create partitions slighly larger than 800KB, but not much larger than that). A full-featured binary of GRUB2 to be placed on that HFS partition can have much more than those 800KB. But how do you get that binary, in the first place? And how do you fit that in the HFS partition?

Creating the GRUB2 binary To answer the first question, you have to construct it from your grub-ieee1275 package (I'm assuming here that you are using Debian or Ubuntu, but similar instructions may apply to other distributions). Then, a first step would be to create such binary with:

 mkdir /tmp/foo
 cd /tmp/foo
 cp -a /usr/lib/grub/powerpc-ieee1275/* .
 grub-mkimage -O powerpc-ieee1275 -o ../grub.img *.mod

The last command of these create an executable named grub.img that is callable from OF and which contains every module from grub-ieee1275. This executable that I call here grub.img is called, in GRUB2 parlance, the core image and it it seems to be named core.img in many systems. On my system, with those commands, the binary grub.img is about 1208KB, which is 50% larger than that 800KB partition. And you would like it to be much smaller, becase you want to still have your yaboot bootloader by default while you are evaluating your bootloaders (or using it as a backup plan). As GRUB2 follow a modular design, you can mix and match the features that you want. This already hints you to the way we can fit it in the HFS partition, and it is always the same story: just trim the fat.

Creating the configuration file You will also have to have GRUB2 configuration's file (or you will have to play with way more commands than you'd want to). An important distinction here is that you usually have 2 or more partitions on your Mac:

• the special bootstrap/HFS partition where OF is going to look at (I'll call it /dev/hda2 here);
• the partition where your / filesystem resides (denoted by /dev/hda3 here);
• some partition to hold /boot (I don't have one of these, but let's say that it is /dev/hda7 for our discussion purposes), usually containing your kernels and initial ramdisks.
• other partitions.

With this in mind, you can With Let's say that this last one, in Linux parlance, is /dev/hda3 (as is the case of this author), and optionally a partition where your Linux kernel resides (people usually use it to store the /boot subtree of a Linux filesystem). Let's say that this last one is /dev/hda7. Then, you would compose something like the following as a configuration file for GRUB2 (named grub.cfg):

insmod part_apple
insmod ext2
set root='(hd,apple7)'
menuentry "Linux"  
    linux /vmlinux root=/dev/hda3
    initrd /initrd
 

There are one two important points here that deserve more comments:

• Note that, differently from a regular x86 system, in a Mac system with only one HD the way that you specify an HD does not have a trailing zero. For instance, in the case above of the variable root, we have (hd,apple7), while in a "common PC" we would have the (hd part replaced with (hd0. That's something that you should make your distribution aware of, if they aren't yet. As an addendum, I don't know how it works with systems with more than one HD, as I only have (PowerPC) Macs that are notebooks. If you can share any experiences, please do.
• One point of caution here: what GRUB2 calls root is not necessarily the root of your filesystem (i.e., the partition that holds /), but the device that everything that is "not fully qualified" is interpreted as being relative to. The "not fully qualified" above means anything that is not prefixed with GRUB's device notation. As an example, (hd,apple2)/boot/vmlinux if fully qualified for GRUB's purpose, while /boot/vmlinux is not.

Putting it all together The next step is to just copy the files grub.img and grub.cfg to the special HFS partition. You can do that using hmount, hcopy, and humount or you can use the regular Linux hfs module to copy to that partition. Then, boot your system, get into the OF prompt and execute:

boot hd:2,grub.img

Here, the 2 above is a reference to my HFS partition. Substitute that with yours, appropriately. You will then see the common (familiar?) GRUB prompt and, from there, everything else that you know will (hopefully) work.

The list of modules that "Works for Me(TM)" As I mentioned above, I use a subset of all modules that come with grub-ieee1275 to create my grub.img binary. Here is the list of modules that I use and that gives me a reasonably sized bootloader:

bitmap.mod        datehook.mod  gzio.mod         lsmmap.mod      reboot.mod          terminal.mod
bitmap_scale.mod  datetime.mod  halt.mod         memdisk.mod     regexp.mod          test.mod
blocklist.mod     echo.mod      help.mod         memrw.mod       relocator.mod       trig.mod
boot.mod          elf.mod       hexdump.mod      minicmd.mod     scsi.mod            true.mod
bufio.mod         ext2.mod      hfs.mod          msdospart.mod   search.mod          video.mod
cat.mod           fat.mod       hfsplus.mod      normal.mod      search_fs_file.mod  video_fb.mod
cmp.mod           font.mod      ieee1275_fb.mod  part_apple.mod  search_fs_uuid.mod  videoinfo.mod
configfile.mod    fshelp.mod    linux.mod        part_msdos.mod  search_label.mod
cpio.mod          gettext.mod   loadenv.mod      parttool.mod    setjmp.mod
crypto.mod        gfxmenu.mod   loopback.mod     probe.mod       sleep.mod
date.mod          gfxterm.mod   ls.mod           read.mod        suspend.mod

Just for the record, my grub.img file has 624KB, and that can certainly be shrunk.

The command line that "Works for Me(TM)" to create the image Actually, I lied when I told you that I used the lines above to create my grub.img file, because I'm lazy and I don't want to type the .img extension. I also embed my configuration file in the binary that I create with GRUB2, so that I don't have two files to copy to my HFS partition, but only one. I do that with:

grub-mkimage -c grub.cfg -o ../grub -O powerpc-ieee1275 -d . *.mod

OK. No more lies here. The nice aspect of GRUB is that one you install that image, you don't have to touch that HFS partition anymore: you simply update your regular filesystem's /boot/grub/grub.cfg file (which is usually performed when you install a new kernel, at least with Debian) and you're ready to go. The good way to do that is to use a minimal configuration file embedded in your grub binary in your HFS partition that will hook into the system's /boot/grub/grub.cfg to read newer kernels and leave the HFS partition (and your system's NVRAM) alone. Here is what I am using right now:

search --no-floppy --fs-uuid --set=root 35d26869-f7c9-4852-a9b8-100314560c34
set prefix=($root)/boot/grub
configfile /boot/grub/grub.cfg

You will, of course, want to modify the file above as you install newer kernels (perhaps even that unsupported operating system from that fruity company, who knows?). Don't forget to change the UUID's, and partition numbers to fit your needs. Well, that's it. I hope that it helps somebody out there, as the information that I got otherwise was way outdated, incomplete, etc. to keep up with GRUB2 from these days. Now, let's go patch the tools that we have so that not everybody who wants to use GRUB2 have to learn about its workings. Oh, of course, you can now have your kernels in ext4, btrfs, xfs etc. partitions without the fear that your bootloader won't load them.

This is the eighth Debian XSF News issue. For a change, I m going to use a numbered list, which should help telling people which item to look for when pointing to a given URL. Feel free to let me know if that seems like a nice idea or whether that hurts readability. Also, it was prepared several days ago already, so I m publishing it (with the needed bits of polishing it still needed) without mentioning what happened in the last few days (see you in the next DXN issue!).

1. Let s start with a few common bugs reported over the past few weeks:
   • The server can crash due to some X Font Server (XFS) issue as reported upstream in FDO#31501 or in Debian as #616578. The easy fix is to get rid of FontPath in xorg.conf, or to remove the xfs package. It s deprecated anyway.
   • Xdm used to crash when started from init, but not afterwards (#617208). Not exactly fun to reproduce, but with the help of a VM, bisecting libxt to find the guilty commit was quite easy. After a quick upload with this commit reverted, a real fix was pushed upstream; a new upstream was released, packaged, and uploaded right after that.
   • We ve had several reports of flickering screens, which are actually due to upowerd s polling every 30 seconds: #613745.
   • Many bug reports were filed due to a regression on the kernel side for the 6.0.1 squeeze point release, leading to cursor issues with Intel graphics: #618665.
2. Receiving several similar reports reminded me of the CurrentProblemsInUnstable page on the wiki, which is long unmaintained (and that s why I m not linking to it). I m not exactly sure what to do at this point, but I think having a similar page on http://pkg-xorg.alioth.debian.org/, linked from the how to report bugs page would make sense. Common issues as well as their solutions or workarounds for stable should probably go to the FAQ instead.
3. As explained in DXN#7, we re waiting for the kernel to migrate to wheezy. The 2.6.38 upstream release was quickly pushed to unstable, which is great news, even if it s not really ready yet (since it s still failing to build on armel and mips).
4. I ve been using markdown for our documentation, basically since it looked sufficient for our needs, and since I ve been using it to blog for years now, but it had some limitations. I ve been hearing a lot of nice things about asciidoc for a while (hi, Corsac!), so I gave it a quick shot. Being quite happy with it, I converted our documentation to asciidoc, which at the bare minimum buys us a nice CSS (at least nicer than the one I wrote ), and with automatic table of contents if we ask for it, which should help navigating to the appropriate place. A few drawbacks:
   • The syntax (or the parser s behaviour) changed a lot since lenny s version, so updating the online documentation broke badly. Thanks to the nice Alioth admins, the version from lenny-backports was quickly installed and the website should look fine.
   • The automatic table of contents is generated through JavaScript, which doesn t play nicely with wkhtmltopdf (WebKit-based HTML to PDF converter), since the table of contents gets pixelated in the generated PDF documents. We could use a2x to generate documents through the DocBook way, but that means dealing with XSL stylesheets as far as I can tell; that looks time-consuming and a rather low-priority task. But of course, contributions are welcome.
5. When I fixed missing XSecurity (#599657) for squeeze, I didn t notice the 1.9 packages were forked right before that, so were affected too. I fixed it in sid since then (and in git for experimental). I noticed that when Ian reported a crash with large timeouts in xauth calls, which I couldn t reproduce since untrusted cookies without XSecurity don t trigger this issue. I reported that upstream as FDO#35066, which got marked as a duplicate of (currently restricted) FDO#27134. My patch is currently still waiting for a review.
6. Let s mention upcoming updates, prepared in git, but not uploaded yet:
   • mesa 7.10.1, prepared by Chris (RAOF); will probably be uploaded to experimental, unless 7.10 migrates to testing first, in which case that update will target unstable.
   • Intel driver: Lintian s been complaining about the .so symlinks for a while, and I finally gave it a quick look. It seems one is supposed to put e.g. libI810XvMC.so.1 in /etc/X11/XvMCConfig to use that library, so the symlinks are indeed not needed at all, and I removed them.
   • Tias Guns and Timo Aaltonen introduced xinput-calibrator in a git repository; that s a generic touchscreen calibration tool.
7. Here come the updated packages, with uploader between square brackets (JVdG = Julien Viard de Galbert, Sean = Sean Finney). For the next issue, I ll try to link to the relevant entries in the Package Tracking System.
   • [KiBi] libxt: to unstable, as mentioned above, with a hot fix, then with a real fix.
   • [KiBi] synaptics input driver: to unstable and experimental, fixing the FTBFS on GNU/kFreeBSD.
   • [KiBi] xterm: new upstream, to unstable.
   • [KiBi] libdrm: new upstream, to experimental. A few patches to hide private symbols were sent upstream, but I ve seen no reactions yet (and that apparently happened in the past already).
   • [KiBi] xorg-server 1.9.5rc1 then 1.9.5, to unstable.
   • [KiBi] xutils-dev to unstable: the bootstrap issue goes away, thanks to Steve s report.
   • [KiBi] libxp to unstable, nothing fancy, that s libxp
   • [KiBi] keyboard input driver: mostly documentation update, to unstable and experimental.
   • [KiBi] mouse input driver: fixes BSD issues, to unstable and experimental.
   • [KiBi] intel video driver: to experimental, but the debian-unstable branch can be used to build the driver against unstable s server.
   • [KiBi] xfixes: protocol to unstable, and library to experimental (just in case); this brings support for pointer barriers.
   • [JVdG] openchrome video driver: Julien introduced a debugging package, and got rid of the (old!) via transitional package. He also performed his first upload as a Debian Maintainer. Yay!
   • [KiBi] siliconmotion video driver: to unstable.
   • [KiBi] pixman: new upstream release candidate, to experimental
   • [Sean] last but not least: many compiz packages to experimental.

For the past couple years I had been reading very little, two or three books a year.

For the past month my average has been two books per week.

The culprit is the Amazon Kindle 3 I bought during my stay in the US. I just can not recommend it enough. For starters, it is quite affordable at $139. The image quality is wonderful, and reading in daylight or even in direct sunlight is pleasant. This is a welcome change from a backlit screen as the eyes get noticeably less strained. The format of the device is even more convenient than of a real book (the size is perfect for plain text, start thinking about the Kindle DX if and only if you intend to read PDFs). The Kindle is quite thin and convenient to hold (and you do not need to keep it from closing as with paperback bindings). Battery life is on the order of weeks. Extra functionality (e.g., web browsing) is available, but not convenient, but that is almost an advantage as distractions are kept at bay. The Amazon store is great, I have already shelled out over $50 with little remorse (my time is much more expensive than the measly $9.99 a typical book costs). There are quite a few free books around too. And to top it off, the "screensaver" with pictures of writers is a very nice touch.

The Kindle is also useful for going through longer articles you would normally be reading on your laptop. The Chrome extension Send to Kindle has worked well for me, do check it out.

The most important drawback of the Kindle is that it is slow to turn pages, so it is not easy to browse a book. Turning a page takes a second or so. This is extremely annoying when reading in non-linearly, e.g. taking in study material, when you constantly need to go back to check up details of previous material. A PDF interpreter is available, but the screen is too small to show a full PDF page (a Kindle DX or an iPad would probably be better) and scrolling is painful because of the delays. Wireless seems to drain the battery noticeably, there have been a few cases where I forgot to turn it off and found a dead Kindle a few days later. I wish the WiFi connection would manage itself intelligently somehow.

The Kindle drove the point home for me that dead-tree books will be going the way of vinyl soon, much sooner than I had expected. And for good reasons. Go order now if you do not have an e-book reader yet (and do not forget to order a sleeve too, given the time you will be spending carrying the device it will come in very handy).

Just a short note, as I've already got e-mails about this: the binary packages are built ASAP, but currently one Build-Depends (openssl) isn't satisfiable for all platforms. The reason is simple: a new OpenSSL package (1.0.0d-1) was uploaded into unstable just recently and not all builds made it into the archive yet, some are still in incoming (please note, that they might not be there anymore, when you click the previous link). So please be patient, the builds are done, when possible. Thanks. ;-)

If you have been using Lintian you may also know that it has some limitations. One of these are that Lintian always checks every package isolated from each other unlike other tools like piuparts. It has its advantages (such as not requiring all dependencies being present) but it also has it disadvantages. Currently Lintian emits a binary-without-manpage -tag if the package contains a binary without a manpage. At first glance this appears reasonable, but it really is too simple (#512645). Basically Lintian complains about the missing manpage even if the manpage will always be present. A simple case is package foo depends on foo-data, the binary is in foo and the manpage is in foo-data. A live example of this is gedit and gedit-common[1]. The problem is that Lintian does not know if a given package is going to processed or not. Lintian does have a few cross package checks; namely binary checks can see the source package if it is available. This can be done with a bit of clever sorting (quote from Lintian source code):
# [...] (the sort is to make sure that source packages are
# before the corresponding binary packages--this has the advantage that binary
# can use information from the source packages if these are unpacked)
This works rather well, but its scope is very limited. Particularly it is no help, if we need to check if the manpage missing in foo might be in foo-data. This is what #513663 is all about. In January I branched the Lintian code and started working on grouping packages from the same source together. Yesterday I finished refactoring Lintian to do just that. However, this in itself is not very useful if the checks cannot take advantage of this. So today I sat down and extended our manpages check a bit and posted the results to the Lintian mailing list. [1]http://packages.debian.org/sid/gedit http://packages.debian.org/sid/gedit-common

I managed to play 3 pranks on myself today.

1. Taught my cat how to leave the house by the cat-flap, but not how to come in by it. (Or maybe he just doesn't want to.) Thus, I am constantly his doorman. This took some setup, the best pranks do.
2. Got a minor amount of hot pepper in my eye, then forgot about it, washed my face, and got the rest of the oil in my eye, leading to a farcical dance around the kitchen.
3. Unplugged my dialup gateway to save power overnight (sun has been scarce lately), and had a "how can I be online" moment hours later. Forgot that I've been using a power-hungry laptop there as my nslu2 is ill.

Today we gathered the representatives of different distributions that are present at GNOME.Asia to discuss what GNOME could do to improve its support for distributions that distribute it, especially in matters of long-term support. It is kind of sad that there weren t any representatives from Canonical nor Red Hat, but the discussion turned out really interesting and we learned a lot about the packaging habits of each other. Furthermore, there were several concrete leads that were explored, which will lead to proposals from the GNOME foundation to all distributions. Helping with long-term support The most widespread GNOME version in the LTS releases that happened recently is 2.30, which is used by Debian squeeze, Ubuntu LTS 10.04, RHEL 6, and Solaris 11. It looks like an accident, but on the other hand:

• GNOME 2.32 isn t really suitable as is for an entreprise distribution;
• Linux distributions agreed on a kernel version to support long-term, so this had an impact on their release schedules, and this might well happen again for the next release.

In the future, a decision to use a common GNOME release could, anyway, only come from the distributions themselves, not from GNOME. A proposal that many people agreed upon was to give distribution maintainers commit access to old branches that GNOME module maintainers don t touch anymore. This way they could share their patches more easily and make new releases of these old branches. This would imply, of course, setting up rules about what changes are allowed, that distributions would have to agree upon (how to treat feature additions for example). Managing bugs Currently it is hard to tell, for a distributor, whether other distributions are affected too and whether they have released a fix for that. It was agreed upon that Launchpad s feature of linking bugs between distributions, including version tracking, would exactly fill that need. One of the solutions would then be to add such a feature to Bugzilla, but it is a lot of work since currently it doesn t have any kind of version tracking. Another proposal was to deploy a new Launchpad instance to do serve as a hub between downstream bug systems and the GNOME Bugzilla. The condition for this to work would be to make it extremely easy to clone bugs between it and Bugzilla, and also if possible from the downstream bug systems. On the side-related topic of how not to crawl under bugs, it might be possible to get bugs forwarded with a single command from the Debian BTS to Bugzilla, using the XML-RPC interface. Upstream also considers that bugs sent to Debian are generally of higher quality than those from e.g. Ubuntu, and would be OK with us routing some of them directly to upstream (like we already do for Evolution). Communicating about the availability of patches Currently distributors are hardly ever informed that patches relevant for their distribution have been committed. They often learn of them by sheer luck while lurking on Bugzilla. The distributors-list ML is clearly the relevant media for that purpose, but it is clearly not used enough. It would need to be advertised more among both GNOME module maintainers, and among downstream maintainers as well. On this matter, the disappearance of the x.y.3 GNOME releases (starting with 2.28) was evoked. The problem was that most of those releases were about insufficient changes to justify e.g. stable updates in distributions. The proposed solution is to encourage maintainers of modules with bugs to fix to release new versions (through an annoucement on desktop-devel-announce), and to send a list of modules with new versions to downstream distributors so that they can integrate them. This avoids the GNOME release team the hassle of making a new release, while still giving distributions that use them some bugfixes. Providing a new service to LTS distributions The idea of having the GNOME foundation employ a person to gather, on the GNOME side, all changes that are relevant to older GNOME versions, and prepare new stable versions, was discussed. This would be a new service for which commercial distributions would need to pay a fee. It s not clear how this information would be privately disclosed and the impact on non-commercial distributions. But it doesn t seem likely that e.g. Red Hat would be interested since they employ a lot of core GNOME hackers who are already doing this job.

---

I don t know what impact these proposals can have on GNOME packaging in Debian, but apart from the last one that I find dubious, it seems that they could greatly improve our support of GNOME in stable Debian releases, be it by having more versions to upload during the freeze, or by having more stuff in point releases. Fr d ric Muller promised to come back to us with more concrete stuff.

Due to cockups and/or willful sabotage by the telcos my ISP relies on for its DSL services, I am unreachable by email starting early this morning (UTC) and until further notice. My primary MX is off the net, mail is spooling on my backup MX so nothing should be lost. <expletive deleted> Update 2011-04-05: stupid telco finally rebuilt the line properly. I m back, no mail lost at first glance and I m slowly digging into that pile of mail. If you don t receive a reply by tomorrow, please resend.

I'm sure you already heard the news about the new joined Canterbury Distribution, and are eager about details. While our teams are struggling to integrate all the existing infrastructure, it's my pleasure to announce that the first pieces of the collaboration are already available for our users. As a first measurement, a common Canterbury Package Manager, called cant will be made available in all distributions. It is already available for the distribution formerly known as Archlinux, and with the next mirror push will also be available for those used to run Debian. You'll be pleased to know, that the command line syntax isn't much of a change, you can still run cant search, cant install or cant remove, but future version will also introduce all the features known from the other distributions. Stay tuned for further updates of Canterbury Linux!

For the whole week, I ve been in Bangalore for the GNOME.Asia 2011 hackfest. I ve been delegated by Stefano to represent Debian here, and my employer EDF has agreed to cover for travel costs since they are very interested in first-hand information the future of the Linux desktop and sharing our work on scientific computing. It s been a really exciting week; I ve spent quite some time packaging missing pieces of GNOME 3.0 (well, the release candidate versions of course) in experimental, together with Fred Peters. I think it s reaching a usable state now, so we ll probably soon provide metapackages to make it easily installable. The latest developments of the Shell make it a very exciting piece of software, with a strong focus on usability. Many things were written about it, but in the end my main criticism would be that it lacks some functionality - for example, the combined clock/weather/locations applet will be greatly missed. The good news is that it is extremely customizable, and with all the libraries being made accessible through GObject introspection, there are many features that are accessible from it. If you know how to write JavaScript, now is the time to write your favorite extension. On the good news front, Vincent Untz also spent a lot of time improving the so-called legacy mode , which is more and more starting to look like the Shell without special effects, and with all the features from gnome-panel 2.x that are still here. We will try in Debian to cover all uses cases that there were for GNOME 2 with GNOME 3 technology, so that panel lovers are not left behind. I ve also proposed an update to the dh_gsettings proposal, which will provide the same functionality as dh_gconf and allow to easily set distribution-specific overrides. It is still missing a way to set mandatory settings, which might come as a problem for some corporate users, but this is planned for a future version of GSettings. Today, we re having a business track where I and representatives of other companies (Oracle, Lanedo, Dexxa) are sharing experiences about making money with free software. Unfortunately the local organizers didn t manage to gather many people, despite our being in a city with an incredible number of IT industries. Tomorrow, the public conference starts, and this should be the opposite: we re expecting around 1000 people, which is a great achievement for a free software conference. For an unrelated topic, being around so many GNOME hackers has some interesting side effects; I ve been added to Planet GNOME. So, hey, hello Planet GNOME readers!

pushing cross-distro collaboration to the next level In case you've missed the announcement, today it's a memorable day for Free Software. Please join the following distributions in welcoming Canterbury, the next generation community distribution:

• http://www.debian.org
• http://www.gentoo.org
• http://www.grml.org
• http://www.opensuse.org
• http://www.archlinux.org

---

Kudos to the, yet unnamed, representatives of the above derivatives who have come up with and coordinated this initiative.

The student application period for applying to GSoC opened last Monday and we already have a couple of very good applications from students. We are still missing yours! The list of Debian projects includes a nice variety of projects:

• If you are into Python, take a look at the project for writing a tool to automate building Python extensions.
• Do you want to contribute to improving the relation of Debian with its derivatives? The DEX tools project is for you.
• If you have good web scripting skills, you might be interested in helping creating the Debian talks database.
• Are you into data mining? Check the Measuring Team Performance project.
• You would like to make Iceweasel better? The Iceweasel plugin finder needs you.
• Are you missing a system where developers can publish and auto-build their temporary non-official packages? You can make it real with the Developer Package Repositories project.
• There is more at our projects page !

There is only one week left, so do not leave it for last minute. Get in touch with the mentors of the projects you are interested in and add your proposal to the Debian wiki and in Google Melange. If you are a Debian contributor wanting to mentor a project, you still can. Please read this email with some hints.

In one of the corners of what is now know as Europa, there was a rich, prosperous and beautiful kingdom known as Trist nia. In the past, not that long ago, it had been a number of smaller kingdoms and caliphates, all with their own cultures, religions and ways of life. Wars, and series of marriages of convenience eventually configured what ended up being the united kingdom of Trist nia. Throughout the years, some of the unified cultures grew and flourished, while others struggled to survive in their ever-shrinking areas of influence. A required introduction Sometimes, the minor cultures would suffer due to oppression coming from the delegates of the King, who would ban any expression of these cultures, as they were seen as a potential threat to the kingdom's stability and unity. For example, just a few decades before the main subject of this tale, the predecessor of the incumbent King took power by force, after crushing everyone who opposed his uprise during a bloody and hard civil war. His reign was ruthless and he imposed draconian laws uppon his people: usage and teaching of the minor languages was banned, and everyone was forced to use the language of the Centr lia region, in public or private. After four decades, the majority of the Tristanian people were sick enough of the situation to consider standing against their fear of the regime and demand freedom, but repression prevailed until the old general died. His place was taken by the King's grandson even if the people had expressed, just before the Great War, that they had had enough kings and demanded a ruler they could choose directly. Of course, the new King seemed a lot nicer than who they had been suffering for ages, so when asked if they accepted the new situation, an overwhelming majority said yes . However, there was a region, Verd lia, where the majority said no . Things were actually more complicated. Verdalians formed a traditional, proud society, and while the years of oppression had undoubtedly weakened it, they had managed to preserve their very unique culture, language and traditions healthy. The Verdal language was really weird to the ears of Centr lians and even other minor cultures of the Kingdom, and erudites struggled to find its real origins, not being able to reach plausible conclusions. Verdanians, as we already know, were a traditional society, living in a land of deep and poorly connected valleys. Little they knew or cared about the complicated matters of Centr lia and other regions. What made them happy was to take care their sheep and cows, keep a good fire in their living room and, every now and then, enjoy one of their log cutting contests. The impositions of the former dictator were too much for them, and some of them started sabotaging, assaulting and killing some of the dictator's soldiers, agents and officers. This was a huge risk at the time; getting caught meant death penalty for sure, and at first, even people from other regions were in favour of these actions. However, this popular support greatly diminished when the new King took the throne, as these minority continued with the killings, while most of the people saw it was no longer justified. The Royal Ball One of the very first measures the young King introduced was to organise the Royal Ball of Trist nia , a major event through which the people of the different regions would be able to elect their delegates to the Crown. Every four years, a Great Ball contest would happen in Centr lia, and the winners would be able to decide by their own on some of the matters that affected their region. Verdanians would send a few teams of dancers, each of which came from different towns or areas. Some Verdanian teams were happy about the King and the new political situation, but other teams weren't so much. And some others, while being simple non-violent dancers, were known to be supporters of the violent minority who kept on harassing, assaulting and even killing in their struggle for freedom of Verd nia . The Verdanian groups aligned with the different culture of Verd nia (including those who were said to support the violent) tended to get a lot more points in the dancing contest, and a majority of the elected delegates were appointed by them, making it easier to pass laws and edicts that favoured protection of their ways, traditions and language. No matter how hard they tried, the dancing groups closer to Centr lia kept losing to the majority. After many years of dance contests, these groups used their closeness to the King's court to pass the Ball Law of Tristanian, that would ban any dancing group which didn't condemn the assaults and killings that kept happening in Verd nia. The unsurprising result was that, with less dancing groups participating in the following Royal Ball, the Verdanian majority was broken and new delegates, friendly of the Centralian officers, were elected. Many people who had been in favour of assaults and killings began to question this strategy, and this political movement's unity started to break. In the end, the dancers decided to part ways with the violent; they wanted to dance in the next ball, and to do so, they wrote a letter to the King, in which they explicitly expressed their rejection of violent ways, and their embracing of dancing as the only means to drive their political agenda. An objective reading of the new Ball Law clearly showed that this was enough: the text only said the requisite for a dancing group was to disavow all kinds of violence. This wasn't really expected in Centr lia, so they started to add new requirements in an attempt to keep this group from the contest: their decisive majority in Verd nia was at stake. The Royal Ball was nearing and registrations for the contest would soon close. The Centralian government first argued that the dancing group should reject the violence coming from the Verdanian extremists in particular. The dancers did it. Then they argued that the dancers were the same people who had been supporting violence in Verd nia for years, and obviously their violence rejection statement was a lie. The dancers struggled to find new dancers who had not been involved in past dances. But it was not enough. They then claimed that this dance group should be quarantined for four years, until they could prove they really were serious about their new non-violent ideas. The dance group made a plea to the Trist nian Supreme Counsel, a group of sixteen experts in law of the Kingdom, and argued that all of these draconian requirements were not part of the law that was being enforced by the King. Their appeal to the elder counselors was in vain, though. They ruled this dancing group was as criminal as the violent minority they had once supported, and should by no means take part in the Royal Ball. As a last, desperate measure, the dancing group reached an agreement with other Verdanian dancers to join forces. They would adopt a new name and new dancing costume colours. Many feared this would only end up in the ban of the other dancing group. Unfortunately, the end of this story has not been written yet, but it will be completed very soon. Only time will tell if things continue being very sad and unfair in Trist nia, or if the dance contest will once again be impartial, with legitimate results.

Este post tambi n est escrito en espa ol. If you follow me on Twitter/Facebook, you probably know that I went to Gothenburg, Sweden, during my last trip to Europe. But you probably don t know what I did in such remote city. Few months ago, I applied to a PhD student position at Chalmers. I was lucky enough to be shortlisted, so I went to some in-situ interviews. And, incredibly, I have been accepted! :-) Chalmers is a TOP 100 university. Most of the papers I read during the last months has been written by Chalmers researchers and for me is a great honor to be part of an academic institution with such prestige. I m going to move to the nice Gothenburg city in August. And I m happy :)

At work, I'm dealing with lots of different database setups, luckily mostly PostgreSQL running on Debian. At the same time, a fair amount of the tools in the PostgreSQL ecosystem (not the PostgreSQL server packages itself) are not in the best shape in the Debian archive. I'm trying to change that by adopting some of the packages. So far, I have fixed a few RC bugs where packages where suddenly trying to build against PostgreSQL 9.0 while expecting 8.4. To my surprise, there are no packages yet in the archive that support multiple PostgreSQL versions in parallel. There is even a package ready to help doing this - postgresql-server-dev-all, but apparently nobody has used it yet. It turned out that after working around a few trivial problems and adding just a few lines of sh code, it was pretty straightforward to port skytools and postgresql-pllua to 9.0 while keeping 8.4 support. The latter has no version-specific code left in debian/ except for a list of supported versions in debian/pgversions, so a future port to 9.1 will be trivial. (Fun fact: the old postgresql-pllua version 0.8.1 was actually a typoed 0.3.1 version.) Most PostgreSQL tools use a common subversion repository on Alioth, but there is no common mailing list address that is put into the Uploaders fields, so it is hard to get an overview over the state of all packages. I've compiled a list of all packages in svn, git, bzr (the server packages), and a few others in DDPO to fix that for now. Other packages I've updated so far are pgtune, pgbouncer, and pgpool2.