News – Page 58

People behind Debian: Philipp Kern, Stable Release Manager

June 10, 2011 by Raphaël Hertzog

Philipp is a Debian developer since 2005 and a member of the release team since 2008. Since he took the responsibility of Stable Release Manager, the process has evolved for the best. I asked him to explain how the release team decides what’s fit for stable or not.

His work on the buildd infrastructure is also admirable but I’ll let him describe that. My questions are in bold, the rest is by Philipp.

Who are you?

I’m a 24 year old Computer Science student, living in Karlsruhe, Germany. As a student assistant I’m currently in two jobs: one is taking care of getting our university IPv6 network in shape, or rather generally getting fringe technologies into the network. The second is taking care of a s390x machine in the basement which my faculty got sponsored recently. In my spare time I tend my Debian duties and I’m active in the student council (Fachschaft) as a sys-admin, software developer and until recently as treasurer.

I got accepted as a Debian Developer in 2005. I’m only really active since I was invited to join the Release Team in early 2008 after I contributed rewrites of some scripts that got lost in a disk crash of ftp-master. In late 2008 I also took on wanna-build/buildd duties.

What’s your notable achievement within Debian?

For one I worked on the deployment of a single buildd/sbuild combination over all of our buildds and I rebased it on the sbuild in the archive several times already. All buildds basically look the same on all architectures, with only few variations. The chroots are now also created in a mostly predictable manner.

Then we finally got build autosigning after years of constant poking. However the policy decision to allow it was made by the ftp-masters anyway, for which I’m grateful, as it eases the workload of the buildd maintainers, the Security Team and the Release Team quite a bit.

On the release side there’s the integration of volatile into the proper structures of Debian. But there I’m guilty for choosing the bad name squeeze-updates is, in comparision with security’s squeeze/updates. Let’s see if we can improve that for wheezy.

The policy for stable updates have changed over time. Can you summarize what kind of updates are allowed nowadays?

All the changes that were made to the policy were driven by the aim to keep stable (and to some lesser degree oldstable) usable throughout its lifetime.

I have to admit that we got slightly more liberal in what we accept since I took over. The previous stable update policy included the fixes of critical bugs that break the system in interesting ways and security fixes. We also opened up the possibility of including important fixes for annoying bugs on a case-by-case basis.

The whole “don’t update that much” part of the stable release management is rooted in “let’s don’t change the behaviour of a running system” and “let’s have as few regressions as possible”. We currently try to counter that with a review process that only allows self-contained fixes that were tested in unstable first, if applicable.

In the future I’d also like to have a feedback process that includes the users of the packages to report problems more early. In fact that’s also why we now send calls for testing to debian-stable-announce one week in advance (see this mail as an example).

So stable is updated through point releases that happen roughly every two months for stable and roughly every four for oldstable. They are accompanied by announcements and new CD/DVD sets.

To be able to push some updates with less delay to our users and to avoid that they have to pick them from proposed-updates, there is stable-updates. The current policy for this suite is available in this post on debian-devel-announce. It boils down to everything urgent like tzdata, regression fixes and volatile packages. We noticed that some packages in stable just weren’t useful anymore when they got updated through volatile. Hence those are folded into stable, too. We also relaxed the rules a bit so that leaf packages like clive, that rely on external websites not to change their URLs, can be updated too.

If somebody wonders what happened to the “and a half” releases… Those were intended to mark the inclusion of new hardware support (mostly by including a co-installable new kernel version). This kind of flag point release is thankfully no longer needed because our marvellous kernel team now backports certain hardware drivers to the kernel version in stable. They have some trouble soliciting test feedback for them, though. It would be cool if more people using stable could respond to their calls for testing.

What are your plans for Debian Wheezy?

Luckily the wanna-build/buildd side isn’t much dependent on release cycles. The stable release management also just takes care of what gets dumped on them by the testing RMs. 😉

The near-term goals are certainly:

getting d-i to use some development process in the archive that’s compatible with the normal flow of packages into testing and
hopefully getting wanna-build to use a sane SQL layout and hence better performance

Apart from that my work is mainly squashing the bugs on buildd.debian.org for the wanna-build part, so if you want something fixed, you need to report it, I’m afraid.

You have several roles within Debian, in particular stable release manager and member of the wanna-build team. Which role do you enjoy more and why?

So the regular duties of the SRM, apart from setting up policies, are reviewing requests for uploads to proposed-updates, accepting them, chasing builds and scheduling point releases. It’s mainly steady work. As for the Release Team it’s working in a fabulous team where everyone’s doing an awesome job.

For me the wanna-build role is holding the things together and fixing up stuff that breaks while the world continues to evolve. And occassionally taking a stab at the ftp-masters. So rather… different.

My heart is probably siding with the buildd side because it’s infrastructure but release work is fun, too.

What’s the biggest problem of Debian?

Mainly that we’re not quick in picking up new technologies and that we got slow on innovation. Distro-wide changes are usually a very big effort to coordinate and to finally complete. I guess people should be able to push fixes for release goals more eagerly into the archive.

Also it seems to me that many DDs are actually disengaging from the release process, especially during the freeze but also before, which makes me a bit sad. However I’m still not sure how we could counter that. As we’re all volunteers you can’t suddenly make others love the idea of releasing something together, I guess.

Do you have wishes for Debian Wheezy?

It’s getting old, but there’s certainly multiarch. Also a usable Python 3 is something I’d really appreciate.

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

Peter Palfrader did an awesome job of getting a nicely working team together for DSA and got many tasks as automated as they are now. It’s a pleasure to work with them and setting up a new buildd is, for example, a real breeze. He also developed a sane archive snapshot service, kudos for that.

Thank you to Philipp 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.

Official Debian/Ubuntu packages for Dropbox

June 6, 2011 by Raphaël Hertzog

Dropbox is a popular service to synchronize files between multiple computers. The service is entirely proprietary but the company is Linux friendly and provides Linux binaries ready to use. They even provide Ubuntu packages that wrap the dropbox client and provide integration with Nautilus.

A bit of story

Unfortunately for Debian users, those packages do not work on Debian due to a dependency that can’t be satisfied (because Ubuntu introduced an epoch on the version of their nautilus package that Debian doesn’t have). This was even reported in a Squeeze review in Linux Weekly News.

At some point, Ivan Borzenkov introduced a dropbox package to Debian but it was not based on the above package, instead it packaged directly the proprietary binaries. This was a bad decision because the binaries bundle a set of LGPL libraries and nobody from Debian wanted to do the required work to provide the corresponding source code. So the package got dropped (see bug #610300).

More recently several persons filed ITP (Intent To Package) bugs stating their willingness to re-introduce dropbox in Debian, but after many months lingering in the bug tracking system (see #544499, #613788), they have been turned back to RFP (Request For Package) because they changed their minds.

What I did

Being a dropbox user myself (despite the recent proof that data stored on dropbox is not 100% private), I offered sponsorship to the volunteers who wanted to package dropbox. But it turns out this was not enough to motivate someone to complete the task.

In the mean time I was still using the old dropbox package that was removed (it used to be downloadable from snapshot.debian.org).

While this was good enough for me, it’s clearly not OK in the long term and way too difficult for the majority of users. So this week-end I spent some hours to create a proper package.

It’s loosely based on the package provided by Dropbox but I upgraded the packaging and changed the way it works. I patched the dropbox wrapper to provide a “dropbox update” command that downloads and updates the proprietary binaries. They are now stored in /var/lib/dropbox instead of having a copy in each user’s home directory (~/.dropbox-dist/). This update command is run by the postinst so that installing the package immediately downloads the proprietary binaries.

Get the Dropbox packages for Debian

The package nautilus-dropbox has been uploaded to Debian unstable, ~~it’s currently in the NEW queue but will shortly reach the mirrors. Then you will be able to~~ You can install the package with a simple apt-get install nautilus-dropbox (provided that you activated the non-free section since that’s where the package is hosted, it can’t be part of Debian since it requires the proprietary binaries to be useful).

In the mean time you can get the packages from the links below:

~~For Debian Squeeze: i386 amd64~~ (now in backports.debian.org)
~~For Debian unstable/wheezy: i386 amd64~~ (now in wheezy/sid)
~~For Debian unstable with GNOME3 from experimental: i386 amd64~~ (now in experimental)

Get the Dropbox packages for Ubuntu

I have setup a PPA for nautilus-dropbox. Feel free to use it in place of the upstream packages.

$ sudo add-apt-repository ppa:hertzog/nautilus-dropbox
$ sudo apt-get update
$ sudo apt-get install nautilus-dropbox

It also includes packages for oneiric, but in theory once the package is accepted into Debian, it should appear in oneiric shortly after.

Package maintenance

I have done the initial packaging work but I don’t really want to maintain it in the long term. I have more than enough to do with dpkg and my other packages. So if you are interested in maintaining this package, please get in touch with me. You should know a bit of python since there are Debian-specific patches of the upstream code. The package is maintained in a git repository.

Feedback

If you have encountered a problem with one of those packages, feel free to leave a comment.

If you’re an happy user of the above packages, click here to find out how you can thank me.

I hope you enjoy the packages!

Trying to make dpkg triggers more useful and less painful

May 30, 2011 by Raphaël Hertzog

Lately I have been working on the triggers feature of dpkg. I would like to share my plan and what I have done so far. I’ll first explain what triggers are, the current problems, and the work I did to try to improve the situation.

Introduction

Dpkg triggers are a neat feature of dpkg that package can use to send/receive notifications to/from other installed packages. Those notifications take the form a simple string.

This feature is heavily used to track changes of packaged files in a list of predefined directories, and to update other files based on this. For instance, man-db is watching the directories containing manual pages so that it can update its cache (in /var/cache/man/). install-info is updating the index of info pages when there have been changes in /usr/share/info. gnome-menus is updating its own copy of the menu hierarchy (with entries from /etc/gnome/menus.blacklist blacklisted) every time that a .desktop file is installed/updated/removed.

From a user’s perspective

You see triggers in action very often during upgrades (in fact too often as we’ll see it later):

Preparing to replace zim 0.52-1 (using .../archives/zim_0.52-1_all.deb) ...
Unpacking replacement zim ...
Processing triggers for shared-mime-info ...
Processing triggers for menu ...
Processing triggers for desktop-file-utils ...
Processing triggers for man-db ...
Processing triggers for hicolor-icon-theme ...
Processing triggers for python-support ...
Processing triggers for gnome-menus ...
Setting up zim (0.52-1) ...
Processing triggers for python-support ...
Processing triggers for menu ...

As you guessed it, those “Processing triggers” lines correspond to the packages which received (one or more) trigger notifications and which are doing the corresponding task.

By default the triggers are processed at the end of the dpkg --unpack invocation which is often too soon because APT will often call dpkg --unpack repeatedly during important upgrades. There are some options to ask APT to use dpkg’s --no-triggers option in order to defer the trigger processing at the end of the APT run. You can put this in /etc/apt/apt.conf.d/triggers:

// Trigger deferred
DPkg::NoTriggers "true";
PackageManager::Configure "smart";
DPkg::ConfigurePending "true";
DPkg::TriggersPending "true";

I have now asked APT maintainers to use those options by default, I filed bug #626599 to track this. At the same time I fixed bug #526774 reported by APT maintainers. This bug forced them to put a work-around in APT which resulted in running triggers sooner than expected.

(And while writing this article I filed bug #628564 and #628574 because it was clearly not normal that the menu triggers was executed twice for the installation of a single package)

From a packager’s perspective

The implementation of triggers has several consequences on the status that packages can have.

Let’s assume that the package A installs a file in a directory that is watched by package B (and that B is currently in the “installed” state). When A is unpacked, dpkg adds B to its “Triggers-Awaited” field and lists the activated trigger in B’s “Triggers-Pending” field. Package A is in “unpacked” state, but B has been changed to “triggers-pending”.

When A is configured, instead of going to the “installed” state, it will go to the “triggers-awaited” state. In that state the package is assumed to NOT fulfill dependencies. However, B—which is still in “triggers-pending” state—does fulfill dependencies.

A and B will switch to “installed” at the same time when the trigger has been processed.

The fact that the triggers-awaited status does not fulfill dependencies means that some common triggers like man-db have to be processed regularly just to be able to ensure dependencies are satisfied before running the postinst of other installed packages.

But a package which ships a manual page can certainly be considered as configured when its postinst has been run even if man-db has not yet updated its cache to know about the new/updated manual page.

When you activate a trigger with the dpkg-trigger command you have an option --no-await to avoid awaiting the trigger processing (and thus to go directly to installed state after the postinst has been run). But with file triggers or activate trigger directives, you do not have this option.

My proposal to improve the situation

This is the problem that I tried to solve during my last vacation. But before changing the inner working of triggers, I wrote a non-regression test suite for that feature (commit here) so I could hack with some confidence that I did not break everything.

The result has been presented on the debian-dpkg mailling list: see the discussion here. I added new directives that can be used in triggers files that work exactly like the current triggers except that they do not put triggering packages in trigger-awaited status.

I believe the code to be mostly ready, but in its current form the patch brings zero benefits until all packages have been converted to use the trigger variants that do not require awaiting trigger processing (and the change requires a pre-dependency on dpkg to ensure we have the required dpkg that understands the new kind of trigger directives).

Remaining question

Thus I wonder if I should not change the default semantic of triggers. The packages which really provide crucial functionality to awaiting packages through triggers would then have to be updated to switch to the new directives.

If you’re a packager using triggers, you can thus help me by answering this question: do you know some triggers where it’s important that the awaiting packages are not considered as configured before the trigger processing? In most of the cases I checked, it’s important for the triggered package rather than for the triggering package.

In truth, a package in triggers-awaited status is usually in a good enough shape to be able to satisfy dependencies (i.e. requirements that other packages can have), but it would still be worth to record the fact that it’s not entirely configured yet because it might be true from the user’s point of view: for example if the menu trigger has not yet been processed, the software might not yet be visible in the application menu.

If you appreciate this kind of groundwork that benefits to the whole Debian ecosystem, please consider supporting my work. Click here and give it a look, there are many ways to contribute and to make a difference for me.

People behind Debian: Steve Langasek, release wizard

May 6, 2011 by Raphaël Hertzog

Steve Langasek has been contributing to Debian for more than a decade. He was a release manager for sarge and etch, and like many former release managers, he’s still involved in the Debian release team although as a release wizard (i.e. more of an advisory role than a day-to-day contributor). Oh, and he did the same with Ubuntu: on the picture on the left, he just announced the release of Ubuntu 10.04 from his Debian-branded laptop. 😉

He has also been maintaining PAM in Debian for as long as can I remember and does a great job at that. He’s very knowledgeable and fully deserves his place within the Debian Technical Committee. I’m glad he still has the time to participate on several important Debian mailing lists because his contributions are always very useful.

I’m sure you’ll notice this just by reading his answers below. My questions are in bold, the rest is by Steve.

Who are you?

I’m 32 years old, have been running Linux since my first year in college back in ’96, and have been a Debian developer now for ten years. Along the way I’ve been involved in maintaining a variety of server packages, worked on the Alpha port for a while, did a stint as a release manager for a couple of years, and serve on the technical committee.

This year I’m also celebrating my ten year anniversary with my lovely wife Patty, who many know as an erstwhile front-desk volunteer at DebConf. God only knows why she puts up with my late-night hacking!

These days in my day job I’m a manager on the Ubuntu Platform team at Canonical, working to help make Ubuntu a daughter distribution that the Debian community can be proud of.

What’s your biggest achievement within Debian or Ubuntu?

There’s no doubt that my biggest achievement in Debian has been overseeing the release of two Debian releases as release manager.

On the other hand, the scope of a release is so huge, and it represents the output of so many developers working together, that it would be arrogant to claim the release itself as an achievement of my own. Also, sarge and etch have long since been rotated off of the mirrors so no one cares about them anymore. 😉 For a more personal and lasting contribution in the distro itself, I’m very proud of writing pam-auth-update. It’s a small piece of code, but one that Debian was missing for a long time – it’s made a big difference to PAM module integration in packages!

What are your plans for Debian Wheezy?

My top priority for this cycle is to see multiarch through. We’re still not far enough along in Debian for most developers to see any difference… and once we are, the first thing people are going to see is a fair bit of breakage when we start breaking a lot of assumptions about paths that have been hard-coded upstream. But I’m still excited by the progress that is being made here. We should be able to ship wheezy without any ia32-libs package. We might even be able to get rid of all the biarch library packages, including those used by the toolchain itself. 54 packages in testing build-depend on gcc-multilib right now, in order to build 32-bit code to ship in the amd64 package; a bunch of those should go away with absolutely no reduction in functionality, saving us a bit of space in the archive and saving the maintainers a lot of complexity in their packages, while at the same time giving us much better support for cross-compilation than we’ve ever had before.

It’s a tall order, certainly, but the pieces are falling into place one by one.

My second priority is to get a policy in Debian around packages integrating upstart jobs. It would of course benefit Ubuntu to have many packages back in sync with Debian, but if all we wanted was to sync with Debian, we could mostly just make debhelper ignore upstart jobs in Debian, prefer them in Ubuntu, and call it good. I’m interested in making sure Debian also gets the benefits of being able to use upstart, because as Linux has become increasingly asynchronous (doing more in parallel at start up), the traditional sysvinit has not been able to keep up. There are all kinds of bugs now related to network startup, for instance, that we don’t have a good answer for in a sysvinit model but that we can fix with an event-based system.

Upstart has been around for a while now, but we’ve been slow to integrate it into Debian because it only works on Linux. It would be a shame if right after the first Debian GNU/kFreeBSD technology preview, packages all stopped working on kFreeBSD because they started to assume the availability of upstart! Unfortunately, having been so cautious we now have systemd on the scene, which not only doesn’t support non-Linux but seems to be in the process of trying to gobble up other, non-Linux-specific components of the desktop stack. So I have to wonder what the future holds for the free desktop on non-Linux kernels.

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

Well, based on my previous experiences when I did spend all my time on Debian, I think the answer here is QA / release work. 🙂 Otherwise, I don’t know. My hands are full enough now with multiarch that it’s hard for me to see what the Next Thing would be.

You’re a member of the technical committee. In the interview of Bdale Garbee, I have argued that it’s not working well. What’s your point of view on this topic?

Well, I feel a constant low level guilt about my own poor level of activity in the TC; but that doesn’t translate into a belief that the system is broken. This is, after all, the decision making body of last resort for technical disputes in Debian, and as such it should really be used sparingly. And if a reputation for glacial deliberation means more developers work out their disputes on their own rather than asking the TC to step in, I think that’s actually a healthy thing!

I do still wish we were more effective at resolving those issues that do come our way, but there’s no silver bullet for this. Though the funny thing is, I’ve noticed that the majority of issues that get referred to the TC nowadays never even need us to make a decision; a short conversation with the disputants is often enough to get them to come to an agreement.

What’s the biggest problem of Debian?

By and large, I think Debian is still doing a great job at what it’s best at — delivering a rock-solid distribution that users can rely on. If I would highlight one problem in Debian, though, it would be that I think we’re becoming less innovative as time goes on. Part of that comes from being such a large project that we’re bound to be more conservative as an institution; but even though the three pet Debian projects of mine that I mentioned above are fairly innovative (multiarch, pam-auth-update, upstart), each of these has landed first in Ubuntu rather than in Debian. Always with a clear intent of pushing back up into Debian, of course, but it just wasn’t possible to do this work within Debian for the first cut without much longer delays.

I worry that if Debian is no longer the place to try new things, that we’re going to miss out on attracting contributions from the folks who are inspired to make Free Software better – and not simply to make it stable.

I’m not sure how to address this, though. Maybe improved conversations with derivatives such as (but not limited to) Ubuntu, about what crack of the day is being tried where and how that can be integrated into Debian once it’s proven to work? I don’t think that team-based maintenance or low-threshold NMUs do anything to address this, though, as the kinds of innovation that matter most are ones that require discussion and consensus-finding — not just routing around inactive maintainers.

Do you have wishes for Debian Wheezy?

Well, I’d like to see the armhf port get on its feet and become an official port. Over the lifetime of the arm and armel ports, the state of the art on ARM has changed quite a bit; it would be great to see Debian taking advantage of this richer platform, to let people make better use of their hardware via Debian.

As a former release manager, you’re now a “release wizard”. I guess you have seen it on debian-devel, there are proposals to not freeze testing and to use another distribution starting as a snapshot of testing to finalize the new stable release. According to your experience, what needs to happen to make this possible?

Frankly, I’ve stayed out of that discussion because I don’t think what’s being asked for is possible. I think proponents of a freezeless release have seriously underestimated the amount of work required on the part of the release team to wrangle testing into a releasable product, and that anything that makes propagation of fixes into the pending release more time consuming will make Debian worse on the whole, not better.

If people really want to avoid long freezes for the Debian release, the best way they can help this happen is by making Debian more releasable on an ongoing basis, by helping to hold our packages to our shared standards for quality (i.e., by fixing RC bugs!). The biggest factor in long freezes for Debian is the slow rate at which we bring the RC bug count down during the freeze. Back in the sarge, etch days we used to have really great bug squashing parties that would get people together on weekends to hack through RC bugs by the dozens. I don’t see that happening as much anymore. I’d really like us to get back to that, but my few attempts at this so far since retiring as release manager have led me to think I’m really terrible at organizing parties of any kind. 🙂

On the other side, as seen at http://bugs.debian.org/release-critical/, the RC bug count for testing at the beginning of the release cycle keeps getting higher and higher. I’d love to know why that is so we can address it. I know we’ve gotten better at detecting some classes of RC bugs; that’s part of it, but I don’t think it explains the whole trend.

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

Wow, what kind of arrogant jerk would I be if I didn’t admire anyone in Debian for their contributions? Debian is and always has been an amazing community of top-notch developers; there are certainly too many I admire to list them all here. Joey Hess certainly makes the list, for his longstanding example of code speaking louder than words and for his ability to get to the heart of common problems and come up with elegant solutions. So does Russ Allbery, who by all accounts had his ability to feel anger in response to email burned out of him at a young age in a flame-related accident on Usenet. 😉 The list goes on, but here I think I have to follow Joey’s example and cut the words short.

Thank you to Steve 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.

A bit of story

What I did

Get the Dropbox packages for Debian

Get the Dropbox packages for Ubuntu

Package maintenance

Feedback

Introduction

From a user’s perspective

From a packager’s perspective

My proposal to improve the situation

Remaining question

Tags

Recent Posts