Welcome to gambaru.de. Here is my monthly report that covers what I have been doing for Debian. If you're interested in Java, Games and LTS topics, this might be interesting for you.
We have reached the end of Stretch's development cycle, a phase called full freeze. That means packages may only migrate to Testing aka Stretch after approval by the release team. Changes must be minimal and only address important or release critical bugs. This is usually the time when I stop uploading new upstream releases to unstable to avoid any disruptions. Of course there are exceptions but if you are unsure best practice is to use experimental instead. A lot of RC bugs are still open and affect the next release. In February I could close five one and triage two more.
- I packaged new upstream releases of Bullet (2.86 and 2.86.1), a 3D physics engine, after I was informed by Debian's OpenMW maintainer (who is also one of the upstream developers) that this would fix a couple of issues for them.
- Debian Bug #848063 - ri-li: FTBFS randomly (Impossible d'initialiser SDL:Couldn't open X11 display): I usually note bug fixes very briefly but this one deserves some extra information. Apparently ri-li randomly failed to build from source on the bug reporter's build system. The error message indicated that an X11 display could not be opened. For those who wonder why an X11 display is required to build a package from source; ri-li is a game and comes with a small development program, MakeDat, to build the data files from source. The program is only needed at build time but it requires some SDL functions to work properly. During the compilation step MakeDat tries to initialize SDL and it requires an X11 display for doing that. Ri-Li uses the xvfb-run wrapper to create a virtual X server environment and then executes MakeDat. I didn't need to touch the package for more than two years and needless to say ri-li has always worked so far. I agreed that this was probably a regression in one of ri-li's dependencies. I immediately suspected xvfb and the xvfb-run script being the most likely cause for the build failures and after some investigation on the Internet I uploaded a new revision using the "-a" switch for xvfb-run. Unfortunately that didn't work as expected. On the other hand I noticed that the package built fine on the official buildd network for all release architectures, not to mention on my own system. I decided that severity important would be the appropriate severity level for this issue because the majority of users was unaffected and the claim the package failed to build 99 % of the time was just wrong.
So much for the prologue. The bug reporter disagreed with the bug severity and insisted to make #848063 release critical again. Since nobody of the Games Team wanted to do that and there were more people in a similar situation who disagreed with such a move, a thread was started on the debian-devel mailing list. I stayed away from it mainly because I already participated in the same discussions before where I got the impression that concerns were simply ignored. Also other people made a good response and expressed my views, for instance here , here and here.
In my opinion Debian is more than just an operating system and "not an academic exercise". I really do think that a package which fails to build from source is a bug and should be fixed but not every FTBFS is release critical, that's why we have for example release architectures and ports. We already make distinctions and we don't support every possible hardware configuration. If a package FTBFS on my laptops because 64 MB RAM or a 6 GB hard disk don't cut it anymore I'm not going to file RC bugs against the package in question, I'll try with a slightly more powerful machine again. RC bugs are a big hammer and we should be really considerate when we file them because as a consequence, if we can't fix them in time the package will not be part of the next stable release or even removed from Debian. We certainly don't have a shortage of bugs and if there is disagreement we should make case-by-case decisions and not blindly act "by the book". Threatening people to escalate bugs to Debian's Technical Committee isn't helpful either. I am not saying that random build failures should be ignored. There are tests which are designed to fail 50 % of the time. Obviously they are not very useful for Debian. But we have also many tests that check for real life situations, which require a specific amount of memory and disk space. I think it is a shame that we have to disable those tests or even the whole test suite if they work locally and on the official buildd network but not in a custom build environment. I fear we don't make Debian better but instead we "verschlimmbessern" (to improve sth. for the worse) it. Last but not least bug #848063 was never about a single vs. multi-core CPU issue, even the bug reporter agreed with this statement but apparently a lot of people who commented on debian-devel never fully read the bug report or followed closely enough.
- I fixed RC bug #852930 in libxml-security-java.
- I triaged RC bug #852253, kryo-serializers and #855324 in pdfsam. Unfortunately I haven't found a solution for the latter yet but I prepared the initial packaging for the latest release, so maybe we will see a more modern and better version of pdfsam in the post Stretch future.
- I prepared security updates for Tomcat 7 (#854551) and Tomcat8 (#851304) in Jessie.
- From 06. February until 13. February I was in charge of our LTS frontdesk. I triaged security issues in mp3splt, spice, gnome-keyring, irssi, gtk-vnc, php5, openpyxl, postfixadmin, sleekxmpp, mcabber, psi-plus, vim, mupdf, netpbm-free and libplist.
- DLA-820-1. Issued a security update for viewvc fixing 1 CVE.
- DLA-823-1. Issued a security update for tomcat7 fixing 1 CVE.
- DLA-825-1. Issued a security update for spice fixing 2 CVE.
- DLA-823-2. Issued a regression update for tomcat7.
- DLA-834-1. Issued a security update for phpmyadmin fixing 1 CVE.
- DLA-835-1. Issued a security update for cakephp fixing 1 CVE.
- DLA-840-1. Issued a security update for libplist fixing 2 CVE.
- I uploaded four NMUs to fix RC bugs in libphp-phpmailer (#853232), mcabber (#854738), slixmpp (#854740) and spice (#854336) for which I also prepared the security update for Jessie.
Thanks for reading and see you next time.