Paris BSP and this blog

Hello everybody!

I've never had a blog up to today, and apparently now I do. Why? Well, it happened that there was a Debian Bug Squashing Party in Paris a few weeks ago, and I thought that it might be nice to go, meet some nice people and humbly help releasing Buster. Great news is that the Debian project is willing to reimbourse its members some of the expenses for taking part to a BSP, asking in return to communicate publicly about what you do during a BSP so that others are motivated to participate as well.

So I guessed that might be the occasion for me to start a blog, and start writing something about what I do in Debian. Here it goes!

It was my first BSP ever, and I am very happy of it. We met for a couple of days at very nice Mozilla's office in Paris (I think they are moving and we were at the old one, though). We were probably around 15 people, mostly from France, Belgium, the Netherlands and UK (which is not surprising if you look at the high-speed rail map in Europe; or any map of Europe, as a matter of facts).

The great thing of a BSP is that you have a very short loop to other developers. Since a BSP is all about getting RC bugs closed, it is useful to talk directly to Release Team members, and discuss whether they would unblock your fix or not when you are not sure. This saves a lot in terms of human bandwidth and context-switching. Also, I had the occasion to watch more experienced developers in action and learn how to tackle issues I haven't dealt with ever before, like bumping up a library SONAME.

So here is what I managed to do during the BSP, in roughly chronological order.

• Bug #920209: that is a bug I already had written a patch for a few months ago, but the whole thing had stagnated and the patch was never uploaded. A simple ping to the maintainer was enough: an easy one!

• Bug #917711: a FTBFS caused by failing tests, in turn caused by a broken internal interface between two libraries. I was able to cook up a patch, but I was not really sure it was the right thing, so I opened a bug upstream, to which upstream never replied. However, upstream itself wrote a similar patch a few days after, which was then up uploaded to Debian by ivodd.

• Bug #925957: this is a bug on a package I maintain, so it was imperative to get it done. fstransform is a tool to convert a filesystem to another format (like, XFS to ext4) without having to copy all the data to another filesystem and then back (see the upstream readme for more details). It is no mistery to anyone that such an operation is inherently dangerous, so both the program and its documentation warn prominently that data loss are always an option. The idea is: if fstransform can be useful for you, use it, but never on data you cannot afford to lose (you should always have a backup of such data, anyway). So this bug was about a reproducible failure case for fstransform when it was ran with a too little copying buffer. Of course the best thing is to have a proper fix, but since the upstream bug had stalled for an year an a half without a solution, the road of fixing it myself seemed implausible, especially because I do not know fstransform's internals. So my fix was to add a warning message (that the user has to explicitly acknowledge); this fits my model for fstransform: the user is advised that things might go wrong, but if they are ok, then good for them. This was also unblocked by the Release Team. Of course it is not the ideal solution, but at least the user knows what to expect from the program, which can still be useful if you are properly warned: given that Buster should be released as soon as possible this is, to me, a reasonable compromise. The bug submitter did not agree and reopened the bug. Fortunately a few days later the upstream author managed to find the proper fix, which I then uploaded.

• Bug #912467: a FTBFS due to an updated reverse dependencies, a relatively common between Java packages. A partial patch had already been begun by andrewsh, but was never completed. Using that as a base and drawing from the corresponding upstream patch, it was not difficult to fix the build, as the API changes were mostly cosmetic. I uploaded my patch to salsa, but not the the archive, because I would like someone else to review it. So far, it has not happened, and maybe I should have another look at it.

• Bug #917501: a rather nasty Eisenbug, that I could not really understand during the BSP: the bug occurred when I built with sbuild, but not when I build directly in my system, so that I could not debug it. Yesterday it was finally traced back to the usage of eatmydata by sanvila, which is plausible because I also use eatmydata with sbuild (it really boosts package installation!). The bug was downgraded to normal severity, and I guess it should also be reassigned to eatmydata, since it would be eatmydata's duty to be transparent to what is happening above it.

• Bug #915319: a FTBFS due to a bad library detection procedure by CMake. The detection of libsmbclient.h failed because CMake insisted to compile with -std=c89 (or so), while that header requires C11. Easy to patch.

• Bug #870267: Very very easy: the bug had already been solved, but was left open.

• Bug #877773: it was quite easy to understand what had to be done here (i.e., a SONAME bump), but I had never done it. So I asked around and jcristau showed me how to do it, including requesting a mini transition and stuff. Very instructive, and, I think, really one of the points of gathering together instead of working everybody at home.

• Bug #905697: I ported some of the kdepimlibs libraries to libical3, so that libical2 can be dropped from the archive. The difficult part was to backtrace the corresponding upstream patches, because in the meantime the libraries had reorganized in different repositories. In the end I found this patch, and it was not difficult to make it ready for Debian.

• One last thing not coming from a bug: Debian Buster should finally support Secure Boot, so that the computer's firmware can cryptographically validate the operating system before launching it. The Debian EFI team recently updated the Secure Boot page on the wiki with a clear description of how it works and how to enable it in Debian. I reviewed it and sent an email with my thoughts to the relevant mailing list.

So here it is, my blog and my report. Now, Debian, give me my money! :-P

Many many thanks to Mozilla for allowing us to use their spaces for the BSP, and to jcristau and olasd who organized it. Now let's try to get Buster released and maybe see you in Brazil (I'm not sure yet I will be able to come, because of [INSERT_REASONS_HERE], but I hope so).