How to use quilt to manage patches in Debian packages

Most Debian source packages are using the “3.0 (quilt)” format. This means that Debian changes to upstream files are managed in a quilt patch series. Knowledge of quilt is thus a must if you want to get involved in some serious packaging work. Don’t worry, this tutorial will teach you how to use quilt in the context of Debian packaging.


Install the packaging-dev package to get a decent set of packages to do Debian packaging. It includes the quilt package.

$ sudo apt-get install packaging-dev

What’s quilt?

Read the description of the Debian package:

Quilt manages a series of patches by keeping track of the changes each of them makes. They are logically organized as a stack, and you can apply, un-apply, update them easily by traveling into the stack (push/pop).

Quilt is good for managing additional patches applied to a package received as a tarball or maintained in another version control system. The stacked organization is proven to be efficient for the management of very large patch sets (more than hundred patches). As matter of fact, it was designed by and for Linux kernel hackers (Andrew Morton, from the -mm branch, is the original author), and its main use by the current upstream maintainer is to manage the (hundreds of) patches against the kernel made for the SUSE distribution.

The various files involved

Stack of files PictureTo better understand the various quilt commands, you should have a basic idea of how the tool works. The “stack of patches” is maintained in a dedicated directory (“patches” by default, but in Debian packages we override this value to “debian/patches”). This directory contains the patch files and a “series” file that gives an ordered list of patches to apply. Example:

$ ls debian/patches/
$ cat debian/patches/series

When quilt is used, it also maintains some internal files in a directory of its own (it’s named “.pc”). This directory is used to know what patches are currently applied (.pc/applied-patches) and to keep backup copies of files modified by the various patches.

Configuring quilt

Before going further, you should put this in your ~/.quiltrc file:

for where in ./ ../ ../../ ../../../ ../../../../ ../../../../../; do
    if [ -e ${where}debian/rules -a -d ${where}debian/patches ]; then
        export QUILT_PATCHES=debian/patches

This ensures that quilt will always use “debian/patches” instead of “patches” when your current directory is within a Debian source package where debian/patches exists. If you only use quilt for debian packaging, then you can be more expedient and put a simple “export QUILT_PATCHES=debian/patches” in that file.

As a matter of personal preferences, I also have those lines in my ~/.quiltrc:

QUILT_DIFF_ARGS="--no-timestamps --no-index -p ab --color=auto"
QUILT_REFRESH_ARGS="--no-timestamps --no-index -p ab"

It enables syntax coloring for the output of several commands and customizes the generated patches to get rid of useless information. I recommend you to use those settings too.

Applying and unapplying patches, navigating in the stack of patches

When you already have a patch series, you can navigate in the stack of patches so that any subset of consecutive patches (starting from the bottom) can be applied. quilt series will list all patches known by quilt.

You can apply all patches with quilt push -a or unapply them all with quilt pop -a. You can also verify what patches are applied (quilt applied) or unapplied (quilt unapplied). quilt push applies the next unapplied patch (i.e. the patch returned by quilt next) and quilt pop unapplies the last applied patch (i.e. the patch returned by quilt top). You can give a patch name as parameter to quilt push/pop and it will apply/unapply all the patches required until the given patch is on the top.

Here are some examples of navigation in a quilt patch series

$ quilt series
$ quilt applied
No patches applied
$ quilt next
$ quilt push
Applying patch 02_disable-sources-in-sphinxdoc.diff
patching file docs/

Now at patch 02_disable-sources-in-sphinxdoc.diff
$ quilt push
Applying patch 03_manpage.diff
patching file docs/man/django-admin.1

Now at patch 03_manpage.diff
$ quilt applied
$ quilt unapplied
$ quilt pop -a
Removing patch 03_manpage.diff
Restoring docs/man/django-admin.1

Removing patch 02_disable-sources-in-sphinxdoc.diff
Restoring docs/

No patches applied
$ quilt push 03_manpage.diff
Applying patch 02_disable-sources-in-sphinxdoc.diff
patching file docs/

Applying patch 03_manpage.diff
patching file docs/man/django-admin.1

Now at patch 03_manpage.diff
$ quilt top

Creating a new patch

If there’s no quilt series yet, you want to create the “debian/patches” directory first.

If you already have one, you need to decide where to insert the new patch. Quilt will always add the new patch just after the patch which is currently on top. So if you want to add the patch at the end of the series, you need to run “quilt push -a” first.

Then you can use quilt new name-of-my-patch.diff to tell quilt to insert a new empty patch after the current topmost patch. In this operation quilt does almost nothing except updating the series file and recording the fact that the new patch is applied (even if still empty at this point!).

Now to add changes in this patch, you’re supposed to modify files but only after having informed quilt of your intent to modify those files. You do this with quilt add file-to-modify. At this point quilt will make a backup copy of that file so that it can generate the final patch when you’re done with your changes. It’s quite common to forget this step and to be unable to generate the patch afterward. That’s why I recommend you to use quilt edit file-to-modify which is a shorthand for doing quilt add and then opening the file in your favorite text editor.

If you want, you can review your work in progress with quilt diff.

When you’re done with the changes, you should call quilt refresh to generate the patch (or to update it if it was already existing). And since you’re a good packager, you call quilt header --dep3 -e to add DEP-3 meta-information to your patch header.

Importing an external patch

If someone else already prepared a patch, you can just import it right away with quilt import /tmp/the-patch. If you want to import it under a better name you can use the option “-P better-patch-name”. Like quilt new, it inserts the patch after the topmost patch.

Updating patches for a new upstream version

With some luck, your patches will still apply with some offsets in line numbers (quilt displays those offsets) and sometimes with some fuzz:

$ quilt push
Hunk #1 succeeded at 1362 (offset 11 lines).
Hunk #2 succeeded at 1533 with fuzz 1 (offset 4 lines).

While offsets are nothing to worry about (it means some lines were added and/or removed before the patched part), fuzz means that patch had to ignore some context lines to find the place where to apply the changes. In that case, you need to double check that patch did the right thing because it might have made changes somewhere where it shouldn’t. Also, you’ll have to update those patches because dpkg-source doesn’t accept any fuzz.

If you’re confident that all patches are correctly applied by quilt, you can refresh them to get rid of those warnings:

$ quilt pop -a
$ while quilt push; do quilt refresh; done

That was for the easy case. Now let’s deal with the case where some of the patches no longer apply. There’s one case that is usually nice to have:

$ quilt push
Applying patch 04_hyphen-manpage.diff
patching file docs/man/django-admin.1
Hunk #1 FAILED at 194.
1 out of 1 hunk FAILED -- rejects in file docs/man/django-admin.1
Patch 04_hyphen-manpage.diff can be reverse-applied

When the patch can be reverse-applied, it means that the upstream authors included the Debian patch (or that they made the same change even though you forgot to forward the patch). You can thus get rid of it:

$ quilt delete -r 04_hyphen-manpage.diff
Removed patch 04_hyphen-manpage.diff

Note that without the -r the patch is only dropped from the series file. With -r the patch file is also removed.

But there’s a less desirable case where the patch is still relevant but it doesn’t apply any longer:

$ quilt push
Applying patch 01_disable_broken_test.diff
patching file tests/regressiontests/test_utils/
Hunk #1 FAILED at 422.
1 out of 1 hunk FAILED -- rejects in file tests/regressiontests/test_utils/
Patch 01_disable_broken_test.diff does not apply (enforce with -f)

In that case, you should follow quilt’s advice to force the patch application, manually apply the parts of the patch that were rejected, and then refresh the patch.

$ quilt push -f
Applying patch 01_disable_broken_test.diff
patching file tests/regressiontests/test_utils/
Hunk #1 FAILED at 422.
1 out of 1 hunk FAILED -- saving rejects to file tests/regressiontests/test_utils/
Applied patch 01_disable_broken_test.diff (forced; needs refresh)
$ vim tests/regressiontests/test_utils/    
$ quilt refresh
Refreshed patch 01_disable_broken_test.diff

Other quilt commands

You should probably read quilt’s manual page too to learn about the various other commands and options that exist.

There’s at least quilt rename new-name that you can also find useful to rename the topmost patch (you can use “-P patch-to-rename” to rename a patch which is not currently at the top).


Please leave comments if you have suggestions of improvements, or if there are some tips that are good to know. I might incorporate them in this article.

Feel free to share this article with newbie packagers which are struggling with quilt. For your convenience, you can also refer to this article with this URL:

Found it useful? Be sure to not miss other packaging tips (or lessons), click here to subscribe to my free newsletter and get new articles by email.

My Debian Activities in July 2012

This is my monthly summary of my Debian related activities. If you’re among the people who made a donation to support my work (72.65 €, thanks everybody!), then you can learn how I spent your money. Otherwise it’s just an interesting status update on my various projects.

This month has been a short one since I have been away for 2 weeks of vacation.


My dpkg work encompasses a bunch of small tasks:

  • I uploaded dpkg 1.16.7 with an important bugfix for a regression.
  • I initiated a new round of discussions about how we were going to solve the problem that source packages with “Multi-Arch: same” binary packages can’t be individually bin-nmued.
  • Following that discussion, I opened a bunch of bugs to plan/discuss the transition of changelog/copyright files within the package metadata (#681289 on debian-policy, #681293 on apt-listchanges, #681295 on for
  • I also filed #681292 on sbuild to get it to use dpkg’s new syntax for bin-nmus. It will allow us to do binary-only rebuilds with arbitrary versions (instead of only “+b1″ suffixes). Ubuntu could use this for their +rebuild1, we could use this to build backports which do not require source changes (and share the common source package instead of duplicating it). It can also be useful if we ever get to the situation where transitions are prepared in external repositories and where we want bin-nmus in those repositories to have unique versions (even though the same package might be bin-nmued in multiple repositories in case of concurrent transitions).
  • I filed an unblock request for dpkg once it was almost 10 days old.
  • I did reconsider the bug #316521 where dpkg looses track of some shared directories with manually created files and proposed an updated patch. No words from Guillem on the patch yet. Fixing this would help to fix a bunch of piuparts issues.
  • And just before my vacation, I filed many bugs against dpkg itself, effectively moving some of the items that accumulated in my TODO in a public place where others can help (I’ll be happy to mentor anyone who wants to tackle one of these):
    • #681443: dpkg-source –commit should be able to merge changes in an existing patch
    • #681470: dpkg-shlibdeps: should also scan Build-Depends-Arch for minimal versions
    • #681474: Dpkg::Vendor: should support /etc/os-release and /etc/os-release.d/*
    • #681477: dpkg-vendor: implement –select-closest command
    • #681480: base-files: Provide HOME_URL, SUPPORT_URL and BUG_REPORT_URL in /etc/os-release
    • #681489: base-files: Add /etc/os-release.d/debian and make it easy to provide supplementary /etc/os-release.d/* files
  • In #595112 we discussed the specifics of a new dpkg-mainstscript-helper feature to move a conffile from one package to another.


I updated nautilus-dropbox to version 1.4.0 and python-django-registration to version 0.8. Both have been uploaded to unstable and I initially wanted to request an unblock for the latter, but it turns out it has gained reverse dependencies and version 0.8 introduces API changes so it’s not an option at this point of the freeze.

QA work

I investigated and fixed #678356 where it had been reported that the PTS static news were no longer working as expected.

At the start of the month, I also unblocked the mostly-unknown but important “mole” service… it was out of date of several weeks and several people were annoyed that the information about new upstream versions was no longer up-to-date.


Almost no Debian work during my vacation but the lack of Wifi nearby made me look for solutions to connect my computer through my Nokia N900 3G/GPRS connection. I discovered the “Mobile Hotspot” application (homepage) and it worked like a charm (although it required Maemo’s non-default devel repository to be able to install the alternative kernel “for power users”).

The Debian Handbook

Michal Čihař proposed us to host a Weblate instance to help translate the book with a web interface. He kindly agreed to implement some improvements to better suit my requirements. Those have been completed and the weblate instance is now live at

There’s no requirement to use Weblate for translations teams but for those that do, it sure makes it easier to recruit volunteers who have no prior knowledge of Git and PO files. If you want to help, please checkout this page first though, you should not start using Weblate without getting in touch with the respective translations teams.

Apart from translations, I also had the pleasure to merge some patches from Philipp Kern who improved the section covering IPv6 and a few other parts. We can make the book even better if more people share their expertise in the part of the book where they know better than me and Roland. :-)


See you next month for a new summary of my activities.

My Debian Activities in June 2012

This is my monthly summary of my Debian related activities. If you’re among the people who made a donation to support my work (168.12 €, thanks everybody!), then you can learn how I spent your money. Otherwise it’s just an interesting status update on my various projects.


This month, I resumed my work on dpkg. I concentrated my efforts on some “polishing” of the “3.0 (quilt)” format. With the latest version (1.16.6 — which was uploaded to unstable shortly before the freeze), dpkg-source restores the source tree in a clean state after a failed patch application (#652970), doesn’t overwrite the patch header from the pre-existing automatic patch, updates automatically debian/source/include-binaries during dpkg-source –commit, and supports a new –no-unapply-patches option for those who dislike the auto-unapplication at the end of the process when the patches were not applied at the start.

I wanted to go further and offer a new feature that could insert the automatic patch at the bottom of the quilt series but I have been short on time to complete this feature. I just managed to factorize all the quilt handling in a dedicated Perl module (Dpkg::Source::Quilt) to have cleaner code in the module handling the source format (Dpkg::Source::Package::V3::quilt).

For those who wonder, this feature is meant primarily for the X Strike Force team which maintains packages in Git and are doings lots of upstream cherry-picks (to fix regressions, etc.). But they also use quilt on top of that tree to keep some lasting Debian specific changes. With the 1.0 format, the “automatic diff” is a bit messy but at least it gets smaller automatically when a new upstream release gets out, there’s nothing to clean out. I’d like them to be able to use “3.0 (quilt)” while keeping their workflow. I’m leaning towards allowing “--auto-commit=first:cherry-picks” that would name the automatic patch “cherry-picks” and put it in the first position in the quilt series. (Opinions welcome on that feature, BTW)


There’s been quite some packaging in this last month before the freeze:

  • I packaged CppUTest (a test framework for C/C++), and I wrote an article about it.
  • I prepared a stable update of Publican to fix a missing dependency. I also updated the unstable version to include a backport of a fix that some user requested me to include.
  • I updated dh-linktree to improve its documentation (following a discussion that happened on debian-devel) and to deal properly with trailing slashes in its input (#673408).
  • I sponsored dblatex 0.3.4-1 and ledgersmb 1.3.18-1.
  • I updated gnome-shell-timer to a new upstream snapshot that was tagged as compatible with GNOME 3.4 (#6776516).
  • I packaged wordpress 3.4 and spent a whole day triaging the old bugs that accumulated. A few days later I developed a new infrastructure to properly manage plugins/themes/language files. The canonical directory where the user is expected to drop his custom plugins/themes is now in /var/lib/wordpress/wp-content/ and the official plugins/themes are “installed” there with symlinks pointing back to /usr/share/wordpress/wp-content/ where they actually reside.
  • I wanted to commit 2 patches for the developers-reference but then I noticed that some translations were complete and were waiting for an upload. So I cleaned the packaging (switch to dh) and I uploaded version 3.4.8 before committing the patches for #678710 and #678712.

While doing all this packaging work, I found 2 possible improvements that I filed as bug reports:

  • #676606: debcommit should be able to identify alone that a new release is prepared (when the distribution field of the changelog changes from UNRELEASED to something else).
  • #679132: lintian outputs false positives for the tag package-uses-local-diversion when neither –local nor –package is given on the dpkg-divert command line.

Debian France Booth at Solutions Linux

From June 19th to June 21th, I manned the Debian France booth at Solutions Linux together with Carl Chenet, Tanguy Ortolo and other members of the association. We answered lots of questions, sold all t-shirts and umbrellas that Carl imported from Germany and Switzerland (we really need to get our own merchandising stuff produced in France!), got people to join the association. We also presented a printed copy of the Debian Administrator’s Handbook and of the corresponding French book.

You can see Carl, me and Tanguy on this picture (click on it to see a bigger picture, thanks to Sébastien Dubois of Evolix for this one!):

I know lots of people are preparing for Debconf but I decided to not attend this year, the price of the air plane ticket was a bit too hefty for me and it was also in partial conflict with our family vacations. I thought about attending the Libre Software Meeting instead but alas I won’t go there either (but Roland Mas will be there!), I have too much work to complete before my own vacation in 2 weeks.


See you next month for a new summary of my activities.

Test Driven Development with CppUTest, now in Debian

I have recently read Test Driven Development with Embedded C by James W. Grenning and published by Pragmatic Programmers.

I really enjoyed the book: while I was aware of the huge benefits of having a comprehensive test suite, I never studied seriously the principles behind Test Driven Development (TDD) and this book makes a good introduction to the topic. At the same time it focuses on the C language and contains lots of examples on how you can create tests even for projects which have to interact with hardware or other unpredictable components (the key is to create many abstractions) using all the possibilities that C offers.

The author convincingly argues that developing code with TDD forces you to create a modular design that is easier to evolve when the underlying requirements change. He also highlights how the tests serve as reference documentation of the API.

James W. Grenning recommends CppUTest as his xUnit test framework of choice. When I wanted to try this test framework, I discovered that it was not available in Debian. I decided to package it because it has some interesting features not offered by the contenders (at least not to my knowledge). It’s now available in Debian and in Ubuntu.

First, it doesn’t require any explicit registration of tests and has a very lightweight syntax. The small downside is that CppUTest requires the usage of C++ for the tests. But C++ is compatible with C so it doesn’t matter much if you have a C++ compiler for your target. On the contrary, usage of variables and methods scoped to the test group makes it easy to write clear tests. Here’s a short sample of test code:

extern "C" {
#include "timer.h"
#include "timefn.h"
#include "CppUTest/TestHarness.h"
static Time the_time;
static const int start_sec = 123;
static const int start_nsec = 456789000;
static const int delay_sec = 8;
static const int delay_nsec = 111111000; // start_nsec + delay_nsec < 10^9
    /* Class variables available to all tests in the group */
    Timer timer;
    Delay remaining;
    /* Standard setup/teardown methods of xUnit tests */
    void setup() {
        timer = timer_new();
        time_set(&the_time, start_sec, start_nsec);
        /* [...] */
    void teardown() {
        /* [...] */
    /* Helper functions specific to the test group */
    void start_timer_with_delay(long sec, long nsec)
        timer_set_real_delay(timer, sec, nsec);
    void ensure_remaining_is(long sec, long nsec)
        CHECK_EQUAL(sec, delay_get_seconds(remaining));
        CHECK_EQUAL(nsec, delay_get_nanoseconds(remaining));
TEST(Timer, NewIsNotStarted)
/* [...] */
TEST(Timer, GetRemainingTimeWithNanosecondPrecision_ShiftOfSeconds)
    start_timer_with_delay(delay_sec, delay_nsec);
    time_set(&the_time, start_sec + delay_sec - 5, start_nsec + delay_nsec + 1000);
    remaining = timer_get_remaining_time(timer);
    ensure_remaining_is(4, 999999000);

To run those tests, you just need this boilerplate code in a main.cpp:

#include "CppUTest/CommandLineTestRunner.h"
int main(int argc, char** argv)
   return CommandLineTestRunner::RunAllTests(argc, argv);

Another interesting feature is its integrated memory leak detection system. Any test that hasn’t released allocated memory at the end of the “teardown” process will be marked as failed.

The upstream developers have made some unusual choices (static library only, installation in a private directory) but this will likely change with the switch to an automake and autoconf-based build system. I have reported the oddities that I found and I requested them to provide a pkg-config file to make it easier to compile and link unit tests exploiting CppUTest.

I already used CppUTest to develop a small application running on an embedded Linux. At some point, I might try to use CppUTest for dpkg development. I believe that it makes for a good fit. dpkg is already C++ ready since dselect is written in C++ and reuses a good part of dpkg’s code.

In any case, if you like Test Driven Development and are writing C or C++ based applications, I invite you to try CppUTest.

My Debian Activities in May 2012

This is my monthly summary of my Debian related activities. If you’re among the people who made a donation to support my work (338.26 €, thanks everybody!), then you can learn how I spent your money. Otherwise it’s just an interesting status update on my various projects.


Like last month, I did almost nothing concerning dpkg. This will probably change in June now that the book is out…

The only thing worth noting is that I have helped Carey Underwood who was trying to diagnose why btrfs was performing so badly when unpacking Debian packages (compared to ext4). Apparently this already resulted in some btrfs improvements.

But not as much as what could be hoped. The sync_file_range() calls that dpkg are doing only force the writeback of the underlying data and not of the meta-data. So the numerous fsync() that follow still create many journal transactions that would be better handled as one big transaction. As a proof of this, replacing the fsync() with a sync() brings the performance on par with ext4.

(Beware this is my own recollection of the discussion, while it should be close to the truth, it’s probably not 100% accurate when speaking of the brtfs behaviour)


I uploaded new versions of smarty-gettext and smarty-validate because they were uninstallable after the removal of smarty. The whole history of smarty in Debian/Ubuntu has been a big FAIL since the start.

Once upon a time, there was a smarty package and some plugins. Everything was great except that the files were installed in a way that differs from the upstream recommendations. So Ubuntu changed the path in their version of the package and did not check whether it broke anything else (and it did break all the plugins). Despite the brokenness of the plugins, this divergence survived for years. So several packages that were using Smarty were modified to use dpkg-vendor to use the correct path depending on whether it was built on Debian or Ubuntu.

In 2010, Smarty 3.0 has been released and instead of upgrading the smarty package to this version, one of the smarty co-maintainers introduced a smarty3 package that used yet another path (despite the fact that smarty 3 had a mode to be compatible with smarty 2).
At some point, I informed him that he had to handle the migration of users of smarty to smarty3… he acknowledged and then lost interest in smarty (“I’m no longer using it”) and did nothing.

After some more bitrot, smarty has been forcefully orphaned in August 2011 by a member of the security team. And in March this year, it has been removed from unstable despite the fact that it still had reverse dependencies (usually removals only happen when they impact no other packages, I don’t know why this wasn’t the case here).

At least the brokenness attracted some attention to the situation and Mike Gabriel contacted me about it. I offered him to take over the various packages since they all needed a real maintainer and he accepted. I sponsored his uploads of all smarty related packages (bringing in the latest upstream versions at the same time).

In the end, the situation is looking better now, except that there’s no migration path from users who rely on smarty in Squeeze. They will discover that they need smarty3 in Wheezy and that the various paths have to be adjusted. It’s probably acceptable since the new upstream versions are no longer backwards compatible with smarty 2…

The Debian Administrator’s Handbook

At the start of the month, I was busy preparing the release of the book. I introduced the publican-debian package to unstable, it’s a Publican brand (aka a set of CSS and XSL stylesheets to tailor the output of Publican) using the Debian colors and using the Debian logo. This brand is used by the book.

I also created the debian-handbook package and setup the public Git repository on

I was ready or so I thought. A few hours after the announce, the website became unusable because the numerous visitors were exhausting the maximum number of client connections. And I could not increase the limit due to Apache’s memory usage (with PHP and WordPress). We quickly off-loaded most of the static files traffic to another machine and we setup bittorrent. The problem was solved for the short term. Thousands of persons downloaded the ebook and to this date, 135 copies of the paperback have been sold.

Then I took a one-week vacation. Even though I had no Internet at the place I was, I wandered in the street to find a “Freewifi” wifi network (customers of the Free ISP can use those freely) to stay on top of incoming email. We quickly received some bug reports and I dealt with the easy ones (typos and the like) on the fly.

When I came back at home, I manually placed 54 lulu orders for the people who opted for the paperback as reward during the fundraising campaign. A bit tedious but it had to be done (if only Lulu supported a way to batch many orders at once…).

I also wanted a long term solution to avoid the use of an external host to serve static files (should a new traffic spike arrive…). So I installed nginx as a front-end. It serves static files directly, as well as WordPress pages which have been cached by wp-super-cache. Apache is still here listening on a local port and responding to the remaining queries forwarded by nginx. Once I’ll migrate to wheezy, I might completely ditch apache in favor of php5-fpm to handle the PHP pages.

Last but not least, I wanted to bootstrap the various translations that people offered to contribute. I wrote some documentation for interested translators and blogged about it. It’s shaping up nicely… check it out if you’re interested to help!


See you next month for a new summary of my activities.

The Debian Administrator’s Handbook is available

The Debian Administrator's Handbook CoverI am so glad that we managed to complete this project. Roland and I have spent countless hours on this book since December, both for the translation itself and also for all the things that we tend to forget: a nice book cover, a great book layout for the print version, coordinating the work of reviewers, registering as an editor to get an ISBN, etc. I think I will come back to this in a future article because some parts of the story are interesting.

In the mean time, enjoy the DFSG-free Debian Administrator’s Handbook:

  • get it from unstable with apt-get install debian-handbook;
  • browse the online version;
  • get the paperback or the ebook (available as PDF, EPUB, MOBI);
  • grab the sources with git clone git:// and contribute a translation :-)

Check out the official announce (there’s a discount for early buyers of the paperback).

My Debian Activities in April 2012

This is my monthly summary of my Debian related activities. If you’re among the people who made a donation to support my work (186.38 €, thanks everybody!), then you can learn how I spent your money. Otherwise it’s just an interesting status update on my various projects.

Dpkg News

For the first time since several years, there has been a dpkg release (1.16.3) where the changelog doesn’t contain any entry of my own. The 3-4 commits I did were not really worthy of a changelog entry. I must admit that it was easy to put dpkg aside given Guillem’s message and given how busy I have been with my other projects.

Keeping a low-profile for a while certainly doesn’t hurt. But I don’t intend to stop contributing to dpkg. Quite on the contrary in fact, it’s something that I (usually) enjoy doing.

Packaging News

I packaged a new upstream release of SQL-Ledger (3.0.0) and later in the month I sponsored the upload of LedgerSMB, a fork of SQL-Ledger which — unlike the former — is maintained like a typical free software project.

I also uploaded version 0.56 of Zim and updated WordPress to version 3.3.2 with its slew of security fixes.

The Debian Administrator’s Handbook

Like several months now, most of my time has been directed towards the Debian Administrator’s Handbook. The big news is that the liberation fund has been completed… this means that the book will be published under DFSG-free licenses from the start (GPL-2+ / CC-BY-SA 3.0).

We hope to publish the book next week (i.e. between May 7th and May 11th). The PDF output for the printed book is almost ready. There’s some work left for the HTML/EPUB output and we have to prepare for the release of the sources as well…

Hopefully everything will work out like planned. Stay tuned!


See you next month for a new summary of my activities.

People behind Debian: Samuel Thibault, working on accessibility and the Hurd

Samuel Thibault is a French guy like me, but it took years until we met. He tends to keep a low profile, even though he’s doing lots of good work that deserves to be mentioned.

He focuses on improving Debian’s accessibility and contributes to the Hurd. Who said he’s a dreamer? :-) Checkout his interview to have some news of Wheezy’s status on those topics.

Raphael: Who are you?

Samuel: I am 30 years old, and live in Bordeaux, France. During the workday, I teach Computer Science (Architecture, Networking, Operating Systems, and Parallel Programming, roughly) at the University of Bordeaux, and conduct researches in heterogeneous parallel computing. During the evening, I play the drums and the trombone in various orchestra (harmonic/symphonic/banda/brass). During the night, I hack on whatever fun things I can find, mainly accessibility and the Hurd at the moment, but also miscellaneous bits such as the Linux console support. I am also involved in the development of Aquilenet, an associative ISP around Bordeaux, and getting involved in the development of the network infrastructure in Bordeaux. I am not practicing Judo any more, but I roller-skate to work, and I like hiking in the mountains. I also read quite a few mangas. Saturday mornings do not exist in my schedule (Sunday mornings do, it’s Brass Band rehearsal :)).

Raphael: How did you start contributing to Debian?

Samuel: Bit by bit.

I have been hacking around GNU/Linux since around 1998. I installed my first Debian system around 2000, as a replacement for my old Mandrake installation (which after all my tinkering was actually no longer looking like a Mandrake system any more!). That was Potato at the time, which somebody offered me through a set of CDs (downloading packages over the Internet was unthinkable at the time with the old modems). I have been happily reading and hacking around documentation, source code, etc. provided on them. Contribution things really started to take off when I went to the ENS Lyon high school in 2001: broadband Internet access in one’s own student room! Since sending a mail was then really free, I started submitting bugs against various packages I was using. Right after that I started submitting patches along them, and then patches to other bugs. I did that for a long time actually. I had very little knowledge of all packaging details at the time, I was just a happy hacker submitting reports and patches against the upstream source code.

At ENS Lyon, I met a blind colleague with very similar hacking tastes (of course we got friends) and he proposed me, for our student project, to work on a “brlnet” project (now called brlapi), a client/server protocol that lets applications render text on braille devices themselves. Along the way, I got to learn in details how a blind person can use a Unix system and the principles that should be followed when developing Accessibility. That is how I got involved in it. We presented our project at JDLL, and the Hurd booth happened to be next to our table, so I discussed with the Hurd people there about how the Hurd console could be used through braille. That is how I got into the Hurd too. From then on, I progressively contributed more and more to the upstream parts of both accessibility software and the Hurd. And then to the packaging part of them. Through patches in bug reports first, as usual, as well as through discussions on the mailing lists. But quickly enough people gave me commit access so I could just throw the code in. I was also given control over the Hurd buildds to keep them running.

It was all good at that stage: I could contribute in all the parts I was caring about. People however started telling me that I should just apply for being a Debian Developer; both from accessibility and Hurd sides. I had also seen a bunch of my friends going through the process. I was however a bit scared (or probably it was just an excuse) by having to manage a gpg key, it seemed like a quite dangerous tool to me (even if I already had commit access to glibc at the time anyway…). I eventually applied for DM in 2008 so as to at least be able to upload some packages to help the little manpower of the Accessibility and Hurd teams. Henceforth I had already a gpg key, thus no excuse any more. And having it in the DM keyring was not enough for e.g. signing the hurd-i386 buildd packages. So I ended up going through NM in 2009, which went very fast, since I had already been contributing to Debian and learning all the needed stuff for almost 10 years! I now have around 50 packages in my QA page, and being a DD is actually useful for my work, to easily push our software to the masses :)

So to sum it up, the Debian project is very easy to contribute to and open to new people. It was used during discussions at the GNU Hackers Meeting 2011 as an example of a very open community with public mailing lists and discussions. The mere fact that anybody can take the initiative of manipulating the BTS (if not scared by the commands) without having to ask anybody is an excellent thing to welcome contributions; it is notable tha the GNU project migrated to the Debbugs BTS. More generally, I don’t really see the DD status as a must, especially now that we have the DM status (which is still a very good way to drag people into becoming DDs). For instance, I gave a talk at FOSDEM 2008 about the state of accessibility in Debian. People did not care whom I was, they cared that there was important stuff going on and somebody talking about it. More generally, decisions that are made through a vote are actually very rare. Most of the time, things just happen on the mailing lists or IRC channels where anybody can join the discussion.

So I would recommend beginners to first use the software, then start reporting bugs, then start digging in the software to try fix the bugs by oneself, eventually propose patches, get them reviewed. At some point the submitted patches will be correct already most of the time. That’s when the maintainers will start getting bored of just applying the patches, and simply provide with commit access, and voilà, one has become a main contributor.

Raphael: You’re one of the main contributors to the Debian GNU/Hurd port. What motivates you in this project?

Samuel: As I mentioned above, I first got real contact with the Hurd from the accessibility point of view. That initially brought me into the Hurd console, which uses a flexible design and nice interfaces to interact with it. The Hurd driver for console accessibility is actually very straightforward, way simpler than the Windows or Linux drivers. That is what caught me initially. I have continued working on it for several reasons.

First, the design is really interesting for users. There are many things that are natural in the Hurd while Linux is still struggling to achieve them, such as UID isolation, recently mentioned in LWN. What I really like in the Hurd is that it excels at providing users with the same features as the administrator’s. For instance, I find it annoying that I still can not mount an ISO image that I build on e.g. Linux now has FUSE which is supposed to permit that, but I have never seen it enabled on an ssh-accessible machine, only on desktop machines, and usually just because the administrator happens to be the user of the machine (who could as well just have used sudo…) For me, it is actually Freedom #0 of Free Software: let the user run programs for any purpose, that is, combining things together all the possible ways, and not being prevented from doing some things just because the design does not permit to achieve them securely. I had the chance to give a Hurd talk to explain that at GHM 2011, whose main topic was “extensibility”, I called it GNU/Hurd AKA Extensibility from the Ground, because the design of the Hurd is basically meant for extensibility, and does not care whether it is done by root or a mere user. All the tools that root uses to build a GNU/Hurd system can be used by the user to build its own GNU/Hurd environment. That is guaranteed by the design itself: the libc asks for things not to the kernel, but to servers (called translators), which can be provided by root, or by the user. It is interesting to see that it is actually also tried with varying success in GNU/Linux, through gvfs or Plash. An example of things I love being able to do is:

$ zgrep foo ~/*.gz

On my Hurd box, the ~/ftp: directory is indeed actually served by an ftpfs translator, run under my user uid, which is thus completely harmless to the system.

Secondly and not the least, the Hurd provides me with interesting yet not too hard challenges. LWN confirmed several times that the Linux kernel has become very difficult to significantly contribute to, so it is no real hacking fun any more. I have notably implemented TLS support in the Hurd and the Xen and 64bit support in the GNU Mach kernel used by the Hurd. All three were very interesting to do, but were already done for Linux (at least for all the architectures which I actually know a bit and own). It happens that both TLS and Xen hacking experience became actually useful later on: I implemented TLS in the threading library of our research team, and the Xen port was a quite interesting line on my CV for getting a postdoc position at XenSource :)

Lastly, I would say that I am used to lost causes :) My work on accessibility is sometimes a real struggle, so the Hurd is almost a kind of relief. It is famous for his vapourware reputation anyway, and so it is fun to just try to contribute to it nevertheless. An interesting thing is that the opinion of people on the Hurd is often quite extreme, and only rarely neutral. Some will say it is pure vapourware, while others will say that it is the hope of humanity (yes we do see those coming to #hurd, and they are not always just trolls!). When I published a 0.401 version on 2011 April 1st, the comments of people were very diverse, and some even went as far as saying that it was horrible of us to make a joke about the promised software :)

Raphael: The FTPmasters want to demote the Hurd port to the archive if it doesn’t manage a stable release with wheezy. We’re now at 2 months of the freeze. How far are you from being “releasable”?

Samuel: Of course, I can not speak for the Debian Release team. The current progress is however encouraging. During Debconf11, Michael Banck and I discussed with a few Debian Release team members about the kind of goals that should be achieved, and we are near completion of that part. The Debian GNU/Hurd port can almost completely be installed from the official mirrors, using the standard Debian Installer. Some patches need some polishing, but others are just waiting for being uploaded… Debian GNU/Hurd can start a graphical desktop and run office tools such as gnumeric, as well as the iceweasel graphical web browser, KDE applications thanks to Pino Toscano’s care, and GNOME application thanks to Emilio Pozuelo Monfort’s care. Of course, general textmode hacking with gcc/make/gdb/etc. just works smoothly. Thanks to recent work on ghc and ada by Svante Signell, the archive coverage has passed 76%. There was a concern about network board driver support: until recently, the GNU Mach kernel was indeed still using a glue layer to embed the Linux 2.2 or even 2.0 drivers (!). Finding a network board supported by such drivers had of course become a real challenge. Thanks to the GSoC work of Zheng Da, the DDE layer can now be used to embed Linux 2.6.32 drivers in userland translators, which was recently ACCEPTed into the archive, and thus brings way larger support for network boards. It also pushes yet more toward the Hurd design: network drivers as userland process rather than kernel modules.

That said, the freeze itself is not the final deadline. Actually, freeze periods are rests for porters, because maintainers stop bringing newer upstream versions which of course break on peculiar architectures. That will probably be helpful to continue improving the archive coverage.

Raphael: The kfreebsd port brought into light all the packages which were not portable between different kernels. Did that help the Hurd port or are the problems too different to expect any mutual benefit?

Samuel: The two ports have clearly helped each other in many aspects. The hurd-i386 port is the only non-Linux one that has been kept working (at least basically) for the past decade. That helped to make sure that all tools (dpkg, apt, toolchain, etc.) were able to cope with non-Linux ports, and keep that odd-but-why-not goal around, and evidently-enough achievable. In return, the kFreeBSD port managed to show that it was actually releasable, at least as a technological preview, thus making an example. In the daily work, we have sometimes worked hand in hand. The recent porting efforts of the Debian Installer happened roughly at the same time. When fixing some piece of code for one, the switch-case would be left for the other. When some code could be reused by the other, a mail would be sent to advise doing so, etc. In the packaging effort, it also made a lot of difference that a non-Linux port is exposed as released architecture: people attempted by themselves to fix code that is Linuxish for no real reason.

The presence of the kFreeBSD is however also sometimes a difficulty for the Hurd: in the discussions, it sometimes tends to become a target to be reached, even if the systems are not really comparable. I do not need to detail the long history of the FreeBSD kernel and the amount of people hacking on it, some of them full-time, while the Hurd has only a small handful of free-time hackers. The FreeBSD kernel stability has already seen long-term polishing, and a fair amount of the Debian software was actually already ported to the FreeBSD kernel, thanks to the big existing pure-FreeBSD hackerbase. These do not hold for the GNU/Hurd port, so the expectations should go along.

Raphael: You’re also very much involved in the Debian Accessibility team. What are the responsibilities of this team and what are you doing there?

Samuel: As you would expect it, the Debian Accessibility team works on packaging accessibility-related packages, and helping users with them; I thus do both. But the goal is way beyond just that. Actual accessibility requires integration. Ideally enough, a blind user should be able to just come to a Debian desktop system, plug his braille device, or press a shortcut to enable speech synthesis, and just use the damn computer, without having to ask the administrator to install some oddly-named package and whatnot. Just like any sighted user would do. He should be able to diagnose why his system does not boot, and at worse be able to reinstall his computer all by himself (typically at 2am…). And that is hard to achieve, because it means discussing about integration by default of accessibility features. For instance, the Debian CD images now beep during at the boot menu. That is a precious feature that has been discussed between debian-boot and debian-accessibility for a few weeks before agreeing on how to do it without too much disturbance. Similarly, my proposition of installing the desktop accessibility engines has been discussed for some time before being commited. What was however surprisingly great is that when somebody brought the topic back for discussion, non-debian-accessibility people answered themselves. This is reassuring, because it means things can be done durably in Debian.

On the installation side, our current status is that the stable Debian installer has a high contrast color theme, and several years ago, I have pushed toward making standard CD images automatically detect braille devices, which permits standalone installation. I have added to the Wheezy installer some software speech synthesis (which again brought discussion about size increase vs versatility etc.) for blind people who do not have a braille device.

I find it interesting to work on such topic in Debian rather than another distribution, because Debian is an upstream for a lot of distributions. Hopefully they just inherit our accessibility work. It at least worked for the text installer of Ubuntu.

Of course, the Accessibility team is looking for help, to maintain our current packages, but also introduce new packages from the TODO list or create some backports. One does not need to be an expert in accessibility: tools can usually be tested, at least basically, by anybody, without particular hardware (I do not own any, I contributed virtual ones to qemu). For new developments and ideas, it is strongly recommended to come and discuss on debian-accessibility, because it is easy to get on a wrong track that does not bring actual accessibility.

We still have several goals to achieve: the closest one is to just fix the transition to gnome3, which has been quite bad for accessibility so far :/ On the longer run, we should ideally reach the scenario I have detailed above: desktop accessibility available and ready to be enabled easily by default.

Raphael: What’s the biggest problem of Debian?

Samuel: Debian is famous for its heated debian-devel discussions. And some people eventually say “this no fun any more”. That is exemplified in a less extreme way in the debian-boot/accessibility discussions that I have mentioned above. Sometimes, one needs to have a real stubborn thick head to continue the discussion until finding a compromise that will be accepted for commit. That is a problem because people do not necessarily have so much patience, and will thus prefer to contribute to a project with easier acceptance. But it is also a quality: as I explained above, once it is there, it is apparently for good. The Ubuntu support of accessibility in its installer has been very diverse, in part due to quite changing codebase. The Debian Installer codebase is more in a convergence process. Its base will have almost not changed between squeeze and wheezy. That allowed the Debian Accessibility team to continue improving its accessibility support, and not have to re-do it. A wiki page explains how to test its accessibility features, and some non-debian-accessibility people do go through it.

A problem I am much more frightened by is the manpower in some core teams. The Debian Installer, grub, glibc, Xorg, gcc, mozilla derivatives, … When reading the changelogs of these, we essentially keep seeing the same very few names over and over. And when one core developer leaves, it is very often still the same names which appear again to do the work. It is hard to believe that there are a thousand DDs working on Debian. I fear that Debian does not manage to get people to work on core things. I often hear people saying that they do not even dare thinking about putting their hands inside Xorg, for instance. Xorg is complex, but it seems to me that it tends to be overrated, and a lot of people could actually help there, as well as all the teams mentioned above. And if nobody does it, who will?

Raphael: Do you have wishes for Debian Wheezy?

Samuel: That is an easy one :) Of course I wish that we manage to release the hurd-i386 port. I also wish that accessibility of gnome3 gets fixed enough to become usable again. The current state is worrying: so much has changed that the transition will be difficult for users already, the current bugs will clearly not help. I also hope to find the time to fix the qt-at-spi bridge, which should (at last!) bring complete KDE accessibility.

Raphael: Is there someone in Debian that you admire for their contributions?

Samuel: Given the concerns I expressed above, I admire all the people who do spend time on core packages, even when that is really not fun everyday. Just to alphabetically name a few people I have seen so often here and there in the areas I have touched in the last few years: Aurélien Jarno, Bastian Blank, Christian Perrier, Colin Watson, Cyril Brulebois, Frans Pop, Jörg Jaspert, Joey Hess, Josselin Mouette, Julien Cristau, Matthias Klose, Mike Hommey, Otavio Salvador, Petr Salinger, Robert Millan, Steve Langasek. Man, so many things that each of them works on! Of course this list is biased towards the parts that I touched, but people working in others core areas also deserve the same admiration.

Thank you to Samuel for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that older interviews are indexed on

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on, Google+, Twitter and Facebook.

People Behind Debian: Francesca Ciceri, Member of the Debian Press & Publicity Teams

Francesca Ciceri, photo by Andrew McMillan, CC-BY-SA 2.0

I met Francesca in Debconf 11 in Banja Luka. If I recall correctly, it’s Enrico Zini who introduced me to her, because she was the “madamezou” (her IRC nickname) who started to get involved in the publicity team. Since then — and despite having a bachelor thesis to complete — she got way more involved and even gained official responsibilities in the project.

Before starting with the interview, I wanted to mention that Francesca is drafting a diversity statement for Debian… I was expecting the discussions to go nowhere but she listened to all objections and managed to improve the text and build a consensus around it. Thank you for this and keep up the good work, Francesca!

Raphaël: Who are you?

Francesca: My name is Francesca, I’m 30 and I studied Social Sciences. Currently I live in Italy but I’m planning to go abroad (not a lot of jobs here for geeky social scientists). Apart for Debian and FLOSS world in general, I have unrestrained passions for chocolate; zombie movies; sci-fi; zombie books; {knitting|sewing|crafting} and DIY in general; zombie videogames; bicycles; pulling apart objects to look inside them; splatter B movies, David Foster Wallace’s books, playing trumpet, and… did I already mentioned zombies?

Days are too short for all this stuff, but I try to do my best.

Raphael: How did you start contributing to Debian?

Francesca: Some years ago I was stuck in bed for — literally — some months, due to a grave series of migraine attacks. I wasn’t able to do anything: no social life, no books or television. So, I decided to turn on the laptop and do something constructive with it: I was already a Debian user and it seemed quite logical to me to try to give back to the community. I am not a coder and I’ve not studied Computer Science, so my first step was to join an Italian Debian on-line community (Debianizzati) and help with tutorials, users support, wiki management. In a couple of months I learnt many things: helping other users with their problems forces you to do lots of research!

My first contributions to the Debian project were mostly translations of the main website. Translators are the perfect typos spotters: they work so precisely on the text to be translated that they finish to do a great QA job. This is how I’ve started to contribute to the Debian website: with very simple things, fixing typos or wrong links or misplaced wml tags. I still remember my first commit to the website: the idea was to undercase some tags, but it ended up that I misplaced some of them and — in addition — I fixed them only in the English page and not on the translations as well. When after a couple of minutes, Kåre Thor Olsen — a long time contributor of the team and now webmaster — reverted my commit, I felt so stupid and full of shame. But, to my great surprise, no one treated me like an idiot for that error: Gerfried Fuchs, one of the guru of the team, replies me in a really helpful and polite way explaining what I did wrong and how to do things correctly. I think this episode was a turning point in my Debian life: there’s this idea that Debian Developers are just a bunch of arrogant assholes and maybe it was true in the past, but for my experience they are not. Well, at least the ones I met and work with ;).

“To my great surprise, no one treated me like an idiot for that error.”

Since then, I joined the WWW team and helped them apply the shiny new design provided by Kalle Söderman. A lot of work was done during the week immediately before the release of the new website. Oh that was a week! We worked night and day to have the new design ready for February 6th, and it was fantastic when we finally published it, simultaneously with the release of Squeeze.

At the same time, I started to contribute more actively to the Debian Publicity team, not only translating news but also writing them. It can sound scary for a non native English speaker to write something from scratch in English, but you have to keep in mind that your text will be reviewed by native speakers before being published. And we have some fantastic reviewers in the English localisation team: particularly Justin B Rye, who is tireless in his effort and — more recently — Moray Allan.

I think I’m particularly lucky to work with all these people: there’s a special mood in both Publicity and WWW team, which makes you feel happy to do things and at the same time pushes you to do more just because it’s fun to work with them sharing jokes, ideas, rants, patches and hugs.

Raphaël: I believe that you have been trough the new member process very quickly. You’re now a Non-Uploading Debian Developer. How was the experience and what does this mean to you?

Francesca: Becoming a Debian Developer was not so obvious for me, because I didn’t need to be a DD for the work I do in Debian. For instance, I don’t maintain packages, so I had no reasons to want to become a DD in order to have uploading rights. For a while I didn’t really feel the necessity of being a DD.

Luckily, some people started to pester me about it, asking me to apply for the NM process. I remember Martin Zobel-Helas doing this for an entire week every single day, and Gerfried Fuchs doing it as well. Suddenly, I realized that people I worked with felt that I deserved the DD status and that I simply had thought I didn’t. As a non coder and a woman, there probably was a bit of impostor syndrome involved. Having people encouraging me, gave me more confidence and the desire to finally become a DD. And so I did.

The process for non uploading DD is identical to the one to become an uploading DD, with one exception: in the second part of the process (named Tasks and Skills) instead of questions about how to create and maintain packages, there are questions about the non packaging work you usually do in Debian.

The general resolution which created the possibility to become a non uploading DD gave us a chance to recognize the great effort of Debian contributors who work in various area (translations, documentation, artworks, etc.) that were not always considered as important as packaging efforts. And this is great because if you are a regular contributor, if you love Debian and you are committed to the project, there are no reasons to not be an official member of it.

With regards to this, I like the metaphor used by Meike Reichle in her recent talk about the Debian Women Project (video recording here):

a Debian Developer status is a lot like a citizenship in a country that you’re living in. If you live in a country and you don’t have citizenship, you can find a job, buy a house, have a family [...] but if this country – at any point in time – decides to go into a direction that you don’t like, there’s nothing you can do about it. You are not in the position to make any change or to make any effect on that country: you just live there, but there’s no way that you can excercise influence on the people who run this country.

Raphaël: You recently joined the Debian Press Team. What does it involve and how are you managing this new responsibility?

Francesca: The Press Team is basically the armed wing of the Publicity Team: it handles announcements that need to be kept private until the release, moderate the debian-announce and debian-news mailing list and maintain contacts with press people from outside the project.

The “real” job, so, is done within the Publicity Team. The most important part of our work is to write announcements and the newsletter: while the newsletter is published bi-weekly, the announcements need to be write in a shorter timeframe. Localization is really important in spreading Debian word, so we work closely with translators: both announcements and DPN are usually translated in four or five different languages.

The publicity work could be stressful, as we have strict deadlines, we need to take quick decisions and often do last-minute changes. Personally, I like it: I work better under pressure. But I know that is sometimes difficult for contributors to accept that we can’t debate endlessly on details, we have just to go on and do our best in a given timeframe.

“The publicity work could be stressful, as we have strict deadlines, […]. Personally, I like it.”

Raphael: You’re one of the main editor behind the Debian Project News. What’s the role and scope of this newsletter?

Francesca: Debian Project News is our beloved newsletter, direct successor of the Debian Weekly News founded by Joey Hess in 1999 and later kept alive by Martin Schulze. In 2007, Debian Weekly News was discontinued but in 2008 the project was revived by Alexander Reichle Schmehl. The idea behind DPN is to provide our users an overview of what is happening inside and outside the project.

As the core team of editors is formed by three people, the main problem is to be able to collect enough news from various sources: in this sense we are always glad when someone points us to interesting blogposts, mails and articles.

DPN is also a good chance for non coders to contribute to Debian: propose news, write paragraphs and review the draft before the publication are quite easy tasks but very useful. English native speakers can do a proofread (as no one of the main editors is a native speaker) while others can always translate DPN in their native language. People who want to help us can take a look at our wiki page.

“DPN is also a good chance for non coders to contribute to Debian.”

Just yesterday I realized that since January we don’t miss or delay an issue: so I’d like to thank the fantastic team of editors, reviewers and translators who made it possible.

The team is now working on another way of spreading Debian’s message: a long-time project is finally becoming real. Stay tuned, surprise arriving!

Raphael: You’re trying to organize IRC training sessions but that doesn’t seem to take off in Debian, while it’s quite common in the Ubuntu community. How do you explain that?

Francesca: I’m not sure about it: both Debian users and contributors seemed to appreciate this initiative in the past. I was quite surprised by the amount of Debian members present during the various sessions and by the amount of interesting questions asked by the users. So the only reason I can think about is that I need to put more enthusiasm in convincing the teams to do it: they need more encouragement (or to be pestered more!).

I, for myself, think that IRC training sessions are a great way to promote our work, to share our best practice, to talk about our project to a wider audience. And I’ll sure try to organize more of them. Help, suggestions, ideas are really welcome!

Raphael: If you could spend all your time on Debian, what would you work on?

Francesca: There is a project I’d like to give more love, but I always end up without the time to do it: the project. Back in 2007, Holger Levsen founded it with the aim of reducing the gap between Debian contributors and Debian users, giving all an opportunity to contribute, share ideas and more. The project was discontinued and I’d really like to revive it: in these years various things have changed, but I think that the core idea of having a node to connect existing local communities is still good and doable. In Debian we don’t have the wide and well articulated local infrastructure present in other distributions (Ubuntu, particularly, but also Fedora): even if I don’t like too centralized structures, I think that a better connection between the project and local groups of users and on-line communities would be a step forward for the project.

Being part of the Events Team, I’m aware of how much we need to improve our communication with local groups. An example is the events organization: sometimes, Publicity and Events teams even don’t know about regional Debian related events (like booth at conferences, workshops, talks, install parties, etc) and this is a shame because we could offer a lot of help in organizing and promoting local events.

What we lack is better communication. And project could give us exactly this. Could be a cluster of local groups, a platform for events organization and even a useful resource for newbies who want to find a local group near them. I started some effort in this sense, sending a proposal about it, working on a census of Debian local groups. Any help is appreciated!

I’m really curious to see how many Debian communities (from all around the world and the web) are out there, and I’d love to have members from these communities better connected with the Debian Project.

Raphael: What’s the biggest problem of Debian?

Probably the bikeshedding feticism of almost all of us. It’s the other side of the coin of Debian’s commitment to technical excellence and our perfectionism, but sometimes it leads just to endless discussions about details, and it is a blocker for various initiatives.

In Debian, you have to be really patient and — in a way — stubborn to push some changes. This is frustrating sometimes.

On the other hand, I really appreciate how people take some times to think to each proposals, give some feedback and discuss about it: the process could be annoying, indeed, but the result is often an improvement of the initial proposal.

Raphael: Is there someone in Debian that you admire for their contributions?

Most of my teammates are simply brilliant and adorable and hard-working. But I have to admit that I particularly admire David Prévot: beside being a webmaster he does a lot of things, from French translations to DPN editing. All his contributions have a great quality and he’s able to push you always further in doing things and doing them better. He is a good example of how I’d like to be as contributor: smart, tireless, friendly.

Thank you to Francesca for the time spent answering my questions. I hope you enjoyed reading her answers as I did. Note that older interviews are indexed on

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on, Google+, Twitter and Facebook.

My Debian Activities in March 2012

This is my monthly summary of my Debian related activities. If you’re among the people who made a donation to support my work (227.83 €, thanks everybody!), then you can learn how I spent your money. Otherwise it’s just an interesting status update on my various projects.


Thanks to Guillem, dpkg with multiarch support is now available in Debian sid. The road has been bumpy, and it has again been delayed multiple times even after Guillem announced it on debian-devel-announce. Finally, the upload happened on March 19th.

I did not appreciate his announce because it was not coordinated at all, and had I been involved from the start, we could have drafted it in a way that sounded less scary for people. In the end, I provided a script so that people can verify whether they were affected by one of the potential problems that Guillem pointed out. While real, most of them are rather unlikely for typical multiarch usage.

Bernhard R. Link submitted a patch to add a new –status command to dpkg-buildflags. This command would print all the information required to understand which flags are activated and why. It would typically be called during the build process by debian/rules to keep a trace of the build flags configuration. The goal is to help debugging and also to make it possible to extract that information automatically from build logs. I reviewed his patch and we made several iterations, it’s mostly ready to be merged but there’s one detail where Bernhard and I disagree and I solicited Guillem’s opinion to try to take a decision. Unfortunately neither Guillem nor anyone else chimed in.

On request of Alexander Wirt, I uploaded a new backport of dpkg where I dropped the DEB_HOST_MULTIARCH variable from dpkg-architecture to ensure multi-arch is never accidentally enabled in other backports.

One last thing that I did not mention publicly at all yet, is that I contacted Lennart Poettering to suggest an improvement to the /etc/os-release file that he’s trying to standardize across distributions. It occurred to me that this file could also replace our /etc/dpkg/origins/default file (and not only /etc/debian_version) provided that it could store ancestry information. After some discussions, he documented new official fields for that file (ID_LIKE, HOME_URL, SUPPORT_URL, BUG_REPORT_URL). Next step for me is to improve dpkg-vendor to support this file (as a fallback or as default, I don’t know yet).


I packaged quilt 0.60 (we’re now down to 9 Debian-specific patches, from a whopping 26 in version 0.48!) and zim 0.55.

In prevision of the next upstream version of Publican, I asked the Perl team to package a few Perl modules that Publican now requires. Less than two weeks after, all of them were in Debian Unstable. Congrats and many thanks to the Perl team (and Salvatore Bonaccorso in particular, which I happen to know because we were on the same plane during last Debconf!).

On a side note, being the maintainer of nautilus-dropbox became progressively less fun over the last months, in particular because the upstream authors tried to override some of the (IMO correct) packaging decisions that I made and got in touch with Ubuntu community managers to try to have their way. Last but not least, I keep getting duplicates of a bug that is not in my package but in the official package and that Dropbox did not respond to my query.

Book update

The translation is finished and we’re now reviewing the whole book. It takes a bit more time than expected because we’re trying to harmonize the style and because it’s difficult to coordinate the work of several volunteer reviewers.

The book cover is now almost finalized (click on it to view it in higher definitions):

We also made some progress on the interior design for the paperback. Unfortunately, I have nothing to show you yet. But it will be very nice… and made with just a LaTeX stylesheet tailored for use with dblatex.

The liberation fundraising slowed down with only 41 new supporters this month but it made a nice bump anyway thanks to a generous donation of 1000 EUR by Offensive security, the company behind Backtrack Linux. They will soon communicate on this, hopefully it will boost the operation. It would be really nice if we managed to raise the remaining 3000 EUR in the few weeks left until the official release of the book!

The work on my book dominated the month and explains my relative inactivity on other fronts. I worked much more than usual, and my wife keeps telling me that I look tired and that I should go in bed earlier… but I see the end of the tunnel: if everything goes well, the book should be released in a few weeks and I will be able to switch back to a saner lifestyle.


See you next month for a new summary of my activities.