Between work and parenthood, I'm struggling to keep on top of things a bit at the moment, but so I'm a bit late to the party.

Debian turned 17 during the week. I think the first thing that brought the fact to my attention was someone sent me a thank you note for maintaining dstat (of all things) via thanks.debian.net, which Marga set up.

I've been a Debian Developer for 7 of those 17 years now, and it's been great. I've learned heaps about Linux and Linux software packaging, and been able to give something back to the distro that I love. My time commitment waxes and wanes as real life permits, and my involvement in the community has dropped to almost nothing, again for time reasons, but I hope to be able to get more involved again in the future.

It's been a while since I've been able to make any progress on the ISC DHCP 4.1 packaging. I had to cannibalise my test infrastructure to deal with hardware failure that would have rendered my MythTV installation out of commission, we bought a condo, did some renovations, and had a baby. I'm still playing catch up.

The other day, I was able to recreate a test environment on my laptop using KVM, instead of Xen on a dedicated machine, and it's 37% more awesome than my old setup, so I'm back in the saddle again.

I've been able to do some basic testing of the 4.1 packages that are in experimental, and they appear to work, and they upgrade cleanly from the 3.1 packages.

There's the small issue of third-party packages that are plonking files in /etc/dhcp3 (it's just /etc/dhcp now). I finished filing bugs for the transition this morning, so I think the next step is to upload to unstable, which I think I'll do on the weekend.

Julien's blog post reminded me that I needed to announce that I'm in the process of transitioning to a new key myself.

I've been meaning to do something about the whole weak 1024-bit DSA key thing ever since everyone started freaking out about them, but I liked how well connected my old key was. Oh well. Time to suck it up and start over.

Here's my transition document, now that I've figured out how sign a file with multiple keys

It's been a while since I made an upload of anything DHCP-related, so I thought a general update was deserved.

The lovely test infrastructure that I built had to be cannibalised to stand in for some other hardware that failed on me, so that prevented me from being able to test as easily. Add to that, the distractions of moving house, and I just haven't had the time to do any work on the DHCP 4.1 packaging.

That said, I haven't been completely idle. I've been pressing the ISC DHCP developers to incorporate the LDAP patch, which is extremely popular in some quarters. At the same time, I was able to flush the author of the LDAP patch (he'd seemed to have disappeared) and connected the two parties together. Hopefully we'll see something in 4.2

Today, I updated the 4.1 packages in experimental to 4.1.1, which includes a reintroduced LDAP patch. I think if there's no unfavourable feedback, I'll look at uploading this to unstable in the next month or so, and the great transition to DHCP 4 can commence (assuming the release time is cool with this).

If I could just figure out how to do bridged networking with KVM and still use NetworkManager for my WiFi, I could probably set up a similar test environment to what I had before, on my laptop...

I had this vague recollection of it being possible to do so, but I think Joerg's blog post has a poor page rank, so this is my attempt to give it a little boost.

There's a release critical bug (that severity is debateable, in my opinion) in elfsign, a package I maintain.

It seems to my casual observation, that switching it to generate SHA1 signatures wouldn't be too hard, given it's using OpenSSL, and OpenSSL has a sha.h file. I really wouldn't know where to start, though, and ideally it should continue to verify existing MD5 signatures, so it's more than just changing an include and a few function calls.

To boot, upstream seems to have disappeared, so it's looking like removal is the best option. The popcon numbers for this package aren't very high either, which is another nail in the coffin.

So if someone reading this cares about elfsign in Debian enough to send me a patch to use SHA1 in the next month or so, I won't file a removal request.

I recently learned of PyMetrics existence via 10 Ways To Let People Know You're A Bad Python Programmer

I've yet to run it on any of my Python code to figure out how bad a Python programmer am I, but I was surprised to discover it was absent from Debian, so I fixed that.

In writing this post, I just realised that I unnecessarily made it an architecture-dependent package, when it doesn't need to be. Better go fix that.

Stefano Zacchiroli's post about fixing an RC bug a day got me thinking. In my Google Reader, I already have the feed of new Debian packages (which was incidentally the highlight of Debian Weekly News for me, and now that I found this feed, I miss its now infrequent publications a whole lot less). What I'd really like to compliment this, is a daily feed of new release critical bugs opened or elevated to release critical status. Then, in my copious amounts of spare time, if I got the urge when an appropriate RC bug went by, I might be more inclined to try and do something about it.

Does such a feed already exist somewhere?

I finalised the initial upload of the ISC DHCP 4.1.0 packages a couple of days ago, and it sat in NEW, because I've renamed the source package (no more dhcp3). Today it was ACCEPTed into experimental. (Kudos to the ftp-team for their quick processing of NEW)

It should deal with upgrading from dhcp3-client or dhcp3-server to the newly-named equivalents, at least for the common cases. The rest will come out in the wash (which is why it's in experimental).

Thanks also to AJ for letting me NMU ifupdown twice to sort out some problems with the way it invokes /sbin/dhclient (thinking it's the v2 client) as opposed to /sbin/dhclient3.

I think the criteria for uploading to unstable will be:

• no egregiously bad issues uncovered by testing in experimental
• the LDAP patch for the DHCP server is sorted out
• bugs are filed, where needed, for consumers of the DHCP client to do the right thing (invoke it correctly as /sbin/dhclient instead of /sbin/dhclient3)

It's been a while since I last wrote about where I was up to with the DHCP 4.1 packaging for Debian.

I'm pleased to report that the packages are now ready for upload to experimental.

The main delay was doing some basic testing to make sure that the transition from the v3 packages to the new v4 packages worked properly. I'm glad I took the time to set up a Xen test environment, because I found all sorts of problems, and fixed them.

The only reason I'm not uploading the packages today is because my testing uncovered a bug (#544371) in the way ifupdown is invoking dhclient. Until that is resolved, there's not a lot of point in uploading, as dhclient won't work.

Oh, and the DHCP server LDAP patch still needs to be sorted out, but I'm not going to wait for that to do an experimental upload.

I'm very excited by the recent announcement of the release goals for Squeeze.

Specifically multiarch. I didn't realise large file support was still an issue, nor IPv6. It's mainly multiarch that I'm jumping up and down about.

Multiarch is something that Debian has been lacking for so long, and is a necessary bridge to full 64-bit userland.

We switched from i386 to amd64 at work with Ubuntu 8.04, and it certainly hasn't been all beer and skittles. The ia32-libs package, which is a gross hack, is very necessary. Flash is still problematic. Multiarch won't fix everything, but it should put Debian on a more level playing field with the likes of Red Hat. Does SuSE do multiarch?

Something I am more happy about is Debian's decision to make time-based freezes. This is a great step in the right direction, and a good compromise between feature based releases and time based releases.

For about the last two years now, my day job has involved the consumption of Ubuntu, and I can say from a quality point of view, its time based releases leave a lot of room for improvement. We've seen time and time again, bugs in an Ubuntu release that never saw the light of day in a stable Debian release.

What will be more interesting is how Ubuntu adapts to Debian's freeze and what that means for the 10.04 Ubuntu release (assuming it's another LTS).

I'll be watching this with interest.

So Debian is going to follow Ubuntu in making /bin/sh be dash by default.

The technically correct side of me welcomes the change, but the realist in me doesn't think it's such a good idea.

It's all fine and dandy to have the entire Debian distribution behaving itself correctly with /bin/sh being dash, but the distribution is never the end of the story, there's always third-party software, and in large Linux shops like where I work, there's going to be bogloads of in-house scripts.

When Ubuntu 8.04 came out with /bin/sh being dash, we tried, valiantly to keep it that way, under the ostensible cover of technical correctness, and not wanting to deviate from the distribution default. We even had a massive fixit and tracked down and fixed all of the scripts that has bashisms in them and made them explicitly use bash.

The problem was we could never track down 100% of the scripts. It got a lot harder when you had to take into account shell code embedded in scripts of other languages. That was when we threw in the towel and just made /bin/sh be bash instead, and as long as it stays that way, people will keep writing #!/bin/sh scripts with bashisms in it, so the problem will never go away.

So if we can't do it, when we've got all of our scripts in a central repository and can do all sorts of analysis across it, then I pity the people in smaller organisations with a greater hodge-podge of scripts. It'll be a nightmare.

It's also unfortunate that popcon is unable to report how many users change /bin/sh back to bash, so we'll have no idea how many people reject the change for pragmatic reasons like we did.

I think some of the arguments for doing it are flawed:

It'll speed up boot times

Really? How much? Show me the numbers. Who cares anyway? Laptops suspend, servers aren't supposed to get rebooted frequently, and I'd really like to know how much of a dramatic difference it makes. I question the value. Also, the set of init scripts within a distribution is more defined than all possible shell scripts in the world, so why not make all of Debian's init scripts use /bin/dash instead and get the same outcome with less collateral damage?

It'll use less memory

Really? How much? Show me the numbers. So what? Do it on embedded systems where memory is tight and third-party scripts are less like to be a problem, sure, but on a modern desktop or server? How about focusing on how much memory Firefox uses instead?

So yeah, I'm not terribly overjoyed by this decision. We'll see how it pans out.

Wouter Verhelst wrote a very insightful blog post about what is involved being a buildd maintainer

For as long as I've been involved with Debian, I've been fascinated by the infrastructure that is the heartbeat of the project. I think it's really cool. Unfortunately, it's not spectacularly documented, so blog posts like his help add some more perspective.

I discovered last night (and it was possibly a rediscovery) that packages that produce udebs seem to be perpetually frozen, and require manual approval from debian-release and debian-boot to enter testing.

I swear that once upon a time, this was only the case around releases, but now it seems to be the case all the time.

I view this as a serious disincentive to make a udeb from a package that also operates outside of debian-installer.

I noticed the problem when I made a high priority upload of dhcp3 to unstable to fix CVE-2009-0692, with the expectation that it would hit testing within a couple of days. When about 3 days had passed without an email from the PTS saying the package had entered testing, I pulled out the trusty grep-excuses, and (re)discovered the freeze for udeb-generating packages.

I think if debian-boot is going to mandate this freeze for udeb-generating packages, then someone on debian-boot should be getting a report every day of udeb-generating packages that are due to enter testing in the next 24-48 hours, so they can be proactively vetted and their entry into testing not delayed unnecessarily. It shouldn't have to fall on me as the package maintainer to have to notice.

I've gone and forgotten again the reason for this freeze in the first place (I've had it explained to me a couple of times, it's possibly due to #271782, which last saw activity four years ago), but every time I'm told "oh, it won't be this way much longer". It's been this way for literally years. Show me the plan to make it different.

There's been a steady trickle of interest in Debian packages of version 4.1 of ISC's DHCP.

I've been a bit busy with Real Life of late, but I had made a start on the packages a little while ago. I got a good chunk of time today and have something close to what I'd be happy to upload to experimental.

There's been three main hold ups:

The upstream build system changed

Upstream switched to using GNU autoconf and automake and all of that jazz, so nothing behaved the way it used to. I used this opportunity to heavily refactor debian/rules and use debhelper more consistently and appropriately.

It was a new major version, so the "3" had to go from everything

For historical reasons dating back to before I was involved in the maintenance of the package, the v2 DHCP package was called "dhcp" and the v3 DHCP package was called "dhcp3". The resulting binary packages were called dhcp3-client and dhcp3-server and so on. It seemed incredibly lame continue calling the v4 packages with v3 names. While I was "de-threeing" everything, I decided that maintaining a monopoly on the name "DHCP" seemed a bit unreasonable, so I've renamed the source package to "isc-dhcp" and all of the binary packages now have "isc-" prepended to them.

I wanted to switch to Git for collaborative maintenance

This is the first package I've maintained in Git, on Alioth, so there's been a bit of a learning curve figuring out how to do everything.

What's still to be done

While the package currently builds, it's not handling upgrades from v3 versions, and I doubt I've expressed all of the dependencies correctly to even try such a thing. The kFreeBSD patches need redoing, as does the LDAP patches.

There's probably not much more to be done before I'd be prepared to upload to experimental, except do a bit of local testing to make sure everything vaguely works. I might get time next weekend to do that.

If you're interested in helping, check out the Alioth project and the Git repository or drop me a line.

Courtesy of a wonky prerm script in a package I'm working on, I just learned that when you dpkg-reconfigure a package, it runs more than just the package's config script. I guess subconsciously, I'd always expected it to run the postinst again as well, but I did not realise the prerm script was also run.

So having now peeked at the innards of dpkg-reconfigure, it runs the prerm with upgrade version, the config with reconfigure version and the postinst with configure version, in that order.

I'm very excited that Debian is dabbling with GeoDNS.

I look forward to the day when one can point at their sources.list at ftp.debian.org (or the generic equivalent) regardless of their location and get a fast local mirror. One less question to answer when installing Debian.

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...

This is pretty cool.

I think the craziest dependency map for a package I maintain is the one for argus-server.

(Discovered via LWN)

Neil:

$ host -t txt manpages.debian.net
manpages.debian.net descriptive text "Javier Pen~a <jfs@debian.org>"
manpages.debian.net descriptive text "PGP D6 91 BB 89 88 7A F7  A0 BA E4 27 FD 7A 6A FE DA"
manpages.debian.net descriptive text "PGP 86AA DB04 D2F5 CC55  3A4D 940F B1A9 DD82 DC81 4B09"

I'm wading through my email and saw a recent announcement about the miniconfs that have been accepted for linux.conf.au 2009, and Debian was conspicuous in its absence. That's a bit of a shame.

I, for one, like Lucas' idea.

Eddy Petrișor wrote about doing some sort of user supported thing for snapshot.debian.net, which I was saddened to learn from his post had reached capacity in May.

I think rather than relying on the generosity of random users, the Debian Project should just throw some money at the problem. It's got more than enough. Disk is cheap.

I'd think that with a few fully loaded SR2421's and an Ethernet switch, you'd be laughing.

Spoken by a co-worker, fighting with nano, when all he wanted was less to browse the installer log to diagnose why an installation with d-i failed.

So hot off the back of my successful upgrade from Sarge to Etch, I thought I'd try the new "Etch and a Half" 2.6.24 kernel on daedalus

Let's just say that it's times like these that I'm glad I got the serial-over-LAN thing working, and have remote power.

I spent many hours today rebooting, trying to get to the bottom of why it wouldn't work.

At first, I thought it was hanging, but then I realised it was dropping to a shell in the initramfs, and just not making that very obvious because the serial over LAN console is a bit crappy.

Once I realised what was going on, I did some poking around.

It seemed like udev wasn't getting started properly, so when it went to assemble the mirrors, that failed, because the component devices couldn't be found, then it freaked out because it couldn't mount the root filesystem.

If I ran the relevant bits of /scripts/init-premount/udev by hand, the SCSI devices appeared, and I could manually assemble the mirror, and mount the root filesystem, which was handy, because I also discovered that you can boot with debug on the kernel command line, and it logs the initramfs run to /tmp/initramfs.debug. So that was a convenient way of preserving the log, because there seemed to be some characters in it that made inspecting it over the serial console difficult, and there was no way to get it off the machine from the initramfs environment.

As far as I can determine, it's telling udev to start, but it certainly isn't still running when it bombs out to a shell after failing to mount the root filesystem. It's not immediately clear if there's something later on that is stopping it again. I've put the log here in case anyone's interested in looking at it. This was with the addition of "x" to the options of the shebang line of /usr/share/initramfs-tools/scripts/init-premount/udev so that I could see what was happening when /scripts/init-premount/udev ran.

So I don't think the kernel itself is at fault, it's some sort of weird udev/initramfs interaction.

Rather than further rebooting the tripe out of daedalus, I'll have to see if I can reproduce the problem on a less important machine locally to do further debugging. In the meantime, I'll have to stick with 2.6.18.

The current autofs package in Debian unstable has twenty-nine patches applied to it.

The Ubuntu autofs package in Hardy Heron LTS has thirty patches applied to it (twenty-nine of them being the Debian ones).

We discovered a bug today in Hardy's autofs, which will undoubtedly also affect Debian's autofs as well, which is apparently fixed in the likes of Red Hat Enterprise Linux for something like four years.

So either Red Hat is doing a shoddy job of feeding patches back upstream, or upstream is doing a shoddy job of accepting them.

The fact that Debian has to carry twenty-nine patches suggests something is similarly wrong in our camp.

We've been finding various problems in autofs in our environment recently, and have accumulated maybe half a dozen patches or so in the last month. I'll have to make sure that they get fed back into Debian and Ubuntu at the very least. Given the nature of one of the bugs we found today, I have grave doubts about the code quality of autofs. I have to wonder if it's worth rewriting from scratch in Python or something.

Martin Krafft did a nice, if overly complicated writeup on disk encryption with Debian.

Martin stated his main motivation for the setup he describes is having separate filesystems whilst still employing encryption, and not entering a passphrase per filesystem at boot.

My laptop is encrypted. I have multiple filesystems, and I only enter one passphrase at boot. I used the standard installer and did nothing beyond what it offered me. I'm using LVM. I have an encrypted root filesystem and an encrypted PV for LVM, and that's the end of my partitioning.

I thought I'd throw the Etch and a half kernel on my laptop, mainly because I wanted better battery performance, which I suspected I'd get (and powertop would work).

So far, all I've noticed is

apollock@frobnitz:~$ sudo iwlist eth1 scan 1>/dev/null
Warning: Driver for device eth1 has been compiled with version 22
of Wireless Extension, while this program supports up to version 20.
Some things may be broken...

It seems the appropriate people are already aware of it, and it's purely cosmetic.

Holger was wondering what tense people write their changelog entries in.

I'm pretty sure I always write mine in the past tense.

Steven Hanley was pondering how to keep /var/cache/apt/archives empty on the mirror that I help administer.

This sounds vaguely similar to mounting the /usr filesystem read-write at the start of an APT run and read-only again at the end. (A practice I used to believe in, but due to various package upgrades making /usr busy for no good reason, and it artificially inflating the maximal mount-count and prematurely causing a fsck at boot, I've discontinued)

So, putting

DPkg::Post-Invoke { "apt-get clean"; };

in /etc/apt/apt.conf (or in a file in /etc/apt/apt.conf.d) ought to do the trick.

Steve Kemp holds the opinion that "Debian package maintainers should be able to program/debug handle the language a package is developed in" to be a package maintainer for that software.

Naturally, as a non-C programmer, maintaining multiple packages in Debian of software written in C, I disagree.

Any bug in the software packaged is inherently an upstream bug, and the problem of the upstream author. As a Debian package maintainer, I'm responsible for how the software is packaged and integrates with the rest of the Debian operating system, but I think to make it a requirement to be overly familiar with the code base itself is too onerous.

My view is more that if the Debian package maintainer doesn't have a good relationship with the upstream author, then they should reconsider packaging it (depending on the complexity of the package).

For most of the packages that I maintain, I have a reasonably good relationship with the authors. For dhcp3, I've met with the guys from the ISC a few times, and follow their mailing lists. For dstat, the upstream author is subscribed to the package via the PTS, and pretty much always chimes in on bugs filed by Debian users.

I don't know C, but I can (generally) read it, I can (usually) refit a patch if necessary, and I know how to drive strace (but sadly not GDB terribly well). Having that skill set has served me well enough to date.

That's not to say I don't want to learn C, I've just always been served well enough by a higher level language like Perl, PHP or Python, that I've not felt the need to go cutting my teeth on C (I have always felt less of a man, not being a C hacker, though).

I have a hankering to try and write an application for Asterisk, so that'd require me to do it in C, so maybe I'll get a chance sometime soon.

So today is the third anniversary of my first upload of the ISC DHCP v3 package to Debian.

It all started back in the days of the linux.conf.au 2005 organising committee. Bob Edwards, who ran the ANU Department of Computer Science computer labs (which ran on Debian at the time), was constantly complaining about bugs like #286011, once he'd found out I was a Debian developer.

So I figured I'd try and do something about it, so I think I emailed the maintainers, who had been fairly inactive (the last upload before mine was in July the year before), and asked if they'd like me to NMU the package.

I think Matt Zimmerman emailed me back and told me to knock myself out, and add myself as an uploader while I was at it, and well, the rest is history...

I've had fun fixing bugs, trying to clean things up, deal with a pretty archaic upstream build system and get the package up to current Debian standards compliance. One of the highlights was being able to finally get rid of Debian Installer's dependence on the v2 DHCP client package, so we could finally jettison the v2 packages for Lenny (which reminds me, I still have to figure out how to handle the transition from Etch with respect to that).

I've been working hard to try and get as many of the patches in Debian's DHCP packages incorporated upstream. Unfortunately, they have a totally unpredictable release cycle, and they have feature releases and bug fix releases. The feature releases are very few and far between, and they won't introduce new features into a bugfix release.

Speaking of patches, my personal philosophy is that distribution packages shouldn't differ radically in behaviour or functionality from their upstream source, so I've resisted incorporating some of the more deviant patches from Ubuntu, instead forwarding them directly upstream.

There's still a bit of work to be done with the package. The ISC released version 3.1.0 a while ago, and that's the version I'm trying to standardise on for Lenny. It's got new support for a domain-search option, which means people can stop abusing the domain-name option to set a domain search list in their clients. The domain-search option is also honoured by Mac OS X (Leopard), and I dare say Windows Vista probably supports it as well, but I haven't checked.

Unfortunately the client-side support for the domain-search option is a bit flaky in 3.1.0, so I'm hoping the ISC will release 3.1.1 real soon now, as I believe most of the flakiness issues are addressed in it. Of course, for Lenny to do the right thing consistently with this new option, #460609 and #465158 need to be resolved also.

The last thing I'm trying to sort out for Lenny is the reasonably in-demand LDAP patch. It's been floating around out-of-tree for longer than I've been maintaining the package. José L. Redrejo Rodríguez has been kind enough to clean up the patch for me, so that rather than bastardising the standard DHCP package to build a dhcp3-server package that has LDAP support, it basically builds DHCP twice, once with the patch and once without, and the dhcp3-server-ldap package just diverts /usr/sbin/dhcpd3 out of the way and plonks in the LDAP-enabled binary in its place. I hope to upload a new revision of the package that builds this new binary package within the next week (hopefully this weekend).

After that's done, and hopefully 3.1.1 has been released, and Lenny is out of the way, I'm going to focus on transitioning away from a versioned set of DHCP packages. The whole "3" in everything was to allow the v2 and v3 packages to coexist. I've sought advice from the release team about this, and they said not to bother, but it feels really gross to have the version 4 package (4.0.0 has been released by the ISC for a while now as well) be still called dhcp3, and to install into /etc/dhcp3 and other such versioned directories.

The final thing I want to look into is collaborative maintenance. I've been wanting to do this for a while, but I wanted to get the package into a revision control system (shock horror, it's not currently) and I've been baulking at how to do it the "right" way. I'm pretty sold on using Git for the revision control system, I just haven't figured out the right approach yet. Martin Krafft's articles about it have been interesting, but feel a bit overly advanced, and don't quite suit my situation. I've been hesitant to start using Git, then discover I've done it all wrong, and have to start again. I need to just bite the bullet. My upstream also doesn't use Git, and doesn't make their revision control system publicly available, so I just get the tarballs when they're released.

Speaking of upstream, I made the discovery last year that they're just down the road from me in Redwood City, so I've been trying to improve relations by getting the main folks who work on DHCP at ISC to pop up to Google for lunch every now and then, which so far has happened twice, and been good a opportunity to have a chat. In fact, they're keen for Debian to join the DHCP Forum (Debian is already a member of the BIND Forum) and I think they've started talking to the Debian folks responsible for our BIND Forum membership about extending that to cover the DHCP Forum as well.

So that's about it. I think after three years of being the sole uploader, I'll formally put myself in as the maintainer and Eloy as an uploader until I get around to implementing collaborative maintenance.

I've been a bit behind with the ISC DHCP v3 package of late. I've had a package of 3.1.0 for a few months, but I'm becoming more and more reluctant to make uploads of this package without giving it some rudimentary testing. Real life has been demanding of late, so I haven't had a chance to do that testing. Nothing's gone wrong with the package to date, I just feel negligent not giving it some basic testing before throwing it out there.

So I chucked a spare QFE card in my workstation brutus, put unstable on the second hard drive, installed Debian unstable on the spare 10G partition of Sarah's old PowerBook, and lashed the two together with a bit of CAT-5, and voila, instant DHCP client/server testbed.

So now that I'd verified that version 3.1.0 wasn't blatantly broken, I could have a fiddle with the new support for option 119 (domain-search) that has people at work very excited. I spent a bit of time off on a wild goose chase trying to figure out how to configure the DHCP server for this new option before I realised it was as simple as option domain-search "foo bar baz"; and then made the necessary tweaks to dhclient-script.

I'm figuring that since one of the blokes who wrote the RFC works at Apple, and since Leopard supports option 119, the way they're doing it in Leopard must be approximately correct, so I've altered the behaviour of the DHCP client accordingly.

All of this assumes you're not using resolvconf.

Prior to 3.1.0, if you had the domain-name option set, the /etc/resolv.conf created by dhclient-script would set the search directive to the domain name. With 3.1.0, I've decided to make this set the domain option instead. The resolver behaviour remains the same, as best as I can determine.

With 3.1.0, if the domain-search option is set, then the search directive is set to this. If the domain-name option is set, this is prepended to the list of domains in the domain-search option. This is consistent with what MacOS X 10.5 (Leopard) does. I'm not sure what Windows does (nor what version started honouring the domain-search DHCP option)), and since it doesn't have an /etc/resolv.conf equivalent, it's a bit hard to test. I'm going to hazard a guess and hope that since the other bloke who wrote the RFC works for Microsoft, that maybe, just maybe, Windows and MacOS X at least behave the same way.

Currently, if resolvconf is in use, you get the old behaviour whereby the search directive is populated with the contents of the domain-name option, and the domain-search option is ignored completely. I've filed #460609 with a patch to fix this. Interestingly, resolvconf itself internally collapses the domain and search directives into the search directive of the /etc/resolv.conf it generates, so I can't quite get the same /etc/resolv.conf generated as would be generated without resolvconf being used. No big deal, the behaviour should be the same. The domain directive is largely unnecessary as I understand it.

I have unearthed what I consider to be a bug with the domain-search option handling code in the client. It seems to be largely benign, apart from causing the client to emit some errors when it's obtaining a lease that contains the domain-search option, and possibly not splitting the domains in the domain-search option correctly. There's also another (I think unrelated) warning that gets emitted as well. I'm waiting to hear back from upstream about both.

I'm not going to package the recently released 4.0 DHCP until I've figured out a transition plan to go from the old DHCP v2 packages to the v3 ones.

I've been procrastinating writing about my Boston trip, for no particular reason.

A bunch of us went to the Boston Ubuntu Developer Summit (in Cambridge, actually) for work purposes. We currently derive from the Long Term Support releases, and Hardy Heron is going to be an LTS, so I wanted us to get more involved directly, particularly at this stage of the game, rather than after it's already a done thing.

Anyway, the reason I'm writing this in the "Debian" category is I found the whole thing to be totally awesome. Debian should do something similar.

Rather than being a conference, this was essentially a week of 1-2 hour small-group meetings to discuss various features for Hardy. I thought it worked pretty well. I'd never seen gobby used before, and it's basically a poor-man's Google Docs (although one could argue it handles real-time collaborative editing better).

They had VoIP up the wazoo. You could dial into a conference bridge to just listen in, or you could dial a different bridge to participate. Every room had a Polycom conference phone in it. That seemed to work pretty well.

I think the main reason I think Debian could take a leaf out of Ubuntu's book on this was it helps resolve potentially controversial technical decisions very quickly. Rather than having a two week protracted flame war on a mailing list, you can have a 30 minute rational debate in person and move on.

So I've no idea how this UDS stacked up to previous ones, but I was very impressed by the whole thing. I'm in total awe of Scott James Remnant and Colin Watson for not having burned out by now. Doing a release every 6 months, with all the associated stuff that goes around it (i.e. running a UDS) has got to take it out of you.

I'm pleased to learn from Romain Francoise that only 3.1% of packages aren't shipping md5sums of their contents. I was pleasantly surprised recently to discover that the level of participation seemed to be a lot higher than I'd previously thought.

So given that Debian tends to make things policy after they've got broad adoption, I wonder if we should make providing md5sums standard practice now?

The RPM proponents have always touted rpm -V as one of the things that it did that Debian didn't.

Gustavo Franco with madison-lite

Screw writing something, what I had in mind was something exactly like madison anyway. Pity I didn't think to just use it. Duh.

Now if only the repository in question didn't have such an incredibly shite layout, I could achieve what I want to achieve without having to have multiple config files and multiple runs of madison-lite with multiple configuration files.

Dearest Lazyweb,

I want to write a program that I can point at a standard repository, and an in-house one, so I can track version differences between common packages.

I wanted to write this in Python, so python-apt sprang to mind, however the documentation is somewhat lacking, and none of the examples include retrieving a package list from anything other than the local APT cache.

The documentation in libapt-pkg-doc is also rather lacking.

So before I go giving up on using a "proper" library for the task, I thought I'd reach out.

Love, and sloppy kisses,

Andrew

So Debconf 7 has been good. Very good. I suck at writing up such events, but I found it a great opportunity to hack on my packages. I got my laptop setup so I could work moderately effectively offline (there's still more I can do), and I was able to work on the DHCP 3 packages fairly heavily.

I'm particularly pleased that I fixed two long-standing bug-bears: the fact that the package only complied with a Standards-Version from about 5 years ago, and that the DHCP client udeb for the installer didn't work. I've fixed both of those issues, and done a pile of bug triage. Very happy.

Due to various talks about git, I've also gotten over my fear of it, and had a play. It still fries my brane big time, but at least I've had a play.

Onward to Dublin. Let's see if I can successfully reapply for my visa.