One useful feature of Bazaar is the ability to cryptographically sign revisions. I was discussing this with Ryan on IRC, and thought I'd write up some of the details as they might be useful to others.

Anyone who remembers the past security of GNOME and Debian servers should be able to understand the benefits of being able to verify the integrity of a source code repository after such an incident. Rather than requiring all revisions made since the last known safe backup to be examined, much of the verification could be done mechanically.

When Storm was released, one of the comments made was that it did not include the ability to generate a database schema from the Python classes used to represent the tables while this feature is available in a number of competing ORMs. The simple reason for this is that we haven't used schema generation in any of our ORM-using projects.

Furthermore I'd argue that schema generation is not really appropriate for long lived projects where the data stored in the database is important. Imagine developing an application along these lines:

I got round to upgrading my desktop system to Gutsy today. I'd upgraded my laptop the previous week, so was not expecting much in the way of problems.

I'd done the original install on my desktop back in the Warty days, and the root partition was a bit too small to perform the upgrade. As there was a fair bit of accumulated crud, I decided to do a clean install. Things mostly worked, but there were a few problems, which I detail below:

When I got back from Florida, I found a copy of the Manic Times in the mail. It seems that I received the copy because I used to be subscribed to The Chaser back when it was a newspaper. The newspaper is being edited by Charles Firth, who was the US correspondent in the last series of The Chaser's War on Everything.

The content is fairly different to what was published in The Chaser, in that they are nominally true. That said, they are written from a non-mainstream point of view. The issue I received seemed to focus on the recent APEC conference and related security measures (which appear to have been fairly poor).

This week I am in Florida for a Launchpad sprint. I was meant to arrive on Sunday night, but I fell asleep in the boarding lounge and missed the San Francisco → Orlando flight (the flight out of Perth was an early morning one, and I didn't get enough sleep on the plane). The earliest alternative fligh was the same time the next day, so I ended up ariving on Monday night.

The new Canonical Shop was opened recently which allows you to buy anything from Ubuntu tshirts and DVDs up to a 24/7 support contract for your server.

One thing to note is that this is the first site using our new Launchpad single sign-on infrastructure. We will be rolling this out to other sites in time, which should give a better user experience to the existing shared authentication system currently in place for the wikis.

In my previous article, I outlined Bazaar's bundle feature. This article describes how the Bazaar developers use bundles as part of their development and code review process.

Proposed changes to Bazaar are generally posted as patches or bundles to the development mailing list. Each change is discussed on the mailing list (often going through a number of iterations), and ultimately approved or rejected by the core developers. To aide in managing these patches Aaron Bentley (one of the developers wrote a tool called Bundle Buggy.

This article follows on from the series of tutorials on using Bazaar that I have neglected for a while. This article is about the bundle feature of Bazaar. Bundles are to Bazaar branches what patches are to tarballs or plain source trees.

Context/unified diffs and the patch utility are arguably one of most important inventions that enable distributed development:

• The patch is a self contained text file, making it easy to send as an email attachment or attach to a bug report.
• The size of the patch is proportional to the size of the changes rather than the size of the source tree. So submitting a one line fix to the Linux kernel is as easy as a one line fix for a small one person project.
• Even if the destination source tree has moved forward since the patch was created, the patch utility does a decent job of applying the changes using heuristics to match the surrounding context. Human intervention is only needed if the edits are to the same section of code.
• As patches are human readable text files, they are a convenient form to review the code changes.

Of course, patches do have their limitations:

This week at the EuroPython conference, Gustavo Niemeyer announced the release of Storm and gave a tutorial on using it.

Storm is a new object relational mapper for Python that was developed for use in some Canonical projects, and we've been working on moving Launchpad over to it. I'll discuss a few of the nice features of the package:

Loose Binding Between Database Connections and Classes

Storm has a much looser binding between database connections and the classes used to represent records in particular tables. The standard way of querying the database uses a store object:

It hasn't been long since the last gnome-vfs-obexftp release, but I thought it'd be good to get these fixes out before undertaking more invasive development. The new version is available from:

http://download.gnome.org/sources/gnome-vfs-obexftp/0.4/

The highlights of this release are:

• If the phone does not provide free space values in the OBEX capability object, do not report this as zero free space. This fixes Nautilus file copy behaviour on a number of Sony Ericsson phones.
• Fix date parsing when the phone returns UTC timestamps in the folder listings.
• Add some tests for the capability object and folder listing XML parsers. Currently has sample data for Nokia 6230, Motorola KRZR K1, and Sony K800i, Z530i and Z710i phones.

These fixes should improve the user experience for owners of some Sony Ericsson phones by letting them copy files to the phone, rather than Nautilus just telling them that there is no free space. Unfortunately, if there isn't enough free space you'll get an error part way through the copy. This is the best that can be done with the information provided by the phone.

I've had a number of requests for USB support in gnome-vfs-obexftp. At first I didn't have much luck talking to my phone via USB. Running the obex_test utility from OpenOBEX gave the following results:

$ obex_test -u
Using USB transport, querying available interfaces
Interface 0:   (null)
Interface 1:   (null)
Interface 2:   (null)
Use 'obex_test -u interface_number' to run interactive OBEX test client

Trying to talk via any of these interface numbers failed. After reading up a bit, it turned out that I needed to add a udev rule to give permissions on my phone. After doing so, I got a better result:

Havoc: for a lot of services advertised via mDNS, the client doesn't have the option of ignoring TXT records if it wants to behave correctly.

For example, the Bonjour Printing Specification puts the underlying print queue name in a TXT record (as multiple printers might be advertised by a single print server). While it says that the server can omit the queue name (in which case the default queue name "auto" is used), a client is not going to be able to do what the user asked without checking for the presence of the record.

I've just released a new version of gnome-vfs-obexftp, which includes the features discussed previously. It can be downloaded from:

http://download.gnome.org/sources/gnome-vfs-obexftp/0.3/

The highlights of the release include:

• Sync osso-gwobex and osso-gnome-vfs-extras changes from Maemo Subversion.
• Instead of asking hcid to set up the RFCOMM device for communication, use an RFCOMM socket directly. This is both faster and doesn't require enabling experimental hcid interfaces. Based on work from Bastien Nocera.
• Improve free space calculation for Nokia phones with multiple memory types (e.g. phone memory and a memory card). Now the free space for the correct memory type for a given directory should be returned. This fixes various free-space dependent operations in Nautilus such as copying files.

Any bug reports should be filed in Launchpad at:

Recently, Bastien has been doing a bit of hacking on gnome-vfs-obexftp. The changes remove the use of the org.bluez.RFCOMM interface to hcid, instead doing SDP and createing RFCOMM sockets directly. This removes the need to run hcid with its experimental interfaces enabled. This is also good because the org.bluez.RFCOMM interface has been removed in newer releases (replaced by org.bluez.serial.Manager).

I've now integrated that patch and made a number of further clean ups so that we don't need any D-Bus requests to establish the connection to the remote device. Now the only D-Bus requests being made are for device enumeration used for the "obex:///" virtual folder. Should make it easier to switch over to HAL if/when it supports scanning for Bluetooth devices.

I recently received a bug report about the free space calculation in gnome-vfs-obexftp. At the moment, the code exposes a single free space value for the OBEX connection. However, some phones expose multiple volumes via the virtual file system presented via OBEX.

It turns out my own phone does this, which was useful for testing. The Nokia 6230 can store things on the phone’s memory (named DEV in the OBEX capabilities list), or the Multimedia Card (named MMC). So the fix would be to show the DEV free space when browsing folders on DEV and the MMC free space when browsing folders on MMC.

Previously, I posted about the FM radio plugin I was working on. I just posted the code to bug 168735. A few notes about the implementation:

• The code only supports Video4Linux 2 radio tuners (since that’s the interface my device supports, and the V4L1 compatibility layer doesn’t work for it). It should be possible to port it support both protocols if someone is interested.
• It does not pass the audio through the GStreamer pipeline. Instead, you need to configure your mixer settings to pass the audio through (e.g. unmute the Line-in source and set the volume appropriately). It plugs in a GStreamer source that generates silence to work with the rest of the Rhythmbox infrastructure. This does mean that the volume control and visualisations won’t work
• No properties dialog yet. If you want to set titles on the stations, you’ll need to edit rhythmdb.xml directly at the moment.
• The code assumes that the radio device is /dev/radio0.

Other than that, it all works quite well (I've been using it for the last few weeks).

I've been working on some FM radio support in Rhythmbox in my spare time. Below is screenshot

At the moment, the basic tuning and mute/unmute works fine with my DSB-R100. I don't have any UI for adding/removing stations at the moment though, so it is necessary to edit ~/.gnome2/rhythmbox/rhythmdb.xml to add them.

---

Comments:

Joel - 4 May, 2007

This feature would truly be a welcome addition!

I'm especially pleased it's being developed by a fellow Australian! (If the radio stations are any indication)

I upgraded to Feisty about a month or so ago, and it has been a nice improvement so far. One regression I noticed though was that my USB FM radio tuner had stopped working (or at least, Gnomeradio could no longer tune it).

It turns out that some time between the kernel release found in Edgy and the one found in Feisty, the dsbr100 driver had been upgraded from the Video4Linux 1 API to Video4Linux 2. Now the driver nominally supports the V4L1 ioctls through the v4l1_compat, but it doesn't seem to implement enough V4L2 ioctls to make it usable (the VIDIOCGAUDIO ioctl fails).

Today we unveiled the Launchpad 1.0 User Interface, which has been in private beta for the last few months. As well as the improved visual appearance, there are a number of new features such as the ability to add your own branding to Launchpad pages associated with your project (for example, Ubuntu's pages).

As mentioned in the press release, we've got two new high profile projects using us for bug tracking: The Zope 3 Project and The Silva Content Management System. As part of their migration, we imported all their old bug reports (for Zope 3, and for Silva). This was done using the same import process that we used for the SchoolTool import. Getting this process documented so that other projects can more easily switch to Launchpad is still on my todo list.

When at conferences and sprints, I often want to see what someone else is working on, or to let other people see what I am working on. Usually we end up pushing up to a shared server and using that as a way to exchange branches. However, this can be quite frustrating when competing for outside bandwidth when at a conference.

It is possible to share the branch from a local web server, but that still means you need to work out the addressing issues.

Recently, the SchoolTool project has migrated to Launchpad for their bug tracker.

We performed an import of all their previous bug reports using a new bug importer I wrote. This was the third Launchpad bug importer I'd written (the previous ones being for the Ubuntu Bugzilla import and a SourceForge importer), so I wanted this one to be the last. So the design of this importer was to have a simple XML format as an intermediate step. That way we only need to target the XML format to support a new bug tracker. This will also make it possible for projects to provide their bug data in a form we can consume for the cases where they want to migrate their bugs to Launchpad but Canonical doesn't have the resources to do the migration.

One of the books I read over the holidays was American Hoax by Charles Firth. This book is apparently what he was working on while the rest of the Chaser guys were doing The Chaser's War on Everything.

The book is an exploration of different aspects of U.S. politics from an outsider's perspective. Of course, it is a bit difficult to get a good view of the different political movements from the outside, so he creates a number of characters representing different points on the political spectrum as a way to become part of the various movements. Each of these characters was given a suitable back story, including Wikipedia articles for some and websites for others.

I put out a tarball release of gnome-vfs-obexftp here:

http://download.gnome.org/sources/gnome-vfs-obexftp/0.1/

This includes a number of fixes since the work I did in October:

• Fix up some error handling in the dbus code.
• Mark files under the obex:/// virtual root as being local. This causes Nautilus to process the desktop entries and give us nice icons.
• Ship a copy of osso-gwobex, built statically into the VFS module. This removes the need to install another shared library only used by one application.

As well as the standard Gnome and D-BUS libraries, you will need OpenOBEX >= 1.2 and Bluez-Utils >= 3.7. The hcid daemon must be started with the -x flag to enable the experimental D-BUS interfaces used by the VFS module. You will also need a phone or other device that supports OBEX FTP :)

While browsing the log of one of my Bazaar branches, I noticed that the commit messages were being recorded as occurring in the +0800 time zone even though WA switched over to daylight savings.

Bazaar stores commit dates as a standard UNIX seconds since epoch value and a time zone offset in seconds. So the problem was with the way that time zone offset was recorded. The code in bzrlib that calculates the offset looks like this:

In my previous entry, I mentioned that Andrew was actually publishing the contents of all his Bazaar branches with his rsync script, even though he was only advertising a single branch. Yesterday I had a need to actually do this, so I thought I'd detail how to do it.

As a refresher, a Bazaar repository stores the revision graph for the ancestry of all the branches stored inside it. A branch is essentially just a pointer to the head revision of a particular line of development. So if the branch has been deleted but the data is still in the repository, recovering it is a simple matter of discovering the identifier for the head revision.