I didn’t get a lousy t-shirt, but I suppose I could make one. And put lice in it.
There have probably been at least a few people who haven’t heard of this, so: if people were unfortunate enough to be running Ubuntu Hardy (the development version that will become Ubuntu 8.04 in late April) yesterday and upgraded libc6 to 2.7-9ubuntu1, their system broke. It broke immediately, if they (like me) were running the upgrade process under sudo, because sudo started refusing to launch dpkg, and segfaulting.
There are a bunch of solutions to this, none of them particularly obvious to anyone who hasn’t had a broken libc6 in the last little while (the whole thing took me right back to when Debian unstable lived up to its name and used to do things like break lilo a lot — for that matter, it took me back to when I used lilo). Hrm, this is going to be one of those things, isn’t it, where none of them particularly obvious
is going to be read as help, I haven’t fixed it, please send advice
? Don’t you worry, I have fixed it on my machine. If you’re actually affected, go try the solutions described at the top of the relevant (now fixed) bug, bug 201673 (note that I had to also reinstall libc6-i686, which not a lot of people seem to mention). If you don’t want to be affected, either don’t be using Ubuntu Hardy right now, or, if you are, don’t upgrade libc6 or anything libc-like to Ubuntu version 2.7-9ubuntu1 (2.7-9ubuntu2 is fixed though). It should be more or less passed now, but maybe some mirrors won’t update for a little while still, I guess. The bad version was marked unreadable in the main package archive, which was probably not exactly useless but not as helpful as #ubuntu+1 claimed either, because the mirrors, including the official mirrors, were still distributing the broken package merrily enough.
Anyway, there were a couple of interesting things about this, from an observer’s point of view. The first is that every second person in the forums and half of #ubuntu+1 had their own personal solution to the problem, most of them correct but some of them harder than others (dpkg -x makes needing to pull the different .tar.gz files out of a .deb unnecessary, and chroot /mnt dpkg -i is even better as it means that your package database will be up to date with your downgrade). I suppose there’s some bias here: the people who followed already posted solutions (like me) just didn’t contribute. It left a thread with the impression that there were about twenty potential fixes, all of which you’d have to try because the earlier ones hadn’t worked for some people, whereas in actual fact the earlier ones hadn’t been tried by some people.
The other is the in practice failure of claims along the lines of [as] is prominently mentioned in a number of places, you should not be using pre-release versions of Ubuntu unless you are comfortable dealing with occasional (even severe) breakage.
It’s only a partial failure: there are plenty of people who heed this and don’t whine (publicly) when development releases break. But there’s certainly a lot of people who don’t, and while you can chide them, you also still have to handhold them through fixing their system afterwards. In fact, it might even be a slight problem: the only people who heed the warning and don’t install development releases are the kind of people who read warnings and heed them, people who by inclination aren’t noisy and whiny. So you get a pretty whiny testing base (on top of the people who are seriously involved testers).
I tend to test pre-release Ubuntu and file bugs because if I don’t, I can be stuck with broken hardware or regressed software for an entire six month official release cycle (breaking hardware is more of a laptop thing). After my experiences with Hardy though I think I’ll go back to my old policy of upgrading at the beta release, rather than before it. Beta should be March 27, then you can find out about all the remaining bugs that are seriously annoying me, still.