DVCS talks at GUADEC

Yesterday, a BoF was scheduled for discussion of distributed version control systems with GNOME.  The BoF session did not end up really discussing the issues of what GNOME needs out of a revision control system, and some of the examples Federico used were a bit snarky.

We had a more productive meeting in the session afterwards where we went over some of the concrete goals for the system.  The list from the blackboard was:

  • Contributor collaboration (i.e. let anyone use the tool rather than just core developers).
  • Distro ⇔ distro and distro ⇔ upstream collaboration.
  • Host GNOME source code repositories
  • Code review
  • Server side hooks
  • Translators: what to do?
  • Enforced checks
  • Offline operations
  • Documentation authors?
  • Support Win32/Mac (important for GTK)

The sys admin tasks were broken down to:

  • MAINTAINERS file syntax checking
  • PO file syntax checking
  • CIA integration.
  • Commits mailing list
  • Check that commit messages are not empty
  • Trigger updates from commits (e.g. the web site module).
  • Release notes tarballs
  • Damned Lies support

It was clear from the discussion that neither Git or Bazaar satisfied all of the criteria.

The Playground

John Carr did a great job setting up Bazaar mirrors of all the GNOME modules.  This provided an easy way for people to see play around with Bazaar.  However, it only gave you half the experience since it didn’t provide a way to publish code and collaborate.

To aid in this, we have set up the bzr-playground.gnome.org machine, which any GNOME developer should be able to use to publish branches based on John’s imports.  Instructions on getting set up can be found on the wiki.  I hope that we will get a lot of people trying out this infrastructure.

We gave a presentation today on some of the things Bazaar provides that could be useful when hacking on GNOME.  Demoing bzr-playground was a bit problematic due to the internet connection problems at the venue, but I think we still showed some useful tools for local collaboration, searching and code review.

Meanwhile, Robert Collins has been working on some of the GNOME sysadmin features that Bazaar was lacking.  Among other things, he got Damned Lies working with both Subversion and Bazaar, with a test installation on the playground machine.


I arrived in Prague yesterday for the Ubuntu Developer Summit.  Including time spent in transit in Singapore and London, the flights took about 30 hours.

As I was flying on BA, I got to experience Heathrow Terminal 5. It wasn’t quite as bad as some of the horror stories I’d heard.  There were definitely aspects that weren’t forgiving of mistakes.  For example, when taking the train to the “B” section there was a sign saying that if you accidentally got on the train when you shouldn’t have it would take 40 minutes to get back to the “A” section.

It is also quite difficult to find water fountains in the terminal, which is inexcusable given that they don’t let people bring their own water bottles.

I had been a bit worried that they’d lose my bag, but it arrived okay in Prague.  Jonathan was not so lucky.

As well as the Ubuntu and Canonical folks, there are a bunch of Gnome developers here, including Ryan, Murray, Olav, David and Lennart.  It will be an interesting week.

Inkscape Migrated to Launchpad

Yesterday I performed the migration of Inkscape‘s bugs from SourceForge.net to Launchpad. This was a full import of all their historic bug data – about 6900 bugs.

As the import only had access to the SF user names for bug reporters, commenters and assignees, it was not possible to link them up to existing Launchpad users in most cases. This means that duplicate person objects have been created with email addresses like $USERNAME@users.sourceforge.net.

If you are a Launchpad user and have previously filed or commented on Inkscape bugs, you can clean up the duplicate person object by going to the following URL and entering your $USERNAME@users.sourceforge.net address:


After following the instructions in the email confirmation, all references to the duplicate person will be fixed up to point at your primary account (so bug mail will go to your preferred email address rather than being redirected through SourceForge).

Weird GNOME Power Manager error message

Since upgrading to Ubuntu Gutsy I’ve occasionally been seeing the following notification from GNOME Power Manager:

GNOME Power Manager notification

I’d usually trigger this error by unplugging the AC adapter and then picking suspend from GPM’s left click menu.

My first thought on seeing this was “What’s a policy timeout, and why is it not valid?” followed by “I don’t remember setting a policy timeout”. Looking at bug 492132 I found a pointer to the policy_suppression_timeout gconf value, whose description gives a bit more information.

Apparently the timeout is designed to ignore spurious messages from the hardware after a resume — you wouldn’t want to process a left over “suspend” message immediately after resuming from suspend after all. This does bring up a few questions though:

  1. While ignoring “please suspend” messages shortly after performing a suspend makes sense, why ignore “please suspend” messages after an “on battery power message”?
  2. While messages from the hardware might be spurious, surely picking an option from GPM’s menu is not. I guess such suspend requests are being mixed in with hardware suspend requests before the point where the policy timeout is checked.

gnome-vfs-obexftp 0.4

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:


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.

Test Suite

As noted in the third point, I’ve started to build up a collection of capability and folder listing XML documents produced by various phone models. This serves a dual purpose:

  1. Ensure that the capability object and folder listing XML parsers don’t regress between releases. It is impractical for me to test gnome-vfs-obexftp against all these phone models since I don’t have the hardware or time.
  2. Give an idea of what information the different phone models provide, which should be useful when planning new features.

If you have an OBEX FTP capable phone that is not already in the test suite, it’d be useful if you could collect the data and file a bug. The information can be collected using the command line “obexftp” program (part of the “obexftp” package on Ubuntu). The following commands will give the capability object and root folder listing:

obexftp --bluetooth $BDADDR --capability
obexftp --bluetooth $BDADDR --list

It’d also be useful to get a listing for one or two other directories. If there is a memory card, it’d be useful to get that folder. For example:

obexftp --bluetooth $BDADDR --list "Memory card/"

It’d be most useful if the transcript of the various commands were included as an attachment. Feel free to censor personal information if you want (e.g. the phone serial number in the capability object, some non-default file names).

In particular, I wouldn’t mind getting information on phones with brands other than than Nokia or Sony to see what info they provide.