I don't usually get around to blogging about UDS, but since I've got a couple of hours to kill and WiFi on the plane, I might as well write something while it's all fresh in my mind.

Unfortunately, I came down with a head cold on the way back from Australia, so I was not my usual perky self all week, so as a result I probably did less networking than usual, but I did start to feel more human by the end of the week.

Four of us from work went, and I think this worked out well, as our kernel engineer was able to cover the kernel track, and there were frequently three applicable sessions on in parallel, so this allowed for good coverage.

That said, there were frequently less than three things of interest as well, and I take this as a good sign: there aren't plans to really do too much weird or wonderfully different things in 10.04, which I think is the right approach for an LTS. Couple that with the fact that Lucid is based off Debian's testing distribution instead of unstable, and I've come away from UDS with a very good feeling that the third time is going to be the charm as far as Ubuntu LTS releases go.

This was also the first time that we submitted blueprints of our own. I think the upgrading running software one was well received. There was certainly a lot of discussion. I'm not sure if anything will be implemented for Lucid, but at least we got the problem onto the radar.

We also managed to score an impromptu demonstration of Landscape, and while I don't think it's quite at the point where we'd want to buy it, it definitely has potential and apparently all of the things that we found to be lacking have already been identified as features that need to be added, so I think that maybe by a 2.0 release, it'll be more compelling. I don't think the Dedicated Server Edition existed last time I'd looked at it, and this sounds like a much more sensible (and reasonably priced) option.

This was my fourth UDS. The first one being the one for the Hardy Heron 8.04 LTS release. The entire team went to that one, and we were all completely uncalibrated for UDS and didn't really know how or if that UDS differed from ones for non-LTS releases. Since then I've learned that every UDS is different anyway, and it's a fairly evolutionary process. Aside from the venue being multi-level, which I think hampered networking, I thought this UDS was the best facilitated one yet.

I was very pleased to see that for the next Long Term Support version of Ubuntu, it's going to be syncing with Debian Testing instead of Debian Unstable.

This was something I brought up in a discussion at the Ubuntu Developer Summit in Barcelona. I always found it somewhat silly that from a development standpoint, an LTS version of Ubuntu was created no differently from a non-LTS version. It still synced from Debian Unstable, it still stabilised over the same 6 month period. They just toned back the release goals so it wasn't quite so full of new, crazy stuff. A high-quality, long-term supportable Linux distribution this does not necessarily make.

As Steve points out, the downside of this new approach is that bug fixes will take longer to appear in Debian Testing, and thus in Ubuntu. I'll be watching how this development cycle pans out with much interest.

Me, I'd go to security.ubuntu.com, because I think I can (successfully) go to security.debian.org to get the functional equivalent. But no, that gives me nothing useful. Apparently one has to go to the less intuitively named www.ubuntu.com/usn

I'll have to see if I can get the former to redirect to the latter.

Update

www.ubuntu.com/security is slightly more intuitive and does what you'd expect.

10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2

Sheesh.

apollock@caesar:~$ host mirrors.kernel.org
mirrors.kernel.org has address 204.152.191.7
mirrors.kernel.org has address 204.152.191.39
mirrors.kernel.org mail is handled by 10 hera.kernel.org.
mirrors.kernel.org mail is handled by 20 zeus1.kernel.org.
mirrors.kernel.org mail is handled by 30 zeus2.kernel.org.
mirrors.kernel.org mail is handled by 999 bl-ckh-le.kernel.org.
apollock@caesar:~$ GET -H mirrors.kernel.org http://204.152.191.7/ubuntu/dists/hardy/Release | md5sum
4f053c0db4bc9d851059c0899b85f338  -
apollock@caesar:~$ GET -H mirrors.kernel.org http://204.152.191.39/ubuntu/dists/hardy/Release | md5sum
c4ba9d980e675875079bf5fea46cffd2  -

It's shit like this that makes my job that much more difficult. Back to archive.ubuntu.com we scurry. (This is obviously not Ubuntu's fault, it's just a pain in the arse nevertheless)

Disclaimer: I may well be an ignoramus with respect to the release schedule for Firefox 3 with respect to the release schedule of Hardy.

It grabs me as breathtakingly stupid to be shipping a Long Term Release of Ubuntu with a pre-release version of Firefox. I can't see how anyone can think this is a good idea.

That said, I remember a thread on ubuntu-devel, where someone was shot down for complaining about a release candidate of the Gimp shipping with Gutsy, so there's certainly a precedent for shipping stable versions of Ubuntu with non-released versions of software. I still think it's sloppy. "Bleeding edge" and "stable release" should be mutually exclusive, yet it seems they're not.

I predict dragons ahead.

ubuntu-keyring

I'm struggling to understand, from a casual inspection, what the change that introduced this is trying to achieve.

So it was trying to fix this bug, which is actually in a completely separate package.

I guess the first thing is to understand what this net-update mode for apt-key is.

Aha. That appears to be an Ubuntu-ism: AptArchiveKeySignatures

Anyway, having looked at the /etc/cron.daily/apt script that ships with Ubuntu's apt package, I fail to see how the changes to ubuntu-keyring address bug 192074. The net_update() function of apt-key is still going to spit out stuff.

Oh wait, I see. The cron job will still spit out output when it actually decides that something should have been done. The presence of /var/lib/apt/keyrings/ubuntu-archive-keyring.gpg will mean the stat call will return a valid mtime, so more often than not, because the mtime is unchanged, the cron job won't feel the need to actually do anything that produces output. I guess it's reasonable to produce output on the odd occasion that a key update actually occurs. Fair enough.

I'm not sure I'd be using mtimes to make the decision though. I'd be more inclined to use the MD5 checksum of the files, but that's just me.

So guess I've now had less of a casual inspection, and understand what the change was trying to achieve. It just failed miserably by not ensuring the directory existed. Oh well, patch supplied.

So I started an Ubuntu category in my blog a while ago, the intention being to document the trials and tribulations of trying to derive (and I use the term loosely) another distro.

The hope has been to get it added to Planet Ubuntu's feed, where I'd like to engage in some discourse with the Ubuntu development community, and perhaps challenge some of aspects of how they do things.

I'm not feeding it to Planet Debian, since me blathering on about Ubuntu's foibles is probably not of interest to that audience.