Tag: Ubuntu

Bugzilla to Malone Migration

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:
    1. If you already had a Launchpad account with your bugzilla email address associated with it, then the existing Launchpad account was used.
    2. No passwords were migrated from Bugzilla, due to differences in the method of storing them. You can set the password on the account at https://launchpad.net/+forgottenpassword.
    3. 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.

Switch users from XScreenSaver

Joao: you can configure XScreenSaver to show a “Switch User” button in it’s password dialog (which calls gdmflexiserver when run). This lets you start a new X session after the screen has locked. This feature is turned on in Ubuntu if you want to try it out.

Of course, this is not a full solution, since it doesn’t help you switch to an existing session (you’d need to guess the correct Ctrl+Alt+Fn combo). There is code in gnome-screensaver to support this though, giving you a list of sessions you can switch to.

Moving from Bugzilla to Launchpad

One of the things that was discussed at UBZ was moving Ubuntu’s bug tracking over to Launchpad. The current situation sees bugs in main being filed in bugzilla while bugs in universe go in Launchpad. Putting all the bugs in Launchpad is an improvement, since users only need to go to one system to file bugs.

I wrote the majority of the conversion script before the conference, but made a few important improvements at the conference after discussions with some of the developers. Since the bug tracking system is probably of interest to people who weren’t at the conf, I’ll outline some of the details of the conversion below:

  • We are only migrating the open bugs — the existing bugzilla will remain available to read those bugs though.
  • Any bugzilla user account associated with an open bug (asignee, reporter, cc, qa contact or commenter) will be imported into Launchpad. If you already have a Launchpad account but use a different email for your bugzilla account, you have the following options:
    1. Add your bugzilla email to your Launchpad account.
    2. In bugzilla, change your email to one of the addresses registered to your Launchpad account.
    3. After the migration, merge the extra account into your existing account.

    Note that passwords are not migrated, because Launchpad uses a different password hashing algorithm to Bugzilla

  • All comments and attachments are imported.
  • Bugs are filed against the appropriate package under the “Ubuntu” distribution in Launchpad.
  • A bug watch is created, pointing at the original Bugzilla bug, so you can see any information not migrated.
  • If the bug was marked UPSTREAM and a bug tracker URL is included in the bugzilla URL field, then we attempt to create a bug task against the upstream product and link it to the remote bug. This depends on the upstream product existing and being linked to the package, so doesn’t always succeed. This feature was implemented to keep Sebastien happy, 68% of the UPSTREAM bugs are assigned to him.
  • Some of the bugzilla bugs are actually imported from debbugs. For these bugs, a bug task will be filed against Debian linked to the appropriate debbugs bug.

There are a few other things that need completing on the production Launchpad server before we can do the migration, but we should have a test import done on the staging server tomorrow some time.

Avahi on Breezy followup

So after I posted some instructions for setting up Avahi on Breezy, a fair number of people at UBZ did so. For most people this worked fine, but it seems that a few people’s systems started spewing a lot of network traffic.

It turns out that the problem was actually caused by the zeroconf package (which I did not suggest installing) rather than Avahi. The zeroconf package is not needed for service discovery or .local name lookup, so if you are at UBZ you should remove the package or suffer the wrath of Elmo.

Avahi on Breezy

During conferences, it is often useful to be able to connect to connect to other people’s machines (e.g. for collaborative editing sessions with Gobby). This is a place where mDNS hostname resolution can come in handy, so you don’t need to remember IP addresses.

This is quite easy to set up on Breezy:

  • Install the avahi-daemon, avahi-utils and libnss-mdns packages from universe.
  • Restart dbus in order for the new system bus security policies to take effect with “sudo invoke-rc.d dbus restart“.
  • Start avahi-daemon with “sudo invoke-rc.d avahi-daemon start“.
  • Edit /etc/nsswitch.conf, and add “mdns” to the end of the “hosts:” line.

Now your hostname should be advertised to the local network, and you can connect to other hosts by name (of the form hostname.local). You can also get a list of the currently advertised hosts and services with the avahi-discover program.

While the hostname advertising is useful in itself, it should get a lot more useful in Dapper, as more programs are built with mDNS support.

Ubuntu Below Zero

I’ve been in Montreal since Wednesday for Ubuntu Below Zero.

As well as being my first time in Canada, it was my first time in transit through the USA. Unlike in most countries, I needed to pass through customs and get a visa waiver even though I was in transit. The visa waiver form had some pretty weird questions, such as whether I was involved in persecutions associated with Nazi Germany or its allies.

I am getting up to speed with Bazaar NG, which looks like it should solve some of the scalability problems in bazaar. The main Launchpad tree had more than 600 branches merged in, comprising about 15,000 revisions). The equivalent bzr tree is significantly smaller, and contains the full revision history for the line of development. As well as the performance improvements, the tool feels a lot nicer to use.

DSB-R100 USB Radio Tuner

Picked up a DSB-R100 USB Radio tuner off EBay recently. I did this partly because I have better speakers on my computer than on the radio in that room, and partly because I wanted to play around with timed recordings.

Setting it up was trivial — the dsbr100 driver got loaded automatically, and a program to tune the radio (gnomeradio) was available in the Ubuntu universe repository. I did need to change the radio device from /dev/radio to /dev/radio0 though.

One of the issues with the gnomeradio is the UI for tuning the radio. The following controls in the main window are used for this purpose:

  1. The slider on the left hand side of the window.
  2. The rewind and fast forward buttons (which are actually scan forward and backward).
  3. The track backward and forward buttons (which actually move back or forward by 0.05MHz).
  4. The presets option menu (which is initially empty).

What you can’t do from the main window is type in a frequency with the keyboard. You can type in frequencies directly when entering presets though, which is nice. These controls could probably be reduced to just an entry field for the frequency (possibly a spin button), and the presets option menu. The scanning feature seems most useful in setting up the presets: create a preset for each radio station that can be tuned and be done with it.

There are a few other small complaints:

  • The button for turning the radio on or off (the button with a speaker on it) doesn’t change appearance like most other mute controls.
  • The recording feature doesn’t use GStreamer. It’d be nice if it offered the same audio profiles for recording as Sound Juicer and other apps.
  • The input selection and volume control should probably also use GStreamer, so that they can work with the ALSA mixer.

I haven’t yet looked into software for doing timed recordings. Other people have though, so I could probably use those scripts as a base.