People behind Debian: Jörg Jaspert, FTPmaster, Debian Account Manager, and more

Photo by Wouter Verhelst

Jörg is a very active contributor within Debian, and has been for a long time. This explains why he holds so many roles (FTPmaster and Debian Account Manager being the 2 most important ones)… Better known as Ganneff (his IRC nick), he’s not exactly the typical hacker. He has no beard and used to drink milk instead of beers. :-)

Check out his interview to learn more about some of the numerous ways one can get involved in Debian, managing its infrastructure… and without having to be a packager.

Raphael: Who are you?

Jörg: My name is Jörg Jaspert and I’m 35 years old working for a small company doing system administration and consulting work for our customers. I’m married for a little while now and sometime soon a little Ganneff will be crawling out of my wife. (Whoever didn’t think of the movie “Alien” now is just boring).

Raphael: How did you start contributing to Debian?

Jörg: I started using Debian somewhere around 2000, 2001. Before that I had the misfortune to try SuSE and RedHat, both with a user experience that let me fully understand why people think Linux is unusable. (Due to my work I’m in the unfortunate situation to have to use RedHat on two machines. Funny how they are still utter crap and worse than bad toys). And all of this “lets get a Linux running here” came up because I was trying to find a replacement for my beloved OS/2 installation, which I had for some years.

So after I got Debian installed, good old Potato, I got myself active on our mailing lists, starting with the German user one.

A bit later I replied to a question if someone can help as staff for a Debian booth somewhere. It was the most boring event I ever visited (very nice orga, unfortunately no visitors), but I got a few important things there:

  • a signature from a DD on my key (Hi grisu),
  • a discussion with an upstream author with some useful piece of software to package and
  • an impression that this can be fun, if there are just some visitors for an event. So I tried again and did help as staff on a LinuxTag booth a while later.

The software I packaged, found me a sponsor and voila, maintainer I was. Some more packages got added and at some point my sponsor turned out to be my advocate. The NM process run around 2 months, and mid April 2002 I got THE MAIL.

Raphael: Some Debian developers believe that you have too many responsibilities within Debian (DAM, FTPMaster, Debconf, Partners, Planet Debian, Mirrors, …). Do you agree that it can be problematic, and if yes, are you trying to scale down?

Jörg: It’s DebConf, tssk.

And yes, I do have some extra groups and roles. And you even only list some, leaving out all I do outside Debian. But simply counting number of roles is a plain stupid way to go. Way more interesting is how much work is behind a role and how many other people are involved.

And looking at those you listed I don’t see any I am a SPOF. Let’s look at those you listed:

DAM: Here I did start out assisting James to get the huge backload down which had accumulated over time.

Nowadays I am merely the one with the longest term as DAM. Christoph Berg joined in April 2008 and Enrico Zini followed during October 2010, both very active. Especially Enrico, lately with the redesign of the NM webpages.

FTPMaster: The basic outline of the FTPMaster history is similar to the DAM one. I joined as an assistant, after the oh-so-famous Vancouver meeting in 2004. Together with Jeroen, we both then got the backload down which had accumulated there. He did most of the removals while I had a fun time cleaning up NEW. And we both prepared patches for the codebase.

And in 2007, as the last action as DPL, Sam made me FTPMaster. Since then I haven’t been alone either. In fact we have much more rotation in the team than ever before, which is a good thing. Today we are 3 FTPMasters, 4 FTP Assistants and 1 Trainee.

Though we always like new blood and would welcome more volunteers.

DebConf: I am very far outside the central DebConf team. I am not even a delegate here. Currently I am merely an admin, though there are 4 others with the same rights on the DebConf machines. I’ve not taken any extra jobs this year, nor will I. Probably for next year again, but not 2012.

Planet: I am one of three again, but then Planet is mostly running itself. Debian developers can just edit the config, cron is doing the work, not much needed here. Occasional cleanups, every now and then a mail to answer, done. In short: No real workload attached.

Mirrors: My main part here is the ftpsync scriptset. Which is a small part of the actual work. The majority of it, like checking mirrors, getting them to fix errors, etc. is done by Simon Paillard (and since some time, Raphael Geissert is active there too, you might have heard about his

Having said that, there is stuff I could have handled better or probably faster. There always is. Right now I have 2 outstanding things I want to do a (last) cleanup on and then give away.

Raphael: You got married last year. I know by experience that entertaining a relationship and/or a family takes time. How do you manage to combine this with your Debian involvement?

Jörg: Oh well, I first met my wife at the “International Conference on OpenSource” 2009 in Taiwan. So OpenSource, Debian and me being some tiny wheel in the system wasn’t entirely news to her. And in the time since then she learned that there is much more behind when you are in a community like Debian, instead of “just” doing it for work. Even better that she met Debian people multiple times already, and knows with who I am quarreling…

Also, she is currently attending a language school – having lots of homework in the evening. Gives me time for Debian stuff. :)

How that turns out with the baby I have no idea yet. I do want to train it to like pressing the M key, so little-Ganneff can deal with NEW all on its own (M being Manual reject), but it might take a day or twenty before it gets so far. :)

Raphael: Thanks to the continuous work of many new volunteers, the NEW queue is no longer a bottleneck. What are the next challenges for the FTPmaster team?

Jörg: Bad link, try this one. :)

Also, “no longer” sounds like its recent. It’s not, it’s just that people usually recognize the negative only and not the positive parts.

Well, there are a few challenges actually. The first one, even if it sounds simple, is an ongoing one: We need Debian Developers willing to do the work that is hidden behind those simple graphs.

Yes, we are currently having a great FTP Team doing a splendid work in keeping that queue reasonably small — this is a/THE sisyphean task per excellence. There will always be something waiting for NEW, even if you just cleaned the queue, you turn around and there is something else back in already. Spreading this workload to more people helps not burning one out.

So if one or more of the readers is interested, we always like new volunteers. You simply need to be an uploading DD and have a bit of free time. For the rest we do have training procedures in place.

Another one is getting the “multi-archive” stuff done. The goal is to end up with ONE host for all our archives. One dak installation. But separate overrides, trees, mirrors, policies and people (think RMs, backports team, security team). While this is halfway easy to think of in terms of “merging backports into main” it gets an interesting side note when you think of “merging security into main”. The security archive does have information that is limited to few people before public release of a security announce, and so we must make sure our database isn’t leaking information. Or our filesystem layer handling. Or logs. Etc. Especially as the database is synced in (near) realtime to a DD accessible machine. And the filesystem data too, just a little less often.

There is also a discussion about a good way to setup a “PPA for Debian” service. We do have a very far developed proposal here how it should work, and I really should do the finishing touches and get it to the public. Might even get a GSoC project on it.

So far for some short to middle term goals. If you want to go really long term, I do think that we should get to the point where we get rid of the classical view of a source package being one (or more) tarballs plus the Debian changes. Where a new version requires the full upload of one or more of those parts of the source package.

I don’t know exactly where it should end up. Sure, stuff like “one central DVCS, maintainers push there, the archive generates the source tarballs and prepares the mirrors” do sound good for a quick glance. But there are lots of trouble and pitfalls and probably some dragons hidden here.

Raphael: The Debian repositories are managed by DAK (Debian Archive Kit) which is not packaged. Thus Debian users pick tools like reprepro to manage their package repositories. Is that how things should be?

Jörg: Oh, Mark Hymers wants to do a package again. More power to him if he does, though yes, DAK is not exactly a quick-and-easy thing to install. But nowadays it is a trillion times easier than the past — thanks to Mark’s work people can now follow the instructions, scripts and whatever they find inside the setup directory.

Still, it really depends on the archive size you are managing. A complex tool like dak does not make sense for someone who wants to publish one or a dozen of his own packages somewhere. Thats just like doing a finger amputation with a chainsaw — it certainly works and is fun for the one with the chainsaw — but you probably end up a little overdoing it.

I myself am using dpkg-scan[packages|sources] from a shell script but also mini-dinstall in places (never got friend with reprepro when I looked at it). Works, and for the few dozen packages those places manage it is more than enough.

Also, using dak forces you into some ways of behaviour that are just what Debian wants — but might not be what a user wants. Like inability to overwrite an existing file. One of the reasons why won’t work with dak. Or the use of a postgres database. Or that of gpg.

Sure, if you end up having more than just a dozen packages, if you have many suites and also movement between them, then dak is sure a thing to look at.

And “how should things be”: however the user and admins of that certain install of reprepro, mini-dinstall, dak, whatever want it. This is not one-tool-for-all land :)

Raphael: What is the role of Debian Account Managers (DAM)? Do you believe that DAMs have a responsibility to “shape” Debian by defining limits in terms of who can join and what can be done within Debian?

Jörg: Quote from

The Debian Account Managers (DAM) are responsible for maintaining the list of members of the Debian Project, also known as Debian Developers. DAMs are authoritative in deciding who is a member of the Debian Project and can take subsequent actions such as approving and expelling Project members.

Now, aside from this quote, my OWN PERSONAL OPINION, without wearing anything even vaguely resembling a DAM hat: DAM is the one post that is entitled to decide who is a member or not. Usually that is in the way of joining (or not), which is simple enough. But every now and then this also means acting on a request to do something about whatever behaviour of a Debian Project member. I hate that (and i think one can easily replace I with WE there). But it’s our job.

We usually aren’t quick about it. And we don’t act on our own initiative when we do, we always have (numerous) other DDs complain/appeal/talk/whatever to us first. The “expulsion procedure”, luckily not invoked that often, does guarantee a slow process and lots of input from others.

Are we the best for it? Probably not, we are just some people out of a thousand who happen to have a very similar hobby — Debian. We aren’t trained in dealing with the situations that can come up.

But we are THE role inside Debian that is empowered to make such decisions, so naturally it ends up with us.

Raphael: You did a lot of things for Debian over the years. What did bring you the most joy? Are there things that you’re still bitter about?

Jörg: The most joy? Hrm, without being involved in Debian and SPI I would never have met my wife.
Or my current job.
Or a GR against me. Not many running around with that badge, though I’m still missing my own personal “Serious problems with Mr. Jaspert” thread. Bad you all.
Or visited so many places. Think of all the DebConfs, QA meetings, BSPs and whatever events.
Or met so many people.
Or learned so many things I would never even have come near without being DD.

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

Jörg: Yes.

Thank you to Jörg 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: Gregor Herrmann, member of the Perl team

Photo by Aigars Mahinovs

I followed Gregor’s evolution within Debian because I used to be somewhat active in the Perl team. His case is exemplar because it shows that you don’t need to be an IT professional to join Debian and to make a difference. His QA page is impressive with hundreds of packages maintained and hundreds of non-maintainer uploads too.

While he started out slowly, I remember meeting him at Debconf 7 in Edinburgh and after that he really got more implicated. Again a case of someone joining for technical reasons but getting more involved and staying there for social reasons! :-) Let’s jump into the interview and learn more about him.

Raphael: Who are you?

Gregor: I’m 41 years old, and I live in Innsbruck, Austria, in a shared apartment with a friend of mine. In my day job, I’m working at the regional addiction prevention agency, so I’m one of the few Debian guys who’s not an IT student or professional. I started maintaining packages in 2006, and I am a DD since April 2008.

Raphael: How did you start contributing to Debian?

Gregor: After having used Debian on servers for some years, I finally switched to it on the desktop after some procrastinating. Soon afterwards I wanted to know more about the “making-of”, started to join mailing lists, filed bugs, and tried to learn packaging.

Luckily I quickly found a permanent sponsor — Tony Mancill, and we’re still co-maintaining each others’ packages. And when I packaged my first Perl modules, Gunnar Wolf invited me to join the Debian Perl Group, an offer I accepted a few days later. — And I’m still there :)

Later, the NM process, although it involved some waiting times, was also a good learning experience due to my AM Wouter Verhelst. (And in the meantime the organization of the NM process has vastly improved, from what I hear.)

So my starting point for joining Debian was my curiosity but what really helped me to find my way into the project was the support of the people who invited and helped me.

Raphael: What’s your biggest achievement within Debian or Ubuntu?

Gregor: I’m not sure I can name a single big achievement but I guess I can say that my contributions to the Debian Perl Group have helped to make and keep the team a success story.

Raphael: The pkg-perl team seems to work very well. As an active member, can you explain us how it is organized? How do you explain its success? In particular it seems to be a great entry point for new contributors.

Gregor: The team is huge, both in numbers of members and packages (over 2200). Since last DebConf we manage our source packages in git, we have 2 mailing lists and an IRC channel, and we manage to keep an overview by using PET, the Package Entropy Tracker.

It’s true that we get new members on a regular basis; we try to invite people (like it happened to me 6 years ago :)) but there are also quite a few new contributors who find our docs and introduce themselves on the mailing list. Maybe someone should conduct a study and ask them what motivated them to join. :)

We hand out group membership/commit access quickly, and we try to mentor new contributors actively during their early times in the group. Some of them leave for other projects after some time, but many also stay and become DDs later.

I’m not sure what the reasons for the group’s success are, maybe a combination of:

  • a culture in the group (and also in the upstream Perl community) that’s based on fun, cooperation, and respect;
  • the fact that packaging Perl modules is most of the time quite easy;
  • a great set of tools, and also (hopefully) useful documentation;
  • a bunch of relaxed people who are open to newcomers and try to help each other.

For everyone interested in joining the Debian Perl Group, our Welcome page on the wiki is a good starting point.

Raphael: What are your plans for Debian Wheezy?

Gregor: Nothing overly exciting. What I should do is getting a newer JabRef into Debian (which involves packaging some new Java libraries — any takers?).

A solution for libdatetime-timezone-perl (which ships timezone data converted to Perl modules and tends to get outdated when the timezone data change) would be nice; let’s see if #660404 leads to some results …

And some Perl packages will also need a bit of work for the hardening build flags release goal (cf. #657853).

Raphael: What’s the biggest problem of Debian?

Gregor: Inertia. While I really like the fact that Debian is a volunteer project, and that every contributor works when and on what they decide to work on, I get the feeling that Debian could do better in moving forward, innovating, taking decisions.

I also think that more uniformity in managing source packages would make things easier; it’s quite amazing to see how many source formats, packaging helpers, patch systems, RCSs etc. are used all over the archive. I’m not advocating for mono-cultures, and I consider this diversity a strength in general, but having to find out first how this particular package works when preparing a bug fix can be annoying.

On the bright side, I think that the myth “Debian and its mailing lists are mostly about flames” can be seen as dispelled in the meantime. Sure, sometimes the tone could be a bit more civil, but in general most of the interactions I’ve seen in the last years were friendly and helpful. IMO, the Debian Project consists of mostly nice and cooperative people, and that’s what makes it fun for me.

Raphael: You’re one of the most dedicated participants to RCBW (Release Critical Bugs of the Week), an initiative to fix RC bugs every week. How much time do you spend on it? What would you advise to people who are considering to join the movement?

Gregor: I got into the habit of fixing RC bugs after having been invited to my first Bug Squashing Party in Munich some years ago. During this weekend I saw that fixing RC bugs can be fun, is often not that difficult, and gives a warm fuzzy feeling :) I can definitely recommend attending a BSP if one happens to be organized near you.

After tasting blood at this first BSP I tried to continue looking at RC bugs, and I guess I spend something around half an hour per day on it. I usually blog about it once a week, in order to motivate others to join in.

And joining is easy: just take a look at the tips people like Zack, Vorlon, or me have written. You don’t have to be a DD to help, many of my NMUs are based on patches that others kindly prepare and send to the BTS — kudos!

Another nice aspect is that the RC bug list contains problems from different fields: general packaging problems, language-specific issues, policy violations, etc. So there’s something for everybody, and you don’t have to be an expert in all fields to fix a specific bug.

What’s rewarding about fixing RC bugs is not only the feeling of accomplishment and the knowledge about having helped the next release — I also received quite a few “Thank you” mails from maintainers who were busy at that time and appreciated the help.

Raphael: Do you have wishes for Debian Wheezy?

Gregor: Well, there’s not so much left of the Wheezy release cycle if we manage to freeze in June :) Some quick thoughts for Wheezy and Wheezy+1:

  • Obviously, getting multi-arch and the hardening build flags as far as possible would be good.
  • What I like is the idea of the time-based freeze, and I hope it will work out in June. And then I hope that the freeze will be shorter this time than during the last 2 releases.
  • Unless I’m missing something, the CUT discussions have more or less died down; IMO that’s a pity because there are users who run testing and would like to avoid the several month long freeze. Maybe someone can come up with new ideas for Wheezy+1 …
  • Too late for broad adoption in Wheezy but still: What constantly annoys me is the handling of conffiles during upgrades (when I want to keep changed values but at the same time want to add new variables). Config::Model seems to be the best idea so far for configuration upgrades but it’s not yet widely adopted.

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

Gregor: There are many people in Debian I admire, too many to name them all. The first one that comes to my mind is Russ Allbery who not only does great work from lintian to Debian policy but who also sets a great example of communicating in a perfectly polite and respectful way even in heated discussions.

Thank you to Gregor 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


My Debian Activities in February 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 (384.14 €, thanks everybody!), then you can learn how I spent your money. Otherwise it’s just an interesting status update on my various projects.

Dpkg and multiarch

The month started with a decision of the technical committee which allowed me to proceed with an upload of a multiarch dpkg even if Guillem had not yet finished his review (and related changes). Given this decision, Guillem made the experimental upload himself.

I announced the availability of this test version and invited people to test it. This lead to new discussions on debian-devel.

We learned in those discussions that Guillem changed his mind about the possibility of sharing (identical) files between multiple Multi-Arch: same packages, and that he dropped that feature. But if this point of the multiarch design had been reverted, it would mean that we had to update again all library packages which had already been updated for multi-arch. The discussions mostly stalled at this point with a final note of Guillem explaining that there was a tension between convenience and doing the right things every time that we discuss far-reaching changes.

After a few weeks (and a helpful summary from Russ Allbery), Guillem said that he remained unconvinced but that he put back the feature. He also announced that he’s close to having completed the work and that he would push the remaining parts of the multiarch branch to master this week (with the 1.16.2 upload planned next week).

That’s it for the summary. Obviously I participated in the discussions but I didn’t do much besides this… I have a “mandate” to upload a multiarch dpkg to sid but I did not want to make use of it while those discussions remained pretty unconclusive. Also Guillem made it pretty clear that the multiarch implementation was “buggy”, “not right” and “not finished” and that he had reworked code fixing at least some of the issues… since he never shared that work in progress, I also had no way to help even just by reviewing what he’s doing.

We also got a few multiarch bug reports, but I couldn’t care to get them fixed since Guillem clearly held a lock on the codebase having done many private changes… it’s not quite like this that I expect to collaborate on a free software project but life is full of surprises!

I’ll be relieved once this story is over. In the mean time, I have added one new thing on my TODO list since I made a proposal to handle bin-nmu changelogs and it’s something that could also fix #440094.

Misc dpkg stuff

After a discussion with Guillem, we agreed that copyright notices should only appear in the sources and not in manual pages or --version output, both of which are translated and cause useless work to translators when updated. Guillem already had some code to do it for --version strings, and I took care of the changes for the manual pages.

I merged some minor documentation updates, fixed a bug with a missing manpage. Later I discovered that some recent changes lead to the loss of all the translated manual pages. I suggested an improvement to dh_installman to fix this (and even prepared a patch). In the end, Guillem opted for another way of installing translated manual pages.

Triggered by a discussion on debian-devel, I added a new entry to my TODO list: implementing dpkg-maintscript-helper rm_conffile_if_owner to deal with the case where a conffile is taken over by another package which might (or might not) be installed.

Misc packaging

At the start of the month, I packaged quilt 0.51. The number of Debian specific patches is slowly getting down. With version 0.51, we dropped 5 patches and introduced a new one. Later in the month I submitted 4 supplementary patches upstream which have been accepted for version 0.60.

This new version (just released, I will package it soon) is an important milestone since it’s the first version without any C code (Debian had this for a long time but we were carrying an intrusive patch for this). Upstream developer Jean Delvare worked on this and based his work on our patch, but he went further to make it much more efficient.

Besides quilt, I also uploaded dh-linktree 0.2 (minor doc update), sql-ledger 2.8.36 (new upstream version), logidee-tools 1.2.12 (minor fixes) and publican 2.8-2 (to fix release critical bug #660795).

Debian Consultants

The Debian Project Leader is working on federating Debian Companies. As the owner of Freexian SARL, I was highly interested in it since Freexian “contributes to Debian, offers support for Debian and has a strategic interest in Debian”. There’s only one problem, you need to have at least 2 Debian developers on staff but I have no employees (it’s me only). I tried to argue that I have already worked with multiple Debian developers (as contractors) when projects were too big for me alone (or when I did not have enough time). Alas this argument was not accepted.

Instead, and since our fearless leader is never afraid to propose compromises, he suggested me (and MJ Ray who argued something similar than me) to try to bring life to the Debian Consultants list which (in his mind) would be more appropriate for one-man companies like mine. I accepted to help “animate” the list, and on his side, he’s going to promote both the “Debian Companies” and the “Debian Consultants” lists.

In any case, the list has seen some traffic lately and you’re encouraged to join if you’re a freelancer offering services around Debian. The most promising thing is that James Bromberger offered to implement a real database of consultants instead of the current static page.

Book update

We made quite some progress this month. There’s only one chapter left to translate. I thus decided to start with proofreading. I made a call for volunteers and I submitted one (different) chapter to 5 proofreaders.

The liberation campaign made a nice leap forwards thanks to good coverage on We have reached 80% while we were only at 72% at the start of the month (thanks to the 113 new supporters!). There’s thus less than 5000 EUR to raise before the book gets published under a free license.

Looking at the progression in the past months, this is unlikely to be completed on time for the release of the book in April. It would be nice though… so please share the news around you.

Speaking of the book’s release, I’m slowly preparing it. Translating docbook files is not enough, I must be able to generate HTML, ePub and PDF versions of the book. I’m using Publican for most formats, but for the PDF version Publican is moving away of fop and the replacement (webkit-based) is far from being satisfactory to generate a book ready for print. So I plan to use dblatex and get Publican to support dblatex as a backend.

I have hired Benoît Guillon, the upstream author of dblatex, to fix some annoying bugs and to improve it to suit my needs for the book (some results are already in the upstream CVS repository). I’m also working with a professional book designer to get a nice design.

I have also started to look for a Python Django developer to build the website that I will use to commercialize the book. The website will have a larger goal than just this though (“helping to fund free software developers”) but in free software it’s always good to start with your own case. :-)

Hopefully everything will be ready in April. I’m working hard to meet that deadline (you might have noticed that my blog has been relatively quiet in the last month…).


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

People behind Debian: Ana Beatriz Guerrero López, member of the Debian KDE team

If you met Ana, you’ll easily remember her. She has a great and pronounced Spanish accent… :-) I’m glad that the existence of the Debian Women project helped her to join Debian because she has been doing a great job.

From KDE packaging to publicity/marketing work, her interests shifted over the years but this allowed her to stay very involved. As she explains it very well, Debian is big enough so that you can stop doing something which is no longer fun for you, and still find something new to do in another part of Debian!

Read on to learn more about Ana, the KDE team, Debian’s participation to the Google Summer of Code, and more.

Raphael: Who are you?

Ana: I’m Ana Guerrero López and I’m in my early 30s. I was born and raised in the wonderful city of Sevilla, Spain and I live in Lyon, France. I share my life with another Debian Developer and my paid work is doing Debian support and integration, so you won’t be surprised to read that Debian is a big part of my life.

Raphael: How did you start contributing to Debian?

Ana: Although I knew about the existence of Linux since 1997 or so, I didn’t really start using Linux until the summer 2001 when I finally got a computer on my own and an Internet link at home. In the beginning, I was using Mandrake in a dual boot with Windows and later around 2003, I happily moved to only using Debian and ditching the Windows partition. Once settled as a Debian user, I knew anybody could help improve the distribution but I hesitated to join mostly due to two reasons, my perception of Debian was the one of a very elitist and aggressive club and who wants to join this kind of cult^wproject? And even if I wanted to join, I did not know how to get started.

By the summer of 2004, the Debian Women project started, it made me seeing Debian as a more welcoming project, and I started maintaining my first packages. The following summer 2005, I attended akademy 2005 (the annual KDE conference) where I had the pleasure to meet there some of the people from the KDE team and this really made a difference for me. Christopher Martin and Adeodato Simó, with the help of other people, have started the maintenance of KDE as a team a few months before and by that time most of the KDE modules where under the maintenance umbrella of the team. This was a very good move since it allowed easily to share the KDE maintenance in a more coordinated way and also eased having non-DDs, like me at that time, to join in and help.

The Debian Women project started, it made me seeing Debian as a more welcoming project.

Raphael: You’re part of the Debian KDE team. What’s your role in the team and what are your plans for Wheezy?

Ana: Nowadays, I am not as active in the KDE team as I used to be in the past. The KDE 3 to KDE 4 transition was quite tiring and changes on the KDE side like the successive marketing renames, the shorter 6 months schedule (it used to be at least 9) or the uncoordinated KDE releases mostly burnt me out. Currently, I am mostly working in helping others to get started within the team, some small fixes here and there, and helping with the uploads: an upload of the full KDE suite to the archive requires some building power and upload bandwidth not everybody have.

For Wheezy, with the tentative freeze date in June, the plan is to try to ship the latest possible point release of the KDE 4.8 series. The first release of the series, 4.8.0 was released a couple of weeks ago and while writing these lines, the packaging work for 4.8 hasn’t started yet. The next move for the team is getting 4.7.4 in unstable, currently sitting in experimental.

For Wheezy, […] the plan is to try to ship the latest possible point release of the KDE 4.8 series.

Besides the KDE packages, there is some software which users perceive as KDE, such as amarok, digikam, etc., which are not part of KDE but fall under its umbrella. These other programs have their own maintainers and their updates depend greatly in the availability of them. For the KDE office suite, we have right now KOffice in the archive. KOffice got a fork some time ago named Calligra and we should replace KOffice by Calligra in the archive before the release of Wheezy. Sadly there isn’t yet a final release of Calligra to use.

My personal goal for Wheezy was to finish the removal of all the remaining packages depending on KDE 3 and Qt 3 that Squeeze still contained. The removal of the KDE 3 libraries and all the packages using them was quickly achieved after the release of Squeeze. The removal of Qt 3 soon showed that it was task harder than expected since some popular packages (sometimes not in the Debian archive, e.g. third-party scientific software) depend on it, and also Qt 3 is a requirement for LSB compatibility. Right now, Qt 3 has been orphaned for 9 months and nobody has shown any interest in adopting it.

Raphael: KDE, much like GNOME, has been forked by people who were unhappy by the direction that the project has taken since version 4 (cf Trinity). What’s your personal opinion on KDE 4.x and what’s the position of the Debian KDE team concerning this fork?

Ana: I use KDE 4 on my laptop and I think it is a solid desktop environment and platform. However I am finding it less and less attractive for me. On one side, my usage of the computer has been slightly changing and on the other side, I do not like how the new developments in KDE are evolving, things like plasmoids or activities are not attractive for me. I have switched my other 2 systems to awesome although I continue to use mainly a bunch of KDE applications: dolphin, konsole, kate, juk, kmix, etc. So you might say my desktop environment is an awesome KDE.

Regarding the Trinity project, a lot of users complained very loudly when KDE 3 got replaced by KDE 4 in testing/unstable, so I find quite laudable the decision of some users to act instead and try to continue with a forked development of KDE 3. However the Trinity team seems to be about 3 persons (funny for a project named Trinity :)) while KDE 3 is big. In perspective, it does not look that big because KDE 4 is even larger, but it is still too much for such small team. In addition those developers need to maintain Qt3 that has been end-of-lifed years ago by Nokia/Trolltech¹. So my guess is that sooner or later the project will fade away.

Nobody from the KDE team is interested in Trinity and in case someone wants to package it for Debian, they would have to make a new team. For the reasons mentioned above: Qt3 maintenance and reduced upstream group, this would be a bad idea.

My advice if you do not like KDE 4 and you miss KDE 3, would be taking a look at razor-qt based on Qt4 and quite similar to KDE 3.

¹ I read they have plans to port it to Qt4, but frankly that could take some years… same it took to the KDE project for KDE 4.0.0 ;-)

Raphael: You used to maintain, a WordPress blog dedicated to Debian, but you stopped a while ago. A few months later you started to maintain a Debian page on Google+. Why did you stop the blog and what’s your goal with the Google+ page?

Ana: I blogged about the reasons I started In short, I thought Debian needed a better system to publish news, something like a blog. I first tried to suggest the idea to the press/publicity team but they weren’t interested, so I started the project alone. IMHO the blog worked quite well and I was feeling like it should be made official. I talked about this with some people but at the time I wasn’t pushing it because I had other priorities and I knew pushing it to become official would need some extra time and energy.

Stefano decided to start the discussion about making official (that’s moving it to a domain) in its own initiative. After the public discussion and some private exchange of emails with DSA, the situation became frustrating and I decided to close after the release of Squeeze.

Later, during DebConf, an officer from the press team announced they were launching a blog and I asked Stefano if he could try to have a discussion about this to see if it could still somehow fit my ideas, and maybe contributing myself, but nobody from the press team answered Stefano’s email and the blog hasn’t started yet either.

Irony that communication didn’t work when wanting to improve communication.

About the Google+ page, everyday I follow what is going in Debian and quite often I find things I want to share. I do not want to clutter my own profiles with Debian stuff or have people following me because of that, so I decided to create the Debian page when Google+ made them available. I like the fact that people can follow that without having an account in Google+ although they can not comment anonymously. I am not happy about the fact that Google+ is a closed platform but hopefully the data will become easier to export in the near future. Right now, there are some services that provides RSS feeds of Google+ pages if you want to follow the page and you are not in Google+ (or I could setup one if several people ask me).

Raphael: Last year you helped to manage Debian’s participation to the Google Summer of Code. How did it went? Is there something that you can improve for this year?

Ana: I think last year we managed to have people in Debian more aware about what the students were doing. That also helped students to get more feedback and therefore get to know more people in the project and get more integrated. Students were sending periodic public reports available to everybody interested in the status of the projects and some of them also held their own sessions in DebConf.

We still failed to start looking for mentors early enough and to give them information about how the GSoC worked and how they could have a successful project. Having good projects in Debian is harder than in other projects because the GSoC mostly promotes having students started in Open Source *coding* for a project, while Debian is more a project about integrating software and we overall do not have so many parts that has to be coded.

My personal goal for this year is to try getting the projects earlier to attract good students from the very beginning, even if that means we have less projects than in other years.

Raphael: What motivates you to continue to contribute year after year?

Ana: Three things. I like improving the OS I use, I like the friends I have made while working in Debian through the years and because I have fun.

Also Debian is quite a big project, so if you become tired or burn out working in some area, you always can easily find interesting things to do somewhere else.

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

Ana: Adeodato Simó, he is now in a long leave from the project, but it is one of those persons who made a difference in the project in his job in the release team some years ago. Aurélien Jarno because of his tireless work in (e)glibc and porting of several architectures.

I also have special admiration for all those people who have been very active in the project for more than 7-8 years because I know it is not always easy to combine it with real life.

Thank you to Ana 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


Dpkg with multiarch support available in Debian experimental

As I announced on debian-devel, Guillem Jover uploaded a snapshot of dpkg’s multiarch branch to experimental (version 1.16.2~wipmultiarch). Beware: There will
likely be some small “interface” changes between this version and the version that will be released later in unstable (possibly in the output of dpkg --get-selections, dpkg --list, maybe other commands).

multiarch allows you to install packages from different architectures on the same machine. This can be useful if your computer can run programs from 2 architectures (eg. x86 CPU supporting i386 and amd64), or if you often need to cross-compile software and thus need the libraries of your target architecture.

Test dpkg with multiarch support

If you want to test multiarch support in dpkg, install the package from experimental (apt-get install dpkg/experimental assuming you have experimental in your sources.list).

Then you can add a supplementary architecture to your system by doing sudo dpkg --add-architecture <arch> (e.g. i386 if you are on amd64, and vice-versa). APT will automatically pick up the new architecture and start downloading the Packages file for the new architecture (it uses dpkg --print-foreign-architectures to know about them).

From there on you can install packages from the “foreign” architectures with “apt-get install foo:<arch>“. Many packages will not be installable because some of their dependencies have not yet been updated to work with in a multiarch world (libraries must be installed in a multiarch-compliant path so as to be co-installable, and then marked “Multi-Arch: same“). Other dependencies might need to be marked “Multi-Arch: foreign“. See for more HOWTO-like explanations.

Now is a good time to see if you can install the foreign packages that you could need in such a setup and to help to convert the required libraries.

You can also read Cyril Brulebois’ article which quickly shows how to hunt for the problematic packages which have not been converted to multiarch (in his sample, “ucf” is not ready. Since it’s an “Architecture: all” package which can run on any architecture, it means that it’s lacking a “Multi-Arch: foreign” field).

Report bugs

If you discover any bug in dpkg’s multiarch implementation, please report it to the Bug Tracking System (against “dpkg” with the version “1.16.2~wipmultiarch”).

If you notice important libraries or packages which are not yet multiarch ready, please open wishlist bug reports requesting the conversion and point the maintainers towards the wiki page linked above. Even better, prepare patches and submit those with your bug reports.

Again, you can follow the lead of Cyril Brulebois who filed 6 bugs!

Review the multiarch implementation

If you’re a C programmer and have some good knowledge of dpkg (or are willing to learn more of it), we would certainly benefit from more eyes reviewing the multiarch branch. If you want to discuss some design issues of the multiarch implementation in dpkg (or have questions related to your review), please get in touch via

The latest version of the branch is pu/multiarch/master in Guillem’s personal repository. I have my own version of the branch (pu/multiarch/full) which is usually a snapshot of Guillem’s branch with my own submitted fixes.

$ git clone git://
$ cd dpkg
$ git remote add guillem git://
$ git remote add buxy git://
$ git fetch guillem && git fetch buxy

If you followed the instructions above, the relevant branches are thus guillem/pu/multiarch/master and buxy/pu/multiarch/full. Both branches are regularly rebased on top of master where Guillem merges progressively the commits from the multi-arch branch as his review progresses.

Thank you in advance for your help bringing multiarch in shape for Debian Wheezy,

My Debian Activities in January 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 (213.68 €, thanks everybody!), then you can learn how I spent your money. Otherwise it’s just an interesting status update on my various projects.


The “biggest change” I made is a small patch that brings to an end years and years of recurring discussions about the build-arch and build-indep targets of debian/rules (see #229357). Last year the technical committee took this issue in its hands (see #629385) but it failed to take any resolution. Fortunately thanks to this we got some concrete numbers on the colateral damages inflicted on the archive for each possible approach. In the end, Guillem and I managed to agree on the way forward.

The remaining of what I did as dpkg maintainer has not much to do with coding. I reviewed the work of Gianluca Ciccarelli on dpkg-maintscript-helper who is trying to provide helper functions to handle migration between directories and symlinks. I also reviewed a 2000-lines patch from Patrick Schoenfeld who’s trying to provide a perl API to parse dpkg log files and extract meaningful data out of them.

I updated the dpkg-architecture manual page to document the Makefile snippet /usr/share/dpkg/ and to drop information that’s no longer releveant nowadays.

I reviewed a huge patch prepared by Russ Allbery to update the Debian policy and document the usage of symbols files for libraries. As the author of dpkg-gensymbols, I was keen to see it properly documented at the policy level.

I brought up for discussion a detail that was annoying me for quite some time: some copyright notices were embedded in translatable strings and updating them resulted in useless work for translators. In the end we decided to drop those notices and to keep them only at the source level.

I updated my multiarch branch on top of Guillem’s branch several times, all the fixes that were in my branch have been integrated (often in a modified form).

Unfortunately even if the code works quite well, Guillem doesn’t want to release anything to Debian until he has finished to review everything… and many people are annoyed by the unreasonable delay that it imposes. Cyril Brulebois tried to release a snapshot of the current multiarch branch to experimental but Guillem has been prompt to revert this upload.

I’m somewhat at a loss in this situation. I offered my help to Guillem multiple times but he keeps doing his work in private, he doesn’t share many details of his review except some comments in commit logs or when it affects the public interface. I complained once more of this sad situation.

Debian Package Maintenance Hub

That’s the codename I use for a new infrastructure that I would like to develop to replace the Package Tracking System and the DDPO and several other services. I started to draft a Debian Enhancement Proposal (DEP), see DEP-2, and requested some comments within the QA team.

For now, it looks like that nobody had major objections on the driving idea behind this project. Those who commented were rather enthusiastic. I will continue to improve this DEP within the QA team and at some point I will bring the discussion to a larger audience like

Package Tracking System

Even if I started to design its replacement, the PTS will still be used for quite some time so I implemented two new features that I deemed important: displaying a TODO notice when there is (at least) one open bug related to a release goal, displaying a notice when the package is involved in an ongoing or upcoming transition.

Misc packaging tasks

I created and uploaded the dh-linktree package which is a debhelper addon to create symlink trees (useful to replace embedded copies of PHP/JavaScript libraries by symlinks to packaged copies of those files).

I packaged quilt 0.50. I helped the upstream authors to merge a Debian patch that had been forwarded by Martin Quinson (a quilt’s co-maintainer). I packaged a security release of WordPress (3.3.1) and a new upstream release of feed2omb and gnome-shell-timer.

I prepared a new Debian release of python-django with a patch cherry-picked from the upstream SVN repository to fix the RC bug #655666.

Book update

We’re again making decent progress in the translation of the Debian Administrator’s Handbook, about 12 chapters are already translated.

The liberation campaign is also (slowly) going forward. We’re at 72% now (thanks to 63 new supporters!) while we were only at 67% at the start of January.


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

People Behind Debian: Josselin Mouette, founder of the Debian GNOME team

Josselin Mouette is one the leaders of the pkg-gnome team, he takes sound technical decisions and doesn’t fear writing code to work-around upstream issues. He deserves kudos for the work he has put into packaging GNOME over the years. He can also be very sarcastic (sometimes he even enjoys participating to flamewars on debian lists), and there are quite a few topics where we have long agreed to disagree. But this kind of diversity is also what makes Debian a so interesting place…

Read on to learn more about the pkg-gnome team, its plans for Wheezy, Josselin’s opinion on the GNOME 3 switch, and much more.

Raphael: Who are you?

Josselin: I am a 31 years old Linux systems engineer. I started in life with physics, which I studied at the ENS Lyon. I started a thesis on experimental and numerical models for optoelectronics, but when it became clear that research was not for me, I abandoned it and accepted a job at the CEA, which holds the largest computing center in Europe. Working on these machines has been the most awesome job ever (except for it being near Paris). After that I worked a bit on system monitoring technologies.

I am married, currently living in Lyon, and working for EDF (the French historical electricity company) on scientific workstations using Debian. EDF is using Debian on more than a thousand workstations and holds the fastest Debian supercomputer in the world (200 Tflops), which makes it another obvious place for Debian developers.

Raphael: How did you start contributing to Debian?

Josselin: I discovered Debian in 1999 while studying at the ENS, which is one of the biggest nests of Debian developers – while being a small place, it is producing almost one Debian developer per year on average. After wondering for a while what it could be useful for, hacking on a slink snapshot made me think that it was for, well, everything except for gaming. Later, in 2002, when I was working on optoelectronics computing codes, I started to package them for Debian in order to make them easier to install, for us as well as other labs over the world. I started the NM process, and it was going smoothly but also going to take time. However, at that moment, the frozen-bubble game went out and made quite some buzz. Since I knew a guy who knew the game’s developer, he asked me to package it. The package found 3 sponsors in a very short time and was fast-tracked into the archive at a speed that was unseen before. After which the NM process was completed very quickly.

At that time, I was a heavy WindowMaker user, but I didn’t like the direction the project was taking (actually, I wonder if there was one). GNOME was starting to become attractive, but its packaging in Debian was very ineffective, with many inconsistent packages maintained by people who didn’t ever talk to each other – some of them didn’t speak English, and some of them didn’t talk at all. Together with awesome people, among which Jordi Mallach, Gustavo Noronha Silva, JHM Dassen, Ross Burton and Sébastien Bacher, we started the GNOME team in 2003, introducing consistent packaging practices, and initiating synchronized uploads. Releasing a completely integrated GNOME 2.8 in sarge was a considerable achievement; proving (together with the Perl team) that a team was the best way to maintain large package sets changed the way people work on Debian.

“Proving […] that a team was the best way to maintain large package sets changed the way people work on Debian.”

Raphael: You’re one of the most active contributors of the team which is packaging GNOME for Debian. What would you suggest to a new contributor who would like to help the team?

Josselin: There are several ways to contact the team, but the recommended one has always been IRC. We hang on #debian-gnome on the OFTC network, so just come around and ask for us.¹ The real question is what you want to do in the team. Of course, most new volunteers want to help packaging the latest and greatest version of GNOME into unstable as soon as possible, but unless they already have Debian background, this is not the easiest task. Since there are already people working on this, the “big” packages are usually waiting on dependencies.

I used to direct newcomers towards bug triage, but it is a tedious task and I’m now convinced that our huge bug backlog will never be dealt with. The most useful thing to do for newcomers now is probably to find a GNOME or GNOME-related package that needs improvement or is lagging behind, and simply try to work on it. You can also come and fix the bugs you find annoying. Find a patch on the GNOME bugzilla, or cook it yourself, propose it, and if it’s worthy enough you’ll soon get commit access.

“Our huge bug backlog will never be dealt with.”

¹ At this point I feel worth mentioning that if no one answers in 10 minutes, it doesn’t mean that no one will answer in 2 hours, so please stay on the channel after asking.

Raphael: There’s been some controversy about GNOME 3 and the direction that the project is taking. What’s your personal stance on GNOME 3? And what’s the position of the pkg-gnome team?

Josselin: The controversy is not new to GNOME 3, but the large-scale changes made with it have put it more prominently. The criticism usually boils down to a few categories:

  1. General lack of configurability
  2. Strange design decisions
  3. Red Hat centric development
  4. Hardware requirements
  5. Change resistance

The lack of configuration options has been an ongoing criticism since GNOME 2.0 has decided to rip off most of them. Of course, when the control center was redesigned again for 3.0, there was a surge of horrified exclamations from people who missed their favorite buttons. On this topic, I fully concur with GNOME developers. The configuration option that is useful for you is not necessarily useful for someone else. Of course, sometimes developers go a bit too far, but the general direction is right. At work, we found that only a minority of users actually configure anything on their desktops: they just want something that works to launch their applications. Apple and Google have sold millions of devices by making them the simplest possible and without any configuration.

Design decisions are, on the contrary, individual decisions, and each of them, while having reasons behind it, can be questioned. I remember seeing a lot of complaints when the OK and Cancel buttons were reversed in dialog boxes, something that nobody questions anymore. GNOME Shell is full of such changes; some are easy to get accustomed with, some others just make eyebrows raise. The most obvious example is the user menu in GNOME 3.2, which contains an entry to configure your Google account, but no entry to shutdown the computer. Both decisions were taken independently, each of them with (good or bad) reasons, but the result is simply ridiculous. The default configuration in Debian will contain an extension to make it a bit better, but on the whole we don’t intend to diverge from the upstream design, on which a lot of good work has been done.

“On the whole we don’t intend to diverge from the upstream design, on which a lot of good work has been done.”

Point 3 is more complex. Red Hat being the company spending the most on GNOME, it is obvious that their employees work on making things work for their distribution. An example is the recurring discussions about relying on system services that are currently only implemented by systemd. Since there is a lot of (mostly unjustified) resistance against systemd in Debian, and since it won’t work on kFreeBSD anyway, someone needs to develop an alternative implementation of these services for upstart and sysvinit. Everything is in place for someone else to do the job but it has to be done, and this can be frustrating. Especially since it can also be hard to integrate changes needed for other distributions¹.

Hardware requirements are mostly a consequence of the previous criticism: there’s hardware that most distributions just don’t want to bother supporting. We’ve seen it in squeeze with the introduction of a hard dependency on PulseAudio. The Debian GNOME team (together with the Gentoo maintainers) made this dependency optional, carrying heavy patches, in order to cover the cases where it does not work. Now that it has gained more maturity, making this effort obsolete, the new tendency is to require 3D acceleration. For various reasons, it is not available to everyone². On this matter, the position of the Debian GNOME team has always been to support as much different configurations as possible with reasonable effort. Thanks to efforts from the incredible Vincent Untz, upstream supports a so-called “fallback mode”, which is the GNOME panel from 2.x with a lot of its bugs fixed. We intend to support this mode for as long as reasonably possible in Debian, possibly even after upstream ends up dropping it. However, other applications are going to require 3D because GStreamer is moving to clutter too, affecting video playback performance on non-accelerated systems³. For epiphany this is not a problem; only embedded video will be affected. But for totem, this is a major issue; because of that we will probably keep totem 3.0 in wheezy.

Finally, there is a natural human tendency to dislike change (I have it too), and it applies a lot to desktop users’ habits. Needless to say a change of such a scale as introducing GNOME Shell can trigger reactions. However, I don’t think it is reasonable, because of this resistance, to keep gnome-panel 2.x in Debian. This would be a lot of work on obsolete technology, and would prevent the upcoming removal of a lot of deprecated libraries. This time is much better spent improving gnome-panel 3.x in Debian and keeping the “fallback mode” great. One of the change that was made in Debian was to make it easier to find, being available as “GNOME Classic” directly from the login manager, instead of having to find it in an obscure configuration panel. In all cases, I would recommend to actually try GNOME Shell for a few hours before ditching it. I had never been accustomed to a new environment as quickly ever before.

“In all cases, I would recommend to actually try GNOME Shell for a few hours before ditching it.”

¹ Having seen several of my GDM patches reverted without a warning, I know we are not finished with carrying patches in Debian packages.
² Scientific workstations are a non-trivial example, since there is a measurable effect of using 3D in the window manager on heavy 3D applications.
³ On the other hand, on accelerated systems, this feature should end up improving performance a lot.

Raphael: What are your plans for Debian Wheezy?

Josselin: The first goal of the GNOME team is, of course, to provide again a great desktop environment to work on. For wheezy it will probably be based on GNOME 3.4. There also needs to be some work on package management interfaces. Upstream bases everything on PackageKit, but it is not as featureful as the aptdaemon Ubuntu technology. If I have time, I would also like to improve HTTP proxy support, since currently it is based on a stack of terrible hacks.

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

Josselin: Obviously I would like to make GNOME in Debian even better. That would imply working on underneath dependencies (what we now like to call plumbing) to make sure everything is working great. This would also imply working more as GNOME upstream to make it more suitable for our needs.

I would also work on large-scale improvements on the distribution, like conditional recommends which I’d love to see implemented¹, or automatic build-dependency generation. I would also work on the installer to make it better for desktops machines.

¹ The idea is to automatically install language packs, or glues between two packages when both packages are installed.

Raphael: What’s the biggest problem of Debian?

Josselin: The obvious answer is the same as the one most people you interviewed before gave: not enough members in core teams. A lot of developers join Debian to work on a small number of pet packages, and don’t necessarily want to be involved with existing teams. It is probably still not obvious enough that the primary way to start contributing to Debian is to join an existing team.

But if there is one thing that is preventing Debian from gaining more momentum now, it is a completely different one: the too short support timeframe. 3 years is really not enough for corporate users. One year to migrate from one version to another is too short, and it is not possible to skip a release. It is definitely possible to change that with reasonable effort: the long-term support after 3 years doesn’t have to cover the same perimeter as the short-term one. For example, we could upgrade the kernel to the version in the current stable release, and stop fixing all non-remote security holes. The important thing is to cover the most basic needs: companies are ready to take the risk of having less support if it allows skipping a version, but not the risk of having no support at all. And even more important is to say that you do something. Red Hat says they support a release for 10 years, but of course after 5 years the supported perimeter is extremely small.

“3 years [of support] is really not enough for corporate users.”

Long-term support will not magically fix all problems in Debian, but it will bring more corporate users into the picture. And with corporate users come paid Debian developers, who can work on critical pieces of the system. Debian was built on the synergy between individuals and companies, and in recent years – perhaps as a reaction against what happened with Ubuntu – we’ve kind of forgot the latter. A lot of individuals have joined the project, and they are actively working, for example, on shortening the release cycle, which goes against the interest of professionals. We should embrace again such users and developers, and that means adapting to the current needs of larger entities.

Raphael: You’re the maintainer of python-support, a packaging helper that was competing with python-central. Both helpers are now deprecated in favor of dh_python2. Does this mean that the situation of Python in Debian is now sane? Or are there remaining problems?

Josselin: dh_python2 (and the Python3 version, dh_python3) has a sane enough design. It fixes a lot of issues in python-central and also python-support, at the expense of somehow reduced functionality for developers. However, just like the previous tools, it merely works around design mistakes in the Python interpreter. For example it is not possible to split binary modules, pure-Python modules and byte-compiled modules in different directory trees, like Perl does – although PEP 3147 introduces a way to do so. There is still no sane and standardized way to deal with module versions. There is no difference made between the module (which is a part of language semantics) and the file containing it (an information which depends on the implementation). Developers heavily rely on introspection features and make assumptions based on the implementation, that make it impossible to work around problems with module files.

Such problems are not restricted to Python. Those who fought against Ruby gems could tell even worse stories. While introducing GObject introspection packages in Debian (they can be used in JavaScript and Python to provide modules based on GObject libraries), I was pleased to see a clear distinction between file and module, but I was again struck by the fact you are not forced to declare API versions in your Python/JS code. In all cases, there is no reliable way to detect runtime dependencies in a given Python or JavaScript file, which leaves the maintainer to declare them by hand, and of course, often be wrong about them. Add to that the fact that most errors cannot be detected before runtime. For all these reasons, and while still being fond of Python for scripts and prototyping, I’ve become really skeptical of using purely interpreted languages to write real applications. Some GNOME developers are moving away from Python and JavaScript, mostly towards Vala; I can only approve of that move and hope the same happens to other projects.

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

Of course there is the never-sleeping, never-stopping, Michael Biebl who can upload a whole GNOME release in a single week-end. But there are a lot of awesome people who make Debian something that simply works. I could talk about Cyril Brulebois from the X strike force, Julien Cristau from the release team, Sjoerd Simons for his sound advice and work on plumbing, Luca Falavigna who is so fast at processing NEW, to quote only a few of those I work with frequently. And of course, Jordi and Sam for their humor.

Thank you to Josselin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that you can find older interviews 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: Steve McIntyre, debian-cd maintainer, former Debian Project Leader

Steve McIntyre has been contributing to Debian since 1996, 2 years before I joined! But I quickly stumbled upon Steve: in 1999, he was struggling with getting his debian-cd script to produce 2 ISO images (it was the first time that Debian did no longer fit on a single CD), I helped him by rewriting debian-cd with a robust system to split packages on as many ISO images as required.

I remember those times very well because Steve was very supportive of my efforts and it was a real pleasure to get this done. His friendly nature probably also explains why he got elected Debian Project Leader twice!

Anyway, enough history, check out his interview to learn more about the great work he’s doing nowadays. My questions are in bold, the rest is by Steve.

Raphael: Who are you?

Steve: I’m a professional software engineer, 37, living in Cambridge (England) with my new wife Jo. I studied for the EIST degree at the University of Cambridge, then (like many people here, it seems) I just forgot to go home again afterwards and settled here. I spent more of my “study” time playing with Linux than working on my degree, so I guess I’m lucky that it worked and I found a career in that area!

Raphael: How did you start contributing to Debian?

Steve: During my time in college, I started hacking on software in my free time, using Slackware as my first Linux distribution from the middle of 1994. After encountering more and more problems with Slackware, I was encouraged by a number of friends to make the jump over to Debian and in October 1996 I did. The installation process back then was much harder than anything people see today, but after a long weekend I finally had my Debian system up and running.

I was already one of the main upstream developers for the Mikmod music player at that time, so that very same weekend I applied to be a DD so I could maintain it in Debian too. Back then, the NM process was much simpler: I just mailed a key to Bruce and he set me up with an account almost immediately!

I then found that Joey Hess had beaten me to it and already packaged Mikmod. Grrr! :-)

Raphael: What’s your biggest achievement within Debian?

Steve: Without a doubt, my proudest achievement within Debian is being elected Project Leader for 2 years by the other developers. It’s a great feeling to have earned the trust of your friends and peers, and also a great responsibility to go and help Debian where needed: talking to the press about Debian, assisting wherever problems crop up, etc. The DPL job is certainly a lot of hard work, and I have nothing but respect for anybody who volunteers for it.

“It’s a great feeling to have earned the trust of your friends and peers.”

Elsewhere, I’ve been leading the Debian CD team for years too, both doing most of the maintenance of the debian-cd package and producing and testing the regular installation CDs and DVDs that we ship to the world. Again, this is a time-consuming job but it needs doing and it’s worthwhile.

Raphael: You’re currently employed by ARM. What are you working on and are they supportive of your Debian involvement?

Steve: The situation within ARM is very interesting; I’m employed in PDSW (Processor Division, SoftWare), a new group founded just a couple of years back to help improve the state of software on ARM. Most of the people in the group are working on Free Software at this stage (e.g. toolchains, browsers, Linux kernel), which is lovely. Some of the engineers have also been seconded into a new non-profit company Linaro, which is a collaboration between ARM and a number of other companies investing in core Linux software and tools for ARM-based CPUs. I’m one of the ARM engineers in Linaro, and I’m a Technical Architect in the Office of the CTO. My role includes looking at future projects for Linaro to help with (e.g. ARM servers), but for the last few months I’ve been concentrating on the new armhf “architecture” in Debian, Ubuntu and elsewhere.

armhf is a new “architecture” in Debian and Ubuntu terms, but it’s not strictly a new type of hardware. Instead, it’s a new ABI. We have two reasons for doing this work:

  1. It targets the latest version of 32-bit ARM CPUs (v7) and makes better use of the hardware, for better performance. Compare targetting i686 instead of i386, for example. We’ll still support the older “armel” port for the foreseeable future for users with older hardware that can’t run armhf.
  2. More importantly: we are standardising on the ABI / compiler options / hardware support for future users.

In the past, there has been a huge amount of specialisation (aka fragmentation) in the ARM Linux environment, and that worked OK for specialised devices that only ever ran the software shipped with them. ARM CPUs are now becoming more and more mainstream, so people will expect to be able to install generic software on their machines. That gives a requirement for a standard base platform, and armhf (arm-linux-gnueabihf in GNU triplet terms) is that standard that we are pushing in the community. Debian, Ubuntu, Fedora, Suse and others are all going to use this, making compatibility possible.

I’ve been working with a small team of people to make armhf happen, helping where needed: putting together build machines; patching Debian packages directly; discussing and fixing toolchain issues with Ubuntu folks; agreeing ABI specifications with people from Fedora; advising people from other distros bootstrapping their new ARM ports.

ARM and Linaro are very supportive of this work, and it’s been lovely being sponsored to work directly on Free Software like this. It’s work that will directly benefit ARM and its partners (of course!), but it’s also helping out more generally too: Debian QA work, cross-build support, bootstrapping efforts, multi-arch. More and more of the ARM market is driven by Free Software, and companies are acknowledging that. I should probably also mention that we’re hiring…! :-)

Raphael: What are your plans for Debian Wheezy?

Steve: There are three main tracks here.

Obviously, I’m interested in seeing armhf release with Wheezy. We’ve just been added to Testing last weekend, so that’s going well. We’ve got over 90% of the archive built now, and we’re mopping up the remaining issues.

I’m the primary maintainer of cdrkit at this point, but I’d prefer to have it go away. Xorriso and the associated software in libisoburn is almost capable of replacing all the aging cdrtools-derived software that we have in Debian, The only missing feature that I’m aware of is creating the HFS hybrid filesystems that we use for installations on Mac systems. I’ve been talking with the upstream folks about this for some time already, and I’m hoping we can finish this soon enough that we can get it into Wheezy.

Finally, I’ve got the ever-growing wishlist of things for debian-cd. We’ve got the beginnings of an automated test suite that Martín Ferrari has written, but it needs integrating and improving. I want to help get regular weekly/daily/release debian-live builds running on the main CD build machine. There’s work needed if we want to make good installation media for the new multi-arch world, too. The Emdebian people are asking for help making CD images… The list goes on :-)

Raphael: The ARM community seems to be very interested in multi-arch. Can you explain why?

Steve: There are a number of reasons for ARM people to be interested in multi-arch; two really stand out for me:

  • With the historical issues around the plethora of ARM ABIs in the wild, multi-arch will allow us to potentially support multiple ABIs cleanly on one system. That allows users to have (for example) an up-to-date system that makes the most of their current hardware, yet also run legacy programs that might use an older ABI. There’s also a new 64-bit architecture coming (ARMv8) which will run older 32-bit software; again, multi-arch makes mixed installation of old and new software reasonable.
  • ARM has traditionally been a common target for cross-compilation, and I’d expect that to remain the case for a long time to come yet. For a lot of embedded developers, using a big fast i386/amd64 machine to compile is much faster than using a limited-power small ARM CPU. However, setting up sane cross-compilation environments has long been a bugbear for developers. Getting the toolchain and all the cross-architecture libraries to work together correctly can be like black magic. This is potentially the “killer app” for multi-arch: simply install the libraries for the target architecture directly on your development machine. Install a simple cross-gcc package and (maybe) qemu, and you’re all set.

“This is potentially the “killer app” for multi-arch: simply install the libraries for the target architecture […], install a simple cross-gcc package […] and you’re all set.”

Raphael: What’s the biggest problem of Debian?

Steve: For me, Debian’s biggest problem has been the same for a long time: we are forever short of enough people to do the work that we’re trying to do. That might sound like a weird thing to claim when Debian is one of the largest Free Software projects on the planet, but it’s more a statement of just how huge our goals are. Many of the largest things in Debian are developed or controlled by very small teams working very hard, and there’s always a risk of losing people due to burnout in those situations.

“We are forever short of enough people to do the work that we’re trying to do.”

Some of the tasks that should be easy given our large membership (e.g. large-scale packaging transitions) can often instead take a very long time. We are fortunate to have more people wanting to join in Debian’s work all the time, but we also need to be careful to keep on promoting what we’re doing and recruiting new contributors, encouraging them to get more and more involved in core work. Debian gets ever bigger in terms of the size and the number of packages we distribute; we’re not currently matching that growth rate elsewhere.

Raphael: What motivates you to continue to contribute year after year?

Steve: This one is much easier to answer! The thing that first attracted me to Debian was the fact that I could help to develop it, help to decide how things could and should be done within it. Instead of being forced to accept what some corporation decided I could do with my computer, I could change the software to suit my needs and preferences. Alongside that, I could get involved with a strong community of similar people all over the world, all with their own strong opinions about how software should work.

I joined in and found it was great fun and very rewarding. That hasn’t changed for me in the intervening years, and that’s why I’m still around. I work on Debian because it helps me to get the OS that I want to use. It seems that lots of people around the world find it useful too, and that’s awesome. :-)

Raphael: Do you believe that Stefano Zacchiroli will be the first DPL who managed to stay 3 consecutive years on the seat? Would you like him to candidate again?

Steve: To be honest, I would be very surprised if Zack stood again for DPL this year. He told me himself that he wasn’t planning on it, and I can understand that decision. He’s been an awesome DPL in my opinion, and I’m glad that he took the job. But: it is also a very difficult and time-consuming task that would be enough to wear down anybody. If Zack does decide to stand again, I would support him 100%. But I know that we also have lots of other good people in Debian who would be ready to take up the challenge next.

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

Steve: There are lots of people I admire in Debian, so many so that I almost don’t want to list individuals here for fear of missing people out. But… :-)

Bdale Garbee has been an inspiration to many of us, for many years. He’s technically excellent, a great friend to many of us, an endless source of sage advice and (last but not least) he has some wonderful stories to tell about his experiences over the years. On top of that, he’s just cool. :-)

Christian Perrier is another exceptional developer, in my eyes – he’s great at co-ordinating people in translations, working tirelessly to make this very important part of Debian work better and better with every release. He’s also a really nice guy and we all love him.

I also have to mention Joey Hess here, whether he likes it or not. *grin* He’s been responsible for so many good things in Debian over the years, even if he did steal my first package…

Finally, the teams of people who make sure that Debian is always working: the security team and DSA. The rest of us can choose to take time off from Debian to go and do other things, but these people need to cover things every day. That’s a major responsibility, and I salute them for taking on that challenge.

Thank you to Steve for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that you can find older interviews 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 December 2011

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

Dpkg and Multiarch

I had some hope to have a multiarch-enabled dpkg in sid for Christmas as Guillem told me that it was realistic. Alas Guillem got sick. We’re in January and we’re still not there.

While some of Guillem’s commits in December were related to multi-arch, the size of his pu/multiarch/master branch did not really shrink. We still have 36 commits to merge… most of the work he did was refactoring some parts of the code that were already merged. And he initiated some discussion on interface changes. I participated to those discussions hoping to bring them to a quick resolution.

I’m still maintaining my own pu/multiarch/full branch, it is based on Guillem’s branch but with further fixes that I developed and that he has not yet merged and with a change reverted (Guillem’s branch allows crossgrading packages between different architectures while dpkg does not manage this correctly yet).

I can only hope that January will be the last month of this never-ending saga. It’s been one year since I started working on this project. :-|

Misc dpkg work

I reviewed (and later merged) a patch of Kees Cook to enhance dpkg-buildflags so that it can report which hardening features are enabled. This feature might then be used by tools like lintian to detect missing hardening features.

I mentored Gianluca Ciccarelli who is trying to enhance dpkg-maintscript-helper to take care of replacing a directory by a symlink and vice-versa.

I took care of #651993 so that dpkg-mergechangelogs doesn’t fail when it encounters an invalid version in the changelog, and of #652414 so that dpkg-source --commit accepts a relative filename when a patch file is explicitly given.

Guillem also merged a fix I developed for LP#369898.

Packaging work

WordPress 3.3 came out so I immediately packaged it. Despite my upstream bug report, they did not update their GPL compliance page which offers the corresponding sources for what’s bundled in the tarball. So I hunted for the required sources myself, and bundled them in the debian.tar.xz of the Debian source package. It’s a rather crude solution but this allowed me to close the release critical bug #646729 and to reintroduce the Flash files that were dropped in the past… which is great since the Flash-based file uploader is nicer than the one using the browser’s file field.

Quilt 0.50 came out after 2 years of (slow) development. The Debian package has many patches and several of them had to be updated to cope with the new upstream release. Fortunately some of them were also merged upstream. It still took an entire morning to complete this update. I also converted the packaging from CDBS to dh with a short rules file.

Zim 0.54 came out and I immediately updated the package since it fixed a bug that was annoying me.

Review of the ledgersmb packaging

As the sql-ledger maintainer (and a user of this software for my accounting), I have been hoping to get ledgersmb packaged as a possible replacement for it. I have been following the various efforts initiated over time but none of them resulted in a real package in Debian.

This is a real pity so I tried to fix this by offering to sponsor package uploads. That’s why I did a first review of the packaging. It took several hours because you have to explain everything that’s not good enough.

I also filed a wishlist bug against lintian (#652963) to suggest that lintian should detect improper usage of dpkg-statoverride (this is a mistake that was present in the package that I reviewed).

nautilus-dropbox work

I wanted to polish the package in time for the Ubuntu LTS release and since Debian Import Freeze is in January, I implemented some of the important fixes that I wanted.

The Debian package diverges from upstream in that the non-free binaries are installed in /var/lib/dropbox/ instead of $HOME.
Due to a bug, the files were not properly root-owned so I first fixed this (unpacking the tarball as root lead to reuse of the embedded user & group information, and those information changed recently on the Dropbox side apparently).

Then we recently identified other problems related to proxy handling (see #651065). I fixed this too because it’s relatively frequent that the initial download triggered during the package configuration fails… and in that case it’s the user that will re-trigger a package download after having given the appropriate credentials through PackageKit. Without my fix, usage of pkexec would imply the loss of the http_proxy environment variable and thus it would not be possible for a user to download through a proxy.

Last but not least I reorganized the Debian specific patches to better separate what can and should be merged upstream, from the changes that upstream doesn’t want. Unfortunately Dropbox insists on being able to auto-update their non-free binaries, they are, thus, against the installation under /var/lib/dropbox and the corresponding changes.

Book update

We’re making decent progress in the translation of the Debian Administrator’s Handbook, about 6 chapters are already translated (not yet reviewed though).

The liberation campaign is also (slowly) going forward. We’re at 67% now (thanks to 90 new supporters!) while we were only at 60% at the start of December.


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

300 EUR for Debian

It’s the amount of the wire transfer that I made to ffis e.V., the German association that works together with Software in the Public Interest to hold Debian’s monetary assets.

This amount includes the 10% of the benefits of my Debian DVD sales (for a total of 47 USD =~ 36 EUR) and the 15% affiliate revenue that was granted to Debian by some supporters of the Debian Administrator’s Handbook crowdfunding campaign (for a total of 259.49 EUR).

Thank you everybody, this donation is really yours and not mine!

If you want to complement this donation, and make a nice gift to Debian for Christmas, go to this page and follow the instructions.