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).
Events
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.
#952899 pillow: d/copyright issues
This very first bug was related to the pillow package. It was related to the debian/copyright file being incomplete, and the fact that the source package was containing possibly non-free code and data. This issue was quite challenging, because it was composed of a list of issues to be fixed:
- Needs "Alex Clark **and contributors**" from LICENSE - Copyright information for Tests/fonts not in d/copyright. - Google suggests that Tests/images/bmp is GPL-3 and also that the files are generated using C code. If that's right, we would need to at least include that code for generating the images in debian/missing-sources/ (and ideally regenerate them). - Tests/images/pillow3.icns looks like it contains a colour space copyright 1998 Hewlett-Packard Company; unclear how licensed. - Tests/test_file_fli.py says that Tests/images/a.fli came from the web and I cannot see any free license; probably needs to be filtered out. - Tests/test_file_mcidas.py says something similar for some other images; this should be accounted for. - Several files matching {docs/example,src/PIL}/*ImagePlugin.py and src/libImaging/BcnDecode.c are public domain/CC0. - Most files matching src/PIL/{ImageMorph,MspImagePlugin,SpiderImagePlugin,_binary}.py and src/libImaging/{Jpeg2K*,Quant*,SgiRleDecode.c,UnsharpMask.c} have different copyright holders. - src/Tk/_tkmini.h has different copyright holders and license; possibly not DFSG-free due to "GOVERNMENT USE" section. - src/libImaging/{QuantOctree.c,raqm.h,nmake.opt} have different licenses and copyright holders.
However it is not clear which items in the list are considered as RC (release-critical) and which items are more of a whishlist kind.
I tackled this first issue with enthusiasm, and tried to address every point in the bug. in fact, i went way too far and also converted the d/copyright file to DEP5 format for my own convenience. It allowed me to use the Files-Excluded directive in order to automatically exclude the offending files from the source package:
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: Pillow Upstream-Contact: Source: https://pypi.python.org/pypi/Pillow/ Files-Excluded: # Missing license data, see: # https://github.com/python-pillow/Pillow/issues/4591#issuecomment-765711479 Tests/images/a.fli Tests/test_file_fli.py # Missing license data from https://ghrc.nsstc.nasa.gov/hydro/details/cmx3g8 Tests/test_file_mcidas.py Tests/images/cmx3g8_wv_1998.260_0745_mcidas.ara Tests/images/cmx3g8_wv_1998.260_0745_mcidas.png # Code Files: * Copyright: 1997-2011 Secret Labs AB 1995-2011 Fredrik Lundh 2010-2020 Alex Clark and contributors License: HPND ...
According to other contributors, this was too much. The aimed goal of the contribution was to provide a NMU (non-maintainer upload) in order to fix the issue to unblock the release. By reformating the d/copyright file to DEP5 format, it would propose a big change that is not appropriate for a NMU. Instead only the issues listed in the bug should be fixed, but anything else should be left untouched.
I got to “convert” the DEP5 file I created back to raw text in order for the upload to be acceptable:
This package was debianized by Simon Richter <sjr@debian.org> on Mon, 21 May 2001 22:20:43 +0200. As of 2004-01-05, it is maintained by Matthias Urlichs <smurf@debian.org>. It was downloaded from https://pypi.python.org/pypi/Pillow/ Files excluded because of missing license data: Tests/images/a.fli Tests/test_file_fli.py Tests/test_file_mcidas.py Tests/images/cmx3g8_wv_1998.260_0745_mcidas.ara Tests/images/cmx3g8_wv_1998.260_0745_mcidas.png Copyright: The Python Imaging Library is Copyright (c) 1997-2011 by Secret Labs AB Copyright (c) 1995-2011 by Fredrik Lundh Copyright (c) 2010-2020 by Alex Clark and contributors ...
My favorite text editor (vim) also took the opportunity to remove unrequired whitespaces in the d/changelog file. This was, again, not acceptable for a NMU as it should be as minimal as possible. I angrily opened the file with another text editor in order to reintroduce the whitespaces. Feels like a (necessary?) waste of time, but whatever.
After all of this, time to verify that the excluded problematic test files did not break the package’s autopkgtests. There are now less of them because of the exclusion, but the remaining still pass just fine.
Time to get the NMU sponsored by a contributor with upload rights (usually a Debian Developer). The NMU was uploaded to the archive, automatically closing the bug thanks to the d/changelog entry. But are we done?
I would like to not loose all of the effort that went into converting the d/copyright file to DEP5 format. It would be a shame, because this format conveys way more information that the current raw text. Especially because DEP5 format is machine-readable and offers other niceties like the Files-Excluded feature for automatic file exclusion upon new upstream versions.
The ultimate step is to propose back this new DEP5-compliant d/copyright to the package maintainer, instead of forcing it using a NMU. For this, a new “whishlist” bug has been created against the pillow source package: #987622 pillow: use dep5 format for d/copyright.
After creating this new entry, we can say that we are done. For this one! Let’s maybe aim for a simpler bug next, as this one took quite some time to figure out.
#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:
override_dh_install-arch: 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:
usr/lib/*/*Qt*.so.*
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/libvtkGUISupportQt-6.3.so.6.3.0 … ./usr/lib/x86_64-linux-gnu/libvtkGUISupportQtOpenGL-6.3.so.6.3.0 … ./usr/lib/x86_64-linux-gnu/libvtkGUISupportQtSQL-6.3.so.6.3.0 … ./usr/lib/x86_64-linux-gnu/libvtkGUISupportQtWebkit-6.3.so.6.3.0 … ./usr/lib/x86_64-linux-gnu/libvtkRenderingQt-6.3.so.6.3.0 … ./usr/lib/x86_64-linux-gnu/libvtkViewsQt-6.3.so.6.3.0 … ./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/libvtkGUISupportQt-6.3.so.6.3 -> … … ./usr/lib/x86_64-linux-gnu/libvtkGUISupportQtOpenGL-6.3.so.6.3 -> … … ./usr/lib/x86_64-linux-gnu/libvtkGUISupportQtSQL-6.3.so.6.3 -> … … ./usr/lib/x86_64-linux-gnu/libvtkGUISupportQtWebkit-6.3.so.6.3 -> … … ./usr/lib/x86_64-linux-gnu/libvtkRenderingQt-6.3.so.6.3 -> … … ./usr/lib/x86_64-linux-gnu/libvtkViewsQt-6.3.so.6.3 -> …
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:
override_dh_auto_install: 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; \ done 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.