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

Posted @ 15/09/2014 Tags: debian

Problem

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 the following debian-* lists: accessibility, boot, cd, devel, project.

Needless to say: Reading, or marking a given mail as read once per maildir rapidly becomes a burden.

Solution

I know some people use a duplicate killer at procmail time (hello gregor) but I’d rather keep all mails in their relevant maildirs.

So here’s mark-read-everywhere.pl which seems to do the job just fine for my particular setup: all maildirs below ~/mails/* with the usual cur, new, tmp subdirectories.

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 , to ,S).

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!

Now to wonder: was it worth the time to automate that?

Posted @ 11/08/2014 Tags: debian

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 (hello, little © character), at least!

First, wrong intuition

Reading Apache’s /etc/apache2/conf.d/charset it looks like the following directive might help:

AddDefaultCharset UTF-8

but comments there suggest reading the documentation! And indeed that alone isn’t sufficient since this would only affect text/plain and text/html. The above directive would have to be combined with something like this in /etc/apache2/mods-enabled/mime.conf:

AddType text/plain .pl

Real solution

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 text/x-perl MIME type, with this single directive (again in /etc/apache2/mods-enabled/mime.conf):

AddCharset UTF-8 .pl

Looking at response headers (wget -d) we’re moving from:

Content-Type: text/x-perl

to:

Content-Type: text/x-perl; charset=utf-8

Conclusion

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

Posted @ 11/08/2014 Tags: debian

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 a 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 testing as 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 debian-release@ and debian-boot@ asking for an unblock. I’ll then review your particular package, and either let it migrate to testing, or delay it until after the release.

Update: official announcement.

Posted @ 10/08/2014 Tags: debian

What’s up? That was the sound of a new Debian Installer release, an early Alpha 1 for the Jessie release cycle.

As usual, see the Debian Installer section of the Debian website, in particular the errata page which lists important, known issues. Then give it a try, and report bugs!

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

Posted @ 19/03/2014 Tags: debian

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

Posted @ 17/09/2013 Tags: debian

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.

Posted @ 29/06/2013 Tags: debian

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.

The Debian Installer 7.0 RC1 announce on the website has links to relevant bug reports in the Debian BTS, and the errata page 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!

Sleepy Arwen

Posted @ 17/02/2013 Tags: debian

#696699 was already a funny bug number, but #696969 is even better. d-i FTW!

Posted @ 30/12/2012 Tags: debian

I’ve been working on some autotesting features for d-i over the past few weeks, and I’ve started lagging behind on my debian-boot@ reading accordingly, by several hundreds of mails. Today’s gift to myself: no more unread/unanswered mails in that mailbox!

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 (hd0).

Wanted!

Speaking of 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 with wheezy beta 4 images and with weekly builds (they use components from testing), all of those are available from the debian-installer website.

Posted @ 25/12/2012 Tags: debian