How to squash Debian release critical bugs

Squashing release critical (RC) bugs is one of the most helpful way to contribute to Debian. Because those are the bugs that we need to get rid of in order to release the next stable version. Let’s see how you can help.

The process is really simple:

  1. Find a RC bug that you can fix
  2. Prepare a fixed package
  3. Send the patch to the BTS
  4. Get your fixed package uploaded

I have already covered points 2 and 3 in a former article: How to prepare patches for Debian packages. So I’m not going to repeat myself in this article, instead I’ll cover how to find a release critical bug to fix and how to get your package uploaded.

Find a RC bug with UDD

The Ultimate Debian Database (UDD) provides a neat interface to query the bug tracking system: http://udd.debian.org/bugs.cgi. The form contains many options to customize the query, we’ll try explain some.

First, at the top, you can decide to list bugs based on whether or not they affect testing/stable/unstable. Indeed, thanks to version tracking the BTS knows if a bug applies to the version of the package present in a given distribution. I suggest you pick a choice that includes “sid” because that’s where you’re going to push your fixed package. If sid is not affected by the bug, you can’t do much about it (except if you want to join the release team and help ensure updates are flowing from unstable to testing).

I usually go for “wheezy and sid” because that filters out packages which are not in testing (and are thus not blocking the next release).

Then you have lots of filters to further reduce the list of bugs. It’s important to reduce the noise as you typically have several hundreds of RC bugs at a given time. I suggest you the following settings for a start, but you’re free to try other combinations depending on what you want to achieve (I’ll give some examples later):

  • ignore bugs tagged patch (a fix is already available);
  • ignore bugs tagged pending (a fix has already been committed to the VCS repository);
  • ignore bugs newer than 7 days (that’s the time we should leave for the maintainer to take care of the bug by himself);

I usually sort the results by source package so that I immediately see if several RC bugs are affecting the source package. And I might add “popularity contest” information to get a feel of whether the package is widely used or not.

You can see the results of the suggested query here.

Other interesting queries:

Find a RC bug with rc-alert

The downside of the above method is that you get bugs on packages that you don’t know at all and that you might not care about. Some of them might even be better removed instead of fixed.

With the rc-alert command (provided by the devscripts package), you will get a list of RC bugs on packages that are installed on your computer. It should be much more restrictive. And you have command line options to further filter the list just like with the UDD form. Bonus feature: you can also filter by debtags allowing you to restrict the bugs to packages which are implemented in programming languages that you know.

$ rc-alert --include-dists TU --exclude-tags P+ --debtags implemented-in::perl,implemented-in::python
Package: gwibber
Bug:     608724
Title:   gwibber bypasses certificate checking when providing the login/password for OAuth
Flags:   [     S  ] (security)
Dists:   [STU] (stable, testing, unstable)
Debtags: implemented-in::python, interface::x11, role::program, uitoolkit::gtk, works-with::im, x11::application
[...]

Get your fixed package uploaded

Usually sending the patch to the BTS is more than enough. The maintainer or another Debian developer will pick it up at some point. But if you’re interested in becoming a Debian maintainer/developer, it might be worth to push your changes more quickly and get credited by a proper upload with your name.

Instead of just preparing a patch, you should also prepare a fixed package following the rules of a Non-Maintainer Upload. Put this package somewhere online (for example on mentors.debian.net).

When you send your patch to the BTS, include the link to the updated package and express your wish to get this update sponsored. If you haven’t heard anything from the maintainer after 2-3 days, try to find a sponsor on debian-mentors@lists.debian.org. NMUs are easier to review than completely new packages and many Debian developers like to kill RC bugs, so there’s a good chance that you’ll find someone.

Now happy RC bug-squashing! And if you really enjoy it, you can subscribe to debian-bugs-rc (~3000 mails per month)… 🙂

If you want to read more articles like this one, click here to subscribe to my free newsletter. You can also follow me on Identi.ca, Twitter and Facebook.

How to prepare patches for Debian packages

You want to start contributing to Debian and/or Ubuntu, you decided to help a package maintainer and you’re now looking for how to change a source package and how to submit your changes.

1. Retrieve the source package and install build-dependencies

The first step is to retrieve the latest version of the source package and to install the required build-dependencies. I already covered how to do this with apt-get in the article explaining how to rebuild a source package.

If you prefer, you can use dget (from the devscripts package) to directly grab the source package. You can find the URL of the .dsc files in the Package Tracking System for example.

Sometimes apt-get will warn you that the source package is maintained in a VCS repository, like this:

$ apt-get source wordpress
[...]
NOTICE: 'wordpress' packaging is maintained in the 'Git' version control system at:
git://git.debian.org/git/collab-maint/wordpress.git
[...]

In that case, you can use debcheckout to retrieve the VCS repository instead (provided that you have the corresponding VCS installed):

$ debcheckout wordpress
declared git repository at git://git.debian.org/git/collab-maint/wordpress.git
git clone git://git.debian.org/git/collab-maint/wordpress.git wordpress ...
Cloning into wordpress...

Note however that some maintainers use their VCS in a way that’s not really compatible with the explanations that I will give below.

It’s also a good idea to install the package “packaging-dev”. It’s a meta-package depending on the most common tools that are used for Debian packaging work.

2. Do the changes

Execute dch --nmu to record the fact that you’re working on an update prepared by someone who is not the maintainer (NMU means Non Maintainer Upload). This also ensures that if we build the package, we won’t overwrite the original source package that we downloaded, thus making it possible to generate a “diff” between both versions.

2.1. Modify Debian packaging files

Now fire your text editor and do the required changes in the “debian” sub-directory. You will probably run dch -a multiple times to document each subsequent change.

2.2. Modify upstream files

If you have to modify upstream files, the proper way to do it depends on the source package format (“1.0” vs “3.0 (quilt)” vs “3.0 (native)”, see the debian/source/format file) and on the presence or not of a patch system (the what-patch can help you identify it). In this explanation, I’ll assume that the package is using the recommended format: “3.0 (quilt)”. (It also works for “1.0” if quilt is used and if you configured ~/.quiltrc as recommended by /usr/share/doc/quilt/README.source).

First you should ensure that all patches have been applied with quilt push -a. If there’s no patch yet, you want to create the debian/patches directory (with mkdir debian/patches). Note that you should better invoke quilt from the root of the source package (and the examples below assume this).

2.2.1. Import a patch

If the upstream changes are already in a patch file (say /tmp/patch that you downloaded from the upstream VCS repository) you can import that patch like this:

$ quilt import -P fix-foobar.patch /tmp/patch
Importing patch /tmp/patch (stored as fix-foobar.patch)
$ quilt push
Applying patch fix-foobar.patch
[...]
Now at patch fix-foobar.patch

The -P option allows to select the name of the patch file created in debian/patches/. As you see, the new patch file is recorded in debian/patches/series but not applied by default, we’re thus doing it with quilt push.

2.2.1. Create a new patch

If the upstream changes that you want to make are not in a patch yet, you should tell quilt that you’re going to create one:

$ quilt new fix-foobar.patch
Patch fix-foobar.patch is now on top

Then you must record every file that you’re going to modify with a quilt add invocation. quilt then makes a backup of those files so that it can generate the patch later on. If you’re going to modify the files with your text editor you can just do quilt edit file-to-modify, it’s the same than quilt add file-to-modify followed by sensible-editor file-to-modify.

$ quilt edit foobar.c
File foobar.c added to patch fix-foobar.patch

The last step is tell quilt to generate the patch:

$ quilt refresh
Refreshed patch fix-foobar.patch

3. Test your changes

You should build your modified package with “debuild -us -uc”. You can easily install the resulting package with “debi”. Verify that everything works as expected. If not, continue your modifications until you’re satisfied with the result.

4. Generate a patch and mail it

If you followed the instructions, you should have two .dsc files in the parent directory, like this:

$ cd ..
$ ls wordpress_*.dsc
../wordpress_3.0.5+dfsg-1.1.dsc
../wordpress_3.0.5+dfsg-1.dsc

Generating the patch to send to the maintainer is then just a matter of running debdiff:

$ debdiff wordpress_3.0.5+dfsg-1.dsc wordpress_3.0.5+dfsg-1.1.dsc >/tmp/wp-debdiff

You can send the /tmp/wp-debdiff file to the wordpress maintainer. Usually you send it via the bugreport that your update is fixing and you add the “patch” tag to the report.

This can be automated with the nmudiff utility. By default it assumes that you’re using mutt but it can also directly feed the resulting mail to sendmail. The default text that nmudiff proposes assumes that you’re actually performing an NMU and that the result has been uploaded. If that’s not the case, you should edit the text and make it clear that you’re just sending a patch.

If you have been working in a VCS repository, instead of using debdiff you can simply use the diff feature integrated in your VCS (git diff, svn diff, etc.). But note that with a distributed VCS (like git/bzr/mercurial, unlike svn) you should probably have committed all individual changes in separate changesets. And instead of sending a single patch, you’re probably going to send a series of patches (though it might be easier to just upload your branch in a public repository and give the corresponding URL to the maintainer).

Found it useful? Be sure to not miss other packaging tips (or lessons), click here to subscribe to my free newsletter and get new articles by email.

How to start contributing to Debian?

I often get requests of persons who would like to contribute to Debian but who don’t know where to start. Let’s try to answer this question properly so that I can give out this URL the next time that I am asked.

The Debian website has a page explaining how to help Debian. While it provides no less than 10 suggestions in a daunting text-only list, it’s difficult to know what to do next once you picked up something that you could do.

I will try to fix this by providing concrete information for each cases in upcoming articles but in the mean time I propose you another approach to start with. Before answering your question (“what can I do for Debian”), we need to know some information about you.

What motivates you?

You’re a volunteer, you’re not doing stuff for Debian because someone told you so. You must have some intrinsic motivation and the ultimate motivation is usually that you’re enjoying what you’re doing.

So what are you enjoying and/or what are your motivations ?

  • Is there something that you would like to learn? A new programming language? Packaging? Coding? System administration? A specific software?
  • Do you want to interact with smart people?
  • Do you like to help users?
  • Do you like to fix software just so that it works for you?
  • Do you like to build something remarkable and useful for millions of people?

On the opposite, make sure to know what you hate and what you want to stay far away from. Maybe you dislike a programming language so much that you don’t want to be involved in a project where you would have to use it, etc.

Write down the answers to the questions, you might need them later when you’ll ask other Debian contributors how you can help.

What are your skills?

If you’re not interested in learning new skills, then you must obviously select a task where your current skills are sufficient. Again make a list of your skills and in particular of skills that you’d like to practice! Here’s a non-exhaustive list of skills to consider:

  • What languages are you fluent with? Are you confident to write documentation or translate documentation in those languages?
  • Are you a programmer? If yes, which languages do you know?
  • Can you diagnose problems? Can you debug problems with strace and/or gdb?
  • Can you triage bugs?
  • Do you know some Debian packaging?
  • Are you an artist and/or a web designer?
  • Do you know how to work with VCS (subversion, git, bzr, …)?

How much time can you spend on Debian?

This is the last important information that you need to communicate whenever you’re asking someone else what you could do for Debian. There’s no point giving you a big task if you can only spend 30 minutes every week. On the opposite if you can work on Debian full time during a week (because you’re between 2 contracts or because you’re in vacation), it’s equally important to know.

In general contributing to Debian requires time, you should be ready to spend at least several hours per week and possibly more at the start while you’re learning everything.

Find something to do

At this point you have a generic idea of what you’d like to do but you’re still missing a concrete objective. Let’s try to find one, we’ll explore several ways to do this.

Scratch your itch

The best objectives are those that satisfy your own needs. Here are some examples:

  • Did you notice a missing feature? Try to implement it.
  • Have you been annoyed by a bug? Try to fix it.
  • Did you lose too much time on something because there was no documentation? Write the missing documentation and submit it where appropriate.
  • File bug reports for the things that you can’t fix yourself. Even wishlist bug reports for new features.
  • Do you use software that are not packaged for Debian? Create the package(s) and maintain it/them.
  • Do you need a newer version of a package compared to what’s in Debian unstable? Contact the maintainer and propose your help to update the package.
  • Do you need a newer version of a package compared to what’s in Debian stable? Contact the maintainer and propose your help to create a backport.

If you’re a good Debian citizen, you have already filed bugs for issues that bugged you. Then you can browse http://bugs.debian.org/from:hertzog@debian.org to find out some ideas of stuff to do (obviously replace hertzog@debian.org by your own email address).

Join a team

If you don’t have a specific itch to scratch, you might want to focus your work on a specific team. Head over to wiki.debian.org/Teams and browse the list of teams.

You’ll surely find one that works in an area that you like. If you select a packaging team, pick one that works on packages that you’re actually using.

Some of the teams have instructions for newcomers, follow them when that is the case. Otherwise join the mailing list and the IRC channel, and get a feel of how the team works. See if it suits you, you can follow several teams at the same time and pick the one that you prefer after a few days/weeks.

Once you have lurked a bit, if you still don’t know how you could help, then just ask on the mailing list. Include all the answers you have collected to the 3 questions on your motivations, your skills and your time available.

Focus on a specific package

You can concentrate your work on a specific package even if you’re in a team, it’s often a good idea. But I list it separately because not all packages are team maintained and you might want to help maintain a package where there’s a single maintainer currently. I leave it up to you to find a way to select a package that interests you…

Then head over to the package tracking system: http://packages.qa.debian.org/dpkg (replace dpkg by the name of the package that interests you)

Fill in the form in the bottom-left corner with your email and select “opts” in the drop-down list, then click “go”. You get a new form where you can select the information that you’ll receive, I recommend you to keep everything except “upload-binary” and to validate the form.

From now on, you get the same mails than the maintainer (and a bit more actually), and it’s a good idea to inform the maintainer that you subscribed and that you’re going to help a bit. Maybe he’s willing to grant you commit rights immediately, maybe he will ask you to send patches for a start. The important thing is to create a good relationship. In any case (even if you did not get any answer from the maintainer), you should be free to help triage existing bugs and to help deal with the flow of incoming bugs (including forwarding bugs when appropriate).

Help a Debian developer

Paul Tagliamonte once blogged Hey, DDs, need help?. He offered his help to “overworked Debian developers”. His post was missing all the information required (cf motivations/skills/time) but the approach is a good one.

The best way to start contributing is to work with existing Debian developers. Even if you “just” want to be sponsored for your own pet package, you should consider that mentoring is a burden for many Debian developers and that you’re more likely to get a sponsor if you have an existing relationship with a Debian developer that you helped. Pick a developer that works in an area that is of interest, and offer him your help.

To simplify things even further, I have created a wiki page where you can find out how you can help me and thus build a relationship with me.

That’s it for now, I hope this article will help you to start contributing. Don’t forget to subscribe to my newsletter to not miss future articles for new contributors. Note that you can refer to this article with the following URL: https://raphaelhertzog.com/go/contributing/ (easier to type and remember).

PS: You might want to also check my Contributing to Debian page.

My Debian package maintainer pledge

When coming back from DebConf9, I wrote this pledge:

As a package maintainer, I will do my best to help the Debian project release a stable version of our operating system. In particular, I will work together with the release team and I will keep all packages associated to my name free of release critical bugs.

To this effect, if I’m not registered as being busy or in vacation, I will start working on my release critical bugs as soon as possible (in less than 1 week in common cases). If I can’t deal with them in a timely fashion, I will state it clearly in the associated bug reports, tag them help and invite other contributors either to provide a patch or to do a non-maintainer upload.

If I do not manage to handle release critical bugs in the above described way, or if I almost never deal with any of my RC bugs by myself, I will:

  • not refuse help and even propose co-maintenance to good contributors
  • recognize my failure and actively try to find a new maintainer and/or co-maintainers
  • not complain if the quality assurance team decides to orphan the package

I recognize that my work is not limited to unstable. I will also work with the stable release team and the security team to provide updated packages for the stable and/or testing distribution when some issues deserve it.

I am aware of the limits of my skills and my available time and I will avoid packaging software that I would not be able to maintain properly.

It tries to sum up the minimal expectations that Debian should have towards the package maintainers. I tried first to get this pledge integrated into the NM/DM process but the discussion concluded that it would be best to document this in the developers-reference. There’s already a chapter called “Debian Developer’s Duties” where this can nicely fit.

I submitted this as a wishlist request for the developers-reference soon after and it’s still open. Now I went to the next step and prepared a patch that restructures the chapter about developer duties. See #548867 for details.

Follow me on Identi.ca, Twitter and Facebook. Or subscribe to this blog by RSS or by email.