Alternative view: by date.
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.orgwent 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.conffile was read, and its configuration was OK, so what? Looking at
libnss_dns.so.2, one could see the usual syscalls for library loading:
mmap… oh wait,
ENOMEM (Cannot allocate memory). Tollef bumped the
rlimitson the Apache side, and that was it.
Linux kernel ABI bump notifications: they were acting weird since kernel people resumed uploading
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
#722939 was reported against
udev-udebsince 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,
*Packagesfiles are checked before they’re put under
lists/; modifying the contents isn’t expected: the modification time is used to set the
If-Modified-Sinceheader when trying to fetch a new version from the server, and it’s OK to get a
304 Not Modifiedin 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
Hitlines for all those files. If something goes wrong, one can still
rmthe 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
email@example.com, 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
Given nobody on
debian-boot@stepped up to prepare new
debian-installerreleases, I figured I would give a hand there until somebody more involved with
d-iwould 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-cdaccount. The intent was to make sure
debian-installercould safely migrate from
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.
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
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
~s "Bug#.*FTBFS" ~P ~d 01/04/2011-
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
an eye on its diff between upstream versions should be easy
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
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
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
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
There are currently no packages in
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.)
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
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.
Thanks to DSA (especially weasel),
kfreebsd-*now have DSA-admin’d
experimentalbuildds. Aurélien took care of setting them up; they managed to go through all
experimentalpackages, 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:
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
lennyenvironment, but maybe people would like it to be directly available once the
lenny-backportsrepository 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.
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
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.
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
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?
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.
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-waitsbecause 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-iport seems to be on good tracks, and having weekly reports is great.
We’re still waiting for
unstablebut 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
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.
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.