It’s a somewhat strange feeling to spend time fixing things that broke instead of implementing new things, but it’s not like I’m a creative guy anyway…

• buildd.debian.org went down, but it’s now up again thanks to the relevant admins. The CGI part mentioned by Philipp was fun to debug: the CGI worked when called from a shell, but not from Apache (with an apparently strange DNS resolution error). I suggested attaching it with strace, and the result was even stranger: a connection to nscd’s socket was attempted but the DNS resolution through the network wasn’t. A closer look revealed the nsswitch.conf file was read, and its configuration was OK, so what? Looking at libnss_dns.so.2, one could see the usual syscalls for library loading: open, read, fstat, mmap… oh wait, mmap failed with ENOMEM (Cannot allocate memory). Tollef bumped the rlimits on the Apache side, and that was it.

• Linux kernel ABI bump notifications: they were acting weird since kernel people resumed uploading -trunk- kernels to experimental. That was identified a while ago, but since I like tested bugfixes, I actually did wait for it to happen; fixed in r68876.

• Of course, d-i’s git repository was updated to bump the ABI from 3.10-2-* to 3.10-3-* accordingly.

• #722939 was reported against udev-udeb since depending on a deb library isn’t a good thing when you’re an udeb binary.

• Trying to look into d-i build failures earlier this month, I thought I managed to reproduce the issue, but that was just my misunderstanding the way apt works. Long story short, *InRelease and *Packages files are checked before they’re put under lists/; modifying the contents isn’t expected: the modification time is used to set the If-Modified-Since header when trying to fetch a new version from the server, and it’s OK to get a 304 Not Modified in that case. As a side effect, that means the files can be hand-edited, for example because you need to work around the dependency bug mentioned above, and one will still get Hit lines for all those files. If something goes wrong, one can still rm the files and start over, but that looks like a large hammer. Let’s see if the issue can get reproduced (and debugged!) later on.

For those last two points, the long term plan is:

• To check udeb installability automatically to catch such dependency issues as early as possible.

• To keep many more logs, so that one can still read the whole output a few weeks after the fact, and so that one can compare some logs to try and spot difference in a semi-automated fashion.

Hopefully getting this done this week (famous last words, eh?).