apt-get install debian-wizard

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!

My Debian activities in May 2011

June 3, 2011 by Raphaël Hertzog

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

I have been…

Doing some work towards Debian Rolling

At the start of the month, the discussions about Debian rolling were still very active on debian-devel. Declaring that testing would be rolling did not make it (as I hoped), the argument that some RC bugs last for far too long in that distribution carried the discussion and thus the most consensual proposition ended up being the one of Josselin Mouette were rolling would be testing plus a few selected cherry-picked packages from unstable.

I believe it’s a workable solution if we only care about a subset of architectures. Otherwise the same reasons that keep the fixed packages out of testing would probably also apply for rolling.

Given this, I did setup britney (the software that controls testing) on my laptop to investigate how we can create rolling. It turns out britney is a very specialized software with very few configuration knobs.

At the same time Joachim Breitner made a proposition that immediately grabbed my attention. He suggests to use SAT solvers to find out the set of packages that should migrate from unstable to testing. I thought that rolling would be a good testbed for this new implementation of britney (which he calls SAT-britney) so I jumped right in this project.

I was not at all familiar with this science field, so I looked up quite some documentation: I learned that all SAT solvers expect the problem to be presented in CNF form, and that DIMACS was the file format of choice to represent those boolean constraints. Several SAT solvers are available in Debian and picosat appears to be one of the best.

Then I started some early coding/prototyping to play with the concept. You can find the result in this git repository, you can grab a copy with git clone git://git.debian.org/~hertzog/sat-britney.git.

There’s not much yet, except some Python code to generate a SAT problem that can be fed to a SAT solver. But I really look forward to this project.

Representing Debian during Solutions Linux

During the second week, I spent 3 days in Paris to help manage the Debian booth at Solutions Linux.

We have responded to lots of queries but most visitors already knew Debian, and many of them use it at work and/or at home. We tried to recruit those people as new members for Debian France, the local association. We also sold all our remaining goodies.

The Ubuntu people were interviewed by France 3 (an important TV channel) and we took this opportunity (with the consent of the Ubuntu guys) to show our Debian t-shirts in the background: you can watch the video here (in French), you can see me with Carl Chenet at 1:21.

We have also been interviewed by Intelli’n TV: here and here (both in French). I’m not very good at this exercise. 🙂

Improving dpkg triggers

The third week was a vacation week, in theory I should have stayed away from my computer but I really wanted to take this opportunity to improve the state of dpkg triggers in Debian.

I already covered my work in another article: Trying to make dpkg triggers more useful and less painful.

The result is not merged yet, I just asked a question to all package maintainers who are using triggers to be able to decide whether I’ll merge it as is, or if I can make the new behavior the default one.

Supporting users after Alioth’s migration

When I came back from my vacation, many services provided by Alioth.debian.org were non-functional after a migration to a new setup that involves two machines instead of one. Given that I used to be an Alioth admin, I know that in those periods you tend to be get bogged down on many user support requests. So I re-joined #alioth on IRC and tried to help a bit.

I did investigate some of the reported problems and prepared fixes (updated scripts, configuration files, etc.) for some of the issues. I also created a list of remaining issues that should have lasted only a few days but that’s still active because there are still regressions left.

The most important things still missing are:

proper support for delegation of rights. We used ACL setup by the admins in the past. With the new FusionForge, each project admin should be able to delegate rights to external “roles”. There’s a Debian Developer role already but trying to grant him right fails…
access to the Ultimate Debian Database. Many tools rely on this database to work.
anonymous FTP access to download project files.
clear guidelines on how we’re supposed to deal with websites that are updated by VCS hooks.
clear guidelines on how we’re supposed to deal with personal git repositories

Improving the “3.0 (quilt)” source format

I have made some proposals to change the way the new source format would work. The goals are to be less painful for packagers who are using a VCS, and to avoid unexpected changes slipping through a new patch generated by dpkg-source.

It seems that the proposals are relatively consensual so I’ll implement them at some point.

Missing in action on my blog

I did a lots of stuff for Debian between travel and vacation, and in the remaining time, I did not manage to write many articles for my blog.

In fact, besides the article on my triggers work mentioned above I only published one interview: People behind Debian: Steve Langasek, release wizard.

I’ll try to do better this month!

Thanks

Many thanks to the people who gave me 151.61 € in May.

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

Discover 5 free software that you can support with Flattr

June 1, 2011 by Raphaël Hertzog

Psychosynth (Flattr link) is a modular synthesis framework. I’m not into music but this user interface looks really different from what you could expect from this kind of software. Watch out the video on its home page!
JS Beautifier (Flattr link) is a very handy tool to beautify javascript code that has been packed to save size (or to obfuscate it)… it’s available as a online service but there’s also a command-line variant.
Bombono DVD (Flattr link) is a DVD authoring tool which aims to be really easy to use. It has a slick user interface and relies on the well known ffmpeg program for the low level tasks.
Key-mon (Flattr link) is a small utility that monitors and displays the status of the keyboard and the mouse in a little non-intrusive window. It’s useful when you record screencasts: you want to show keyboard combinations that have been used, and the viewer should be able to notice that some clicks were made with modifier keys (like CTRL/ALT).
Libre Graphics Magazine (Flattr link) is a publication devoted to people who are working with Libre Graphics software, both professionals and hobbyists. The magazine is a community work and is thus useful to share experience. It’s also a great tool to promote free software in circles where proprietary software is still the norm. The magazine is licensed under the CC BY-SA license so it’s truly free… well worth a few Flattr IMO.

This article is part of the Flattr FOSS project.