nbd 2.9.10

I Just released NBD 2.9.10. It had been upcoming for a while already, with a few interesting patches being applied. In addition, some bugfixes were applied to subversion, and some more interesting things had happened. Really, a release was getting overdue. Sometimes life just intervenes.

Anyway, apart from the upstream release, I of course also did a Debian update of these packages, which also contains some changes that had been pending for a while. Combined, the changelog mentions five different bugs of which none are l10n bugs, which is a record (there had been 5-bug uploads before, but those did include l10n bugs). On top of that, I closed some other outstanding bugs which really had been closed a while back, but either I forgot to close the bug, or I forgot that there even was a bug in the first place.

I should stop slacking so much.

While preparing this upload, it occurred to me that nbd has come a long way since I got involved with it back in 2001. The original nbd-server that Pavel Machek had written did work well, but it was a bit of a hack; it did not fork() upon startup or anything similar, so starting it was a pain. It could only serve one device at a time. It was not documented. It had no concept of a configuration file. The code, frankly, was also bit of a mess; it was written on a hack night, and not much design had gone into it.

I guess it was no surprise, then, that no single distribution had a package for nbd at the time. I only packaged it because I actually had some use for nbd; at the time, I'd just bought quickstep, my first functional m68k machine, and had installed Debian on its 250MB hard disk. However, running a buildd on that machine proved problematic, to say the least; with so little disk space, you could hardly boot Debian, and due to speed and clock skew issues, NFS was not an option. So I went with NBD, which worked great. After a while, quickstep got a bigger hard disk (it has an 18G disk today), so diskspace was less of an issue at that point; but, well, I'd been maintaining it already, and that was fun, so I didn't think of giving up.

When Pavel lost interest in nbd back in 2003, he gave maintenance of the kernel bits to Paul Clements, and maintenance of the userspace bits to me. I promptly went ahead with what I thought should have been done already, but felt reluctant to do at the time to suggest that: refactoring the code, adding features, etc. Today, nbd-server does support all of the above things of which I mentioned it was lacking; and, probably as a result of that, apart from Debian, there are now packages of nbd in, at least, SuSE, Fedora, Gentoo, uClibc, and FreeBSD (the latter obviously only containing the server). Well—the fact that LTSP uses it might have something to do with it, too

That's not to say there's nothing left to be done, but I'm quite happy about how far we've come. Really.

IRC nicknames

Yes, I too would like to explain that my name is 'Wouter', and not 'Yoe'. I've always considered nicknames a necessary evil—'wouter' usually being taken on most IRC networks I connect to, and 'retuow', as some have suggested, being far too silly—and one which I prefer not to be reminded of if at all possible. No, please don't ask why.

That being said, I must ask: Martin, if you're only mad on IRC, why does your hackergochi refer to your nickname, and why are your blog and hostname named after it, too? I find it helps people limit their use of my nickname to IRC if I do so, too.

Film: the story of the weeping camel

Just now, a movie was on TV. This was a non-fiction film, but it was still a story, rather than just a simple documentary or something; it only wasn't scripted or anything similar. The film is about a group of shepherds in Mongolia, who not only own sheep, but also camels, for transport. One of these camels gave birth to a rare white camel; however, the mother does not accept the young for some reason, despite the shepherds' best efforts.

Eventually, however, they did succeed in calming the mother, and persuading her to accept the young. What really blew me away, however, is how they did that:

By using music. Incredible.

So, next time you need to calm down a camel, here is the procedure:

1. Go by camel to the nearest town, and fetch a violinist.
2. By way of a blue piece of cloth, attach the violin to the camel's side, and allow the wind to blow against the snares, so that it makes sound. The camel will start to make sound too, the tone of which will sound suspiciously close to the tone produced by the violin.
3. Get a soprano to sing, while having her gently touch the camel's side. Preferably one who can sing incredibly beautiful. No, really.
4. After half a minute or so, have the violinist join in.
5. After yet a few more minutes, slowly and gently bring the young to the mother. Have the young drink some of the milk.
6. The mother will now accept the young, while she was aggressive if you even brought the young anywhere near her.

Words cannot express how incredible this is. I mean, sure, music can have an effect on one's emotions; and if this is true for human beings, I'm sure the same can be said for animals. But this? Whoa.

Actually, you can

Uwe Hermann and Russell Coker talked about resizing ext3 volumes in several scenarios. While they point out interesting things (i.e., the fact that you can resize stuff without losing data), they both get the important bits wrong.

Uwe, you can do online resizing. Just use

resize2fs <device-node>

Russell, resizing the LVM volume on which the root filesystem lives used to deadlock the kernel in the old days, but that bug has been fixed since around Linux 2.6.13. I've done online resizes of the LVM volume (and ext3 filesystem) of my root filesystem many times since then, both on some of my home systems and on huge customer boxes, and never encountered any problems.

I really love LVM, especially on servers. /home is full? lvresize -L +5G /dev/<hostname>/home && resize2fs /dev/<hostname>/home, and we can work again.

Playing with git

A few years, ago, I decided that there were way too many SCM systems out there, and that I'd give the war of the SCMs some time before deciding on which one I'd use. Mean time, I did spend some time with subversion, since, well, CVS sucks my pants off, subversion is quite a bit better, and easy enough to understand for those of us who are already familiar with CVS.

But it still sucks. I often find myself on the train, wanting to do an svn commit, and not being able to. svk helps, but not by much.

I didn't spend much time during the past years in trying to wrap my head around one of the distributed SCMs; partially because I was somewhat coping, and partially because the above-linked blog post was written in response to me running away scared aftery trying to understand arch. I should have shoved arch up Tom Lord's <censored> years ago.

So, anyway, I don't think "The World" has made a choice yet, and I don't think it ever will. However, it seems clear that git is a pretty popular choice these days; and, well, if a project the size of the Linux kernel is using it, then it must be good, right?

Right. So I gave it a shot. After reading the tutorial, I can already honestly say I like it. The tutorial links to a number of different pages, most of which give a set of standard workflows for different ways of interacting with git. Exactly what I needed!

I should've done this years ago.

Anyway. I'm now considering switching the NBD repository over from svn to git, which should help ensure that patches which are important for several branches are applied to all of them (this requires much more manual work in subversion). Before taking that step, however, I'll have to make sure I fully understand the thing; after digging through docs for "only" an hour or so, I can't say I do.

Dep-wait parser

One thing that's been bothering me since quite a while is the fact that apt and friends are not very verbose when things go wrong. Usually that's just fine; if a package can't be installed, there isn't much you can do about it anyway.

However, for those of us who have to maintain buildd machines, a message like the following is not very helpful:

ome packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  kdelibs4-dev: Depends: kdelibs4c2a (= 4:3.5.9.dfsg.1-2) but it is not going tobe installed
                Depends: libarts1-dev (>= 1.5.0) but it is not going to be installed
                Depends: libavahi-qt3-dev (>= 0.4) but it is not going to be installed
                Depends: libopenexr-dev (>= 1.2.2-3) but it is not going to be installed
                Depends: libqt3-mt-dev (>= 3:3.3.5) but it is not going to be installed
E: Broken packages

If you're not convinced, let me tell you that the culprit is libopenexr2ldbl. If you've noticed that libopenexr2 is not mentioned anywhere in the above output, you understand why I hate this. Usually, figuring out this stuff requires you to manually walk the dependency tree, which is silly. So today, I finally spent some time to sit down and write a couple of perl scripts to help me with that:

wouter@country:~/code/perl$ ./cache-packages Packages 
Reading data... done (20492 packages). Closing cache... ready. Have a nice day!
wouter@country:~/code/perl$ ./check-dep-waits 
kdelibs4-dev
checking dependencies of kdelibs4-dev
 checking dependencies of kdelibs4c2a (= 4:3.5.9.dfsg.1-2)
   checking dependencies of kdelibs-data (>> 4:3.5.9.dfsg.1)

  checking dependencies of  libopenexr2ldbl (>= 1.2.2)
libopenexr2ldbl is not available in any version

So, there. Obviously the "Packages" file in the first command line above came from a Debian mirror. The "cache-packages" script writes a file "~/.packages-dbm", which contains an MLDBM tiehash of all the packages, indexed on package name. If you have no clue what that means, just remember that it parses the Packages file into something my laptop can load in a split-second rather than requiring 45 seconds to open and parse the Packages file. Once you've ran that, you can call 'check-dep-waits' as many times as you want, that is, until the Packages file is outdated and you need to download a new one.

The second command will just sit and wait. On the first line, you give it a piece of Depends: information, and it will parse that and see whether the dependency can be resolved. There's a lot of output; but given how I want to verify dependencies, I thought I'd rather have too much than too little information. If there are version numbers involved, this script will call dpkg --compare-versions to do the actual verification, so I don't have to watch policy for any possible changes, which is helpful; but it does mean that it'll only work on a Debian machine.

The code is available for download at http://comp.uter.be/perl-Packages, FTWCA buildds.

Update: While on the train, I realized that I'd totally forgotten about virtual packages. That's now been fixed; if you downloaded the code before, you may want to re-fetch it...

Planet installations

Funny how technical people always seem to search for technical solutions to social problems.

"Some people think there's too much content on Planet Debian. Let's create another Planet with less content, that will solve the issue"

Allow me to just say: "Hah"

Planet Debian is a website with a lot of content. If you read such a site, inevitably there's going to be some content you're not going to like. This is a fact of life. Reducing that content so that it no longer carries the content you personally don't like might solve the issue for you, but there's no guarantee that it will also solve the issue for everyone else. For instance, I know I don't generally like Russel's writing style, but I don't assume that's the case for everyone else. It would be silly for me to request his removal from Planet Debian for that reason alone.

If there's stuff on Planet Debian you don't like, then just don't read it. That's easy enough... and if it isn't, fix that!

Hah

priceless. Even if I had to check twice to get the joke.

Armed network guards...

...closing a firewall hole by way of a railgun. No, really.

Joking aside, the monitoring properties of L3DGEWorld seem interesting. Except that you'll probably need a separate network just to account for the extra QuakeNet traffic.

Breakfast

I should have breakfast with Dave Jones some day. Giggle.

Working in the appartment...

Lessons learned today:

• Assembling a bunch of kitchen cabinets is no easy feat. While assembling a bit of IKEA furniture is usually done in 30-60 minutes, assembling 4 cabinets took all afternoon. And we're only halfway through.
• Apparently, Gamma will not double-check that the package you receive from them is complete—the drawer set for the 30cm cabinet wasn't.
• Sometimes, being helpful turns out not to be. The Gamma kitchen cabinets come with some of the metal bits already in the wood. Due to this, I had not been able to form a mental picture of what the metal bits look like; and as a result of that, we damaged some of the cabinets (though luckily not critically).

Anyway, the bottom half of the kitchen is now assembled. Sortof. The upper half, we'll probably do tomorrow. Or, er, well, "today", since 5 minutes ago...

Other than that, there's still much work to be done: Do something about the holes in one of the walls, treat another one of the walls for water damage, finish the paint job. Next tuesday and wednesday, a plumber will be connecting the kitchen sink and most of the plumbery in the bath room—hence the need for the assembly of the kitchen before that time. After that, I'll probably need to finish off some other things as well...

Oh, well, and I'll also need to move, of course.

In case you've been wondering, yes, this is why I haven't been very active on the Debian front lately. I've been signing my buildd mails (although not usually as prompt as one would expect), but that's about it. As a result, I got NMU'ed for the first time in my career as a Debian Developer—by two people at the same time, no less. Feels rather strange, I must say.