This morning I created maverick chroots for the Apport retracers, and they are currently processing the backlog. I also uploaded a new Apport package which now enables crash reporting by default again.

Happy segfaulting!

So for now I committed a manually adjusted vapi for gudev. This now makes it easy to write code that queries and listens to udev in Vala.

Small example:

using GUdev;

void
print_device(GUdev.Device d)
{
    stdout.printf("%s → %s\n", d.get_device_file(), d.get_sysfs_path());
    foreach (string s in d.get_device_file_symlinks())
        stdout.printf("  link: %s\n", s);
}

void
on_uevent(GUdev.Client client, string action, GUdev.Device dev)
{
    stdout.printf("[%s] ", action);
    print_device(dev);
}

int main(string[] args)
{
    var uc = new GUdev.Client({"usb"});

    print_device(uc.query_by_device_file(args[1]));

    stdout.printf("---- all block devices ---\n");
    GLib.List devs = uc.query_by_subsystem("block");
    foreach (GUdev.Device d in devs)
        print_device(d);

    stdout.printf("---- usb events ---\n");
    uc.uevent.connect(on_uevent);
    new GLib.MainLoop().run();
    return 0;
}

Build with valac --pkg gudev-1.0 udev.vala, and perhaps specify --vapidir if you keep the gudev-1.0.vapi file somewhere locally.

Update: I reverted the commit upstream for now, since Vala 0.8 already ships a gudev vapi. I must have overlooked that when I played with vapigen.. In the long run it’s probably better to generate vapis in the projects themselves to avoid API skew, but as long as the vapi can’t be generated automatically it does not make sense to have it in udev. Above code was updated for the vala provided one (which is lacking a return type specification for query_by_subsystem()).

The actual commit is rather dull though, it’s just the release/upload tag for version 107 which I just uploaded to Debian unstable (it will hit Ubuntu maverick and backports soon). 107 introduces support for PostgreSQL 9.0, and I fixed up the scripts and tests enough so that all the tests pass now, and thus it’s good for public release.

I also uploaded the 9.0 beta 1 server itself now. It’ll be in Debian’s NEW queue for a bit, and hit experimental in a few days (or hours; recently the ftpmasters have been awesome!) It has a few cool new features (see the announcement), and upstream really appreciates testing and feedback. So, bug reports appreciated!

In particular, if you have existing 8.4 clusters you can just try to pg_upgradecluster them to 9.0 beta 1. Remember, if anything goes wrong, the cluster of the previous version is still intact and untouched, so you can run upgrades as many times as you like and only pg_dropcluster the old one when you’re completely satisfied with the upgrade.

So from now on you are strongly encouraged to report sound problems with

$ ubuntu-bug audio

instead of trying to guess the package right.

With my new powers, I fixed a crash in gdm, and applied two stragglers into gvfs’ build system today.

More to come!

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.

Yesterday I dropped the superfluous hal dependency from gparted, today I uploaded gdm to stop using hal for getting the keyboard layout and use libxklavier instead.

I also applied Julian Cristau’s udevified X.org branch to our xorg-edgers packages into my halsectomy PPA, created some udev rules for udev-based X.org input detection ([1], [2]), and off we go: that was the last hal reverse dependency. My system now fully boots and works without hal.

Hooray!

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.

As discussed at UDS Barcelona, Apport will grow this functionality in Karmic. A first preview is available in my PPA. The GUI looks horrible, but the API for hooks won’t change any more, so you can now begin to develop your interactive hooks.

Example:

import apport.hookutils

def add_info(report, ui):
    apport.hookutils.attach_alsa(report)

    ui.information('Now playing test sound...')

    report['AplayOut'] = apport.hookutils.command_output(['aplay',
            '/usr/share/sounds/question.wav'])

    response = ui.yesno('Did you hear the sound?')
    if response == None: # user cancelled
        raise StopIteration
    report['SoundAudible'] = str(response)

Please see the package-hooks.txt documentation for details.

I implemented all currently existing UI functions (information, yes/no question, file selector, multiple choice dialog) for GTK and CLI, and all except the multiple choice dialog for Qt. Anyone willing to hack on an implementation of ui_question_choice() similar to what the GTK frontend is doing?

Update:I merged Richard Johnson’s branch (thanks!) and uploaded a new package into my PPA. apport-qt is now fully functional.

I started a discussion with upstream about how to migrate the libgphoto bits away from hal to udev rules. It shoulnd’t actually be hard to do, and I’m keen on working on it, but it needs agreement between the libgphoto, udev-extras, and gvfs/KDE upstreams, so some coordination work is in order.

I also created a wiki page of the current migration status. Please edit if I forgot something. If you feel inclined to work on a particular bit, the Linux world will heavily appreciate this! It’s still a major Karmic goal to push the transition as far as possible, to avoid intrusive system changes for Ubuntu 10.04 (which is likely to become an LTS).