Martin Pool's blog

Moving...

My blog's moving to a new location, blog.sourcefrog.net. The old articles will still be here, and I'll arrange for the RSS feed to redirect.

Passing the baton for distcc

The time's come for me to pass over the baton of distcc to a new maintainer, Fergus Henderson.

Fergus, along with his Google colleagues Nils Klarlund and Craig Silverstein, have been working for some time on a large new extension, distcc-pump. distcc up to the last release I made always did preprocessing on the client machine, then sent the preprocessed source to a server for compilation. This keeps things pretty simple and works well across a wide domain but does eventually reach a scalability limit. With distcc-pump more of the work can be distributed. It looks like there will also be support for gcc precompiled headers coming in soon, in collaboration with Sascha Demetrio. A release candidate for 3.0 is now up on the new distcc site, and they're churning through the several outstanding patches.

I'm very touched by his words about the project. Thanks, Fergus.

Sydney Film Festival

Great films (Cronocrimines, Revue, Sukiyaki Western Django, My Winnipeg, ...) and the State Theatre is at the height of it's pre-Depression glory.

Amazingly awful online ticketing though. I had to wait three days from booking a multi-pass to being able to book in to particular films. My advice is to buy paper tickets at the box office like we did last century. The woman behind us in the queue who came down from Brisbane for the long weekend had spent three hours on Ticketmaster trying to book a few movies.

Bazaar gedit integration

Javier Derderian is working on integrating Bazaar into gedit, the GNOME standard text editor, so that you can very easily record changes, push them to a server, and so on. Bazaar's model that a branch is just a directory with extra metadata fits pretty well here. He just made another exciting release (or should that be "excited"? :-)

Economist article titles, or indy playlist?

Now I want to hear what A lot to be angry about sounds like.

Avoiding "not permitted to upload" errors from PPAs

Morten asked today on irc about an error I have hit before myself: you go to upload your new package to a PPA, and get an odd message of Not permitted to upload to the RELEASE pocket in a series in the 'CURRENT' state.

What this means is that your upload was trying to go into the Ubuntu distribution, rather than into a PPA, and you're not authorized to put it there. The underlying reason is that the command line for dput, the tool for uploading source packages, is

dput [options] [host] package.changes ...

It's easy to forget the optional host parameter and if it's omitted it uploads into the Ubuntu archive.

There is a pretty easy (if crude) way to disable this behaviour, by adding these lines to your ~/.dput.cf:

[DEFAULT]
default_host_main = notspecified

[notspecified]
fqdn = SPECIFY.A.PPA.NAME

Using a Dvorak keyboard for a year, and pain avoidance

About a year and a half ago I switched to using a Dvorak keyboard layout everywhere rather than the more common Qwerty, as one of several measures to avoid keyboard-related wrist pain. After blogging about how I was going to switch I said no more about it, partly because ironically enough my typing speed temporarily decreased quite substantially. Marius asked me what happened.

I did stick with Dvorak and I'm glad I switched. I would recommend it to anyone who uses a computer for a substantial amount of time.

It really does seem to require less stretching and remarkably less hand movement. However it may be that part of this effect is just improving touch typing, being more aware of what finger is used for what key — in other words if one somehow forgot Qwerty and then sytematically re-learned it, it might give some of these benefits.

If you do want to switch, I'd recommend just jumping in: don't try to cut over gradually, don't put stickers on your keyboard, don't rearrange the keycaps. I put a printout of the layout near my screen and just kept looking when I got lost until I'd memorized it. At the peak of switching I would type sentences in my mind in idle moments.

Command keys, and vim in particular take a bit of adaption. I found it best to just use mouse actions instead for a while, and then slow down and think about the letter of the key before pressing it. Once I'd adapted it generally worked well. I used to use emacs a lot and rarely do so now, and going back to it is very difficult because what I do remember is in muscle memory.

Passwords can be very difficult, as people tend to remember commonly-used ones by muscle memory rather than as characters. It may be wise to write them down somewhere safe, at least for the transition period.

I can't really touch-type Qwerty now: I don't hunt-and-peck but I do need to look at the keyboard when I rarely have to use it — hotel computers, boot loaders, other people's computers and so on. On the other hand I have no trouble using a Qwerty layout on my phone, I suppose because it's a different mental context.

Some people like to pry off the keyboard caps and rearrange them to correspond to the Dvorak layout. I didn't do this, and I wouldn't recommend it, for a few reasons. I think that to learn Dvorak, you need to be able to touch-type it without looking at the keycaps, if only so that you can use it on machines where you can't (or may not) modify the hardware. Conversely, sometimes you may need to type Qwerty on your own machine, or you may want to lend it to someone who can't touch type Qwerty.

Perhaps most important, the little nubs on the (physical) F and J keys really matter to me now, and if I'd moved the keycaps they'd be in completely the wrong place. Dvorak makes the "home row" concept much more important, and my hands really feel at home with the nubs under my index fingers.

The transition is easiest on a Mac: you can easily put a little switcher on the menu bar, and even use it to display an Aussie flag rather than insisting on showing the stars and stripes. On Ubuntu it works pretty well, with a few nits: the text-mode recovery environments tend to "forget" that you wanted Dvorak during upgrades, the GNOME panel indicator likes to show the rather unhelpful labels of "USA" and "USA2" (with unpredictable meanings) and in some places like the screen-lock dialog there's no indication of which layout is active.

Vista I found generally pretty poor, as it wants to set the layout per-application not per-session. I very casually play WoW on Windows, which needs both typing of text and control through keys, and so far found it's best to leave my keyboard layout in Dvorak so I can type text in the way I'm used to, and then rebind all the keys so they have the same position: the WASD diamond comes out as <AOE.

I only later heard of the Colemak layout, which is supposed to be like Dvorak but better optimized for actual typing patterns, including those that occur in programming. It may well be; the hassle of the Dvorak transition is far enough in the past and the benefits are clear enought that I'm open to trying it. Dvorak does have the advantage that although it is used by a minority of people, it is widely available: if you borrow a random person's terminal the odds are low that it will already be in the Dvorak layout, but the odds are very good that you can easily and quickly change it. This is probably not true for Colemak (as of 2008).

More later on other RSI avoidance techniques...

Bundle Buggy, for list-based code review

My favourite thing about Bazaar is actually a tool built on top of it, Bundle Buggy, a tool for managing contributions and reviews.

When you send a patch or a Bazaar bundle to the developer mailing list, Bundle Buggy gets a copy of it, sees the proposed merge, creates a web page about it, linked back to the mail thread and to a bug number if there is one.

By catching all patches to the list it makes sure that things are not accidentally dropped. The important thing though is the getting-things-done workflow and the integration with Bazaar. Seeing a long list of mails can make it hard to decide where to begin, which is an invitation to procrastinate. BB tries to sort out patches which are ready to merge, which have been reviewed by others, which you ought to review yourself, which need other work and other states. It knows about our quasi-voting process, where we try to get at least one core contributor to review all patches, and you can do the reviews entirely over mail.

BundleBuggy is (just about?) all Aaron Bentley's work, and credits Jeremy Kerr's Patchwork tool for inspiration.

We could do a lot more here, I'm sure: a nicer review interface than just showing the diff, perhaps automatically firing off a merge if the patch is approved, telling the bug and its subscribers if we believe a fix has been merged.

Tips for Launchpad PPAs

Launchpad has relatively new (well, a few months old) feature called Personal Package Archives.

PPAs have been taken up quite a lot by people making variations of packages in Ubuntu. One common situation is that developers will put pacakages with a proposed fix for a bug up into their PPA to let people try it out and confirm the bug is fixed.

I have been using them this week to make packages of Bazaar.

It's a pretty nice service; with probably less hassle than setting it up ourselves we have a nice apt archive that can be uploaded to by anyone in our team, and that rebuilds across several supported architectures. I hope with a bit more scripting we will be building these automatically on each release.

One piece of advice is to create a team specifically for packaging. PPAs as the name implies are owned by people or teams, so the URLs people put into their apt sources are bound to that team. So if, maybe later on, you want to allow more people, or indeed fewer people, to upload to the archive that can most easily be accomplished by making a specific team for it in the first place. Team memberships is transitive so you can always add your whole project's team to the PPA team. I put ours under ~bzr but it would have been better to use ~bzr-ppa. Or indeed, to allow for several different types of archive, maybe ~bzr-ppa-stable.

(More later, it's after 6 and enough for a week.)

About Launchpad betas

Launchpad.net has a fairly complex system by which new code is gradually exposed to a larger audience. This is managed through Bazaar branches, and automatic merging between them.

As this has evolved there has been a little confusion between launchpad.net, edge, beta, staging and so on. So to explain this there is now a help page about Launchpad beta testing.

Archives 2008: Oct Jun May Apr Feb 2007: Jul May Feb Jan 2006: Dec Nov Oct Sep Aug Jul Jun Jan 2005: Sep Aug Jul Jun May Apr Mar Feb Jan 2004: Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan 2003: Dec Nov Oct Sep Aug Jul Jun May