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?).

Stuff/team I’m currently involved with:

• Debian System Administration: I’m just in the porter-* groups, so that I can fulfill installation requests in various chroots on Debian porterboxes; this means real DSA members can concentrate on more important things while still keeping the turnaround quick for developers who want to debug stuff on exotic architectures. Reminder for that procedure: Chroot Install Request Guidelines.

• After having maintained the kfreebsd-* buildds for a while, I’m still in the wanna-build team, meaning I can take care of give backs, one of the most common requests on debian-wb-team@. It’s been a while since it’s been split up from debian-release@, and instructions are still available in wanna-build.txt. Basically: anything buildd-related goes to $arch@buildd.debian.org or debian-wb-team@lists.debian.org, with the sole exception of binNMUs, which are handled by the release team.

• Speaking of which, I joined the release team a few months ago; plenty of (not-so-)funny things to do, like coordinating transitions to testing, and more recently, dealing with unblock requests during the freeze. While the Debian world is usually driven by the “just do” motto, there’s one area where one has to learn to say “no, sorry”. Hopefully people won’t hate us for that, and we’ll find alternative ways (like backporting specific fixes, or postponing new features until wheezy-backports is open).

• Given nobody on debian-boot@ stepped up to prepare new debian-installer releases, I figured I would give a hand there until somebody more involved with d-i would manage that on the long run. That’s a lot of heavy work, trying to get all involved packages into shape at a given moment, and getting people to fix their stuff when anything breaks. Hopefully that’ll work out and once CD images are ready, we should be able to run some more tests on those before officially publishing d-i beta 1.

• And since the CD team is also understaffed, I joined Steve McIntyre a while ago during a point release to see how that was done, and how I could help. Things drove me to the other teams above, so I couldn’t help much so far, but at least I managed to build a few test images on pettersson (the very nice machine on which images are built), using the debian-cd account. The intent was to make sure debian-installer could safely migrate from unstable to testing. That has happened lately, so images are being prepared.

• And of course I’m still maintaining the whole X stack, with the help of a few other guys on specific areas.

I don’t feel like getting hit by a bus, but I would hate burning out and going away from all this.

People have called repeatedly for help in core packaging team. And that has been true for the X Strike Force for a while (hint: Julien only managed to pull me into this because I ported the Graphical Installer from DirectFB to X11).

The same holds with non-packaging teams. I’m pretty sure Steve would love to see new members in debian-cd. I’m also pretty sure having more people involved in the d-i team would be very nice, especially if one could find out how to make the whole release process less insane than it is currently. I guess we could try out new ideas right after the release; it feels to me that right now is just not the time to fight the current release process.

It’s been a while since my last patches for GNU/kFreeBSD, and Christoph kindly took over the kfreebsd-* build daemons from me some time ago, but still: smile of the day. Thanks, Russ.

As already blogged by Riku, getting replaced by script is really great!

Until now, I’ve had a crontab fetching my supporting-very-big-mails (up to 100MB or so) mailbox every few minutes, and looking into my =incoming-buildd/ maildir on a very regular fashion. With some simple mutt maildir hooks, replying to a Successful log would trigger extracting the changes file from there, setting some options, like PGP inline signing, and the mail would be ready to go back to the buildd. That part was just about being a GPG-signing monkey, so really not a funny part.

Since we no longer have to worry about this boring and time-consuming task, I’ve switched to a crontab firing up 4 times a day, and I try to deal with all incoming mails at once. Coupled with the new filters (e.g. on out-of-date packages on the buildd status page), I started using my time to file FTBFS bugs again, so that maintainers notice their packages fail to build without having to wait for a non-happening testing migration.

After 10 days, the following mutt filter in =debian-bts/ lists 69 bugs:

~s "Bug#.*FTBFS" ~P ~d 01/04/2011-

(Subject contains Bug#.*FTBFS, mails from me, starting from 01/04/2011.)

Figuring out whether that’s due to another package’s bug, an outdated chroot, a temporary glitch, etc. might take some time; that’s why it’s a bit hard to stay on top of things; and when the backlog grows up, motivation to go through this tedious task can be pretty low, especially when one sees repeated mistakes. I hope the amount of (possible) use cases for #620686 will decrease over time; instead, I’d be very happy if maintainers could at least check what’s mentioned in configure.ac/configure.in. Keeping an eye on its diff between upstream versions should be easy enough. ;)

Being a buildd admin means one gets to sign successful build logs so that the built packages get uploaded from buildds to the archive, but that also includes filing bugs for packages which fail to build from source (Build-Attempted). Once that done, they can be marked as Failed, usually with a reason. A few words plus a bug number is usually convenient, so that people (maintainers, possible NMUers, other buildd admins) browsing https://buildd.debian.org/status/ can just click the bug number to reach the BTS.

There were a few packages in Build-Attempted for alpha, for which I reported some bugs yesterday, which explains the crossing lines on the following graph:

(That’s an edited version of the buildd stats for alpha.)

One has to be careful while filing bugs, since the severity depends on the target architecture(s) for which the package is failing, but also on its already being built there. Mostly, that boils down to serious for regressions (no longer builds) on release architectures, important otherwise. The only exception I’m applying is packages failing on all architectures due to obviously missing build dependencies, since they can’t be built again, even on the single architecture they’re available for (and we want to guarantee that doesn’t happen, we want to be able to binNMU them).

There are currently no packages in Build-Attempted for alpha, kfreebsd-amd64, kfreebsd-i386, and sparc (architectures I take care of), but I’m going to have a look at other architectures as well, since having portable software and reported (FTBFS) bugs sounds like a worthwhile goal.

(Disclaimer: this post is not about G.I.)

Graphical installer

Josselin posted his thoughts about g-i, and given at least the first parts sound doable, I’m tempted to have a look at dealing with the needed udebs. Never touched anything like this before, but oh well, one learns every day. Time to learn a bit more about X11 as well.

It looks like generating a new mini.iso (using d-i’s trunk) wasn’t that difficult, so hopefully once I’m done with a few udebs, it should be possible to add them to this image and make sure those are usable, at least when loaded manually.

Once that finished, gluing everything together is probably going to be another story, but hopefully that won’t be impossible.

Unrelated stories

• Thanks to DSA (especially weasel), kfreebsd-* now have DSA-admin’d experimental buildds. Aurélien took care of setting them up; they managed to go through all experimental packages, and bugs were filed accordingly. Some were just marked as failed, usually with “Needs porting.”, especially when there were no regressions with respect to what was previously built on those architectures (as a reminder: out-of-date means serious, uncompiled means important).

• On a related note, this buildd.d.o form makes it possible to browse the build logs for various suites. See the dda@ announce for details.

• It looks like I’m going to stop dealing with Java at all: #557230. Thanks to Gabriele Giacone for taking care!

• It also looks like I’m done with Python packages as well.

• A new module-assistant package got uploaded, which should fix issues with newer kernel versions (ya can haz detailz). I’m wondering whether backporting it through backports.org from time to time would be of some help to anyone? It is (or should be) directly installable in a lenny environment, but maybe people would like it to be directly available once the lenny-backports repository enabled? Mail/wishlist bug welcome if you want it.

• If you received some signatures from me lately… no, I wasn’t pretending I met you at LCA or whatever, but that was from Cáceres (Hi Penny! ;)). Key rollover being thought of.

Extremadura

• DebConf’9 timing was really nice, allowing for following talks, getting things done, and meeting people.

• Upper talk room’s speaker’s chairs aren’t as comfortable as they seem; First row seats are OK to sleep on, though.

• Guards actually don’t want people to sleep there, and can even chase people in hacklabs to make sure they go sleep in the right venue; Funny wake-up, with a lot of Spanish, and little to be understood (note to self: try and get some Spanish basics before being in the plane for Spain next time).

• Very sympathetic guard anyway, apparently (read: still in Spanish) saying how sorry she felt for that. And even hugging and kissing when one was leaving. Spanish people, you rock.

• Day trip totally rocked, as well as the formal dinner. Orga-team \o/.

• Totally in love with the Bosnian bid for DebConf’11. Let’s hope they’ll keep on doing a great job.

• Oh, and decided to get another NM. Very funny to sit next to each other and mail NM Q&A every few hours.

Packages

• I requested assistance for the src:graphviz package. While being a quite interesting technical challenge back when I started packaging various things, it is currently quite sucking my time, and I would really love someone else step in. I guess the RFH (#536245) will be turned into an RFA quite soon.

• Pabs orphaned Synfig-related packages src:etl, src:synfig, src:synfigstudio. Given I don’t currently plan to dive more into them, I don’t feel like I would do a great job by keeping on maintaining them alone.

• The same goes for src:luxrender. It’s RC-buggy but given I may orphan it as well, I’m not really keen on uploading a new upstream release to fix it. On a related note, I might have spent some time on the src:aqsis package but again, if one is not a very regular user, what’s the point?

• I’m also quite wondering what to do with Blender. Details can be found in my mail to debian-devel@.

It’s quite sad to let some packages go, especially some which are quite popular, and which have made me dream for years (graphics stuff interested me back when I first touched a computer already); But well, time is a scarce resource. :(

GNU/kFreeBSD

• Taking care of buildds is a really interesting experiment.

• The new wanna-build feature called edos-builddebcheck is really appreciated on kfreebsd-*; most of the time, I’ve been setting dep-waits because of missing and/or uninstallable packages. Now it seems that all that stuff is being handled automatically, and I only have to concentrate on the successful build logs, and on the failed ones due to needed porting, broken build systems, etc. EPIC WIN, if you ask me.

• d-i port seems to be on good tracks, and having weekly reports is great.

• We’re still waiting for util-linux in unstable but once that done, we should get hal (thanks to a close cooperation with both its Debian maintainer and upstream), which should make it possible to get a lot of packages from the X11, GNOME, and KDE stacks. Once that done, a status update might be sent to d-d-a@.

Would someone guess the link between:

• What mail client are you using?

• Are you around during the next two weeks?

After answering those, I’ve been offered to take care of the GNU/kFreeBSD buildds, which is yet another experience. \o/

Quite a good timing since I’ve recently tried to get involved with the GNU/kFreeBSD ports again, prodding maintainers, uploading fixed packages (usually thanks to Petr Salinger’s patches), or providing patches myself.