Chilli Beer

Got around to tasting the latest batch of home-brew beer recently: a chilli beer. It came out very nicely: very refreshing but with a chilli aftertaste in the back of your throat. You can definitely taste the chilli after drinking a pint :).

I used a beer kit as a base, since I haven’t yet had the patience to do a brew from scratch. The ingredients were:

  1. A Black Rock Mexican Lager beer kit.
  2. 1kg of Coopers brewing sugar.
  3. About 20 red chillis.
  4. Caster sugar for carbonation.

I took half the chillis and cut off the stems and cut them up roughly (in hind sight, it probably would have been enough to cut them lengthwise). I then covered them with a small amount of water in a pot and pasteurised them in the oven at 80°C for about half an hour. The wort was then prepared as normal, but with the pasteurised chillis added before the yeast.

After the fermentation was complete (about a week later), I cut up the remaining chillis (a fair bit smaller this time – they need to easily fit through the neck of a bottle) and pasteurised them the same way as the first batch. This lot was added to the bottles along with the priming sugar.

The beer tasted pretty good 4 weeks after bottling, and it should improve further with time.

UTC+9

Daylight saving started yesterday: the first time since 1991/1992 summer for Western Australia. The legislation finally passed the upper house on 21st November (12 days before the transition date). The updated tzdata packages were released on 27th November (6 days before the transition). So far, there hasn’t been an updated package released for Ubuntu (see bug 72125).

One thing brought up in the Launchpad bug was that not all applications used the system /usr/share/zoneinfo time zone database. So other places that might need updating include:

  • Evolution has a database in /usr/share/evolution-data-server-$version/zoneinfo/ that is in iCalendar VTIMEZONE format.
  • Java has a database in /usr/lib/jvm/java-$version/jre/lib/zi. This uses a different binary file format.
  • pytz (used by Zope 3 and Launchpad among others) has a database consisting of generated Python source files for its database.

All the above rules time zone databases are based on the same source time zone information, but need to be updated individually and in different ways.

In a way, this is similar to the zlib security problems from a few years back: the same problem duplicated in many packages and needing to be fixed over and over again. Perhaps the solution is the same too: get rid of the duplication so that in future only one package needs updating.

As a start, I put together a patch to pytz so that it uses the same format binary time zone files as found in /usr/share/zoneinfo (bug 71227). This still means it has its own time zone database, but it goes a long way towards being able to share the system time zone database. It’d be nice if the other applications and libraries with their own databases could make similar changes.

For people using Windows, there is an update from Microsoft. Apparently you need to install one update now, and then a second update next year — I guess Windows doesn’t support multiple transition rules like Linux does. The page also lists a number of applications that will malfunction and not know about the daylight saving shift, so I guess that they have similar issues of some applications ignoring the system time zone database.

San Francisco

I arrived in San Francisco today for the Canonical company conference. Seems like a nice place, and not too cold :). So far I’ve just gone for a walk along Fisherman’s Wharf for a few hours. There look

On the plane trip, I had a chance to see Last Train to Freo, which I didn’t get round to seeing in the cinemas. Definitely worth watching.

Daylight Saving in Western Australia

Like a few other states, Western Australia does not do daylight saving. Recently the state parliament has been discussing a Daylight saving bill. The bill is now before the Legislative Council (the upper house). If the bill gets passed, there will be a 3 year trial followed by a referendum to see if we want to continue.

I hadn’t been paying too much attention to it, and had assumed they would be talking about starting the trial next year. But it seems they’re actually talking about starting it on 3rd December. So assuming the bill gets passed, there will be less than a month til it starts.

If it does get passed, then everyone will need to get time zone data updates for their computers (if they’re in WA, or communicate with people in WA). Curtains will fade! Cows will be confused! It will be chaos!

Building obex-method

I published a Bazaar branch of the Nautilus obex method here:

http://bazaar.launchpad.net/~jamesh/+junk/gnome-vfs-obexftp

This version works with the hcid daemon included with Ubuntu Edgy, rather than requiring the btcond daemon from Maemo.

Some simple instructions on building it:

  1. Download and build the osso-gwobex library:

    svn checkout https://stage.maemo.org/svn/maemo/projects/connectivity/osso-gwobex/trunk osso-gwobex

    The debian/ directory should work fine to build a package using debuild.

  2. Download and build the obex module:

    bzr branch http://bazaar.launchpad.net/~jamesh/+junk/gnome-vfs-obexftp

    There is no debian packaging for this — just an autogen.sh script.

It should work on other distributions, but I haven’t tried it. The main requirement is bluez-utils 3.7, and that -x is passed to hcid to enable the org.bluez.RFCOMM interface.

Still to do is cleaning up the obex:/// listing of bonded devices, so that it serves desktop entries rather than symlinks, so that it is usable in Nautilus. This would also make it easier to show the device names to the user and get nice icons.

Playing Around With the Bluez D-BUS Interface

In my previous entry about using the Maemo obex-module on the desktop, Johan Hedberg mentioned that bluez-utils 3.7 included equivalent interfaces to the osso-gwconnect daemon used by the method. Since then, the copy of bluez-utils in Edgy has been updated to 3.7, and the necessary interfaces are enabled in hcid by default.

Before trying to modify the VFS code, I thought I’d experiment a bit with the D-BUS interfaces via the D-BUS python bindings. Most of the interesting method calls exist on the org.bluez.Adapter interface. We can easily get the default adapter with the following code:

import dbus

bus = dbus.SystemBus()
manager = dbus.Interface(
    bus.get_object('org.bluez', '/org/bluez'),
    'org.bluez.Manager')

adapter = dbus.Interface(
    bus.get_object('org.bluez', manager.DefaultAdapter()),
    'org.bluez.Adapter')

At this point, it is possible to perform discovery:

import dbus.glib
import gtk

def remote_device_found(addr, class_, rssi):
    print 'Found:', addr
def discovery_complete():
    gtk.main_quit()

adapter.connect_to_signal('RemoteDeviceFound', remote_device_found)
adapter.connect_to_signal('DiscoveryCompleted', discovery_completed)

adapter.DiscoverDevices()
gtk.main()

It is also possible to configure periodic discovery, which will send signals about devices that get found, disappear, or change name, so we could easily implement the obex: directory listing that shows all the devices found that support OBEX-FTP. One thing that isn’t clear from the API documentation is what happens if multiple programs try to start or stop discovery at the same time. It looks like the second program will get a org.bluez.Error.InProgress error when it tries to begin discovery. Ideally discovery would stay active til the last program interested in the results closed. Maybe I am misunderstanding it a bit and you can actually use the interface in this mode.

When we want to actually do OBEX-FTP with the device, we can establish the rfcomm connection:

rfcomm = dbus.Interface(
    bus.get_object('org.bluez', manager.DefaultAdapter()),
    'org.bluez.RFCOMM')

# will return e.g. /dev/rfcomm0
devname = rfcomm.Connect(bluetooth_address, 'ftp')

# communicate with the phone via the new rfcomm device

rfcomm.Disconnect(devname)

So it should be possible to modify obex-method to function with only the daemons included in Ubuntu Edgy. All that’s left is to do the actual work :).

bzr branch https://launchpad.net/products/foo

One of the things we’ve been working on for Launchpad is good integration with Bazaar. Launchpad provides a way to register or host Bazaar branches, and nominate a Bazaar branch as representing a particular product series.

For each registered branch, there is a branch information page. This leads to a bit of confusion since Bazaar uses URLs to identify branches, so people try running bzr branch on a branch information page. We also get people trying to branch the product or product series pages.

There were two ways we could address this problem: (1) do more to encourage people not to do this, or (2) make bzr branch do what the user meant it to do. The second option is the more user friendly, so that’s what we chose. This just left the problem of how to implement it efficiently.

The obvious way to get this to work is with a simple HTTP redirect for files under the .bzr/ directory. Unfortunately this would result in Bazaar hitting the Launchpad webapp for every file in the branch which is not desirable (each request results in a number of database accesses, which would add unnecessary load to the system). There is a Bazaar bug about improving this so that it would use the new location after the first redirect. This bug was the main reason for not implementing the feature previously.

While playing around with things a bit, I realised that Bazaar already had the features needed to implement the redirects and they have been there since 0.8.

In Bazaar 0.8, the concept of a lightweight checkout was introduced. This is just a working tree plus a reference to a branch stored elsewhere. You can perform most operations on the branch from the checkout directory that you can do from the real branch directory. So what happens if you publish the “branch reference” part of a lightweight checkout on the web? It turns out that they work fine, so that’s what I used for launchpad.net.

So with the change in place, the following commands will all give you a copy of the Bazaar webserve plugin:

bzr branch http://bazaar.launchpad.net/~bzr/bzr-webserve/webserve-dev
bzr branch https://launchpad.net/people/bzr/+branch/bzr-webserve/webserve-dev
bzr branch https://launchpad.net/products/bzr-webserve/trunk
bzr branch https://launchpad.net/products/bzr-webserve

Furthermore, they will all record the http://bazaar.launchpad.net/ URL as the parent branch, so future bzr pull commands will go directly to the branch.

OBEX in Nautilus

When I got my new laptop, one of the features it had that my previous one didn’t was Bluetooth support. There are a few Bluetooth related utilities for Gnome that let you send and receive SMS messages and a few other things, but a big missing feature is the ability to transfer files to and from the phone easily.

Ideally, I’d be able to browse the phone’s file system using Nautilus. Luckily, the Maemo guys have already done the hard work of writing a gnome-vfs module that speaks the OBEX FTP protocol. I had a go at compiling it on my laptop (running Ubuntu Edgy), and you can see the result below:


Browsing files and viewing images stored on my phone

There are a few rough edges:

  • While I can get a list of discovered devices at the location obex:///, it displays the raw bluetooth addresses rather than device names. Furthermore, the files displayed here are symlinks to the appropriate obex://[$ADDRESS]/ URLs, which aren’t that useful given that gnome-vfs does not support symlinks pointing to other schemes or authorities. This could be fixed by generating .desktop files instead, which would make it possible to provide nice icons too.
  • Can’t rename files. This might be a limitation of the OBEX FTP protocol though: the man page for the command line obexftp client says moves only work with Siemens phones.
  • Doesn’t seem to handle devices disappearing very well — when I tried turning off Bluetooth on my phone and told Nautilus to reload the window, Nautilus hung and stopped redrawing til I turned Bluetooth on again.

I don’t have any ready made binaries for others to try at this point. Below are some notes for anyone else who wants to try building it:

  • You’ll need the osso-gwconnect, osso-gwobex and osso-gnomevfs-extra modules. I grabbed them from Maemo Subversion.
  • When trying to build a debian package for osso-gwconnect, I removed the libosso-dev and mce-dev build dependencies, and made an equivalent change to the configure arguments in debian/rules. The configure script also asks for BlueZ 3.2, while Edgy only has 3.1. The package built fine when I decreased the minimum version requirement.
  • You’ll need to build osso-gwconnect and osso-gwobex before osso-gnomevfs-extra. There are a few build problems with this last module:
    1. The autogen.sh script asks for automake 1.8.x specifically, but works fine with the current 1.9.x releases.
    2. I had to change a dbus_connection_disconnect() call to dbus_connection_close() in obex-module/src/om-dbus.c.
    3. You only need to build the obex-utils and obex-module directories. There are other bits in this module that you probably don’t want, and some bits like the replacement GTK filesystem backend didn’t build for me.

With a little bit of work, this would fit into the main Gnome desktop quite well. When talking to Bastien a while back, he said that the extra dbus daemons shouldn’t really be necessary, so it might be worth trying to bypass them.

Lenovo Battery Recall

So it seems that Lenovo has decided to join in on this battery recall fad. It turns out that the main battery in my X60s is one of the explosive Sony variety (the extended life battery isn’t though). I rang them up to organise the replacement, which will be arriving in 5 weeks.

Even though he hasn’t asked for it yet, I sent the details to Richard Hughes. It looks like the battery model numbers are exposed through HAL, so gnome-power-manager should be able to detect the bad batteries.

If you have an affected Thinkpad, check your batteries.