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.

Thursday was our fourth wedding anniversary. To mark the occasion, we had dinner and a show in San Francisco.

We had dinner at Farallon, which is an absolutely gorgeous restaurant. They've really gone to some trouble with the decor. It's very well themed.

We then high-tailed it a few blocks to the Orpheum Theatre and we just got to our seats when they turned down the lights to start Wicked.

Now I am most certainly not a fan of musicals. I can't remember the last time I saw a live play or musical, but I absolutely loved this show. It was very well done. I loved the sets, and it was full of one-liners that made me chuckle, and the storyline itself was very good. We had a thoroughly enjoyable evening.

It's been a while since we've done a road trip, so we're making up for that for having a bit of an epic one...

Our neighbours from a few doors down, who we're really good friends with, are sadly moving to Atlanta. Chris got a job at Georgia Tech as an associate professor.

He was intending to do an insane drive with his mother to get their two cars from here to there, which didn't strike us as being particularly safe. I could do with some time off, and we want to see more of the US while we're here, so we offered to drive one of the cars for them, so him and his mum can alternate driving the one car.

So tomorrow afternoon we're heading out. We're looking at doing it in about 5 days, spending a few days in Atlanta, and then flying back.

We're hoping to drive to Needles, California, the first night, then Roswell, New Mexico (via Albuquerque) the next day, then Dallas, Texas, the next day, then Jackson, Mississippi the next day, and wind up in Atlanta, Georgia.

The following Saturday we're supposed to be going to the 1st birthday party of our former next-door neighbours' second son, in Sacramento, so rather than flying back to San Francisco on Friday and then driving to Sacramento on Saturday, we're just going to fly back to Sacramento from Atlanta on Saturday. We'll spend the night with them and then catch the train back to Mountain View on Sunday.

I'm then going to fly down to LA that night to spend the week in Santa Monica for work, which was what I was originally going to be doing next week, but I pushed it back a week for this trip.

So it's going to be a travel-heavy couple of weeks, but it should be fun. We're looking forward to the road trip and seeing a bit more of the country. This will be as far east as we've gone by car.

The Mountain View Public Library is a really fantastic public library. A little while ago, they redid the check out system and switched to using RFID for everything. I can walk in check out books and walk out again without having to interact with anyone.

I put a hold request for a book recently via the library's website, and it came in a few days ago, and just popped down to pick it up. All of the books on hold for people are on a set of shelves in the "holds" section, with a bit of paper sticking out of them with your name on it.

I was ferreting around these shelves, trying to find the P's, when I overheard a woman remarking semi-shocked to her husband about the privacy implications. She commented to a librarian stocking shelves nearby about how she worked in library in Fort Lauderdale, and weren't they concerned about privacy and everyone seeing what these people were reading? The librarian said that she guessed not.

I must have low privacy standards (or I guess everyone else who puts holds on books in the library does as well) because I really can't see a problem with the way the holds are done.

It would be horribly inefficient to have to ask at the counter for my book (the holds section would have had easily a hundred books on the shelves). The bit of paper has my name on it. Granted, it has a fraction of my middle name, so it's a little more personally identifying than it perhaps needs to be, but either way, I don't consider it a terrible invasion of my privacy.

As it was, I was able to walk in, find my book, use a self-checkout machine and walk out again. For that convenience, I'm prepared to lose a little bit of privacy if someone wants to spend all day, every day, casing the holds section of the library just to try and figure out that I'm reading Good calories, bad calories

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.

Chromium bug 13395 has been fixed. All is right with the world.

I've been sufficiently annoyed by this to try and file a bug against Facebook (we'll see how well that works) and to go to the trouble of documenting the problem as I see it...

I have my blog importing into Facebook as what they call a "note". I figured, I could, so why not? It also gives me spam-free comment support for free (not that I particularly care about comments, people seem to be able to figure out how to email me if they really want to say something to me about a post).

I have a very rudimentary blogging setup. I'm using Blosxom (an old version at that). I hand-write my posts, and the HTML, in Vim. It works for me, and I can't be bothered changing it. Vim is set to wrap lines at 76 characters. I'm writing raw HTML, so sometimes it wraps sooner than it might if I was writing raw text.

The fact that I've got newlines in my HTML source doesn't seem to affect the way my blog is displayed, nor does it seem to mess up in anything else that consumes the RSS feed. Consider this recent post:

There's a newline after "in", there's a newline after "ask".

Here's how it gets mangled by Facebook:

It seems to have correctly ignored the newline characters, except everything else seems to treat the newline as whitespace. Facebook seems to just eat it completely, which mangles the words together.

This phenomenon is not observed in Planet:

Nor in Google Reader:

and of course it looks fine in its native environment:

So I'm really inclined to say that Facebook is doing it wrong. I haven't read an HTML specification yet to try and figure out if how this should be done is specifically codified, but it seems to make the most sense to treat a newline as whitespace - it's being used to break words.

I was just booking a flight and hotel accommodation for an upcoming work trip, and it occurred to me: why does everyone ask for the state and the ZIP code, when the state can be derived from the ZIP code?

For example, 94043. The first three digits fall within 900 to 961, so it's obviously in California.

It seems like such an annoying extra step to have to drop down a list and find your state. At least I'm in one close to the top.

I guess I could ask the same question about Australia. The state is similarly encoded in the post code.

Any system I ever have anything to do with in the future is not going to ask for the state.

I just learned via this article, that the Gold Coast Medical Association president's name is Philip Morris.