Debian – Page 64

Journey of a new GNOME 3 Debian packager

April 11, 2011 by Raphaël Hertzog

With all the buzz around GNOME 3, I really wanted to try it out for real on my main laptop. It usually runs Debian Unstable but that’s not enough in this case, GNOME 3 is not fully packaged yet and it’s only in experimental for now.

I asked Josselin Mouette (of the pkg-gnome team) when he expected it to be available and he could not really answer because there’s lots of work left. Instead Roland Mas gently answered me “Sooner if you help”. 🙂

First steps as a GNOME packager

This is pretty common in free software and for once I followed the advice, I spent most of sunday helping out with GNOME 3 packaging. I have no prior experience with GNOME packaging but I’m fairly proficient in Debian packaging in general so when I showed up on #debian-gnome (irc.debian.org) on sunday morning, Josselin quickly added me to the team on alioth.debian.org.

Still being a pkg-gnome rookie, I started by reading the documentation on pkg-gnome.alioth.debian.org. This is enough to know where to find the code in the SVN repository, and how to do releases, but it doesn’t contain much information about what you need to know to be a good GNOME packager. It would have been great to have some words on introspection and what it changes in terms of packaging for instance.

Josselin suggested me to start with one of the modules that was not yet updated at all (most packages have a pre-release version—usually 2.91—in experimental, but some are still at 2.30).

Packages updated and problems encountered

(You can skip this section if you’re not into GNOME packaging)

So I picked up totem. I quickly updated totem-pl-parser as a required build-dependency and made my first mistake by uploading it to unstable (it turns out it’s not a problem for this specific package). Totem itself was more complicated even if some preliminary work was already in the subversion repository. It introduces a new library which required a new package and I spent a long time debugging why the package would not build in a minimalistic build environment.

Indeed while the package was building fine in my experimental chroot, I took care to build my test packages like the auto-builders would do with sbuild (in sid environment + the required build-dependencies from experimental) and there it was failing. In fact it turns out pkg-config was failing because libquvi-dev was missing (and it was required by totem-pl-parser.pc) but this did not leave any error message in config.log.

Next, I decided to take care of gnome-screensaver as it was not working for me (I could not unlock the screen once it was activated). When built in my experimental chroot, it was fine but when built in the minimalistic environment it was failing. Turns out /usr/lib/gnome-screensaver/gnome-screensaver-dialog was loading both libgtk2 and libgtk3 at the same time and was crashing. It’s not linked against libgtk2 but it was linked against the unstable version of libgnomekbdui which is still using libgtk2. Bumping the build-dependency on libgnomekbd-dev fixed the problem.

In the evening, I took care of mutter and gnome-shell, and did some preliminary work on gnome-menus.

Help is still welcome

There’s still lots of work to do, you’re welcome to do like me and join to help. Come on #debian-gnome on irc.debian.org, read the documentation and try to update a package (and ask questions when you don’t know).

Installation of GNOME 3 from Debian experimental

You can also try GNOME 3 on your Debian machine, but at this point I would advise to do it only if you’re ready to invest some time in understanding the remaining problems. It’s difficult to cherry-pick just the required packages from experimental, I tried it and at the start I ended up with a bad user experience (important packages like gnome-themes-standard or gnome-icon-theme not installed/updated and similar issues).

To help you out with this, here’s a file that you can put in /etc/apt/preferences.d/gnome to allow APT to upgrade the most important GNOME 3 packages from experimental:

Package: gnome gnome-desktop-environment gnome-core alacarte brasero cheese ekiga empathy gdm3 gcalctool gconf-editor gnome-backgrounds gnome-bluetooth gnome-media gnome-netstatus-applet gnome-nettool gnome-system-monitor gnome-system-tools gnome-user-share baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-system-log gstreamer0.10-tools gucharmap gvfs-bin hamster-applet nautilus-sendto seahorse seahorse-plugins sound-juicer totem-plugins remmina vino gksu xdg-user-dirs-gtk gnome-shell gnome-panel dmz-cursor-theme eog epiphany-browser evince evolution evolution-data-server file-roller gedit gnome-about gnome-applets gnome-control-center gnome-disk-utility gnome-icon-theme gnome-keyring gnome-menus gnome-panel gnome-power-manager gnome-screensaver gnome-session gnome-settings-daemon gnome-terminal gnome-themes gnome-user-guide gvfs gvfs-backends metacity mutter nautilus policykit-1-gnome totem yelp gnome-themes-extras gnome-games libpam-gnome-keyring rhythmbox-plugins banshee rhythmbox-plugin-cdrecorder system-config-printer totem-mozilla epiphany-extensions gedit-plugins evolution-plugins evolution-exchange evolution-webcal gnome-codec-install transmission-gtk avahi-daemon tomboy network-manager-gnome gnome-games-extra-data gnome-office update-notifier shotwell liferea epiphany-browser-data empathy-common nautilus-sendto-empathy brasero-common
Pin: release experimental
Pin-Priority: 500

Package: *
Pin: release experimental
Pin-Priority: 150

The list might not be exhaustive and sometimes you will have to give supplementary hints to apt for the upgrade to succeed, but it’s better than nothing.

I hope you find this useful. I’m enjoying my shiny new GNOME 3 desktop and it’s off for a good start. My main complaint is that hamster-applet (time tracker) has not yet been integrated in the shell.

People behind Debian: Adam D. Barratt, release manager

April 7, 2011 by Raphaël Hertzog

Adam D. Barratt is a Debian developer since 2008, in just a few years he got heavily involved to the point of being now “Release manager”, a high responsibility role within the community. He worked hard with the other members of the release team to make Squeeze happen.

You could expect the release managers to have some rest after a big release, but it’s not really the case. With the long freeze, loads of “transitions” have accumulated and they are now busy to get all those updated packages in the new testing (wheezy). Despite this Adam took some time to answer my questions.

He shares with us his impression on the Squeeze release, his opinion on time-based freezes (regular/predictable freeze) and much more. Read on. My questions are in bold, the rest is by Adam.

Who are you?

I’m a 31 year old software developer and part-time sysadmin for a software and IT services company based in the south of England. I have no children, no pets and a long-suffering partner who puts up with me spending far too much time tinkering with things and people making fun of her Macbook during Debconf.

As well as being on the release team, I’m a member of the maintainer teams for devscripts and lintian.

Can you describe your journey in Debian and in the release team?

I was introduced to Debian as part of an infrastructure upgrade at work, moving from a set of Red Hat and Solaris-based systems. As part of that, we submitted some bugs for issues we found during the upgrade and for small patches we included in some software to add extra functionality we wanted. From that starting point I became more interested in Debian in general and began following some of the mailing lists and IRC channels.

When Julian Gilbey asked for help with the maintenance of devscripts, I submitted some patches for some of the outstanding bug reports and was invited to join the team which was being created to handle maintenance for the package. One of the then Release Managers was also on the team and asked if I’d be interested in working on a couple of updates they wanted to the scripts which generate the proposed-updates overview pages. I added the new functionality which was merged in to the live scripts and a little while later I was invited to join the team, shortly before Debconf 9.

As most readers will be aware, we unfortunately reached a point during last year where we didn’t have anyone filling the Release Manager role. During that period, I became more active in handling transitions and requests for updates to stable and as time went on more people started to suggest that I should put myself forward for the position, or refer to me as already being RM. I procrastinated over the decision for some time but after discussions during Debconf 10 I came round to the idea that we should have the RM role filled again and agreed to take it on, together with Neil. The rest, as they say…

How much time do you usually spend working for the release team ?

I’ve been trying to work out how to usefully answer this question. My initial answer was “approximately two hours each day”, but the longer I thought about it the more I started debating exactly what I should include under the umbrella of release work; after some to-and-fro I’ve decided to stick with my initial answer.

During periods when Debian is frozen and particularly in the lead up to the release that time commitment increases significantly, particularly over weekends. I’m reliably informed that at that point the correct answer to the question is “too much time”. 🙂

What’s your own retrospective of the Squeeze release? What went well and what needs to be improved?

Overall, I believe the release went well and that we should all be proud of the Squeeze release. The parts of the release cycle which highlighted the need for improvement all share, imo, a single root cause – communication, particularly around freeze-related plans. We worked hard during the freeze itself to improve our communication with the rest of the project and want to continue in that vein during the Wheezy cycle.

One thing that I personally found quite difficult at times before the freeze was keeping track of the transitions which were still waiting for a place in the queue; it’s also something that we could improve on at this early stage of the Wheezy cycle. In order to help us keep a clear overview of requests for transitions, stable updates and binNMUs, it would be helpful if they could be filed as appropriately user-tagged bugs. This not only allows us to easily get an overview of the status of requests from the BTS but also aids transparency by allowing anyone else to do so; as a useful additional feature, it means that we can use the BTS’s blocking functionality to indicate reasons why a request cannot be fulfilled right now.

Are you in favor of time based freeze?

I think there’s merit in having a time frame that we can work towards in order to achieve the goals which we set ourselves for the release, as individual maintainers, maintenance teams and a project. I do have concerns that even with such a time frame in place there will still be uploads made very close to the proposed freeze point and transitions which may be unfinished, for example because of an unforeseen entanglement with or reliance on the transition of another package.

One thing I’m interested in is how exact and specific that time frame should be and the balance between predictability and being able to achieve everything we want for a great release; this is something we can cover in the debate on this subject which I know many people have strong opinions about.

What are your plans for Debian Wheezy?

The Wheezy to-do list I started before the final Squeeze release begins “multiarch, multiarch, multiarch”. It looks like we’re finally going to get that achieved during this release cycle, thanks to a great deal of hard work from various people. I’m also interested in seeing the C.UTF-8 locale standardised throughout Debian and continuing to work on our tools and processes to make tracking of transitions and stable updates simpler (or at least appearing to be so 🙂 and more transparent.

With my package maintenance hats on, I’d like to help ensure that both devscripts and lintian are able to keep pace with changes in the development landscape in Debian (e.g. more useful package diffing for source format v3 packages) and continue to be tools that are an integral part of package development in Debian.

Some people (including me) would like a rolling distribution constantly usable by end-users. Do you think that the release process currently geared towards producing “stable” can be accommodated to support this?

I’m not yet convinced that the concept of a rolling, “constantly usable” distribution can be easily integrated in to the workflow that exists around preparing stable releases in Debian. The “testing” distribution was created as, and continues to be used as, a tool to enable the release team to create the next stable release – that it happens to be something that people can use every day for much of the time is mostly a happy side-effect of the fact that we don’t gratuitously break it, but is by no means guaranteed to be the case early in the release cycle or during large, disruptive, transitions.

It’s been suggested that “testing” and “rolling” could be basically the same for most of the cycle, with “rolling” then continuing to be updated when testing is frozen. This would essentially mean an extra suite which is only used for a few months every couple of years or so, which is one of the things that “testing” was intended to avoid (i.e. the old “frozen” suite) and seems like a lot of overhead to introduce in order to reduce disruption to some users during the freeze. The early part of the release cycle also tends to include a number of larger transitions which often require packages to either be removed from testing or broken as part of migrating the transition, if they are not able to be successfully updated in time.

What’s the biggest problem of Debian?

The thing that I’ve been noticing myself becoming frustrated by recently is a tendency to debate the minor details of proposals, rather than concentrating on getting the key points right to begin with. Clearly for some projects such as multiarch the details may be as important as the big picture, but in most cases the people working on a development should be allowed to look after the smaller details themselves.

That’s not meant to imply that feedback from other parts of the project should not be welcomed, simply that if we consider Debian to be a “do-ocracy” then we need to permit people the freedom to “do”.

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

All previous release managers, for making the job look much easier than it seems when you’re in the “hot seat”. 🙂

Outside of the release team, Joey Hess for his contributions to various parts of the Debian development environment over the years, such as debhelper and debian-installer, and Colin Watson for his enviable willingness to tackle a wide variety of different projects within Debian.

Thank you to Adam 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 Identi.ca, Twitter and Facebook.

March 2011 wrap up

April 3, 2011 by Raphaël Hertzog

Since I’m soliciting donations to support my Debian work, the least I can do is explain what I do. You can thus expect to see an article like this one every month.

Multi-Arch work

I updated the code to use another layout for the control files stored in /var/lib/dpkg/info/. Instead of using a sub-directory per architecture (arch/package.type), we decided to use package:arch.type but only for packages which are Multi-Arch: same. dpkg is taking care to rename the files the first time it is executed with write rights and then updates /var/lib/dpkg/info/format to remember that the upgrade has been done and that we can rely on the new structure.

I filed a few bugs on packages that are improperly accessing those internal files instead of using the appropriate dpkg-query interface. I sent a heads-up mail on -devel to make other people aware of those problems in the hope to discover most of them as early as possible.

After that, the work stalled because Guillem went away for 2 weeks and thus stopped his review of my work. I hope he will quickly resume the review and that we will get something final this month.

With the arrival of dpkg 1.16.0, it’s now possible to start converting libraries to multi-arch even if full multi-arch support has not yet landed in dpkg proper. See http://wiki.debian.org/Multiarch/Bootstrapping for the detailed plan.

If you’re curious about Multi-Arch, you might want to read this article of Steve Langasek as well.

Bug triage for dpkg in launchpad

At the start of the month, there was close to 500 bugs reported against the dpkg package in Launchpad. Unfortunately most of it is noise… many of the reported bugs are misfiled, they show an upgrade problem of a random package and that upgrade problem confuses update-manager which tries to configure an already configured package. This generates a second error that apport attributes to dpkg and the resulting bug report is thus filed on dpkg. There are literally hundreds of those that have to be reclassified.

Michael Vogt and Brian Murray did some triaging, and I also spend quite some hours on this task. It’s a bit frustrating as I tend to mark many reports “Incomplete” because there’s no way they can be acted upon and many of them are so old that the reporter is unlikely to be able to provide supplementary information.

But in the middle of this noise, there are some useful bug reports, like LP#739179 which enabled me to fix a regression even before it reached Debian Unstable (because Ubuntu runs a snapshot of dpkg with multiarch support).

I subscribed to the Launchpad bugs for dpkg via the Debian Package Tracking System (thanks to the derivatives-bugs keyword) and will try to keep up with the incoming reports.

Misc dpkg work

The ftpmasters came up with a request for a new field (see 619131) in source packages. After a quick discussion and a round of review on debian-policy@l.d.o, I implemented the new Package-List field. This should allow the ftpmasters to save some time in NEW processing, but we deferred the change for the next dpkg version (1.16.1) to ponder a bit more on the design of the field.

I also fixed a bunch of bugs (#619541, #605719, #598922, #616096) and merged a patch of Mark Hymers to recognize the new Built-Using field.

Developers-reference work

The review process for changes to the developers-reference is not working as it should. And I suffered from it while trying to integrate the patch I wrote for the “Developer duties” chapter (see #548867).

We purposely changed the maintainer field from debian-doc to debian-policy in the hope to have more reviews of suggested changes and to seek some sort of consensus before committing anything. But we don’t get more reviews… and deciding to commit a patch is now even harder than it was (except for trivial stuff where personal opinions can’t interfere).

In my case, I only got the feedback of Charles Plessy which was very mixed to say the least. I tried to improve my patch based on what he expressed but I also clearly disagreed with some of his assertions and was convinced that my wording was in line with the dominant point of view within Debian.

We tried to involve the release team in the discussion because most of what I documented was about helping making stable release happen, but nobody of the team answered.

Instead of letting the situation (and my patch) rot, I solicited feedback from the DPL and from another developers-reference editor to see whether my patch was an improvement or not. After some more time, I went ahead and committed it.

It was not pleasant for anyone.

I don’t know how we can improve this. Contrary to the policy, the developers-reference is a document that is not normative, I believe the result is better when we put some “soul” into it. But it’s a real challenge when you seek a consensus and that the interest in reviewing changes is so low.

DVD shop listed on debian.org

In February, I launched a DVD shop whose benefits are used to fund my Debian work. Shortly after the launch I used the official form to be added to the official listing of Debian CD vendors and offered a few suggestions to deal with vendors who are selling unofficial images (with firmware in my case).

A few weeks later, I got no answers: neither for my request nor for my suggestions, I mailed the cdvendors@debian.org team directly asking for a status update and quickly got an answer suggesting that Simon Paillard usually does the work and can’t process the backlog due to some injury. At this point no concerns had been raised about adding me to the list. To save some time and some work for the team, I added myself to the list since I had commit rights and I informed them that I did it, so that they can review it.

Shortly after I did that, Martin Zobel Helas objected to my addition. I cleared some misunderstandings but the discussion also lead to some changes to please everybody: the listing now indicates that some images are unofficial and I have prepared a special landing page for people coming from the Debian website through this listing.

Debian column on OMG! Ubuntu

I have always been a firm believer that it’s important for Debian to reach out to the widest public with its message of freedom. Thus when Benjamin Humphrey contacted the debian-publicity team to find volunteers to write a Debian column on OMG! Ubuntu, I immediately jumped in.

I wrote 4 articles over there. The tone is very different from my articles on my blog and I like that duality. Check out Debian is dying! Oh my word!, Debian or Ubuntu, which is the best place to contribute?, Are you contributing your share? and Ubuntu’s CTO reveals DEX: an effort to close the gap with Debian.

It’s a great win-win situation, OMG! Ubuntu benefits from my articles, Debian’s values are relayed further, and OMG! Ubuntu’s large audience also helps me develop my own blog.

Work on my book

I had lots of paperwork to do this month (annual accounting stuff for my company) and I did not have as much time as I hoped for my book. Still I have a updated a few more chapters of my French book and I certainly hope to complete the update during April.

This means that the work on the English translation could start in may.

Work on my blog

Just like for my book, it has been relatively difficult for me to cope with my policy of two articles every week. But I still managed to get quite some good stuff out.

I interviewed Christian Perrier (Debian’s translation coordinator) and also Bdale Garbee (chair of Debian’s technical committee).

I finished my series of “Debian Cleanup Tips” with 2 supplementary articles:

The removal of firmware is causing troubles to quite some users so I wrote an article explaining how to deal with the problem. A regular reader also asked me to write an article about Jigdo, I executed myself because it was a good idea and that he has been very nice with me: Download ISO images of Debian CD/DVD at light speed with Jigdo.

Last but not least, I shared my package maintainer pledge which inspired my developers-reference patch (see discussion above).

Thanks

Many thanks to all the people who showed their appreciation of my work. The 324.37 EUR that you gave me in February represented 2 days and a half of my time that I have spent working on the above projects.

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

People behind Debian: Bdale Garbee, chair of the technical committee

March 28, 2011 by Raphaël Hertzog

Bdale is a long-time Free Software believer, he has been contributing even before Debian existed… in the prehistoric era of free software. 🙂

Anyone who went to a big Free Software conference has seen one of his colorful t-shirts. Or maybe you have heard the story where he got his beard shaved by Linus Torvalds to raise funds to protect the Tasmanian Devil.

More seriously Bdale has played and continue to play a number of important roles in the Debian community. He also represents one of the biggest corporate sponsors (both for DebConf and for the servers that Debian owns): Hewlett Packard.

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

Who are you?

I made my first personal contribution of source code to what we now call Free Software in 1979. I started with HP in 1986 and for nearly a decade have served the company as Chief Technologist for Open Source & Linux. I am president of Software in the Public Interest, which is the “umbrella organization” providing legal and financial existence for Debian in the USA. I also represent users, developers, and Debian interests on a number of boards including at the Linux Foundation and the Freedombox Foundation.

I’m happily married with two children. Many people in Debian have met some or all of my family. They all joined me for Debconf in Edinburgh, and my daughter Elizabeth also attended in Caceres and New York.

I joined Debian in 1994. I’ve been responsible for a number of packages essential to our base system continuously since that time. But I’ve also contributed to the project in many other ways over the years. I ran the first server that was fully dedicated to Debian. Ideas of mine influenced the development of project infrastructure, from the early design of our mirror network to structuring the archive around a ‘package pool’. I started or made significant early contributions to 5 ports of Debian to non-i386 architectures. I served as Debian Project Leader (DPL) in 2002-2003, was acting Secretary for a while, and have served on the Technical Committee for a number of years.

Over the years, I’ve also had some interesting hobbies. I helped design, build, and program pieces of various amateur radio satellites. I enjoy making physical things, and have many tools for working in wood and metals. My son and I are very active in the world of high power model rockets. And with my partner (and fellow Debian developer!) Keith Packard I’m now running a small business making and selling open hardware and open source avionics for hobby rockets. You can read more about that at http://altusmetrum.org.

You’re the chair of the Debian technical committee. Can you quickly explain the role of this committee?

I think many people assume the Technical Committee has a larger role in Debian than it really does. Section 6 of Debian’s constitution defines the official role of the Technical Committee. Most importantly, the committee exists as a last resort place to resolve technical conflicts between Debian developers that they are unable to resolve by themselves. Most of the power in Debian is left in the hands of individual developers, who are usually able to collaborate with each other to make good technical decisions. So the Technical Committee’s resolution process has only rarely been needed, which I think is a very good thing.

From my point of view, the technical committee is not working. In many cases, the committee does not take any (timely) decision and just waits until the underlying situation has evolved to a point where the intervention of the committee is no longer needed. Do you agree with this and how can you explain it?

I think it’s very important for all of us to remember that everyone working on Debian does so voluntarily, and people who volunteer their time generally deserve a measure of respect and appreciation for their efforts.

No issue is brought to the Technical Committee unless resolving it is expected to be really difficult, or at least contentious. And often, the issues brought to the committee have been as much or more about personality than technology. That makes some of them really hard to solve.

So I do not agree that the technical committee is not working. It seems to me that the decisions that bog down and take a long time are the ones where arguments start out or become emotional instead of technical. In this context, if committee members can help lead public and private discussions in a way that causes a situation to evolve to the point where a decision is no longer needed, that may be healthier for the project in the long term than a quick vote that satisfies some contributors at the expense of others.

The last important change that was made to try to revive the committee was the addition of two new members (Don Armstrong and Russ Allbery). Is there anything else that could be tried?

The biggest improvement I could personally wish for is something people sending issues to the committee can help with. As the ultimate technical decision making body for a project whose output is mostly software, the more a request can be put in terms of a decision about source code, the easier it will be for us to make a decision. That won’t always be possible, but when we’re forced to try and dream up alternatives and then figure out whether anyone would actually be willing to write the code to implement those alternatives, the process takes a lot longer than choosing between competing patch sets or deciding whether a patch should be included.

Besides your role in the technical committee, you have held the role of mediator/facilitator/advisor on numerous occasions. Because you’re an old wise bearded guy who travels a lot and knows many Debian contributors… I would like to thank you for all this work that few people notice. Are there been times where this has been a real burden for you?

Thank you for mentioning this. I’ve put a lot of my heart into Debian over the years, largely because it’s a project and a community that continues to amaze and inspire me.

I feel fortunate to have been able to meet and work on Debian with so many outstanding people from around the world. Many are now my friends, with all the silly and serious things being a friend implies. I’ve been asked for and have given advice many times. I’ve helped celebrate birthdays, marriages, new jobs, and the arrival of children. Sadly, I have also found myself having to try and find the right words to mark the loss of some of these friends…

The only time any of this feels like a burden is when there’s some important problem that many people care about, that I’m working “behind the scenes” to help fix, but can’t really talk about publicly without causing more harm than good. It’s distressing to have people think you don’t care or aren’t helping, when really you’re doing everything you possibly can… just not in a publicly visible way. Of course I understand that this is an impossible situation. If you can’t see what’s happening, there’s no way to know if something is happening or not. That’s why I advocate doing as much as possible in Debian, and SPI, and everywhere else I contribute in as open a way as possible.

You have been Debian Project Leader and you promoted the vision of Debian as the Universal Operating System. What does “universal” mean for you?

The biggest thing to me at the time was the idea that Debian could be anything. Those who chose to work on Debian would ultimately determine what Debian became. I also wanted to make sure we thought about as broad a set of potential users and collaborators as possible.

But this vision provided a framework for pursuing a whole range of worthwhile increases in Debian’s scope of utility, some of which I articulated in my DPL platforms, some others put forward. Internationalization, porting to more supported architectures, our inclusive and evolving approaches to accepting new developers and new packages, and so forth.

I think this vision has served us well, and it pleases me that it has stayed a part of our collective thinking for so long.

We’re again in Debian’s electoral period, what do you think of the work done by the current DPL?

I’m very happy with what I’ve observed of Stefano’s activities during his first year as DPL. He has an obvious enthusiasm for Debian, communicates well both in one to one interactions and in front of a crowd, and I think represents Debian very well.

It is interesting that he’s running unopposed for re-election this year. I choose to interpret that as evidence he’s doing a good job, the project is running well, and nobody feels the need to try and take the job away From him. I’m glad he’s willing to continue in this role for another year.

What’s the most important thing that Debian should achieve in the wheezy timeframe?

I don’t yet have a very crisp personal wish-list for wheezy. But I would certainly like to see multiarch support finally completed! I’m also very interested to see what comes from the CUT work.

You have been an early supporter of “multiarch”, a project to allow easy installation of foreign architecture packages. It’s on good track for Wheezy. Do you think it’s an important milestone?

My original motivation for requesting multiarch support was to enable support for 32-bit x86 binaries on ia64 “Itanium” systems, in the time leading up to the “sarge” release. I ended up creating the ia32-libs package, which I’m not proud of. The emergence of 64-bit extensions to x86 (the amd64 architecture) made this a much broader issue. Today, I run a 64 bit kernel and a 32 bit user space on my notebook. There are problems with just moving entirely to 64 bit… but I would like to be able to run some applications that work with large data sets in full 64 bit mode!

Thank you to Bdale Garbee 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 Identi.ca, Twitter and Facebook.