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.
This blog is powered by ikiwiki.