Debian Bug Squashing Party: Salzburg 2021 virtual edition

During April 24th and 25th, the Debian Bug Squashing Party (BSP) planned in Salzburg, Austria was held virtual. During this event, various Debian contributors grouped together and try to fix all of the release critical bugs for the next stable release, Bullseye. Let’s see how things went.

Communication means

Normally BSP are held in person. Grouping people at the location over a weekend creates a nice environment for everyone to try to fix bugs and eventually ask for help from more experienced contributors. This year, given the pandemic situation, the Debian Salzburg BSP organizers decided to go online.

While not as effective as in-person chit-chat, various communication means have been put in place to support the event:

  • A dedicated IRC channel on OFTC for the event: #debian-bsp-2021-szg;
  • A collaborative pad for sharing who is working on which bug;
  • A Jitsi room for occasional vocal and video activities; and
  • A Zoom room for the sports event (because of some Jitsi limitations).


Various events were proposed during the virtual meetup:

  • Presentation rounds at the beginning of the event via Jitsi;
  • A sports session monitored by coaches over Zoom in order to not hurt ourselves;
  • A yoga session with an instructor via Jitsi;
  • Virtual datacenter tour of the event sponsoring company via Jitsi; and
  • Gaming sessions.

I was not able to join the sports session, but I have heard over IRC that it was quite physical. However, I did attend the yoga one. It was focused on exercises you can do with an office chair — a good idea given the amount of time we spend sitting during the day. The teacher was kind and funny. It is not easy do describe the exercises in a written form. But they are easy enough to remember. Thus I hope I will be able to practice them on a (more or less) regular basis.

The virtual datacenter tour was quite nice. One session was in German, and the other one I attended was in English. It was a kind of streetview journey around the different rooms of the building. Of course, one major missing element is the noise of all of the machinery that I usually enjoy when visiting such places. I did point out the lack of fire exit signs during the visit, to be informed that the building was not completely achieved. One thing I have learned is that a European Union datacenter “law” exists, and that you have to comply to it, be it in Austria or elsewhere in the union.

Concerning the gaming sessions, they were not planned with a day and hour like the other activities, and I think there was none during the event. Or maybe I missed them.

Achieved Debian work

While having fun in one objective of the event, the other one is of course squashing bugs in order to unblock the release of the next Debian stable iteration: Debian Bullseye. Only release-critical (RC) bugs are considered during this event, and the objective is to fix them all (or, at least, as much as you can and will to).

Being a very new contributor to the project — and not having any status within the community (not Debian Developer nor Debian Maintainer) — the contribution experience was somewhat limited. I needed other members’ time to be able to move forward. But after some messages on IRC I was able to get my work reviewed and eventually sponsored to fix some of the bugs I focused on.

These bugs were really simple ones, as I was aiming to help with the little accumulated knowledge of Debian packaging I accumulated over the last months.

#987462 libvtk6.3-qt is empty

From now on, after having a new look at the RC bugs list, I decided to aim for simpler issues. One of them is empty binary packages. Usually this happens because the maintainer forgot to populate them, or removed their content but forgot to remove the package from the d/control file.

I randomly chosed this bug from the vtk6 package.

Luckily for us, this package is versioned in a git repository on Salsa. This will give us way more context and history than the d/changelog file. In the bug itself, another user points out that the empty package seems to originate from the maintainer’s removal of Qt support from the vtk source package — according to a commit on the Salsa repository. However, if we dig a bit in the git history of the package, the Qt support is activated back again later in time, by reverting the mentioned commit. This means that the package should support Qt again.

We can verify this by building the package from source. After the build, the libvtk6-qt-dev package is correctly populated, but the libvtk6.3-qt one is indeed empty:

$ dpkg -c libvtk6.3-qt_6.3.0+dfsg2-8_amd64.deb
… ./
… ./usr/
… ./usr/share/
… ./usr/share/doc/
… ./usr/share/doc/libvtk6.3-qt/
… ./usr/share/doc/libvtk6.3-qt/changelog.Debian.gz
… ./usr/share/doc/libvtk6.3-qt/copyright

Something is wrong. After looking at the d/rules file, we can see that the Qt .so files are explicitly removed from the libvtk6.3 package:

    dh_install -a
    find $(CURDIR)/debian/libvtk6-dev/ -name "*Qt*" -exec rm {} \;
    find $(CURDIR)/debian/libvtk6.3/ -name "*Qt*" -exec rm {} \;
    find $(CURDIR)/debian/libvtk6-dev/usr/include/ -name "Q*" -exec rm {} \;

This is probably in order to deliver them in the libvtk6.3-qt package instead. But there is nothing to tell this package to be populated by any file! The solution is to create a libvtk6.3-qt.install file in the debian/ directory in order to ship these .so Qt files:


After creating this file and rebuilding the binary packages from the source package, the libvtk6.3-qt package is finally correctly populated:

$ dpkg -c libvtk6.3-qt_6.3.0+dfsg2-8.1_amd64.deb
… ./
… ./usr/
… ./usr/lib/
… ./usr/lib/x86_64-linux-gnu/
… ./usr/lib/x86_64-linux-gnu/
… ./usr/lib/x86_64-linux-gnu/
… ./usr/lib/x86_64-linux-gnu/
… ./usr/lib/x86_64-linux-gnu/
… ./usr/lib/x86_64-linux-gnu/
… ./usr/lib/x86_64-linux-gnu/
… ./usr/share/
… ./usr/share/doc/
… ./usr/share/doc/libvtk6.3-qt/
… ./usr/share/doc/libvtk6.3-qt/changelog.Debian.gz
… ./usr/share/doc/libvtk6.3-qt/copyright
… ./usr/lib/x86_64-linux-gnu/ -> …
… ./usr/lib/x86_64-linux-gnu/ -> …
… ./usr/lib/x86_64-linux-gnu/ -> …
… ./usr/lib/x86_64-linux-gnu/ -> …
… ./usr/lib/x86_64-linux-gnu/ -> …
… ./usr/lib/x86_64-linux-gnu/ -> …

So the solution was not to remove the empty package like suggested in the bug report, but to correctly populate it instead.

After proposing the fix in the bug itself, someone with upload rights was able to publish my second NMU in order to close this second bug. The meetup is approaching its end, so let’s try to tackle one more bug during the remaining time.

#987458 libjs-of-ocaml-doc is empty

This bug is also about an empty binary package, so let’s have a look. After downloading and building the source package, we can see that this libjs-of-ocaml-doc binary package is indeed empty. After looking in the d/rules file, it seems that the maintainer is removing the generated documentation on purpose during the build, and not installing them anywhere:

    rm -rf debian/tmp
    cp -a _tmp debian/tmp
    for u in js_of_ocaml-compiler js_of_ocaml-ppx \
             js_of_ocaml-ppx_deriving_json js_of_ocaml-lwt \
             js_of_ocaml-ocamlbuild js_of_ocaml-toplevel \
             js_of_ocaml-tyxml; do \
      rm -rf debian/tmp/usr/doc/$$u; \
    rm -f debian/tmp/usr/doc/js_of_ocaml/LICENSE

For this one, my instinct tells me that the documentation is not built anymore, but the documentation package was not removed by the maintainer. I propose a patch to the maintainer to remove the empty package, by answering the bug. However, since we are not sure what the intent of the maintainer is, we do not go to the NMU route but wait for an answer of the package maintainer instead.

Rightfully so. After some time, the package maintainer answers in the bug that the patch is not the correct fix. They were waiting for some ocaml documentation generation tool to arrive in testing before generating back the documentation. The documentation package was kept empty on purpose while the tool was not available, as the maintainer was not aware that this would case a release-critical bug to be raised.

Instead of removing the empty package, the maintainer took the route of generating back the documentation and populating the package. Great! By uploading this fix, the maintainer was able to close the bug. So I was not able to personally close it in the end, but it is not a big deal. Proposing a wrong patch made the maintainer move forward and find a solution that will help final Debian users by delivering more documentation.

Final thoughts

This event was great overall. I was able to address 3 RC bugs. I have learned how to make a proper NMU by just not doing too much. I also learned about the nmudiff tool (and reported a bug about it, too).

I expected that my first BSP would happen in France with real people in the Paris area, but the pandemic happened. So the virtual event in Salzburg was welcome.

I wonder if the Debian project is usually paying for expenses of Debian members to fly over BSP events in Europe and stay there a couple of days. Or if the original event, before it was decided to be virtual, usually only gathers people from Austria. I would see it as a great opportunity to travel and meet contributors if the project was paying this kind of fees for the event. Of course, one has to become Debian Maintainer or Debian Developer in order to claim expenses I guess, so I would never have been able to attend this event if it was not held virtual.

Maybe this kind of possible benefits would motivate me to try to get one of these Debian titles in order to meet new people and new places, when the pandemic is over.

I should soon receive a goodie bag with a nice t-shirt and some homemade honey from bees that live by the datacenter building in Austria. Who knows, maybe they got… electrolytes.