As seen in some mailinglist discussion:

"It seems to be a common belief between some developers that users should have to read dozens of pages of documentation before attempting to do anything.
"I m happy that not all of us share this elitist view of software. I thought we were building the Universal Operating System, not the Operating System for bearded gurus."

I think this is an interesting quote as it shows an important misunderstand of what Debian is for many people. Debian (and Linux in general) was in its beginnings quite complicated and often not very easy to use. People still felt a deep relieve to have it and a strong love. Why? Because it's not so much about about how you can use it, but how you can fix it. A system that only has a nice surface and hides everything below it, that does in a majority of cases just what you most likely want it is nice. But if the only options are "On", "Off" and perhaps some "something is not working as it should, try to fix it" (aka "Repair") it is essentially a form of paternalism: There is your superior that decided what is good for you, you would not understand it anyway, just swallow what you get. Not very surprisingly many people to be in the position of the inferior of a computer (the less the more stupid the computer is, but even modern computers are still stupid enough for most people). So what those people want is not necessarily a system that can only be used after reading a dozen pages of documentation, but a system they know they can force to do what they want even if that might then mean reading some pages of documentation. So a good software in that sense might have some nice interface and some defaults working most of the time. But more importantly it has a good documentation, easy enough internals so one can grasp them and be transparent enough that one can understand why it is currently not working and what to do against this and then allowing enough user interference to fix it. If all I get offered is some "interface for users too stupid to understand it anyway" and all options to fix it are checking and unchecking all boxes and restarting a lot or perhaps some gracious offer of "There is the source code, just read that spaghetti code, you can there see anything it does though you might need to build a debug version just to see why it does not work" then I would not call any strong feelings against this situation "elitist".

A new comment on the Samsung N150 Ubuntu Netbook Remix reminded me that maybe I should post this here: I ve just seen a report of lost files in a dual-boot Windows 7 situation. One suggestion is that you shouldn t suspend Windows, boot GNU, edit files on the Windows disks, shutdown GNU, then resume Windows. I ve not dual-booted for over a decade, but friends and clients do and they re slowly moving to Windows 7 as it comes on new PCs. Is this a new twist on the old Windows-expects-one-user-at-a-time sharing problems, perhaps?

Mandatory warning: What follows is for testing only, and insecure (root all over the place, giving access to host devices from the container, etc.). Problem of the day

• It d be nice to package Wayland. It s been split in several repositories: one for the core protocol/library implementation; one for the demo compositor and clients.
• Easy? Not quite, mesa needs to be rebuilt against the library. Doing so on a system running stable doesn t seem too good: some newer libraries might be needed; and using make install could make it harder to remember additional bits installed all over the place ($DESTDIR is our friend but that might mean more work on the build system side to get everything detected).
• What about having the whole development environment running in a Linux container? That s what I investigated.

Giving Linux containers a try

• Start from a squeeze system.
• apt-get install lxc, read its README.Debian, get the mount point set up.
• Copy the /usr/lib/lxc/templates/lxc-debian template somewhere as lxc-squeeze, and edit it:
  • Replace dhcp-client with dhcp3-client.
  • Replace lenny with squeeze.
  • Specify a better mirror than ftp.debian.org.
• Create a lxc-test directory, and create a container: ./lxc-squeeze -p lxc-test.
• Start the container, which gives access to a console: lxc-start -n test -f lxc-test/config (the test name passed through -n can be used to call lxc-stop -n test). Use root/root to get in.
• Edit /etc/apt/sources.list to point to sid instead, and dist-upgrade (using squeeze to start with means fewer headaches while bootstrapping, in case sid breaks or gets into some transition).
• Try lxc-stop and lxc-start to make sure the container can be stopped and restarted at will.

Getting devices

• First things first (and unless I missed something), udev + LXC = fail. So let s install it, note that it can t be configured, edit /var/lib/dpkg/info/udev.postinst, add exit 0 at the top, and dpkg --configure udev.
• Now, some devices are needed under /dev. Using mknod would be too easy, that s called a container for a reason. So let s edit the config file (the one passed to lxc-start earlier) to add a few devices (see below for an example).
• Once that done, restart (lxc-stop/lxc-start) the container, mknod on those devices is now possible.
• Input devices are not considered here, only video output is wanted for this test case. [This post might be edited if some examples get added later.]

Example, with a Radeon card, KMS enabled, let s assume those devices are wanted:

crw-rw---- 1 root video 226, 0 Apr  5 02:34 /dev/dri/card0
crw-rw---- 1 root video  29, 0 Apr  5 02:34 /dev/fb0
crw------- 1 root root    4, 7 Apr  5 02:34 /dev/tty7
crw------- 1 root root    4, 8 Apr  5 02:34 /dev/tty8

Note the major, minor right between owner groups and dates, and edit the config file accordingly, adding those lines (watch the syntax, it doesn t like extra whitespaces):

lxc.cgroup.devices.allow = c 226:0 rwm
lxc.cgroup.devices.allow = c 29:0 rwm
lxc.cgroup.devices.allow = c 4:7 rwm
lxc.cgroup.devices.allow = c 4:8 rwm

Once the container restarted, create the devices:

cd /dev
mkdir -p dri
mknod -m 666 dri/card0 c 226 0
mknod -m 666 fb0       c 29 0
mknod -m 666 tty7      c 4 7
mknod -m 666 tty8      c 4 8

Getting serious

• apt-get install xorg
• startx
• strace -f can help diagnose issues. If /dev/dri/card0 shows up with ENODEV, an old libdrm could even remove that device, so running mknod is needed again (but not sufficient)
• A likely cause of such issues might be that an X server already ran (or is still running) on the host system. Disabling the display manager on the host, rebooting, and trying startx from the container again should give better results (that s what happened here).
• If startx just works , just use ^Z then bg to put it in the background.
• Move on to installing a random window manager (e.g. awesome) and mesa-utils, and enjoy!

Enjoy:

export DISPLAY=:0
awesome &
# this is not a benchmark:
glxgears &
# direct rendering:
glxinfo egrep '(direct renderer)'

which printed here:

direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on ATI RS690

As mentioned on Phils blog, Debian buildd's have now capability of autosigning builds. Today when arriving home I was greeted by an empty feeling - There was no builds to sign. The long standing routine had come to an end.

Good system administrators constantly look how to replace themselves with scripts and automation. Bad ones build job security by owning manual processes than nobody else can master.

With signing now done by some code instead of us, I (and other buildd admins) have more time and energy to work on irregular tasks - upgrading chroots, helping developers with porting problems etc. Not to mention blogging and updating ones own packages to sid..

Meanwhile, there are still some issues needing solving - $HOME isn't available on all buildds, -volatile and binNMU's need still manual signing. Certainly not the smoothest update, but it is already making life easier.

We celebrate the 4th edition of Debian Groupware meeting last weekend at Linuxhotel in Essen. A weekend with 'full-time-hacking' on Groupware related stuff. So now we have Icedove 3.1 and translation packages for Iceowl in Sid. Another task was bugfixing and try to solve license/trademark problems with z-push. Due to the lovely weather on Saturday, we have BBQ together with some people from FROSCON. And these people carried unwittingly Debian swirled sweets. Just in one phrase: I'm looking forward to the 5th Groupware meeting in 2012.

A build-fix release RQuantLib 0.3.7 is now on CRAN and in Debian. RQuantLib combines (some of) the quantitative analytics of QuantLib with the R statistical computing environment and language. Thanks to the help by Brian Ripley (who compiled QuantLib for 64 bit Windows), Josh Ulrich (who did the same for 32 bit Windows, and arranged the Windows builds) and Uwe Ligges (who runs win-builder for R) we once again have Windows binaries as well as the usual source distribution (and Debian binaries). The only other change was minor fix to the documentation files. We had found that the pdf reference manual build would break for Uwe and Kurt (using A4 paper settings) but not myself (using letter). Uwe finally tracked that down: we had some arguments to \url with over seventy characters, and that broke typesetting. I commented those out (as the entries were in doxygen-generated QuantLib page which have volatile names anyway) and fully automated builds now resume as usual. Thanks again to Uwe for that too. No other changes were made. Thanks to CRANberries, there is also a diff to the previous release 0.3.6. Full changelog details, examples and more details about this package are at my RQuantLib page.

Conrad Sanderson made a bug-fix release (1.1.92) by for his wonderful Armadillo templated C++ library for linear algebra appeared yesterday and as usual a new release 0.2.18 of RcppArmadillo, our Rcpp-based integration into R is now on CRAN mirrors. The short NEWS file extract follows below containing just Conrad's entry for 1.1.92. No further changes from our side.

0.2.18  2011-04-03
    o   Upgraded to Armadillo Version 1.1.92  "Jurassic Barbecue"
          * Bugfix in cor()
          * Automatic installation now requires CMake >= 2.6

And courtesy of CRANberries, here are the diffs to the previous release.

 ChangeLog                                          8 ++
 DESCRIPTION                                       10 +--
 inst/NEWS                                          7 ++
 inst/doc/Makefile                                  2 
 inst/doc/RcppArmadillo-unitTests.tex           only
 inst/include/armadillo_bits/Cube_meat.hpp         12 ---
 inst/include/armadillo_bits/Cube_proto.hpp         4 -
 inst/include/armadillo_bits/Mat_meat.hpp           2 
 inst/include/armadillo_bits/Mat_proto.hpp          4 -
 inst/include/armadillo_bits/arma_version.hpp       4 -
 inst/include/armadillo_bits/glue_cor_meat.hpp     83 ++++++++++++--------------
 11 files changed, 73 insertions(+), 63 deletions(-)

More information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

As you may know, Apache's mod_authzn_ldap allows to authenticate users in Apache HTTP server using an LDAP server. Unfortunately, it has a little implementation flaw. The filter used to authenticate the user is built by abusing the RFC 2255 which specifies the LDAP URL format. This format has an "attribute" field which is normally used to specify which attributes should be returned. But mod_authzn_ldap uses this attribute to compare with the username given by the client. That means that you have to have an attribute in your LDAP entries which matches the username, and you have to use it in the "attribute" part of the URL to get things working. Therefore, I wrote a patch to add a format string in the LDAP URL in order to user the provided username in the filter, and ignore the attribute part of the URL, which has no use in such a context anyway. The bug has been opened in ASF Bugzilla and has number #51005, with the patch. The patch is backward compatible with the current configuration format, which is not the best choice in theory, but probably the more pragmatic. I've no clue on the typical delay for patches in clusion in Apache HTTP server, so let's just wait'n see.

Today was the 30th annual Race That's Good for Life 5k race in Oak Park. I had run this in 2003, 2004, 2005 and 2006 but not afterwards as the spring marathons got in the way. As I am now on a more relaxed (and seemingly non-marathon ;-) schedule, I was able to participate again. Really nice to leave your house fifty minutes before race start and cycle over... And kudos to the Oak Park Runner's Club who once again put a nice race together. Given the lack of (more intense) training, I am also a lot slower: 21:50.7 was the chip time, or a 7:02 pace. We will see if I ever get faster again. On race day I am usually motivated; it remains to be seen if I get over to the track in the early morning to push myself through some speedwork.

Here is a small update for my English readers. Most of my blog posts have been in Norwegian the last few weeks, so here is a short update in English. The kids still keep me too busy to get much free software work done, but I did manage to organise a project to get a Norwegian port of the British service FixMyStreet up and running, and it has been running for a month now. The entire project has been organised by me and two others. Around Christmas we gathered sponsors to fund the development work. In January I drafted a contract with mySociety on what to develop, and in February the development took place. Most of it involved converting the source to use GPS coordinates instead of British easting/northing, and the resulting code should be a lot easier to get running in any country by now. The Norwegian FiksGataMi is using OpenStreetmap as the map source and the source for administrative borders in Norway, and support for this had to be added/fixed. The Norwegian version went live March 3th, and we spent the weekend polishing the system before we announced it March 7th. The system is running on a KVM instance of Debian/Squeeze, and has seen almost 3000 problem reports in a few weeks. Soon we hope to announce the Android and iPhone versions making it even easier to report problems with the public infrastructure. Perhaps something to consider for those of you in countries without such service?

Today I made a couple of small tweaks to my systems. First of all I updated my email handling to allow further restrictions to be applied to incoming mail. Generally the way I handle incoming mail is to first of all test the recipient, then apply spam checks. To allow mail for a new localpart to be received I'll run this:

cd /srv/example.com/users/valid
touch localpart

The result of the file /srv/example.com/users/valid/localpart existing is that mail is accepted for localpart@example.com. As of today that still works - any file beneath users/valid allows the appropriate localpart to receive email. But now a directory indicates an ACL. So I can create:

rm    /srv/example.com/users/valid/root
mkdir /srv/example.com/users/valid/root/
touch /srv/example.com/users/valid/root/1.2.3.4
touch /srv/example.com/users/valid/root/2.3.4.5

Now only the named IP addresses may mail root@example.com. Finally I updated the proxy which is handling incoming access to my websites, so that I actually take advantage of the regular expression support.

    '(xen-hosting.net www.xen-hosting.net)':  
        'rules':  
            '^/': 'http://kvm-hosting.org/'
         ,
     ,
    '(xen-hosting.org www.xen-hosting.org)':  
        'rules':  
            '^/': 'http://kvm-hosting.org/'
         ,
     ,

Using regular expressions meant that I didn't have seperate matches for xen-hosting.org and www.xen-hosting.org. (Obviously I could have combined all four hosts into one regexp, but it looks cleaner this way.) ObQuote: "Nobody likes a perky goth" - Blood Ties.

Now that I have access to the serial console on Samsung e60 reader let s build a new linux kernel for it. The e60 reader has an ARM processor, to compile the kernel we need a cross compilation toolchain.
The first option is to use the one Samsung released with the other sources. It must work, however I don t really like the idea to run binaries from unknown sources.
The second option is to build our own toolchain, we often have to do that for systems that requires patches on the compiler.
Here, Samsung s binutils look like they were taken between 2.17 and 2.18 release (they are named 2.17.50 but are still slightly different from this snapshot) but they don t seam to embed homemade patches. As for ggc I didn t take time to check.
I choose to use the emdebian cross-development toolchain lenny version. (As the article in the french open silicium magazine #1 about FriendlyARM proposes to do). Installing the cross-development toolchain on debian First the archive keys:

sudo apt-get install emdebian-archive-keyring

Then we add a /etc/apt/sources.list.d/emdebian.list file with the following content:

deb http://ftp.uk.debian.org/emdebian/toolchains lenny main
deb-src http://ftp.uk.debian.org/emdebian/toolchains lenny main

The we update the package list to install the needed packages:

sudo apt-get update
sudo apt-get install libc6-armel-cross libc6-dev-armel-cross libstdc++6-armel-cross binutils-arm-linux-gnueabi gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi

That s it ! We have now our cross-compilation toolchain installed from packages, so easy to update or remove. The kernel sources Samsung released it s modified 2.6.29.4 version. By cloning the kernel 2.6.29.y git branch, I could quickly see that their changes applied well to the 2.6.29.6 version (the last in the branch). In order to better sort the changes michel.s had splat them into several patches
(patchs on e60-open project). After a few trials I build a series file allowing to apply those patches with quilt or better to import them to a git branch with git quiltimport. The order I choose allows to drop easily some patches (the last ones). One particular point on those patches is that some include binary files:

• fs/rfs/*.o a proprietary journaling layer over FAT. If you want my point ov vue, we don t need that. After all we have free journaling file systems available and linux is able to mount something else than FAT over USB
• drivers/usb/gadget/file_storage.o also the corresponding .c file was removed, the BSD/GPL license from the original code allows a binary distribution (however I didn t check if Alan Stern s name appears in the doc) but I d have liked that Samsung give that source code.

U-Boot Before compiling the kernel, we need the mkimage utility from U-Boot. Here, Let s build the U-Boot released by Samsung, and let s just copy the tools/mkimage to a location in our PATH (that s the only install method I could find).

make smdkc100_config
make CROSS_COMPILE=arm-linux-gnueabi-
cp tools/mkimage ~/bin/

Building linux For the config, one of the patches includes a .config. That file is a copy of config_rfs so even without the previous patch, we can get Samsung s config. Finally we can compile!

make CROSS_COMPILE=arm-linux-gnueabi- CFLAGS="-march=armv4t -mtune=cortex-a8" CXXFLAGS="-march=armv4t -mtune=cortex-a8" ARCH=arm uImage

We can then load our kernel by following The kernel testing howto from e60-open project. To load the kernel we will need the following command:

sudo dnw arch/arm/boot/uImage

That it, and it works ! Well almost, the kernel cannot find his modules. This will not be a big deal for the ones included in the sources (but the subject of a next post) but the /lib/modules/max14540.ko and lib/modules/dhd.ko modules are not included in the sources while reporting a GPL license to the kernel. Missing source code The Samsung Open Source Release Center website has a contact form, but it does not seam to work (I even booted my netbook on windows to try with IE8 without success). After browsing the french e60 forum I found their email address and mailed them, no answer so far (not even automatic). Let s wait Conclusion We can compile a kernel for the e60 reader without using the cross tools from Samsung.
There still some work to load modules as the one on the reader are copiled for 2.6.29.4 and our kernel does not want to load them. (I ve already done a few tests but that will be a next posts topic.)
But without the missing sources it will be hard for us to best use our e60 reader. Update: I got an answer from Samsung, they updated the released archive. I still have to look at it.

Today I shot an image of a bear my daughter gave to my wife for mothers day. This week I am also including a behind the scenes shot that shows how cheap my home "studio" is. In case you can't tell that is my bed with t-shirt covered boxes on it. All the light for this image comes from the window. After a little editing of the image the final outcome is what you see at the top of this post.

So, the last countdown to Paris marathon started today for me. One week left. Nearly last run before it, today, with a quiet 12.5km trail at marathon speed. The point was testing my legs one week after the Eco-Trail 55km run. I'm balanced. Things seem to be OK but running 42km two weeks after such a hard trail is really like jumping in unknown water. I feel a small pain in my right leg. Not something really worrying, just not perfect at all. The hard choice is the starting pace. I'll probably be as careful as possible, with something like 5'25"/km, which should end up in 3h48'. If things are OK at half-marathon distance (OK being "perfect"), then I'll try to speed up slightly to 5'20", trying to hit the 3h45' mark. This one is probably the very best I can do. If things aren't OK, then I'll probably slow down from km 15, or even before, and try to keep up with 5'40" and stay below 4h. Marathon start is 8h45 in Champs-Elys es. Eh, maybe Zack and Ralf will show up in Bastille neighbourhood, between km 23 and 24, as they did last year. I should be there between 10h50 and 11h05 (watch the red cap!). Now.....just rest, drink, eat pasta and sleep!

This post is password protected. To view it please enter your password below: Password:

I hope that registration for Debconf 11 will open soon as....I just booked my flights..:-) I'll be leaving Paris on Monday July 18th with EasyJet (wish me luck...but they were noticeably less expensive than Air France) and be back on Sunday July 31st. See you in Banja Luka!

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.