Back from Dunedin

Last week I was in sunny Dunedin for a Launchpad/Bazaar integration sprint with Tim and Jonathan. Some of the smaller issues we addressed should make their way to users in the next Launchpad release (these were mainly fixes to confusing error messages on bazaar.launchpad.net). Some of the others will probably only become available a release or two further on (mostly related to improving development workflow for branches hosted on Launchpad). My previous trip to New Zealand had also been to Dunedin (for last year's linux.conf.au). Since then they'd replaced all the coins for denominations less than NZ$1. Other than being less familiar to Australians, the smaller coins seem like a good idea. They don't seem to have taken Australia's lead in making the $2 coin smaller than the $1 coin though.

Google’s Australian Election Tools

It is probably old news to some, but Google have put up an information page on the upcoming Australian Federal Election. The most useful tool is the Google Maps overlay that provides information about the different electorates. At the moment it only has information about the sitting members, their margin and links to relevant news articles. Presumably more information will become available once the election actually gets called. Presumably they are planning on offering similar tools for next year's US elections and this is a beta. So even if you aren't interested in Australian politics, it might be worth a peak to see what is provided.

Signed Revisions with Bazaar

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. Turning on Revision Signing The first thing you'll need to do is get a PGP key and configure GnuPG to use it. The GnuPG handbook is a good reference on doing this. As the aim is to provide some assurance that the revisions you publish were really made by you, it'd be good to get the key signed by someone. Once that is done, it is necessary to configure Bazaar to sign new revisions. The easiest way to do this is to edit ~/.bazaar/bazaar.conf to look something like this: [DEFAULT] email = My Name <me@example.com> create_signatures = always Now when you run "bzr commit", a signature for the new revision will be stored in the repository. With this configuration change, you will be prompted for your pass phrase when making commits. If you'd prefer not to enter it repeatedly, there are a few options available: install gpg-agent, and use it to remember your pass phrase in the same way you use ssh-agent. install the gnome-gpg wrapper, which lets you remember your pass phrase in your Gnome keyring. To use gnome-gpg, you will need to add an additional configuration value: "gpg_signing_command = gnome-gpg". Signatures are transferred along with revisions when you push or pull a branch, perform merges, etc. How Does It Work? So what does the signature look like, and what does it cover? There is no command for printing out the signatures, but we can access them using bzrlib. As an example, lets look at the signature on the head revision of one of my branches: >>> from bzrlib.branch import Branch >>> b = Branch.open('http://bazaar.launchpad.net/~jamesh/storm/reconnect') >>> b.last_revision() 'james.henstridge@canonical.com-20070920110018-8e88x25tfr8fx3f0' >>> print b.repository.get_signature_text(b.last_revision()) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bazaar-ng testament short form 1 revision-id: james.henstridge@canonical.com-20070920110018-8e88x25tfr8fx3f0 sha1: 467b78c3f8bfe76b222e06c71a8f07fc376e0d7b -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG8lMHAa+T2ZHPo00RAsqjAJ91urHiIcu4Bim7y1tc5WtR+NjvlACgtmdM 9IC0rtNqZQcZ+GRJOYdnYpA= =IONs -----END PGP SIGNATURE----- >>> If we save this signature to a file, we can verify it with a command like "gpg --verify signature.txt" to prove that it was made using my PGP key. Looking at the signed text, we see three lines: An identifier for the checksum algorithm. This is included to future proof old signatures should the need arise to alter the checksum algorithm at a later date. The revision ID that the signature applies to. Note that this is the full globally unique identifier rather than the shorter numeric identifiers that are only unique in the context of an individual branch. The checksum, in SHA1 form. For the…

Schema Generation in ORMs

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: Write the initial version of the application. Generate a schema from the code. Deploy one or more instances of the application in production, and accumulate some data. Do further development on the application, that involves modifications to the schema. Deploy the new version of the application. In order to perform step 5, it will be necessary to modify the existing database to match the new schema. These changes might be in a number of forms, including: adding or removing a table adding or removing a column from a table changing the way data is represented in a particular column refactoring one table into two related tables or vice versa adding or removing an index Assuming that you want to keep the existing data, it isn't enough to simply represent the new schema in the updated application: we need to know how that new schema relates to the old one in order to migrate the existing data. For some changes like addition of tables, it is pretty easy to update the schema given knowledge of the new schema. For others it is more difficult, and will often require custom migration logic. So it is likely that you will need to write a custom script to migrate the schema and data. Now we have two methods of building the database schema for the application: generate a schema from the new version of the application. generate a schema from the old version of the application, then run the migration script. Are you sure that the two methods will result in the same schema? How about if we iterate the process another 10 times or so? As a related question, are you sure that the database environment your tests are running under match the production environment? The approach we settled on with Launchpad development was to only deal with migration scripts and not generate schemas from the code. The migration scripts are formulated as a sequence of SQL commands to migrate the schema and data as needed. So to set up a new instance, a base schema is loaded then patched up to the current schema. Each patch leaves a record in the database that it has been applied so it is trivial to bring a database up to date, or check that an application is in sync with the database. When the schema is not generated from the code, it also means that the code can be simpler. As far as Python ORM…

Upgrading to Ubuntu Gutsy

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: Dual Head Configuration With previous releases, I was using the Radeon driver's MergedFB mode, as it gives a better user experience than the traditional Xinerama code (3D acceleration on both heads, better performance, etc). After moving adding the MergedFB options to xorg.conf, I was just getting the same image cloned on both displays. Looking at the X server log file, there was a message saying that MergedFB support had been removed in favour of RandR 1.2 support. And it was possible to get dual head working with the xrandr command line tool: xrandr --output VGA-0 --right-of DVI-0 It was good to know that dual-head still worked, but I didn't want to reconfigure this every time I restarted the machine. I didn't find much information on how to configure the initial RandR configuration on the X.org website, but did find a useful guide on the Intel Linux Graphics website. While the guide was aimed at the Intel driver, it had enough information to get things configured for the Radeon driver. The main difference was in the naming of the outputs. Below is a an excerpt of my configuration file that configures things the way I had them previously: Section "Device" Identifier "ATI Technologies Inc RV280 [Radeon 9200 SE]" Driver "ati" BusID "PCI:1:0:0" Option "monitor-DVI-0" "Sony SDM-S74 [1]" Option "monitor-VGA-0" "Sony SDM-S74 [2]" EndSection Section "Monitor" Identifier "Sony SDM-S74 [1]" Option "DPMS" HorizSync 30-65 VertRefresh 50-75 Option "LeftOf" "Sony SDM-S74 [2]" EndSection Section "Monitor" Identifier "Sony SDM-S74 [2]" Option "DPMS" HorizSync 30-65 VertRefresh 50-75 EndSection Section "Screen" Identifier "Default Screen" Device "ATI Technologies Inc RV280 [Radeon 9200 SE]" Monitor "Sony SDM-S74 [1]" DefaultDepth 16 SubSection "Display" Modes "1280x1024" "1024x768" "800x600" "640x480" Virtual 2560 1024 EndSubSection EndSection I had originally tried setting the VGA monitor to be "RightOf" the monitor connected to the DVI, but that left me with the desktop in clone mode. The main difference I've noticed with this configuration compared to my previous one is that the GDM login prompt displays on the right hand head (VGA) rather than the left hand head (DVI). Window Shadows Don't Render Desktop Effects were enabled by default after the install (and on the live CD). While some effects seemed to work, the shadows on the panel and drop down menus were rendered as opaque grey boxes around the windows. I ended up just disabling the effects to clear up the problem. This bug had already been reported as bug 141304 (which may be the same as bug 116808). Firefox Crashes…