I just read that they plan to put WiFi on the trains in Brisbane.

I had one of my crazy business ideas to try and do this years ago. I think it'd be great for public transport adoption. Imagine being able to be on top of your email by the time you arrive at your desk?

Of course, with mobile broadband becoming more and more ubiquitous, you don't really need WiFi on the train, so it may be too late...

At work, we have a bit of a vested interest in the Puppet and Facter packages that are in Debian, because we ultimately consume them in Ubuntu.

We noticed that what was in Debian unstable was lagging a bit behind what was released upstream, and when one of my co-workers tried getting in contact with the Debian developers that were maintaining the Puppet package and got no response, I got involved.

I got in touch with Micah Anderson and got myself and Nigel Kersten added to the Alioth project for Puppet.

Despite Jamie Wilkinson being listed as the maintainer of the facter package in Debian, he claimed this was news to him, and Matt Palmer, who was listed as an uploader, didn't really claim much knowledge of maintaining the package either, so we took that as blessing to take over that package as well.

This is where the fun begins.

I've been meaning to try out Git ever since Debconf 7, where all the cool kids were using it and raving about it.

I've been meaning to make the Debian DHCP package collaboratively-maintained, and use Git for the revision control, but I haven't quite gotten off my good intentions and done it yet. Part of the problem is not knowing exactly what workflow I should use, and suffering from paralysis by analysis, reluctant to experiment, because I don't want to go down the wrong path.

Anyway, this is about Puppet, not DHCP. The Puppet package, as it turns out, is already maintained in Git on Alioth, so the problem here was more one of figuring out what the current workflow was, and trying to follow it.

This is where Nigel came in. Conveniently, the upstream Puppet development is done in Git also, and Nigel is a contributor to Puppet upstream, so he had some Git-fu. So between the instructions on how to get started with Git on Alioth and what he knew, we could start fumbling around.

It seems like the Alioth Git repository was also tracking the upstream Puppet repository, as there were commits in the Alioth one by Luke Kanies, and we didn't really imagine that he was doing Debian-specific stuff.

Here's what we ended up doing to try and get what was in the Alioth repository up to the upstream version 0.24.8 of Puppet:

git clone ssh://apollock@git.debian.org/git/pkg-puppet/puppet.git

This part was fairly straight forward. Clone what's in Alioth locally.

git remote add reductive git://reductivelabs.com/puppet
git remote update
git fetch --tags reductive

Next, we added a remote branch that tracked upstream. We called it "reductive", and we updated it. The bit that took some fiddling with was fetching the tags. Nigel later figured out that tags are inherently private to a repository, and normally stay that way. So if I have a local clone of say the upstream Puppet repository, I can tag it to my heart's content, and normally those tags would stay in my local repository, because they're probably only meaningful to me.

git checkout -b upstream/0.24.8 0.24.8

This bit took a bit of work to arrive at as well. What we wanted to do was create a new branch called upstream/0.24.8, which was at what was tagged 0.24.8 in the reductive repository. Nigel pondered what would happen if you already had a tag or a branch called "0.24.8" before you added the remote repository. This is also why we had to fetch the tags from the remote repository, so we had something to check out.

git checkout master
git merge upstream/0.24.8

Next, we switched back to the master branch and merged the contents of our local upstream/0.24.8 branch that we just created. This now got the Puppet source in the master branch up to what was released as version 0.24.8. (and this is better than just running uupdate?)

We did some fiddling with the debian/control file and debian/changelog and fixed up a few things that Lintian was bitching about, and were done.

I'd set up a sid chroot with cowdancer previously, and had to do some faffing around with git-buildpackage to convince it to use pbuilder. I ended up using

git-buildpackage --git-builder="pdebuild --debbuildopts '-i\.git -I.git' --basepath /var/cache/pbuilder/base-unstable.cow"

So now we've got most of what we want to ship checked into Git on Alioth. I have no idea if we've done it "right", I suspect we may have done something wrong by operating on the master branch. Looking at the revision history in the Git repository on Alioth, it looks like previously things have been done a few different ways. I certainly want to write up a definitive workflow once we've figured one out.

We haven't uploaded the new package to unstable yet, because we're still trying to give it a modicum of testing, and we'd like to sort out the Facter package as well.

The Facter package was a more greenfield exercise, as while there was already a Git repository on Alioth for it, it was empty. So Nigel had to do some futzing around to get it checked in the right way to make git-buildpackage want to build it. He did this by himself, so I'm not sure exactly what he did. I've since discovered that it's probably lacking some dependencies it needs, so that'll need to get fixed before it gets uploaded.

I look forward to reading blog posts from the smart people who actually know how to use Git properly, telling me how we should have done it.

I'm still very interested in coming up with a proper workflow for preparing packages and committing the changes, and for doing code review.

Now that Lenny is released, I've got some time to go to town on the ISC DHCP packages.

The first thing I want to do is get DHCP 4.1 uploaded. Unfortunately, this first requires a bunch of transition work, and the associated coordination that goes with it. This post is an attempt to marshal the stream of consciousness and come up with a plan...

Problem #1: everything has 3 in it

The packages themselves need to lose the 3 everywhere. The source package is dhcp3. That seems kinda retarded if its DHCP 4.1.0. The binary packages all need to loose the 3 as well.

apt-cache rdepends dhcp3-client tells me I'll need to reach out to the maintainers of the following packages:

avahi-autoipd
wifi-radar
synce-hal
rutilt
rootstrap
resolvconf
nfsboot
lxnm
laptop-net
ifupdown
education-desktop-other
dhcdbd
bpalogin
avahi-autoipd

Obviously I can keep the old packages around for a while for transitionary reasons.

The 3's also persist in various directories provided by the packages: /etc/dhcp3, /var/lib/dhcp3

apt-file search /etc/dhcp3 tells me I need to reach out to the maintainers of the following packages:

avahi-autoipd
debian-edu-config
debian-installer
dhcdbd
fai-doc
fai-nfsroot
ntp
ntpdate
resolvconf
samba-common
sendmail-base
whereami

Obviously I can keep some compatibility symlinks around for a transition period.

Problem #2: the names themselves

Is it right to monopolise the name "dhcp-client" or "dhcp-server"? I tend to think not. So should I rename the source package to "isc-dhcp" and prefix all of the binary packages with "isc-"? I think this would cleanly address #520842 and the fact that there's apparently supposed to be a "dhcp-client" virtual package.

Problem #3: dhclient-script is old and crufty

This is less pressing, and less packaging related, but the dhclient-script we ship now is Debian-specific. There is room for optimisation, and there are better ways to implement the script so it's more externally customisable. I'd also dearly love to switch over to using iproute for everything possible.

This brings us to the game plan, which I think I'll write in a future post after I've meditated on the problem a bit, now that I've finally written it all down...

Neil put me onto this guy who is also doing monitoring of his cat water bowl. Unlike my way of doing it, he seems to be doing it without any probes in the water, which would make refilling the water bowl a lot less fiddly, although adds the requirement to have a rig above the bowl.

This ultrasonic sensor thing sounds very interesting.

I foresee the soldering iron making a reappearance in the near future...