Alternative view: by date.
I’m not used to talking about my day job but here’s an exception.
Over the past few years I worked in two startups (3 years each). It was nice to spend time in different areas: one job was mostly about research and development in a Linux cluster environment; the other one was about maintaining a highly-customized, Linux-based operating system, managing a small support team, and performing technological surveillance in IT security.
In the meanwhile I’ve reached a milestone: 10 years with Debian. I had been wondering for a few months whether I could try my luck going freelance, becoming a Debian consultant. I finally decided to go ahead and started in August!
The idea is to lend a hand for various Debian-related things like systems administration, development/debugging, packaging/repository maintenance, or Debian Installer support, be it one-shot or on a regular basis. I didn’t think about trainings/workshops at first but sharing knowledge is something I’ve always liked, even if I didn’t become a teacher.
For those interested, details can be found on my website: https://mraw.org/.
Of course this doesn’t mean I’m going to put an end to my volunteer
activities within Debian, especially as a Debian Installer release
manager. Quite the contrary in fact! See the August and September
debian-boot@ archives, which
have been busy months.
Discussions are sometimes started by mailing a few different mailing lists so that all relevant parties have a chance to be aware of a new topic. It’s all nice when people can agree on a single venue to send their replies to, but that doesn’t happen every time.
Case in point, I’m getting 5 copies of a bunch of mails, through
debian-* lists: accessibility, boot, cd, devel,
Needless to say: Reading, or marking a given mail as read once per maildir rapidly becomes a burden.
I know some people use a duplicate killer at
procmail time (hello
gregor) but I’d rather keep all mails in their relevant maildirs.
which seems to do the job just fine for my particular setup: all
~/mails/* with the usual
Basically, given a mail piped from
mutt, compute a hash on various
headers, look at all new mails (
new subdirectories), and mark the
matching ones as read (move to the nearby
cur subdirectories, and
change suffix from
Mutt key binding (where X is short for cross post):
macro index X "<pipe-message>~/bin/mark-as-read-everywhere.pl<enter>"
This isn’t pretty or bulletproof but it already started saving time!
I noticed a while ago a Perl script file included on my blog wasn’t
served properly, since the charset wasn’t announced and web browsers
didn’t display it properly. The received file was still valid UTF-8
© character), at least!
First, wrong intuition
/etc/apache2/conf.d/charset it looks like the
following directive might help:
but comments there suggest reading the documentation! And indeed that alone
isn’t sufficient since this would only affect
text/html. The above directive would have to be combined with
something like this in
AddType text/plain .pl
To avoid any side effects on other file types, the easiest way forward
seems to avoid setting
AddDefaultCharset and to associate the
UTF-8 charset with
.pl files instead, keeping the
MIME type, with this single directive (again in
AddCharset UTF-8 .pl
Looking at response headers (
wget -d) we’re moving from:
Content-Type: text/x-perl; charset=utf-8
Nothing really interesting, or new. Just a small reminder that tweaking
options too hastily is sometimes a bad idea. In other news, another Perl
script is coming up soon.
A bit of history: A while ago udeb-producing packages were getting frozen on a regular fashion, when a d-i release was about to be cut. While I wasn’t looking at the time, I can easily understand the reasons behind that: d-i is built upon many components, it takes some time to make sure it’s basically in shape for a release, and it’s very annoying when a regression sneaks in right before the installation images get built.
I took over d-i release maintenance in May 2012 and only a few uploads
happened before the
wheezy freeze. I was only discovering the job at
the time, and I basically released whatever was in
testing then. The
freeze began right after that (end of June), so I started double
checking things affecting d-i (in addition to or instead of the review
performed by other release team members), and unblocking packages when
changes seemed safe, or once they were tested.
A few uploads happened after the
wheezy release and there’s already
Jessie Alpha 1 release. I was about to release
Jessie Beta 1
after some fair bits of testing, a
debian-installer upload, and the
only remaining bits were: building installation images (hello Steve),
and of course communication (mail announce and website update).
Unfortunately a new upstream release reached
testing in the
meanwhile, breaking the installer in several ways. I’ll give details
below, of course not because I want to point finger at the maintainer,
but to illustrate the ramifications that a single package’s migrating to
testing can induce.
parted 3.2-1 was uploaded on 2014-07-30 and migrated on 2014-08-05.
parted 3.2-2 fixed a regression reported in Ubuntu only (LP#1352252) which I also hit with images built locally after that migration.
I then built some images locally using fixed parted packages but then discovered that auto-lvm was still broken, which I reported in #757417.
After some investigation Colin confirmed some behavioral changes in this new parted release, which imply the need for an update of several other
partman-*components: #757661, #757662, #757663, #757664, #757665, #757666.
Thankfully fixes have been added for all of those, but more testing is needed before possibly urgenting those packages so that they get into
testingas soon as possible.
Since I’d like to avoid such experience in the future, I’ll probably reintroduce the old method and freeze all udeb-producing packages during next d-i releases.
So you know why it might happen. Your next question might be: “What to
do when your package is getting caught in that net?”. In that case,
please get in touch with both
asking for an unblock. I’ll then review your particular package, and
either let it migrate to
testing, or delay it until after the
Update: official announcement.
What’s up? That was the sound of a new Debian Installer release, an early Alpha 1 for the Jessie release cycle.
Let’s see if we can keep the debian-boot@ bug count below 1400 for a while, even if we get many new installation reports. Last weeks have been busy:
Speaking of which, if you feel like helping with the triaging effort,
there’s now a bug type called “installer bugs” on
UDD’s Bugs Search page.
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?).
Look! A tiny TARDIS-powered release, as if we were a few years back, when Perl was hype! It’s called IPC::GimpFu and abstracts talking to Gimp’s script-fu server, making it possible to run a few commands/scripts without having to care too much about Gimp’s start-up time, and without having to deal manually with the script-fu server protocol.
At the moment, it was mainly tested against a local server, and without caring much about the reply (there’s the nasty #583778 anyway), and it needs some polishing to make reports from CPAN testers greener…
Source is at http://git.mraw.org/ (
git clone git://git.mraw.org/ipc-gimpfu).
More on the reasons why I needed this module and those Gimp filters in a later post.
After a release cycle longer than between each beta (which is slightly sad, but I can’t spend all my time on Debian), here comes the first release candidate of the Debian Installer for Wheezy.
Debian Installer 7.0 RC1 announce
on the website has links to relevant bug reports in the Debian BTS, and the
lists things you probably want to know about (including gotchas with
grub-install we’ve been having for a while, now diagnosed, and
hopefully fixed for the next release candidate).
According to Arwen’s sleepy attitude, it’s officially time for a nap!
I’ve been working on some autotesting features for
d-i over the past
few weeks, and I’ve started lagging behind on my
reading accordingly, by several hundreds of mails. Today’s gift to myself: no more unread/unanswered mails in
Even if I’ve prepared things for a possible
d-i wheezy rc1 release
around Christmas, several things weren’t ready, most notably:
grub-installer. Hopefully #696615
will be fixed soonish, probably by asking where to write when
/target(/boot) isn’t on
grub-installer, if anyone can reproduce
#681227, I’m all ears! Wouter has a
workaround for it (only in
sid for now), but I’d very much like to
track down the root cause for that one. It is supposedly reproducible
wheezy beta 4 images and with weekly builds (they use
testing), all of those are available from the