Canonical Voices

Posts tagged with 'script'


Apport has provided built-in support for automatically identifying and marking duplicate bug reports for normal signal as well as Python crashes. However, we have more kinds of bug reports submitted through Apport which could benefit from automatic duplication: GPU freezes, package installation failures, kernel oopses, or gcc internal compiler errors, i. e. pretty much everything that gets reported automatically these days.

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])


    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 graphics driver for GPU hangs!

Read more

A common source of unnoticed depwaits or uninstallability are main packages which introduce new build or binary dependencies from universe. These either require fixing, or filing a main inclusion report.

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 if this source package needs to get into in main/restricted, or reconsider if the package really needs above dependencies.

Read more

These days I often use launchpadlib in my projects for scripting access/modifications in Launchpad. While launchpadlib has quite a good API documentation, this only covers the method calls, not the attributes or collections. So it often takes some poking and trying until you figure out how to access/change things.

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.

Read more

I often do upstream releases of my upstream projects that I do on Launchpad, mostly for Apport and jockey. But doing this has been quite tedious until now: You have to go to the project page, pick the series (usually “trunk”), create a new release, create a new milestone along the way, then go to “add download file”, and upload your .tar.gz and .tar.gz.asc.

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.

Read more