I got an email last year pointing out a cosmetic issue with changelogs.debian.net. I think at the time of the email, the only problem was some bitrot in PHP's built-in server variables making some text appear incorrectly.

I duly added something to my TODO list to fix it, and it subsequently sat there for like 13 months. In the ensuing time, Debian changed some stuff, and my code started incorrectly handling a 302 as well, which actually broke it good and proper.

I finally got around to fixing it.

I also fixed a problem where sometimes there can be multiple entries in the Sources file for a package (switching to using api.ftp-master.debian.org would also address this), which caused sometimes caused an incorrect version of the changelog to be returned.

In the resulting tinkering, I learned about api.ftp-master.debian.org, which is totally awesome. I could stop maintaining and parsing a local copy of sid's Sources file, and just make a call to this instead.

Finally, I added linking to CVEs, because it was a quick thing to do, and adds value.

In light of api.ftp-master.debian.org, I'm very tempted to rewrite the redirector. The code is very old and hard for present-day Andrew to maintain, and I despise PHP. I'd rather write it in Python today, with some proper test coverage. I could also potentially host it on AppEngine instead of locally, just so I get some experience with AppEngine

It's also been suggested that I fold the changes into the changelog hosting on ftp-master.debian.org. I'm hesitant to do this, as it would require changing the output from plain text to HTML, which would mess up consumers of the plain text (like the current implementation of changelogs.debian.net)

I picked up Zoe from Sarah this morning and dropped her at Kindergarten. Traffic seemed particularly bad this morning, or I'm just out of practice.

I spent the day powering through the last two parts of the registration block of my real estate licence training. I've got one more piece of assessment to do, and then it should be done. The rest is all dead-tree written stuff that I have to mail off to get marked.

Zoe's doing tennis this term as her extra-curricular activity, and it's on a Tuesday afternoon after Kindergarten at the tennis court next door.

I'm not sure what proportion of the class is continuing on from previous terms, and so how far behind the eight ball Zoe will be, but she seemed to do okay today, and she seemed to enjoy it. Megan's in the class too, and that didn't seem to result in too much cross-distraction.

After that, we came home and just pottered around for a bit and then Zoe watched some TV until Sarah came to pick her up.

I have a couple of virt-manager virtual machines for doing DHCP-related work. I have one for the DHCP server and one for the DHCP client, and I have a private network between the two so I can simulate DHCP requests without messing up anything else. It works nicely.

I got a bit carried away, and I use LVM to snapshots for the work I do, so that when I'm done I can throw away the virtual machine's disks and work with a new snapshot next time I want to do something.

I have a cron job, that on a good day, fires up the virtual machines using the master logical volumes and does a dist-upgrade on a weekly basis. It seems to have varying degrees of success though.

So I fired up my VMs to do some investigation of the problem for #749410 and discovered that they weren't booting, because the initramfs couldn't find the root filesystem.

Upon investigation, the problem seemed to be that the logical volumes weren't getting activated. I didn't get to the bottom of why, but a manual activation of the logical volumes allowed the instances to continue booting successfully, and after doing manual dist-upgrades and kernel upgrades, they booted cleanly again. I'm not sure if I got hit by a passing bug in unstable, or what the problem was. I did burn about 2.5 hours just fixing everything up though.

Then I realised that there'd been more activity on the bug since I'd last read it while I was on vacation, and half the investigation I needed to do wasn't necessary any more. Lesson learned.

I haven't got to the bottom of the bug yet, but I had a fun day anyway.

I managed to spend a few hours doing Debian stuff again today, which was great.

Today I learned about blhc, which is sadly not mentioned in the wiki page on hardening, which I always refer to. It turns out that it is mentioned in the walkthrough wiki page linked off it though. I'd not read that page until today. Many thanks to Samuel Bronson on IRC for pointing out the tool to me.

Initially I didn't think the tool told me anything I didn't already know, but then I realised it was saying that the upstream Makefile wasn't passing in $(CPPFLAGS) and $(LDFLAGS) when it invoked the compiler. Know that I know all of that, the build warning also mentioned in the PTS made a whole lot more sense. Definitely a case of "today I learned..."

So I made a simple patch to the upstream Makefile.in and simpleproxy is now all appropriately hardened. I'm very happy about that, as it was annoying me that it wasn't Lintian-clean.

I was able to use the same technique to similarly fix up sma. It's somewhat entertaining when you maintain a package for almost 7 years, and the upstream homepage changes from being the software author's website to what appears to be erotic fiction advertising for London escorts... That made for some entertaining reading this morning.

I've now managed to give all my packages a spring clean. I might do another pass and convert them all to debhelper 9 as a way of procrastinating before I touch isc-dhcp.

I had a really productive day today actually working on Debian, as planned for my Mondays.

I'm still working through my list of packages, trying to get them all vaguely up to date for jessie. It's mostly just addressing Lintian issues that mostly revolve around old standards versions, with the occasional new upstream release. I've also been doing bug triage where the bugs aren't overwhelming.

Today I made uploads for pssh (a new upstream release), pymetrics (mostly just a rebuild), rcs-blame (mostly just a rebuild) and simpleproxy (mostly just a rebuild).

I need to revisit simpleproxy, because I'm having problems convincing the resulting binary to be linked correctly for relro. It's weird, because I'm doing everything I'm supposed to be doing and I can see all the other hardening flags being passed in except for this one.

I really like simplifying down debian/rules using dh, that really makes things readable. You can see the useful stuff without losing it in all the boilerplate. For some reason I was never a fan of CDBS, but I'm quite liking dh. I think it's because it's less opaque than CDBS.

I received a complaint about the frequency of my life category posts appearing on Planet Debian. It's the first such complaint I've received, whereas I've received more complimentary feedback, presumably from readers via Planet Debian.

It has made me self-conscious about my posts, though, and I don't want it to affect my blogging, so I've pulled the life category from what I feed to Planet Debian. If you want to keep up with the minutia of my life, and you were doing that via Planet Debian, you'll have to follow my blog directly.

My apologies if anyone was annoyed.

Various security folks at work have been keen on a newer version of audit be in Ubuntu (preferably 12.04), but unfortunately the Debian maintainer has been too busy to package it for Debian, so I finally carved out some time recently to do an upload to experimental, with his permission.

It would have been really nice to land it in unstable before Wheezy froze, but as it involved a library transition, and I didn't get a chance to talk to the release team about it until very close to the freeze, they said it was too late.

That meant the grand plan of getting it into Ubuntu 12.10 and then trying to get it into precise-backports went up in smoke as well. Oh well.

It was a fair bit of work to package. A lot of the patches were no longer relevant, and the remaining ones all needed to be refitted. It was also my first attempt at touching a library package where a SONAME bump was involved. I think I did everything correctly.

I really should write these a bit more often.

Wow, I can't believe it was over 4 years ago that I started having occasional face to face meetings with the ISC DHCP folks.

The entire ISC DHCP team (of 5) was in town for an all-hands meeting, and Larissa Shapiro, the Product Manager for DHCP (and BIND) suggested it would be a good opportunity for another catch up. Given the current (bad) state of DHCP 4.2 in unstable, I thought this was an excellent idea, and so we all had lunch on Tuesday.

I pretty much set the agenda, and it was

• general state of 4.2.2 in Debian
• situation with GNU/Hurd and their patch to fix an FTBFS (#616290)
• the current FTBFS issues with kFreeBSD (#643569)
• the embedded BIND sources in the DHCP source
• removal of the RFCs from the embedded BIND source (#645760)

The general state of 4.2.2 in Debian

In a nutshell, it's a bit of a mess. We've got release critical bugs, build failures, the whole cat and kaboodle. It makes me very sad, because 4.2.2 was the first 4.2 series that I had a chance to upload, and I was very excited to do so, because it contains the hotly desired LDAP patches merged upstream. Unfortunately, it's also got the beginnings of the BIND/DHCP merger that's going to be BIND 10, and that is all a bit of a mess. It's directly responsible for the kFreeBSD FTBFS and the introduction of the RFCs, which are both keeping 4.2.2 out of testing.

I gave the ISC folks a high-level overview of how Debian development works, and the normal progression of packages from unstable to testing to stable, and the release process and whatnot, and impressed upon them the implications of the current release critical bugs. I also showed them how Ubuntu development fitted into the picture. Finally, I showed them the popcon statistics for DHCP. I think they found it useful.

FTBFS issues on kFreeBSD

This was a good segue to #643569. The issue is actually with the embedded BIND sources. I'd already forwarded this bug upstream when it first happened, but I don't know what had happened to it. They seemed to act as if this was the first they'd heard of it. I'm hoping that they can get this fixed in 4.2.3, which is due around the end of the quarter.

Embedded BIND sources

Since we were already talking about an issue caused by the embedded BIND sources, we moved on to talking about #645760 and the existence of the embedded BIND sources in general. It should be pretty straightforward for them to strip the RFCs out of the source. They've already done it in the past for the DHCP sources, so I'm also hopeful that this will get resolved in 4.2.3.

The issue of the embedded BIND sources is apparently a bit more complicated, although the day before our meeting, Michael Gilbert filed #643569 and #645760, so I hope that the ISC folks can take a look at these patches and see if it's feasible to adopt them.

Patches for GNU/Hurd

Finally we talked about #616290, which I know is near and dear to the GNU/Hurd porters' hearts.

We probably spent the most time talking about this. The DHCP developers have concerns about accepting a patch for an OS that they do absolutely no testing on, and also questioned the viability of the OS in general. They stressed that they're fairly thin in numbers relative to what they have on their plate to achieve this year, and so pushed back pretty firmly on accepting the current patch.

I relayed the frustration that the Hurd folks were having about a lack of dialogue around the patch (most of the interaction has been via an ISC support person). There was actually a bit of a split between the developers, with one of them appreciating that the Hurd was unlikely to go anywhere as a platform without a working DHCP client, so in some regards, they were condemning the platform by taking the position they were taking.

They're going to go away and take another look at the patch and try to come back with some actionable feedback on what needs to change to make it more acceptable to them, so we'll see what comes of this. I'm not particularly optimistic that anything acceptable to the GNU/Hurd folks is likely to happen any time soon, but maybe if the patch gets cleaned up a bit more, I'll just bite the bullet and start applying it to the Debian package.

BIND 10

One of the guys is more involved in BIND 10 than DHCP, and asked if I could help out with the packaging of a build dependency for BIND 10. It seemed like #578387 was languishing so I offered to pick it up. I've not packaged a library before, mainly because the library packaging guide has scared me off it (I feel I lack the deep C fu that seems necessary), but I figured that this would be a good learning opportunity, so I'm going to dive in.

I just discovered that I'd been hit by #409864 since upgrading to Lenny. A very unfortunate bug that one. I'm surprised it hasn't been fixed in a point release.

As readers of my blog (who care about Debian stuff) may know, I've been plugging away at the DHCP 4.x packages for some time now.

I first uploaded 4.1.1-P1-7 to unstable in early July, then -8 in mid-July followed by -9 in late July.

The main reason for the delay (beyond my lack of spare time) was the coordination with third-party packages that were plonking hooks into /etc/dhcp3/dhclient-{enter,exit}-hooks.d. Once that got all squared away, the release team gave me the green light to upload to unstable. On the 26th of July, 4.1.1-P1-9 made it into the testing distribution.

Rather unfortunately (for me), the release team then declared testing frozen on August 6. I'd been hoping for a few more iterations on the package after getting feedback from the testing user base. Alas, it was not to be.

One piece of feedback I did get on August 9 was release critical bug #592361, which made me very sad, because I totally agreed with the severity of it. It was an upstream issue, and I immediately escalated it to upstream. Unfortunately, they did not get back to me particularly quickly (I had to use some back channels to get a response at all).

I eventually got the response I was pretty much expecting: I was going to have to directly patch configure.ac to make it stop trying to link with libcrypto. To complicate matters, the LDAP patch also goes and messes with configure.ac, so it required some fiddling with the LDAP patch as well. I figured I could wrap my head around it all, it was just some patch wrangling, but with parenthood and a wife who was trying to be a full-time mother as well as a part-time student-by-correspondence, large chunks of spare time were not in great abundance.

So I've had this bug niggling away at the back of my mind for literally months now, when in sails Simon McVittie with a patch. Hallelujah, I said to myself. I could just take this guy's patch, and we'd all be home and hosed. So I spent a bunch of hours yesterday, while I was at home trying to kick a cold, faffing around with his patch and trying to get it to build.

Alas, it would not build.

I went to bed far too late last night, feeling like I was on the verge of having it work, but it wasn't. I emailed Simon back today, and he quickly got back to me with the (easy) fix, and tonight, I am in business! The much awaited 4.1.1-P1-10 is uploaded to unstable.

I'm still not particularly happy with the state of the package though. The supplied dhclient-script doesn't properly support DHCPv6, and I'm in no position to quickly rectify this, unfortunately, especially in light of the freeze.

If you are interested in helping test pre-releases of an updated dhclient-script, please feel free to subscribe to pkg-dhcp-devel@lists.alioth.debian.org, and I'll coordinate such activities on that list in the near future.

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.