About Archive Tags RSS Feed


Guess he wasn't too popular at the end, huh?

23 December 2008 21:50

Previously I've posted a couple of running commentries describing how I've examined and gone about fixing a couple of bugs in Debian packages I use, enjoy, or have stumbled upon by accident.

Each of these commentries has resulted in a change or two to the affected software to make the bug vanish.

Fixing the bug is usually the hard part, but obviously it isn't the only thing that you need to do. While it is fun to have a locally fixed piece of software if you don't share it then the very next release will have the same bug again - and you'll spend your life doing nothing more than fixing the same bug again and again.

Generally the way that I report my fixes is by sending email to the Debian bug tracker - because I usually only try to fix bugs that I see reported already. Specificially I tend to only care about:

  • Bugs in packages that I maintain.
  • Bugs that affect me personally. I'm selfish.
  • Bugs in packages I use, even if they don't affect me.
  • Segfaults. Because segfaults and security issues often go hand in hand.

So my starting point is generally an existing bug report, such as the last bug I attempted to fix:

This bug was pretty simple to track down, and once I had added a couple of lines to the source to fix it creating the patch and reporting it was pretty simple.

The way I generally work is to download the source tree of the Debian package to my local system and work with it in-place until I think I've fixed the issue. I generally get the current sources to a package by running:

apt-get source "package"

Once I'm done fixing I'll want to create a patch. A patch is just a simple way of saying:

  • open file foo.c
  • Change "xxx" on line 12 to be "yyy".
  • Add "blah blah" after line 25

Assuming I made my changes in the local source in /tmp/gnomad2-2.9.1 I'll move that somewhere safe, and download another copy of the unmodified source, so I can create a diff and ensure that I've got the change recorded correctly:

skx@gold:/tmp$ mv gnomad2-2.9.1 gnomad2-2.9.1.new
skx@gold:/tmp$ apt-get source gnomad2

Now I have two trees:

  • /tmp/gnomad2-2.9.1.new - My modified, fixed, and updated directory.
  • /tmp/gnomad2-2.9.1 - The current source in Debian's unstable branch.

Creating the patch just means running:

 diff --recursive \
      --ignore-space-change \
      --context \
 gnomad2-2.9.1 gnomad2-2.9.1.new/

This will output the diff to the console. You can save it to a file too by rusing tee:

 diff --recursive \
      --ignore-space-change \
      --context \
 gnomad2-2.9.1 gnomad2-2.9.1.new/  | tee /tmp/patch.diff

If the new directory isn't clean your patch will include things like:

Only in gnomad2-2.9.1.new/src: player.o
Only in gnomad2-2.9.1.new/src: playlists.o
Only in gnomad2-2.9.1.new/src: prefs.o
Only in gnomad2-2.9.1.new/src: tagfile.o
Only in gnomad2-2.9.1.new/src: util.o
Only in gnomad2-2.9.1.new/src: wavfile.o

Just edit those lines out of the diff.

So the next step is to submit that to the bug report. Simply mail "bugnumber@bugs.debian.org" (509288@bugs.debian.org in our example) including your patch in the mail. If all goes well you'll receive an auto-reply after a while.

Finally to make things neat you can manipulate the bug tracker by email by sending a mail :

To: control@bugs.debian.org
Subject: updates

tags 12344 + patch
bored now

Here is one I sent earlier.

This will ensure that the bug is reported as having a patch present in it.

Job done.

In an ideal world the next time the package is uploaded to Debian the bug will be fixed, marked as closed, and the world will be a little happier.

In a non-ideal world your patch will sit in the bug tracker for years with no further comment. If that happens there is not too much you can do, except send reminders by email, or distract yourself with a nice curry.

Happily Debian maintainers really do seem to appreciate bug fixes, and I'd say it is rare that my fixes have been ignored. It happens, but not often enough to make me give up.

ObFilm: Ghostbusters 2



Comments on this entry

icon Anonymous at 18:20 on 23 December 2008
A few suggestions:
With devscripts installed, you could use "bts tags 509288 patch" rather than manually generating a mail. devscripts will also syntax-check for you.
Also, your diff options have some problems. Most developers seem to prefer unified diffs rather than context diffs, and furthermore if you add any new files your options will omit them. You also don't want to ignore whitespace changes. diff -Nur will do the right thing.
Finally, rather than apt-get source you might consider "debcheckout".
icon Steve Kemp at 18:59 on 23 December 2008

Thanks for the comments.

I prefer context diffs, but if people have a different preference reworking that is easy enough. I do find that I need to use "--ignore-space-changes" though - because my editor is configured to remove trailing whitespace on file save - which frequently introduces bogus changes to diffs.

Anyway debcheckout looks neat - so thanks for the hint. I guess it will only work for those packages using version control, but I can see it would be very useful for them.

icon Kumar Appaiah at 19:04 on 23 December 2008
How about adding a changelog entry with a version bump, editing the source in place and running debdiff --exclude changelog? Might save you the trouble of having to save the original source away and having to diff...
Thank for the thoughtful post.
icon tim at 19:21 on 23 December 2008
Thanks Steve. For learn by doing folk, these are great blog entries.
icon Steve Kemp at 19:28 on 23 December 2008

Adding a changelog entry is a good idea for making significant changes, but for a simple bugfix I'd prefer to let the maintainer decide how to describe it.

icon Anonymous at 04:30 on 24 December 2008
@Steve: You just described precisely why I *don't* configure my editor to nuke trailing whitespace. I can always tell my editor to do so explicitly, but I don't want it happening implicitly.
icon Alex at 12:49 on 24 December 2008
@Anonymous: I prefer to nuke trailing whitespace which has led to some "interesting" problems in the past, but a few hitches isn't going to make me stop doing it -- generally it's a Good Thing(TM) so I'm happy to work around it in the *few* cases it causes problems. YMMV.