Artikel getaggt mit script

New Apport feature: custom bug duplicate identification

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: X.org 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])

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!

Tags: , , , , , ,

New tool to check support status of dependencies

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 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.

Tags: , , , ,

lpshell – convenient launchpadlib script

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.

Tags: , , , ,

Automated release tarball upload to Launchpad

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.

Tags: , , , , ,

Easier testing for Apport bug patterns

This morning I added a test script to the Apport bug patterns.

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

Tags: , , , ,

Presentations of shell commands

Today I was sitting in the plane from Dresden to San Francisco, and worked on my DKMS demo for the Linux Foundation summit. DKMS is a command line tool for managing device driver packages.

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.

Tags: , ,