The latest Apport 1.20 (which also just hit current Ubuntu Natty) now allows package hooks to set a special field DuplicateSignature, which abstracts the concept for other kinds of bug reports where Apport doesn’t do automatic duplication. This field should both uniquely identify the problem class (e. g. “XorgGPUFreeze”) as well as the particular problem, i. e. variables which tell this instance apart from different problems. Aside from these requirements, the value can be any free-form string, Apport only treats it as an opaque value. It doesn’t even need to be ASCII only or only be one line, but for better human inspection I recommend this.

So your report could do something like

   report['DuplicateSignature'] = 'XorgGPUFreeze: instruction %s regs:%s:%s:%s' % (
                     current_instruction, regs[0], regs[1], regs[2])

or

    report['DuplicateSignature'] = 'PackageFailure: ' + log.splitlines()[-1]

This is integrated into Apport’s already existing CrashDatabase class, which maintains a signature →master bug mapping in a SQLite database. So far these contained the crash signatures (built from executable name, signal number, and the topmost 5 stack trace names). As usual, if an incoming report defines a duplicate signature (from the crash stack trace or from DuplicateSignature), the first one will become the master bug, and all subsequent reports will automatically get closed as a duplicate in Launchpad.

Thanks to Bryce Harrington, who already came up with using this in the latest Intel X.org graphics driver for GPU hangs!

To help with this, I added a new check-mir script into ubuntu-dev-tools version 0.110, which walks through all build and binary dependencies, checks if they are in main/restricted, also considers alternative dependencies, and create a report with a few hints.

For a main package where everything is alright, it looks like this:

$ check-mir
Checking support status of build dependencies...

Checking support status of binary dependencies...
All dependencies are supported in main or restricted.

Example output for a totally synthetic situation with universe dependencies, non-preferred alternatives in main, and other special cases:

Checking support status of build dependencies...
 * pmount binary and source package is in universe
  ... alternative libexif-dev is already in main; consider preferring it
 * weechat binary and source package is in universe
 * sendmail-bin is in universe, but its source sendmail is already in main; file an ubuntu-archive bug for promoting the current preferred alternative

Checking support status of binary dependencies...
 * wesnot does not exist (pure virtual?)
 * wesnoth binary and source package is in universe

Please check https://wiki.ubuntu.com/MainInclusionProcess if this source package needs to get into in main/restricted, or reconsider if the package really needs above dependencies.

I found myself typing the same things over and over, so I finally wrote a little script called lpshell:

#!/usr/bin/python -i
import code, os, sys
from launchpadlib.launchpad import Launchpad, STAGING_SERVICE_ROOT, EDGE_SERVICE_ROOT
lp = Launchpad.login_with('test', STAGING_SERVICE_ROOT)

This logs into Launchpad and gives you an interactive Python shell with an “lp” object:

$ lpshell
>>> lp.bugs[439482].duplicate_of

Update: I committed this to ubuntu-dev-tools now, renamed to lp-shell for consistency with the other lp-* commands.

Because this is rather inconvenient, I don’t do as many upstream releases as I should. But thanks to our tireless launchpadlib developers it is now possible to automate all that, so I wrote a new script lp-project-upload which does all that in a simple command:

  $ lp-project-upload apport 1.8.2 apport-1.8.2.tar.gz
  Release 1.8.2 could not be found for project. Create it? (Y/n) y
 

The script is based on Brad Crittenden’s recipe for uploading project files, and I added the creation of milestones and releases.

The script is contained in current Karmic’s ubuntu-dev-tools package now. Enjoy, and of course feel free to extend it for changelogs, release notes, etc.

This finally allows you to reliably test a new bug pattern before you actually
commit/push it. You can invoke it with either a .crash file, or a Launchpad bug
number:


$ ./test-local 122988
Matched bug pattern: https://launchpad.net/bugs/122637
$ ./test-local /var/crash/_bin_bash.1000.crash
No match


I wondered how to present this. The commands and features I wanted to show are quite complex, and typing all of them during the presentation is too cumbersome. Besides, I’m just a lousy typer when someone else is watching. On the other hand, pasting them into classical slides is too static; I find it much easier to understand something that reveals itself step by step.

So what I needed is to prepare the chain of commands in advance, and then send them through an interactive “step by step” interpreter. A quick apt-cache search did not reveal any readymade solution, thus I hacked together a small script “shellpresent” which does exactly that:

• a line with a command gets echoed, then it waits for a keypress, then runs the command and waits for another keypress (so that you can explain the output)
• a comment line starting with # is printed in green, and doesn’t wait for a keypress
• a blank line clears the screen
• commands are prepended by a red “$” sign to indicate a command prompt

It now does exactly what I want. Perhaps it is useful for someone else out there as well.