People behind Debian: Maximilian Attems, member of the kernel team

Maximilian, along with the other members of the Debian kernel team, has the overwhelming job of maintaining the Linux kernel in Debian. It’s one of the largest package and certainly one where dealing with bug reports is really difficult as most of them are hardware-specific, and thus difficult to reproduce.

He’s very enthusiastic and energetic, and does not fear criticizing when something doesn’t please him. You’ll see.

My questions are in bold, the rest is by Maximilian.

Who are you?

My name is Maximilian Attems. I am a theoretical physicist in my last year of PhD at the Technical University of Vienna. My main research area is the early phase of a Quark-Gluon Plasma as produced in heavy ion collisions at the LHC at CERN. I am developing simulations that take weeks on the Vienna Scientific Cluster (in the TOP 500 list). The rest of the lab is much less fancy and boils down to straight intel boxes without any binary blobs or external drivers (although lately we add radeon graphics for decent free 3D). Mathematica and Maple are the rare exceptions to the many dev tools of Debian (LaTeX, editors, git, IDE’s, Open MPI, ..) found at the institute, as those are unfortunately yet unmatched in Free Software for symbolic computations. The lab mostly runs a combination of Debian stable (testing starting from freeze) for desktops and oldstable/stable for servers. Debian is in use for more than 10 years. So people in the institute know some ups and downs of the project. Newcomers like my room neighbors are always surprised how functional a free Debian Desktop is. :)

What’s your biggest achievement within Debian?

Building lots and lots of kernels together with an growing uptake of the officially released linux images.

I joined the Debian kernel team shortly after Herbert Xu departed. I had been upstream Maintainer of the linux-2.6 janitor project for almost a year brewing hundreds of small cleanups with quilt in a tree named kjt for early linux-2.6. In Debian we had lots of fun in sorting out the troubles that the long 2.5 freeze had imposed: Meaning we were sitting on a huge diverging “monolithic” semi-good patchset. It was great fun to prepare 2.6.8 for Sarge with a huge team enthusiastic in shipping something real close to mainline (You have to imagine that back then you had no stable or longterm release nor any useful free tools like git. This involved passing patches around, hand editing them and seeing what the result does.)

From the Sarge install reports a common pattern emerged that the current Debian early userspace was causing lots of boot failures. This motivated me to develop an alternative using the new upstream initramfs features. So I got involved in early userspace. Thanks to large and active development team initramfs-tools got a nice ecosystem. It still tries to be as generic and flexible as possible and thus gains many nice features. Also H. Peter Anvin (hpa) gave me the official co-maintenance of klibc. klibc saw uptake and good patches from Google in the last 2 years. I am proud that the early userspace is working out fairly well these days, meaning you can shuffle discs around and see your box boot.

Later on we focused on 2.6.18 for Etch, which turned out to a be good release and picked up by several other distributions. Only very much later we would see such a “sync” again. With 2.6.26 for Lenny we got somehow unlucky as we just missed the new longterm release by one release. We also pushed for another update very late (during freeze) in the release cycle, which turned out to semi-work as too much things depend on linux-2.6.

For Squeeze 2.6.32 got picked thanks to discussions at Portland Linux Plumbers and it turned out to be a good release picked up by many distributions and external patchsets. The long-term support is going very well. Greg KH is doing a great job in collecting various needed fixes for it. Somehow we had hoped that the Squeeze freeze would start sooner and that the freeze duration would be shorter, since we were ready for a release starting from the actual freeze on. The only real big bastard on the cool 2.6.32 “sync” is Red Hat. Red Hat Enterprise 6.0 is shipping the linux-2.6 2.6.32 in obfuscated form. They released their linux-2.6 as one big tarball clashing with the spirit of the GPL. One can only mildly guess from the changelog which patches get applied. This is in sharp contrast to any previous Red Hat release and has not yet generated the sharp and snide comments in press it deserves. Red Hat should really step back and not make such stupid management moves. Next to them even the semi-maintained Oracle “Unbreakable” 2.6.32 branch looks better: It is git fetchable.

What are your plans and those of the kernel team for Debian Wheezy?

Since 2.6.32 many of the used patches landed upstream or are on the way (speakup, Kbuild Debian specific targets, ..). The proper vfs based unionfs is something we’d be looking forward. We haven’t yet picked the next upstream release we will base Wheezy on, so currently we can happily jump to the most recent ones. There are plans for better interaction with Debian Installer thanks to generating our udebs properly in linux-2.6 source itself. Also we are looking forward to using git as tool of maintenance. We’d hope that this will also allow for even better cross distribution collaboration.

Concerning early userspace I plan to release an initramfs-tools with more generic userspace for the default case and finally also a klibc only for embedded or tuning cases.

What do you like most in Debian?

For one thing I do like the 2 year release cycle. It is not too long to have completely outdated software and on the other hand it gives enough time to really see huge progress from release to release. Also at my institute the software is is recent enough without too much admin overhead. For servers the three years support are a bit short, but on the manageable side.

I do enjoy a lot the testing distribution. For my personal use it is very stable and thus I mainly run testing on my desktop and work boxes. (Occasionally mixing in things from sid for unbreaking transition or newer security fixes).

Debian is independent and not a commercial entity. I think this is its main force and even more important these days. I enjoy using the Debian platform a lot at work thus in return this motivates me to contribute to Debian itself. I also like the fact that we strive for technical correctness.

Is there some recurrent problem that hinders the progress of Debian?

The “New Maintainer process” is a strange way to discourage people to contribute to Debian. It is particularly bureaucratic and a huge waste of time both for the applicant and his manager. It should be completely thrown overboard.

One needs a more scalable approach for trust and credibility that also enhances the technical knowledge for coding and packaging of the applicant.

NM is currently set in stone as any outside critics is automatically rejected. Young and energetic people are crucial for Debian and the long-term viability of the project, this is the reason why I’d consider the “New Maintainer process” as Debian’s biggest problem.

Note from Raphaël Hertzog: I must say I do not share this point of view on the New Maintainer process, I have witnessed lots of improvements lately thanks to the addition of the Debian Maintainer status, and to the fact that a good history of contribution can easily subsume the annoying Tasks & Skills questionnaire.

Another thing I miss is professional graphics’ input both for the desktop theme and the website. I know that effort has been done there lately and it is good to see movement there, but the end result is still lacking.

Another trouble of Debian is its marketing capabilities. It should learn to better sell itself. It is the distribution users want to run and use—not the rebranded copies of itself with lock-in “sugar”. Debian is about choice and it offers plenty of it: it is a great default Desktop.

Linus Torvalds doesn’t find Debian (and/or Ubuntu) a good platform to hack on the kernel. Do you know why and what can we do about this?

The Fedora linux-2.6 receives contributions from several Red Hat employed upstream sub-Maintainers. Thus it typically carries huge patches which are not yet upstream. As a consequence eventual userland troubles get revealed quite quickly and are often seen there first. The cutting edge nature of Fedora rawhide is appealing for many developers.

The usual Debian package division of library development files and the library itself is traditionally an entry barrier for dev on Debian. Debian got pretty easily usable these days, although we could and should again improve a lot more in this sector. Personally I think that Linus hasn’t tried Debian for years.

I have the feeling that the implication of the Debian Kernel team in LKML has been on the rise. Is that true and how do you explain this?

Ben Hutchings is the Nr.1 contributor for 2.6.33. He also is top listed as author of patches on stable 2.6.32. Debian is not listed as organization as many send their linux-2.6 patches from their corporate or personal email address and thus it won’t be attributed to Debian.

There is currently no means to see how many patches get forwarded for the stable tree, but I certainly forwarded more then fifty patches. I was very happy when Greg KH personally thanked me in the release.

In the Squeeze kernel, the firmwares have been stripped and moved into separate packages in the non-free section. What should a user do to ensure his system keeps working?

There is a debconf warning on linux-2.6 installation. It is quite clear that the free linux-2.6 can’t depend on the firmware of the non-free archive (also there is no strict dependency there technically).

On the terminal you’d also see warnings by update-initramfs on the initramfs generation for drivers included in the initramfs.

The debconf warning lists the filename(s) of the missing firmware(s). One can then “apt-cache search” for the firmware package name and install it via the non-free repository. The check runs against the current loaded modules. The match is not 100% accurate for special cases as the one where the device might be handled well by this driver without firmware, but is accurate enough to warrant the warning.

The set of virtualization technologies that the official Debian kernel supports seems to change regularly. Which of the currently available options would you recommend to users who want to build on something that will last?

KVM has been a smooth ride from day zero. It almost got included instantly upstream. The uptake it has is great as it sees both dev from Intel and AMD. Together with libvirt it’s management is easy. Also the performance of virtio is very good.

The linux containers are the thing we are looking forward for enhanced chroots in the Wheezy schedule. They are also manageable by libvirt.

Xen being the “bad outside boy” has an incredible shrinking patchset, thus is fair to expect to see it for Wheezy and beyond. For many it may come a bit late, but for old hardware without relevant CPU it is there.

Many tend to overstate the importance of the virtualization tech. I’d be much more looking forward to the better Desktop support in newer linux-2.6. The Desktop is important for linux and something that is in heavy use. The much better graphics support of the radeon and nouveau drivers:

  • For Nouveau in 32 with 33 drm we could only deliver a first taste meaning something better then rusty nv.
  • For Radeon the support for Evergreen and newer is only been shaping now.

The performance optimizations thanks to dcache scalability work and the neat automatic task-grouping for the CPU scheduler are very promising features for the usability of the linux desktop. Another nice to have feature is the online defrag of ext4 and its faster mkfs. Even cooler would be better scalability in ext4 (This side seems to have seen not enough effort lately).

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

Hans Peter Anvin and Ted Tso are a huge source of deep linux-2.6 knowledge and personal wisdom. I do enjoy all sorts of interactions with them.

Christoph Hellwig with Matthew Wilcox and also William Irwin for setting up the Debian kernel Team.

Several Debian leaders including the previous and the current one for their engagement, which very often happens behind the scene.

The Debian Gnome Team work is great, also the interactions have always been always easy and a pleasure.

Martin Michlmayr and previously Thiemo Seufer do an incredible job in porting Debian on funny and interesting ARM and MIPS boxes. Debian has a lot of upcoming potential on this area. I’m looking forward to other young enthusiastic people in that area.

Colin Watson is bridging Debian and Ubuntu, which is an immense task.

Michael Prokop bases on Debian an excellent recovery boot CD: I’d be happy if any Debian Developer would work as carefully coding and working.

Thank you to Maximilian for the time spent answering my questions. I hope you enjoyed reading his answers as I did. 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, Twitter and Facebook.

People behind Debian: Mike Hommey, Firefox/Iceweasel maintainer

Mike Hommey, our Iceweasel maintainer

For as long as I have known Mike, he’s been maintaining one of the largest (and most widely used) package: Iceweasel, Debian’s default web browser. It’s effectively Mozilla’s Firefox although it has been renamed to avoid some rules enforced by Mozilla’s trademark policy. But we might see Firefox back in Debian… read on to know Mike’s plans.

His story is also very interesting in that he went from simple user to Iceweasel maintainer, and now he’s working for Mozilla Corporation. But you already knew that contributing to free software is a good way to grow skills and gain experience that are valuable on the job market, right? 😉

My questions are in bold, the rest is by Mike.

Who are you?

I am Mike Hommey. I am French, even if my name doesn’t sound so.

I have been a GNU/Linux user since 1995, using Debian since 1999, and started packaging in 2003. After a long time in the NM queue, I became a DD in 2005.

The main reason I started being actively involved is quite selfish: I wanted some things done, and I just did them. My first packages were extensions for the Mozilla Suite, the old one that directly inherited from Netscape Communicator. Later on, I wanted some of these extensions to work with the new kid on the block: Phoenix; or maybe it was already Firebird. By then, integrating extensions was a hassle, and the mozilla-browser maintainer had come up with a script that would make it easier for extension packages. So I ported that script for use with Phoenix/Firebird and sent it to the BTS.

Then Phoenix/Firebird became Firefox, and it grew a real extension manager. Except that is was entirely not suited for extensions installed by the packaging system. So I made it work better. And made a few more changes to make Firefox work better. All through patches or NMUs.

Then I became co-maintainer, then Firefox couldn’t keep its name and became Iceweasel, and, fast-forward until today, I’m now taking care of Iceweasel/Xulrunner and Iceape in stable, unstable, experimental and an external repository.

This 8 years-long story (wow, I hadn’t even realized it had been that long until I wrote it) tells you something: newcomers shouldn’t be afraid to stick their hands anywhere, even in big packages. I was only a Mozilla and Phoenix end-user when I started.

Apart from Mozilla-related packaging, I also happen to (co-)maintain some other packages in Debian, most notably webkit, though I haven’t been very active in the pkg-webkit team recently. There are several reasons for that, the main one being that there are other team members getting the job done. And I can’t say that much about the pkg-mozilla team, since there are effectively no other team members.

What’s your biggest achievement within Debian?

I am quite proud that Squeeze will be the first Debian release where Iceweasel works on all supported architectures. Previously, we only knew the package compiled on all these architectures. Starting with Squeeze, we know it passes several of the test suites coming with the source code. This ensures most of the browser is functional. It was actually far from being the case before, as it appeared when the test suites were first enabled.

I think it is very important to have properly working packages on all our supported architectures. The current evolution of hardware shows how important it still is. Who would have thought a few years back that we would see ARM or MIPS based netbooks today ?

What are your plans for Debian Wheezy?

For Debian Wheezy, I would like to improve Iceweasel/Icedove/Iceape integration with the packaging system. Something that would allow to use the apt database to find extensions or plugins, on top of the current behaviour. I also want to improve desktop integration, most notably for KDE.

Another thing I’d like to see happen is to package google breakpad independently (its source code is currently embedded in chromium and iceweasel, though not built, as far as I know), and have our Mozilla products builds be able to send their crash reports upstream. It is very important that upstream gets direct visibility over what crashes on GNU/Linux systems. It helps making them aware of issues that would otherwise probably remain unnoticed, as there are much more users using distributions packages than upstream tarballs. And not all Debian users report crashes to the BTS. I know at least Fedora and SuSE are already doing it.

More importantly, I want to avoid the sad situation we got with Squeeze, where we’re going to release a 18 months old Iceweasel. We got there for a combination of reasons, one being that I was preparing for a freeze in December 2009 and focusing on getting 3.5 in shape instead of the then upcoming 3.6.

The result was that we didn’t get 3.6 packages before upstream released 3.6.3 in April 2010. By then it was too late, considering the uncertainty of the release schedule, to update reverse dependencies and get 3.6 ready for Squeeze.

Things are different for 4.0. I’m already getting ahead of things, and while reverse dependencies haven’t been taken care of, all beta releases have been made available through, usually within hours after upstream release (sometimes even a few hours before official announcement, but always after availability on A great share of our patches were also pushed upstream.

Several things made that possible:

  • I’m now closely following upstream trunk
  • I’m starting to prepare packages when candidate builds are distributed upstream, which usually happens a few days ahead for betas, and more than a week ahead for stable releases.
  • I automated part of the package building process, and have a beefy build machine. I’m getting near being able to provide nightly builds of upstream trunk.

There will be a couple major upstream releases until Wheezy comes along, and I want to make them available early in unstable, even if that means breaking reverse dependencies until they are fixed.

Finally, I would like to get other people involved, starting with the Icedove maintainer. Volunteers are very much welcome, for any kind of involvement: bug triaging, documentation (which we are deeply lacking), testing, code… People interested can contact the pkg-mozilla team list. As the Debian packaging gets less time consuming, I should be able to spend more time mentoring, which should help.

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

I actually have been working almost full time on Debian for a few months during a more-or-less purposeful unemployment period. That’s when I attempted to add an alert popup when Iceweasel or extensions are upgraded (which was eventually removed because not working very effectively). That’s when I worked on Iceweasel 3.6 and the first 4.0 betas. That’s when I pushed more than 70 patches upstream, and got upstream commit access.

I know for a fact that keeping up with upstream and answering bug reports is already time consuming, and time comes in finite quantity. Working full time on Debian allows to do more than that, as I’ve been able to experience first hand. Unfortunately, that doesn’t help pay the bills, so it would be best if time could be shared with other persons. Like, actual members in the pkg-mozilla team. 😉

Anyways, if I were to work full time on Debian again, I’d like to do more than packaging, and help improve some of our infrastructure, most notably the buildd network, to grow some automated way to get packages built on all or some of our architectures. Call that PPA if you want, though I don’t think we need something exactly like PPA.

We sure do have porter boxes, but there is a huge overhead to get packages built there: you need to first try, then see you lack build dependencies, then wait for admins to install them, then come back and launch your build, and finally come back again much later to see how it went. And that’s when it goes smoothly. Repeat for each architecture.

It’s already cumbersome when it’s a small package, so imagine when it’s Iceweasel. I’d like to be able to push a (signed) .dsc somewhere, say I want it built on that and that architecture, and get binary packages and logs back. It could then be up to developers to distribute them, or not. Sometimes, you’re just interested in test suite results.

Another related wish would be a way to access build trees of failed builds, possibly on the buildd where it failed.

What’s the biggest problem of Debian?

Lack of contributors, lack of contributors, and… lack of contributors.

It can sound weird to say that in a community of 1000+ people. But the sad reality is that we’ve seen, repeatedly, calls for help in various places from various understaffed teams (most often of effectively one member) for years. So there is obviously a problem getting people to invest time in these teams either on the long term, or at all.

I know this is not a very significant metric, but it already should say a lot: I wouldn’t be surprised if more than 2/3 of the number of source lines of code in Debian come from less than 5% of the number of packages in the archive, and see less than 5% of the DD/DM population involved. If someone feels like doing the actual math, I’m curious to know how far I’m from reality, and in what direction.

We also lack manpower to be able to make our release development smoother. In a perfect world where manpower is not a scarce resource, we should work on $release+1 when $release is being frozen. Said otherwise, we should have been able to start working on Wheezy in August 2010, or even earlier.

You’ve been working for Mozilla Corporation for a few months. How does the work look like and what are you working on?

I am actually not working full time for MoCo; I am only contracting for 4 days a week. That was a request I made to keep having enough spare time for Debian or other activities. I am working from home, and am pretty much free about when I work, as long as I work long enough. I take advantage of this freedom and the saved commuting time to live a healthier life by doing some sports in the daytime (which also happens to be cheaper).

I mostly work with Taras Glek and other people on various aspects of Firefox startup performance. This involves pretty interesting low-level stuff, in which I actually got involved before being contracted. This work has nothing to do with packaging Iceweasel, though I can have a few opportunities to do things somehow related.

You told in your blog that you were discussing with Mozilla how Debian could use the Firefox trademark. Can you tell us a bit about the progress you made?

I have got an informal approval of the patches we are applying to the Iceweasel 4.0 beta packages. There are a few concerns about using the system cairo library, and the embedded copy of libpng needs to be used to have support for the animated PNGs that are used in the user interface and that are required in Firefox’ feature-set. Other than that, there are pretty much no objection on the technical side.

We managed to get to some common ground as to how to manage stable updates and more generally, changes to our packages, but I’m still waiting for an actual agreement draft. While I, as the maintainer, am fine with the way it should look according to my discussions with the people involved at Mozilla, I’ll seek review from my fellow Debian Developers when I’ll have something to show.

I haven’t decided yet how this will reflect on the Debian packages, though. For example, would Iceweasel stay? But I do hope Wheezy will get Firefox back.

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

Not someone, but all past, present and future release team members. This is a team that receives a lot of critics (and I indirectly gave one a few paragraphs ago), yet manages to keep doing an amazing job and its members are very committed to their task. I admire their dedication.

Thank you to Mike for the time spent answering my questions. I hope you enjoyed reading his answers as I did. 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, Twitter and Facebook.

People behind Debian: Michael Vogt, synaptic and APT developer

Michael and his daughter Marie

Michael has been around for more than 10 years and has always contributed to the APT software family. He’s the author of the first real graphical interface to APT—synaptic. Since then he created “software-center” as part of his work for Ubuntu. Being the most experienced APT developer, he’s naturally the coordinator of the APT team. Check out what he has to say about APT’s possible evolutions.

My questions are in bold, the rest is by Michael.

Who are you?

My name is Michael Vogt, I’m married and have two little daughters. We live in Germany (near to Trier) and I work for Canonical as a software developer. I joined Debian as a developer in early 2000 and started to contribute to Ubuntu in 2004.

What’s your biggest achievement within Debian or Ubuntu?

I can not decide on a single one so I will just be a bit verbose.

From the very beginning I was interested in improving the package manager experience and the UI on top for our users. I’m proud of the work I did with synaptic. It was one of the earliest UIs on top of apt. Because of my work on synaptic I got into apt development as well and fixed bugs there and added new features. I still do most of the uploads here, but nowadays David Kalnischkies is the most active developer.

I also wrote a bunch of tools like gdebi, update-notifier, update-manager, unattended-upgrade and software-properties to make the update/install situation for the user easier to deal with. Most of the tools are written in python so I added a lot of improvements to python-apt along the way, including the initial high level “apt” interface and a bunch of missing low-level apt_pkg features. Julian Andres Klode made a big push in this area recently and thanks to his effort the bindings are fully complete now and have good documentation.

My most recent project is software-center. Its aim is to provide a UI strongly targeted for end-users. The goal of this project is to make finding and installing software easy and beautiful. We have a fantastic collection of software to offer and software-center tries to present it well (including screenshots, instant search results and soon ratings&reviews). This builds on great foundations like aptdaemon by Sebastian Heinlein, by Christoph Haas, by Michael Bramer, apt-xapian-index by Enrico Zini and many others (this is what I love about free software, it usually “adds”, rarely “takes away”).

What are your plans for Debian Wheezy?

For apt I would love to see a more plugable architecture for the acquire system. It would be nice to be able to make apt-get update (and the frontends that use this from libapt) be able to download additional data (like debtags or additional index file that contains more end-user targeted information). I also want to add some scripts so that apt (optionally) creates btrfs snapshots on upgrade and provide some easy way to rollback in case of problems.

There is also some interesting work going on around making the apt problem resolver a more plugable part. This way we should be able to do much faster development.

software-center will get ratings&reviews in the upstream branch, I really hope we can get that into Wheezy.

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

In that case I would start with a refactor of apt to make it more robust about ABI breaks. It would be possible to move much faster once this problem is solved (its not even hard, it just need to be done). Then I would add a more complete testsuite.

Another important problem to tackle is to make maintainer scripts more declarative. I triaged a lot of upgrade bug reports (mostly in ubuntu though) and a lot of them are caused by maintainer script failures. Worse is that depending on the error its really hard for the user to solve the problem. There is also a lot of code duplication. Having a central place that contains well tested code to do these jobs would be more robust. Triggers help us a lot here already, but I think there is still more room for improvement.

What’s the biggest problem of Debian?

That’s a hard question :) I mostly like Debian the way it is. What frustrated me in the past were flamewars that could have been avoided. To me being respectful to each other is important, I don’t like flames and insults because I like solving problems and fighting like this rarely helps that. The other attitude I don’t like is to blame people and complain instead of trying to help and be positive (the difference between “it sucks because it does not support $foo” instead of “it would be so helpful if we had $foo because it enables me to let me do $bar”).

For a long time, I had the feeling you were mostly alone working on APT and were just ensuring that it keeps working. Did you also had this feeling and are things better nowadays ?

I felt a bit alone sometimes :) That being said, there were great people like Eugene V. Lyubimkin and Otavio Salvador during my time who did do a lot of good work (especially at release crunch times) and helped me with the maintenance (but got interested in other area than apt later). And now we have the unstoppable David Kalnischkies and Julian Andres Klode.

Apt is too big for a single person, so I’m very happy that especially David is doing superb work on the day-to-day tasks and fixes (plus big project like multiarch and the important but not very thankful testsuite work). We talk about apt stuff almost daily, doing code reviews and discuss bugs. This makes the development process much more fun and healthy. Julian Andres Klode is doing interesting work around making the resolver more plugable and Christian Perrier is as tireless as always when it comes to the translations merging.

I did a quick grep over the bzr log output (including all branch merges) and count around ~4300 total commits (including all revisions of branches merged). Of that there ~950 commits from me plus an additional ~500 merges. It was more than just ensuring that it keeps working but I can see where this feeling comes from as I was never very verbose. Apt also was never my “only” project, I am involved in other upstream work like synaptic or update-manager or python-apt etc). This naturally reduced the time available to hack on apt and spend time doing the important day-to-day bug triage, response to mailing list messages etc.

One the python-apt side Julian Andres Klode did great work to improve the code and the documentation. It’s a really nice interface and if you need to do anything related to packages and love python I encourage you to try it. Its as simple as:

import apt
cache = apt.Cache()

Of course you can do much more with it (update-manager, software-center and lots of more tools use it). With “pydoc apt” you can get a good overview.

The apt team always welcomes contributors. We have a mailing list and a irc channel and it’s a great opportunity to solve real world problems. It does not matter if you want to help triage bugs or write documentation or write code, we welcome all contributors.

You’re also an Ubuntu developer employed by Canonical. Are you satisfied with the level of cooperation between both projects? What can we do to get Ubuntu to package new applications developed by Canonical directly in Debian?

Again a tricky question :) When it comes to cooperation there is always room for improvement. I think (with my Canonical hat on) we do a lot better than we did in the past. And it’s great to see the current DPL coming to Ubuntu events and talking about ways to improve the collaboration. One area that I feel that Debian would benefit is to be more positive about NMUs and shared source repositories (collab-maint and LowThresholdNmu are good steps here). The lower the cost is to push a patch/fix (e.g. via direct commit or upload) the more there will be.

When it comes to getting packages into Debian I think the best solution is to have a person in Debian as a point of contact to help with that. Usually the amount of work is pretty small as the software will have a debian/* dir already with useful stuff in it. But it helps me a lot to have someone doing the Debian uploads, responding to the bugmail etc (even if the bugmail is just forwarded as upstream bugreports :) IMO it is a great opportunity especially for new packagers as they will not have to do a lot of packaging work to get those apps into Debian. This model works very well for me for e.g. gdebi (where Luca Falavigna is really helpful on the Debian side).

Is there someone in Debian that you admire for his contributions?

There are many people I admire. Probably too many to mention them all. I always find it hard to single out individual people because the project as a whole can be so proud of their achievements.

The first name that comes to my mind is Jason Gunthorpe (the original apt author) who I’ve never met. The next is Daniel Burrows who I met and was inspired by. David Kalnischkies is doing great work on apt. From contributing his first (small) patch to being able to virtually fix any problem and adding big features like multiarch support in about a year. Sebastian Heinlein for aptdaemon.

Christian Perrier has always be one of my heroes because he cares so much about i18n. Christoph Haas for, Michael Bramer for his work on debian translated package descriptions.

Thank you to Michael for the time spent answering my questions. I hope you enjoyed reading his answers as I did. 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, Twitter and Facebook.

People behind Debian: Mehdi Dogguy, release assistant

Mehdi Dogguy

Picture of Mehdi taken by Antoine Madet

Mehdi is a Debian developer for a bit more than a year, and he’s already part of the Debian Release Team. His story is quite typical in that he started there by trying to help while observing the team do its work. That’s a recurrent pattern for people who get co-opted in free software teams.

Read on for more info about the release team, and Mehdi’s opinion on many topics. My questions are in bold, the rest is by Mehdi (except for the additional information that I inserted in italics).

Who are you?

I’m 27 years old. I grew up in Ariana in northern Tunisia, but have been living in Paris, France, since 2002.

I’m a PhD Student at the PPS laboratory where I study synchronous concurrent process calculi.

I became interested in Debian when I saw one of my colleagues, Samuel Mimram (first sponsor and advocate) trying to resolve #440469, which is a bug reported against a program I wrote. We have never been able to resolve it but my intent to contribute was born there. Since then, I started to maintain some packages and help where I can.

What’s your biggest achievement within Debian?

I don’t think I had time to accomplish a lot yet :) I’ve been mostly active in the OCaml team where we designed a tool to compute automatically the dependencies between OCaml packages, called dh-ocaml. This was a joint work with Stéphane Glondu, Sylvain Le Gall and Stefano Zacchiroli. I really appreciated the time spent with them while developing dh-ocaml. Some of the bits included in dh-ocaml have been included upstream in their latest release.

I’ve also tried to give a second life to the Buildd Status Pages because they were (kind of) abandoned. I intend to keep them alive and add new features to them.

If you had a wand and could change one thing in Debian, what would that be?

Make OCaml part of a default Debian installation 😀

But, since I’m not a magician yet, I’d stick to more realistic plans:

  1. A lot of desktop users fear Debian. I think that the Desktop installation offered by Debian today is very user-friendly and we should be able to attract more and more desktop users. Still, there is some work to be done in various places to make it even more attractive. The idea is trying to enhance the usability and integration of various tools together. Each fix could be easy or trivial but the final result would be an improved Desktop experience for our users. Our packaged software run well. So, each person can participate since the most difficult part is to find the broken scenarios. Fixes could be found together with maintainers, upstream or other interested people.

    I’ll try to come up with a plan, a list of things that need polishing or fixes and gather a group of people to work on it. I’d definitely be interested in participating in such a project and I hope that I’ll find other people to help. If the plan is clear enough and has well described objectives and criteria, it could be proposed to the Release Team to consider it as a Release Goal for Wheezy.

  2. NMUs are a great way to make things move forward. But, sometimes, an NMU could break things or have some undesirable effects. For now, NMUers have to manually track the package’s status for some time to be sure that everything is alright. It could be a good idea to be auto-subscribed to the bugs notifications of NMUed packages for some period of time (let’s say for a month) to be aware of any new issues and try to fix them. NMUing a package is not just applying a patch and hitting enter after dput. It’s also about making sure that the changes are correct and that no regressions have been introduced, etc…

  3. Orphaned packages: It could be considered as too strict and not desired, but what about not keeping orphaned and buggy packages in Testing? What about removing them from the archive if they are buggy and still unmaintained for some period? Our ftp archive is growing. It could make sense to do some (more strict) housekeeping. I believe that this question can be raised during the next QA meeting. We should think about what we want to do with those packages before they rot in the archive.

[Raphael Hertzog: I would like to point out that pts-subscribe provided by devscripts makes it easy to temporarily subscribe to bug notifications after an Non-Maintainer Upload (NMU).]

You’re a Debian developer since August 2009 and you’re already an assistant within the Release Management team. How did that happen and what is this about?

In the OCaml team, we have to start a transition each time we upload a new version of the OCaml compiler (actually, for each package). So, some coordination with the Release Team is needed to make the transition happen.

When we are ready to upload a new version of the compiler, we ask the Release Team for permission and wait for their ack. Sometimes, their reply is fast (e.g. if their is no conflicting transition running), but it’s not always the case. While waiting for an ack, I used to check what was happening on debian-release@l.d.o. It made me more and more interested in the activities of the Release Team.

Then (before getting my Debian account), I had the chance to participate in DebConf9 where I met Luk and Phil. It was a good occasion to see more about the tools used by the Release Team. During April 2010, I had some spare time and was able to implement a little tool called Jamie to inspect the relations between transitions. It helps us to quickly see which transitions can run in parallel, or what should wait. And one day (in May 2010, IIRC), I got offered by Adam to join the team.

As members of the Release Team, we have multiple areas to work on:

  1. Taking care of transitions during the development cycle, which means making sure that some set of packages are correctly (re-)built or fixed against a specific (to each transition) set of packages, and finding a way to tell Britney that those packages can migrate and it would be great if she also shared the same opinion. [Raphael Hertzog: britney is the name of the software that controls the content of the Testing distribution.]
  2. Paying attention to what is happening in the archive (uploads, reported RC bugs, etc…). The idea is to try to detect unexpected transitions, blocked packages, make sure that RC bug fixes reach Testing in a reasonable period of time, etc…
  3. During a freeze, making sure that unblock requests and freeze exceptions are not forgotten and try to make the RC bug count decrease.

There are other tasks that I’ll let you discover by joining the game.

Deciding what goes (or not) in the next stable release is a big responsibility and can be incredibly difficult at times. You have to make judgement calls all the time. What are your own criteria?

That’s a very hard to answer question (at least, for me). It really depends on the “case”. I try to follow the criteria that we publish in each release update. Sometimes, an unblock request doesn’t match those criteria and we have to decide what to accept from the set of proposed changes. Generally, new features and non-fixes (read new upstream versions) changes are not the kind of changes that we would accept during the freeze. Some of them could be accepted if they are not intrusive, easy and well defended. When, I’m not sure I try to ask other members of the Release Team to see if they share my opinion or if I missed something important during the review. The key point is to have a clear idea on what’s the benefit of the proposed update, and compare it to the current situation. For example, accepting a new upstream release (even if it fixes some critical bugs) is taking a risk to break other features and that’s why we (usually) ask for a backported fix.

It’s also worth noticing that (most of the time) we don’t decide what goes in, but (more specifically) what version of a given package goes in and try to give to the contributors an idea on what kind of changes are acceptable during the freeze. There are some exceptions though. Most of them are to fix a critical package or feature.

Do you have plans to improve the release process for Debian Wheezy?

We do have plans to improve every bit in Debian. Wheezy will be the best release ever. We just don’t know the details yet :)

During our last meeting in Paris last October, the Release Team agreed to organize a meeting after Squeeze’s release to discuss (among other questions) Wheezy’s cycle. But the details of the meeting are not fixed yet (we still have plenty of time to organize it… and other more important tasks to care about). We would like to be able to announce a clear roadmap for Wheezy and enhance our communication with the rest of the project. We certainly want to avoid what happened for Squeeze. Making things a bit more predictable for developers is one of our goals.

Do you think the Constantly Usable Testing project will help?

The original idea by Joey Hess is great because it allows d-i developers to work with a “stable” version of the archive. It allows them to focus on the new features they want to implement or the parts they want to fix (AIUI). It also allows to have constantly available and working installation images.

Then, there is the idea of having a constantly usable Testing for users. The idea seems nice. People tend to like the idea behind CUT because they miss some software disappearing from Testing and because of the long delays for security fixes to reach Testing.

If the Release Team has decided to remove a package from Testing, I think that there must be a reason for that. It either means that the software is broken, has unfixed security holes or was asked for the removal by its maintainer. I think that we should better try to spend some time to fix those packages, instead of throwing a broken version in a new suite. It could be argued that one could add experimental’s version in CUT (or sid’s) but every user is free to cherry-pick packages from the relevant suite when needed while still following Testing as a default branch.

Besides, it’s quite easy to see what was removed recently by checking the archive of debian-testing-changes or by querying UDD. IMO, It would be more useful to provide a better interface of that archive for our users. We could even imagine a program that alerts the user about installed software that got recently removed from Testing, to keep the user constantly aware any issue that could affect his machine. About the security or important updates, one has to recall the existence of Testing-security and testing-proposed-updates that are used specifically to let fixes reach Testing as soon as possible when it’s not possible to go through Unstable. I’m sure that the security team would appreciate some help to deal with security updates for Testing. We also have ways to speed migrate packages from Unstable to Testing.

I have to admit that I’m not convinced yet by the benefits brought by CUT for our users.

Thank you to Mehdi for the time spent answering my questions. I hope you enjoyed reading his answers as I did. 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, Twitter and Facebook.

People behind Debian: David Kalnischkies, an APT developer

The two first interviews were dedicated to long-time Debian developers. This time I took the opposite approach, I interviewed David Kalnischkies who is not (yet) a Debian developer. But he’s contributing to one of the most important software within Debian—the APT package manager—since 2009. You can already see him in many places in Debian sharing his APT knowledge when needed.

English is not his native language and he’s a bit shy, but he accepted the interview nevertheless. I would like to thank him for the efforts involved and I hope his story can inspire some people to take the leap and just start helping… My questions are in bold, the rest is by David.

Who are you?

I am David Kalnischkies, 22 years old, living in the small town Erbach near Wiesbaden in Germany and I’m studying computer science at the TU Darmstadt. Furthermore I am—for more than half a decade now—young group leader of my hometown.

I never intended to get into this position, but it has similarities with my “career” in this internet-thingy here. I don’t remember why, but in April 2009 I was at a stage that some simple bugs in APT annoyed me so much that I grabbed the source, and most importantly—I don’t know why I did it— but I published my changes in Mai with #433007, a few more bugs and even a branch on launchpad. And this public branch got me into all this trouble in June: I got a mail from “Mr. package managment” Michael Vogt regarding this branch…

A few days later I joined an IRC session with him and closely after that my name appeared for the first time in a changelog entry. It’s a strange but also addicting feeling to read your own name in an unfamiliar place. And even now after many IRC discussions, bugfixes and features, three Ubuntu Developer Summits and a Google Summer of Code in Debian, my name still appear in places I have never even thought about—e.g. in an interview.

What’s your biggest achievement within Debian?

I would like to answer “MultiArch in APT” as it was my Google Summer of Code project, but as it has (not much) use for the normal user at this point—will hopefully change for wheezy—I chose three smaller things in squeeze’s APT that many people don’t even know yet:

  • “MMap run out of room”, the most famous error related to the APT::Cache-Limit option is gone. The DynamicMMap in APT now deserves its name :)
  • Download and usage of multiple Translations of Descriptions
  • crazy stuff like apt-cache show ^apt-.*$/experimental works

If your impression is now that I only do APT stuff: that’s completely right, but that’s already more than enough for me for now as the toolchain behind the short name APT contains so many tools and use cases that you always have something different.

You’re an active member of the APT development team. Are there plans for APT in Debian Wheezy? What features can we expect?

That’s very hard to answer, as the team is too small to be able to really plan something. I mean, you can have fancy plans and everything and half a second later someone arrives on the mailing list with a “small” question which eats days of development time just for debugging…

But right now the TODO list contains (in no particular order):

  • MultiArch – managing packages built for different architectures like i386 on amd64 to ease the usage of packages which only work on specific architectures or cross-compiling.
  • rewriting the subsystem responsible for downloading files to e.g. enable tools like apt-file or debtags to reuse the infrastructure by plugging into it.
  • splitting long descriptions out of the Packages file to possibly decrease the size to download on an “apt-get update”. Includes mostly pulling the button only to enable it by the archive masters
  • backporting popular features of some frontends to enable all frontends to use them, e.g. “apt-get changelog” or “apt-get download”
  • support research on resolver improvements by implementing support for a distribution independent upgrade problem format (CUDF).
  • an additional single binary for users wrapping apt-get, apt-cache and co.
  • getting in contact (again) with various forks like apt-rpm and derivatives like maemo or telesphoreo to join forces instead of splitting them by working on different (and possibily very old) heads of the dragon

We will see what will get real for wheezy and what is postponed, but one thing is sure: more will be done for wheezy if you help!

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

I would spend it on APT’s debbugs count… zero would be cool to look at! We make progress in this regard, but with the current velocity we will reach it in ten years or so.

Reading more mailing lists would be interesting, as I am kind of an information junky. Maintaining a package could be interesting to share the annoyance of a maintainer with handcrafted dependencies just to notice that APT doesn’t get it in the way I intended it to be. Through, to make it feel real I need to train a few new APT contributors before so they can point my mistake out, but this unfortunately doesn’t depend so much on time but on victims… Maybe I could even be working on getting an official status.

Beside that, I would love to be able to “apt-get dist-upgrade” the increasing mass of systems I and many others carry around in their pockets. In regards to my phone, this is already fixed, but there is much room for improvements.

What’s the biggest problem of Debian?

You need to be lucky. You need to talk at the right time to the right person. That’s not really a debian-only problem as such, but in a global project full of volunteers you can see it clearly as there are plenty of opportunities to be unlucky.

For example, it’s unlikely that an interview would be made with me now if Michael had not contacted me in June 2009. In a big project like Debian, you are basically completely lost without a mentor guiding you, so things like the debian-mentors list are good projects, but I am pretty certain they could benefit from some more helping hands.

The other thing which I consider a problem is that—and I read from time to time—some people don’t care for translations. That’s bad. Yes, a developer is able to read English, otherwise s/he couldn’t write code or participate on the mailinglists.

Still, I personally prefer to use a translated application if I have the chance as it’s simply easier for me to read in my mother tongue, not only because I am dyslexic, but because my mind still thinks in German and not in English. Yes, I could personally fix that by thinking in English only from now on, but its a quite big problem to convince my family—which is not really familiar with tech-stuff—to use something if they can’t understand what is written on screen.

It was hard enough to tell my mother how to write an SMS in a German interface. My phone with English words all over the place would be completely unusable for her—despite the fact that my phone is powered by Debian and better for the task from a technical point of view.

You are not yet an official Debian developer/maintainer, but you’re already perceived in the community as one the most knowledgeable person about APT. It’s a great start! What’s your advice to other people who want to start contributing to Debian in general, and to APT in particular?

It was never a goal in my life to “start contributing”. My goal was and still is to make my life easier by letting the computer work for me. At some point APT hindered the success of this goal, so it needed to be fixed. I didn’t expect to open pandora’s box.

So, my advice is simple: Just start. Ignore the warning signs telling you that this is not easy. They are just telling you that you do something useful. Only artificial problems are easy. Further more, contribution to APT, dpkg or any other existing package is in no way harder than opening an ITP and working on your own, and it’s cooler as you have a similar minded team around you to talk to. :)

“APT didn’t accept release codenames as target release” was one of the first things I fixed. If I had asked someone if that would be a good starting point the answer would have been a clear “no”, but I didn’t search for a good starting point…

As a kid I can start playing football by just walking on the field and play or I can sit near the field, watching the others play, while analyzing which position would be the best for me to start ruling out one by one as the technical requirements seem too high… “Oh – bicycle kick – that sounds complicated… I can’t do that”

Julian Andreas Klode is working on a APT replacement, there’s also Cupt by Eugene V. Lyubimkin. Both projects started because their authors are not satisfied with APT, they find APT’s code difficult to hack partly due to the usage of C++. Do you share their concerns and what’s your opinion on those projects?

I don’t think C++ is a concern in this regard, after all cupt is currently rewritten to C++0x and APT2 started in vala and is now C + glib—last time I checked at least. I personally think that something is wrong if we need to advertise an application by saying in which language it is written…

The major “problem” for APT is probably that the code is “old”: APT does its job for more than 12 years now, under different maintainers with an always changing environment around it: so there are lines in APT which date from a time when nobody knew what a “Breaks” dependency is, that packages can have long descriptions which can be translated or even that package archives can be signed with a gpg key! And yet we take all those for granted today. APT has proven to adapt to these changes in the environment and became in this process very popular. So I don’t think the point is near (if it will come at all) that APT can go into retirement as it is completely replaced by something else.

The competitors one the other hand have their first 12 years still to go. And it will be interesting to see how they will evolve and what will be the state of the art in 2022…

But you asked what I think about the competitors: I prefer the “revolution from inside” simply because I can see effects faster as more users will profit from it now. Cupt and co. obviously prefer the “normal” revolution. The goal is the same, creating the best package manager tool, but the chosen way to the goal is different. aptitude and cupt have an interactive resolver for example: that’s something I dislike personally, for others that is the ultimate killer feature. cupt reading the same preference file as APT will have a different pinning result, which we should consider each time someone mentions the word “drop-in replacement”.

APT2 isn’t much more than the name—which I completely dislike—currently from a user point of view, so I can’t really comment on that. All of them make me sad as each line invested in boilerplate code like configuration file parsing would be in my eyes better be spent in a bugfix or new feature instead, but I am not here to tell anyone what they should do in their free time…

But frankly, I don’t see them really as competitors: I use the tools I use, if other do that too that’s good, if not that’s their problem. :) The thing that annoys me really are claims like “plan is to remove APT by 2014″ as this generates a “vi vs. emacs” like atmosphere we don’t need. If some people really think emacs is a good editor… who cares?

I really hope we all can drink a beer in 2022 in Milliways, the restaurant at the end of the package universe, remembering the good old 2010… 😉

Is there someone in Debian that you admire for his contributions?

No, not one, many!

Michael Vogt who has nearly the monopole of “package manager maintainer” by being upstream of APT, synaptics and software center to name only the biggest and still has the time to answer even the dumbest of my questions. :) Jason Gunthorpe for being one of the initial developers behind “deity” who I will probably never meet in person beside in old comments and commit logs. Christian Perrier for caring so much about translations. Obey Arthur Liu as a great admin for Debian’s participation in Google’s Summer of Code. Paul Wise for doing countless reviews on debian-mentors which are a good source of information—not only for the maintainer of the package under review.

I guess I need to stop here because you asked for just one. So let’s end with some big words instead: I am just a little cog in the big debian wheel…

Thank you to David Kalnischkies for the time spent answering my questions. I hope you enjoyed reading his answers as I did. 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, Twitter and Facebook.

Go2Linux interviewed me: the biggest problem of Debian

Guillermo Garron of Go2Linux enjoys a lot the “People behind Debian” interviews that I make. That’s why he interviewed me (with somewhat similar questions) and published the result on his blog.

Click here to read the full interview. I speak of my Debian projects, of the Ubuntu-Debian relationship, and more.

The question that I would like to highlight is “What’s the biggest problem of Debian?”. I answered this:

Our project identity is somewhat minimalistic. It evolves around the social contract and the Debian Free Software Guidelines. Both documents answer the question of what we’re doing but we lack a clear answer to the question of how we’re supposed to work towards our goals. It would be great if Debian could agree on some principles concerning topics like goal setting, collaboration, team work, politeness, respect. We could then advertise those and build on them while recruiting volunteers.

PS: The interview also hit LinuxToday.

People behind Debian: Colin Watson, the tireless man-db maintainer and a debian-installer developer

Colin Watson is not a high-profile Debian figure, you rarely see him on mailing lists but he cares a lot about Debian and you will see him on Debconf videos sharing many thoughtful comments. I have the pleasure to work with him on dpkg as he maintains the package in Ubuntu, but he does a lot of more interesting things. I also took the opportunity to ask some Ubuntu specific questions since he’s worked for Canonical since the start. Read on.

My questions are in bold, the rest is by Colin.

Who are you?

Hi. I’m 32 years old, grew up in Belfast in Northern Ireland, but have been living in Cambridge, England, since I was 18. I’m married with a stepson and a daughter.

I became interested in Debian due to the critical mass of Debian work happening in Cambridge at the time (and perhaps more immediately because my roommate was running Debian: “hey, what’s that?”), started doing random bits of development in 2000, and joined as a developer in 2001 (a really exciting time, with lots of new people joining who became integral parts of the project). I’d only really been intending to do QA work and various bits of packaging around the edges, and maybe some work on the BTS, but then Fabrizio Polacco died and I took over man-db from him, and it sort of snowballed from there.

I graduated from university shortly before becoming a Debian developer. I worked for a web server company (Zeus), then a hardware cryptography company (nCipher), before moving to work for Canonical in 2004, since when I’ve been working full-time on Ubuntu. By this point, I suspect that going back to work in an office every day would be pretty tough.

What’s your biggest achievement within Debian or Ubuntu?

One thing I should say: I rarely start projects. Firstly I don’t think I’m very good at it, and secondly I much prefer coming on to an existing project and worrying away at all the broken bits, often after other people have got bored and wandered off to the next new and shiny thing. That’s probably why I ended up in the GNU/Linux distribution world in the first place, rather than doing lots of upstream development from the start – I like being able to polish things into a finished product that we can give to end users.

So, I’ve had my fingers in a lot of pies over the years, doing ongoing maintenance and fixing lots of bugs. I think the single project I’m most proud of would have to be my work on the Debian installer. I joined that team in early 2004 (a few months before Canonical started up) partly because I was a release assistant at the time and it was an obvious hot-spot, and partly because I thought it’d be a good idea to make sure it worked well on the shiny new G4 PowerBook I’d just treated myself to. I ended up as one of the powerpc d-i port maintainers for a while (no longer, as that machine is dead), but I’ve done a lot of core work as well: much of the work to put progress bars in front of absolutely everything that used to have piles of text output, rescue mode, the current kernel selection framework, a good deal of udev support, several significant debconf extensions, lots of os-prober work, and I think I can claim to be one of the few people who understands the partitioner almost top to bottom. :-)

d-i is the very first thing many of our users see, and has a huge range of uses, from simple desktop installs to massive corporate deployments; it’s unspeakably important that it works well, and it’s a testament to its design that it’s been able to trundle along without actually very much serious refactoring for the best part of five years now.

I have a soft spot for man-db too. It was my first major project in Debian, starting out from an embarrassingly broken state, and is now nice and stable to the point where I recently had time to spawn a useful generic library out of it (libpipeline).

What are your plans for Debian Wheezy?

d-i has a lot of code to deal with disks and partitions. Of course a lot of it is in the partitioner, and for that we use libparted so we don’t have to worry very much about the minutiae of device naming. But there are several other cases where we do need to care about naming, mainly before the partitioner when detecting disks, and after the partitioner when installing the boot loader. Back in etch, we introduced ‘list-devices’, which abstracted away the disk naming assumptions involved in hardware detection. In wheezy, I would like to take all the messy, duplicated, and error-prone code that handles disk naming in the boot loader installers, and design a simple interface to cover all of them. This has only got more important following the addition of the kFreeBSD and Hurd d-i ports in squeeze, but it bites us every time we notice that, say, CCISS arrays aren’t handled consistently, and it’s a pain to test all that duplicated code.

I’d also like to spread the use of libpipeline through C programs in the archive, which I think has potential to eliminate a class of security vulnerabilities in a much simpler way than was previously available.

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

I would love to systematically reduce the need for the current mass of boot loaders. There’s a significant cost to having so much variation across architectures here: it’s work that needs to be done in N different places, the wildly differing configuration means that d-i has to have huge piles of code to manage them all differently, and there are a bunch of strange arbitrary limitations on what you can do.

The reason I’m working on GRUB 2 is that, in my view, it’s the project with the best chance of centralising all this duplicated work into a single place, and making it easier to bring up new hardware in future (in a way that doesn’t compromise software freedom, as many proprietary boot loaders of the kind often found on phones do). Of course, with flexibility tends to come complexity, and some people have a natural objection to that and prefer something simpler. The things I don’t quite have time to do here are to figure out a coherent way to address the specific over-complexity problems people have with the configuration framework while still keeping the flexibility we need, and to do enough QA and porting work to be able to roll out GRUB 2 at installation time to all the Debian architectures it theoretically supports.

What’s the biggest problem of Debian?

Backbiting, and too much playing the man rather than the ball. With one or two honourable exceptions, I’ve largely stopped reading most Debian mailing lists since it just never seems a productive way to spend time compared to writing code and fixing bugs; and yet I’m conscious that they’re one of the primary means of communication for the project and I’m derelict in not taking part in them.

I do find it a bit frustrating that people are seen primarily in terms of their affiliations. I suppose it’s natural for people to see me as an “Ubuntu guy”, but I don’t really see myself that way: I’ve been working on Debian for nearly twice as long as I’ve been working on Ubuntu, and, while I care a great deal about both projects, I’ve put far more of my own personal time into Debian and I try to make sure that a decent number of the things I’m involved with there aren’t to do with work. Work/life separation is a good thing, not that I’m very good at it. Generally speaking, when I’m working on Debian, I’m doing so as a Debian developer, because I want Debian to be better. When that’s not the case, if it matters, I try to indicate it explicitly.

You’re working for Canonical since Ubuntu’s inception. If you were Mark Shuttleworth, is there something that you would have done differently?

We had many good intentions when we founded Ubuntu. We also had a huge amount of work to deliver, to the point where it wasn’t at all clear whether it would be possible (the warty release was named based on the expectations of it, after all, and came out much more usable than we’d dared to hope). In hindsight, it might have helped to be quieter about our good intentions, so that we could exceed expectations rather than in some cases failing to meet them. That might have set a very different tone early on.

(Personally, I’m happy I’m not Mark. The decisions in my office are much easier to take.)

It seems to me that the community part of Ubuntu is much more eager to cooperate with Debian than the corporate part. It’s probably just that more and more Canonical employees are not former Debian contributors. Do you also have this feeling? Are there processes in place to ensure everybody at Canonical is trying to do the right thing towards Debian cooperation?

Just to be clear, I’m wearing my own hat here—which, ironically, is a fedora—rather than a company hat.

It makes sense for Canonical to be taking on more non-Debian folks; after all, we can’t simply hire from the Debian community forever, and a variety of backgrounds is healthy. As you say, it may well be natural that Ubuntu developers who don’t work for Canonical are more likely to have a Debianish background, as it tends to take something significant to get people to switch to a very different family of GNU/Linux distributions, and changing jobs is one of the most obvious of those things.

Certainly, there was a definite sense among the early developers that we were all part of the Debian family and cared about the success of Debian as well. As Ubuntu has developed its own identity, people involved in it now tend to care primarily about the success of Ubuntu. At the same time, pragmatically, it’s still true that getting code changes into Debian is one of the most economical ways to land them; changes made in Debian or upstream land once and tend to stay in place, while changes made only in Ubuntu incur an ongoing merge overhead, which is not at all trivial.

In many ways it’s human nature to try to fulfil your immediate goals in the most direct way possible. If your goal is to deliver changes to Ubuntu users, then it’s natural to concentrate on that rather than looking at the bigger picture (which takes experience). Debian developers often fail to send changes upstream for much the same reason, although there’s more variation there because they’re normally working on Debian of their own volition and thus tend to have wider goals; the economics are more or less parallel though.

Thus, I think the best way to improve things is to make it the path of least resistance for Ubuntu developers to send changes to Debian. We’re already seeing how this works with the Ubuntu MOTU group; if you send a patch for review, or work on merging a package from Debian, very often the response includes “have you sent these changes to Debian?”. We’re working on both streamlining our code review through a regular patch pilot programme and requiring more code review for changes in general, so I think this will be a good opportunity to ask more people to work with Debian when they propose changes to Ubuntu.

For myself, this may be obvious, but I notice that I’m much better at getting changes into Debian when I already have commit access to the Debian package in question. All the work on improving collaborative maintenance in Debian can only help, for Ubuntu as well as for everyone else. It doesn’t make so much difference for large changes that require extensive discussion, but there are lots of small changes too.

Canonical is upstream of many software projects (unity, indicators infrastructure, etc.). Why aren’t those software immediately packaged in Debian? Do you think we can get this to change?

I’m not sure what the right approach is here, particularly as I haven’t been involved with much of that on the Ubuntu side. I suspect it would be helpful to look at this in a similar way to Ubuntu changes in general. It’s understandable that those developers have getting changes into Ubuntu as their first goal. And yet, having code in Debian offers a wider, and often technically adept, audience, and most developers like having their code reach a wider audience even if it’s not their first priority, particularly if that audience is likely to be able to help with finding problems and fixing bugs. It should be seen as something beneficial to both distributions.

The hardest problems will be with things that aren’t merely optional add-ons (which should generally be fairly non-controversial in Debian, given the breadth of the archive in general – the existence of things like bzr and germinate as Debian packages was never a hard question), but which require changes in established packages. For example, gnome-power-manager in Ubuntu is built with application indicator support, and that’s an important part of having a good indicator-based panel: a lot of the point of indicators is consistency. Since I do very little desktop work myself, I don’t know exactly what would be involved in making it possible to choose this system based on a Debian desktop, but I think it’s probably a bit more complicated than just making sure all the new packages exist in Debian too. Obviously you have to start somewhere.

Is there someone in Debian that you admire for his contributions?

Christian Perrier is absolutely tireless and has done superb things for the state of translations in Debian. And Russ Allbery, even aside from his fine ongoing work on policy, Lintian, and Kerberos, is a constant voice of sanity and calmness.

Release management is incredibly hard work, as I know from my own experience, and anyone who can sustain involvement in it for a long period is somebody pretty special. Steve Langasek and I got involved at about the same time but he outlasted me by quite a few years. He deserves some kind of medal for everything he’s done there.

Thank you to Colin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. 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, Twitter and Facebook.

People behind Debian: Joey Hess of debhelper fame

I decided recently to publish interviews from Debian contributors and I picked Joey Hess as my first target. He’s one of the few who have heavily influenced Debian by creating software that have become building blocks of the project, like the debian-installer (Joey uses the shorthand d-i to refer to it).

My questions are in bold, the rest is by Joey (except for the additional information that I inserted in italics).

Who are you?

Hello, I’m Joey Hess. I’m one of the oldtimers in Debian. Actually, I just checked, and there are still up to nineteen active Debian Developers who joined the project before I did, in 1996. I got started fairly young, and am “just” 34 years old.

I spend part of my time working with Lars Wirzenius, another Debian oldtimer, on Branchable. It makes it dead-easy for anyone to make a website that is built from Git, using my Ikiwiki engine to do wiki and blog style things. These days I spend the rest of my time working on free software, when I should really be looking for work to pay the bills.

What’s your biggest achievement within Debian or Ubuntu?

I guess I’m mostly known by Debian developers for writing debhelper and perhaps debconf. Probably founding the Debian Installer project has been a bigger impact for users. I’m fairly equally proud of all three projects. But while it might sound corny, I am more proud of the accumulation of all the smaller things done in the context of Debian. It’s more of a deep connection to the project. All the bugs fixed, and filed, and packages uploaded, and late night discussions, and just being a part of the larger project.

What are your plans for Debian Wheezy?

Hmm, I stopped thinking of Debian releases by code names back around Slink. :) So, few specific plans for Wheezy. The main thing I would like to help make happen in Debian next is Constantly Usable Testing, and it transcends releases anyway. The only specific plans I have for Wheezy are that there will probably be a new debhelper compat level, and I hope d-i will finally switch to using git.

RH: You can learn more about “Constantly Usable Testing” in my article Can Debian offer a Constantly Usable Testing distribution?.

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

Getting Debian on all these computers that we carry around in our pockets and can’t easily run apt-get on and hack on. Phones that is. It’s a bigger problem than just Debian, but I think Debian needs to find a way to be part of the eventual solution. The FreedomBox concept at least hints at a way around the current situation with embedded computers in general.

What’s the biggest problem of Debian?

I believe that the biggest problem is institutional, social and technological inertia. Every specific case of something that frustrates me about Debian today can be traced back to that.

You contribute regularly to Debian mailing lists, yet I don’t remember any aggressive/frustrated mail of you. How do you manage that? Are you avoiding heated discussions?

Rats, sounds like all my wonderful flames of years past have been forgotten!

Seriously though, after I noticed thread patterns, I started trying to avoid participating in the bad patterns myself. Now I limit myself to one expression of an opinion, and I don’t care who gets the last word. If people can’t be convinced, it’s time to find another approach to the problem. Also, code talks.

Most of the programs you wrote for Debian are in Perl. Do you regret this choice?

I love that question! No, no regrets. My only concern is whether the language limits contributors or users. I have not seen Perl significantly limiting the use of anything except for debconf (we had to rewrite it in C for d-i). And I do not notice fewer contributions to my Perl-based code than to other code.

I do sometimes regret when someone tells me they had to learn or re-learn Perl to work on something I wrote. But while I’m enjoying writing new things in Haskell now, and while I hope it will mean less maintenance burden later, I don’t think using Haskell will make it easier for others to contribute to my programs. Anyway, for me the interesting thing about writing a program is the problem it solves and the decisions made doing it. Choice of language is one of the less interesting decisions.

Is there someone in Debian that you admire for his contributions?

Well, lots. You’re tempting me to throw a dart at a map. So arbitrarily, I’ll say Anthony Towns. We could all learn something from how he’s approached making big, fundamental changes, like introducing Testing, and making Debian Maintainers happen.

Thank you to Joey for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter and don’t miss further interviews. You can also follow along on, Twitter and Facebook.

PS: If you want to suggest me someone to interview, leave a comment or mail me.