The Bugzilla migration on Friday went quite well, so we’ve now got all the old Ubuntu bug reports in Launchpad. Before the migration, we were up to bug #6760. Now that the migration is complete, there are more than 28000 bugs in the system. Here are some quick points to help with the transition:

All bugzilla.ubuntu.com accounts were migrated to Launchpad accounts with a few caveats:

If you already had a Launchpad account with your bugzilla email address associated with it, then the existing Launchpad account was used.

If you had a Launchpad account but used a different email to the one on your Bugzilla account, then you now have two Launchpad accounts. You can merge the two accounts at https://launchpad.net/people/+requestmerge.

If you have a bugzilla.ubuntu.com bug number, you can find the corresponding Launchpad bug number with the following URL:

http://launchpad.net/malone/bugtrackers/ubuntu-bugzilla/$BUGZILLA_ID

This will redirect to the Launchpad bug watching that bugzilla bug. This URL can easily be used to make a Firefox keyword bookmark.

You can file bugs on Ubuntu at https://launchpad.net/distros/ubuntu/+filebug. Note that the form expects a source package name rather than a binary package name. If you only have a binary package name, you can use the following command to find the source package name:

apt-cache show $packagename | grep ^Source:

We’ll make it easier to enter bugs when you only know the binary package name in the future.

The Launchpad data model for bugs differs from Bugzilla in that a single bug can be targetted at multiple packages or products (internally, we call these bug tasks). To change information about a bug task (source package name, assignee, status, priority, severity, etc), you must first click on the bug target in the “fix requested in” table at the top of the bug page.

There are still a few issues that need to be ironed out. The mailing lists subscribed to most Ubuntu bugs are not yet properly configured to accept mail from Launchpad, so result in “held for moderation” messages. These issues should get fixed shortly.

The gnome-gpg utility makes PGP a bit nicer to use on Gnome with the following features:

Present a Gnome password entry dialog for passphrase entry.

Allow the user to store the passphrase in the session or permanent keyring, so it can be provided automatically next time.

Unfortunately there are a few usability issues:

The anonymous/authenticated user radio buttons are displayed in the password entry dialog, while they aren’t needed.

The passphrase is prompted for even if gpg does not require it to complete the operation.

If the passphrase is entered incorrectly, the user is not prompted for it again like they would be with plain gpg.

If an incorrect passphrase is provided by gnome-keyring-daemon, you need to remove the item using gnome-keyring-manager or use the --force-passphrase command line argument.

I put together a patch to fix these issues by using gpg‘s --status-fd/--command-fd interface. Since this provides status information to gnome-gpg, it means it knows when to prompt for and send the passphrase, and when it gave the wrong passphrase.

I also swiped the zenity_util_show_dialog() function from Zenity to make the password dialog a transient of the terminal that ran it, so the passphrase dialog stays on the same desktop and can’t be obscured by that terminal.