bastardizing packages or stepping down

To: Debian Install System Team <debian-boot@lists.debian.org>, debian-release@lists.debian.org, debian-ctte@lists.debian.org, Cyril Brulebois <kibi@debian.org>

Subject: bastardizing packages or stepping down

From: Michael Tokarev <mjt@tls.msk.ru>

Date: Thu, 05 Mar 2015 13:38:29 +0300

Message-id: <[🔎] 54F83225.5090601@msgid.tls.msk.ru>

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello. I didn't really want to write this email, but it looks I now have to, even if, for reasons which whill be shown below, don't expect any good news from this. Trying to make the story short. For quite some time we had a bug in glibc in jessie which resulted in statically-linked applications malfunctioning when using any of nsswitch-related functionality (eg gethostbyname() etc), #757941. This glibc bug resulted in bugreport about busybox package -- #769190 (#757941 has been filed against busybox too, initially). The problem was that many busybox applets didn't work in static build. That bug was rather fun, because even if it is fixed in glibc, your package depends on the fixed version to be present on all buildds, or else the resulting binary will be buggy again. This is exactly what happened with #769190 -- to work around initial #757941 in bb, it has been bin-NMUed and rebuilt with a fixed glibc. But once I uploaded a next release of busybox to the archive, it was rebuilt using older, unfixed glibc, and the original problem reappeared. For added fun, since glibc package names are architecture-dependent, it is rather difficult to express all necessary build-depends correctly. Having all this, and having in mind that at least initially you don't know if this particular build of your package is affected or not, another bug has been filed against busybox -- #768876, requesting that busybox-static have a Built-Using field to allow seeing which glibc version it was built against, at least. This bugreport (#768876, built-using) is of serious severity and is tagged with jessie-ignore, not because it is irrelevant for jessie but because it is _difficult_ to fix and the package already received manual treatment to be rebuilt against a fixed glibc version. Understanding the actual severity of this problem, I tried to fix this before jessie, because I know it is important to do so (see below). I had fever at that time, and fixing it turned out rather difficult and required several iterations to finally get it right. I especially tried to fix that as fast as possible despite the fever, because it was near jessie freeze so, even if I was absolutely sure it wont be a problem to accept these changes to jessie, I didn't want to add more work for already busy enough release team to review and accept the changes. But at that time things didn't go right, because it turned out many buildds are still having old version of glibc and the resulting binary is buggy again. So I tried to add a versioned build-dependency on glibc, which too took several iterations because glibc package names are arch-specific and because I wanted to keep ability of busybox to be compiled against old version of glibc (eg for backports), both of which finally worked. Also I added a built-time test which builds a tiny static program which does getpwnam("root"), to verify before build that the build environment is able to produce static executables at all. At least this should ensure we wont have known-broken binary after a successful build. All 3 changes -- the generation of Built-Using field, the build-time test to ensure static linking works, and addition of extra build-depends field -- are small and self-contained in d/rules (or d/control) file, easy to review or remove when it all really becomes history. Meanwhile I fixed another, unrelated, buglet in the package which annoyed me enough during these multiple uploads -- I changed d/rules so it does not produce arch-all package (busybox-syslogd) when asked only to produce arch-specific packages. This was a bit larger change in d/rules but is a well tested in other packages. Neither of these changes, and this is important point, -- neither of these changes affects the resulting binary packages on a system where glibc is fixed. The changes adds one extra field (Built-Using) to busybox-static package, ensures the build environment is able to produce a static binary and introduces a versioned build-depends on libc which allows us to build the package either with fixed glibc version or with glibc which does not have that bug yet. After all this it turned out that several buildds were still having issues with the new build-depends, so the package were attempted to build multiple times - some buildds had unfixed glibc so build-depends were impossible to satisfy. More, it turned out hurd-i386 build env is not able to produce a working statically-linked getpwnam("root") binary at all. So I pinged buildd maintainers asking to update glibc, I also contacted hurd people asking what to do (hurd is not a release arch but it is in buildd and if I can fix hurd before freeze so I wont need to add more work for the release team that'd be nice). But time was, ofcourse, ticking. (Btw, I received no replies to my inquires about release-goal buildds, however after numerous attempts buildd network finally was able to produce working busybox binaries). And jessie was frozen. Why I think it is important to fix all this for jessie. First of all it is because buildds was using old glibc version for a very long time and I had to do quite some work to ensure the result is sane. The bug manifests itself in a very unexpected situation -- busybox-static package is a bit special in a way that you use it only for rescue purposes or something like that, when your system is hosed somehow, and you want to fix it (or else other, easier, tools are available). And only at this stage you discover that this last-resort binary is buggy and eg can't use the network to d/load stuff to fix your system. What a surprize. So I wanted to ensure it wont happen on jessie, no matter where or by whom the package is rebuilt -- be it an nmu/security upload from a machine where someone forgot to run sbuild-update, be it some derived distribution or whatnot. We don't have (for a good reason!) much static binaries, so that bug in glibc isn't really that important for most people, until you're in a situation like I described. That's all technical background. I'm sorry it took this long. Now the "fun part". So I filed an unblock request (#769129) for the early attempt to add build-using, and later on another unblock request (#771208) for the last, successful version. The changes included earlier security fix too (CVE-2014-4607). And to my great surprize, Cyril rejected (very softly at that stage) the unblock, saying in #771208 "At this stage, I'd rather see the security fix only". That was really great surprize to me, because he was "Putting on my d-i RM fedora", but absolutely _none_ of the changes in question affects d-i in any way whatsoever, the udeb binary hasn't changed by these changes at all. To me it was obvious (see above) everything is really needed for jessie, I especially rejected other changes (bugfixes) I wanted to add in order to make the whole thing obviously necessary. After https://bugs.debian.org/771208#25 I was somewhat pissed off, because I spent so much energy ensuring we're in good shape for jessie... Probably I should have described my reasons more accurately, but I think everything was clear already from the unblock request itself. And later on come <20150106000453.GA19051@mraw.org> which basically bastardizes busybox and reintroduces all the stuff which I tried so hard to fix. Now I was really pissed off, and replied with <54C71D86.8000702@msgid.tls.msk.ru>. To which come <20150127055909.GZ14135@mykerinos.kheops.frmug.org>. After that the discussion popped up in several related places, last one was in #776186. So now we have an interesting situation. On one hand, we're all busy and don't have enough time, On the other hand, we have a package whith serious enough (to my view anyway) changes to go to jessie, because I don't want this mess to repeat anywhere, and which does not break anything. And yet, without any good reason, we're creating much more work for ourself (to maintain this package and to maintain it twice!). I asked several times what is the reason this carefully done thing can't just go with everyone happy, what is the justification of all this more work? I never got answer to this question. The only answer I have is that these changes are not needed for jessie. Even if I disagree (which I demonstrated several times), is it really better to do more work and to piss off people than to just accept things which are working now? Is doing more work better than some unknown principle (again, which I yet to see) of not accepting "unneded" but small, self-contained and easy to review, and which the maintainer think are necessary? Speaking of intrusive versus needed. The last action which prompted me to write all this was the acceptance of a "security" patch in #776186. This is a relatively large patch which actually changes code but which has absolutely no effect in debian. This is a security problem in busybox version of modprobe which is NEVER USED in debian at all. Even in very very rare cases (such as rescue shell, I dunno) when it can actually be used, it will work in a controlled environment. It is not used in d-i (where again we have controlled environment), it is not used in initramfs (kmod is used there) etc. Yet we have time to fix it and to do this work twice, for jessie and for unstable, - but _that_ is definitely not needed for jessie! Guys, come on, what is really needed is not pushed, but unneded changes are. Oh well. Now, I respect what Cyrill does, especially in the d-i front, d-i is basically his baby. This is fine, and I'm thankful for that (even if I myself never used it, debian will not be debian without an installer). I don't see his reasonings for rejecting my work, I don't understand his reasoning to bastardize my work and to add more work for himself and the d-i team. This is what prompted this my email. In this context, I obviously can't do my work, I treat this simply as Debian does not want my contributions. There was only one person who participated in this whole discussion besides me and Cyrill -- it was Ivo in #771208. No one said anything. I view this as that everyone understand Cyrill work is more important and he is too touchy due to whatever issues (I had a large pressure myself whole last year, facing several deaths and serious illiness of my friends and relatives) -- since I don't expect anyone to speak in this context, especially after <20150127084310.GE18832@mraw.org> "If some release manager insist that we go for -14 as a basis for CVE-2014-9645 (#776186), we can probably do that. But..." (I can think of a possible reason -- following some Rules by a letter, everything marked as "security" is RC, no matter if it actually matters or not, and anything marked as "ignore", without considering a reason, is not needed. That does not help our users anyway). So, I don't really expect any other opinion except of the one which was expressed by Cyrill. But this obviously means I don't understand how and why Debian works, and can't help Debian, no matter how I wanted to. And since I can't do my work, I'm stepping down from being busybox maintainer, and am kindly asking the release team to remove my name from debian/control file in busybox, so that people don't blame me for things I can't do. The same for mdadm package since it is too a part of d-i, and I can't see my attempt to upload it targetting jessie will be successful, because obviously it will be "not needed for jessie" but it is absolutely required for me. I had enough sleeples nights due to all this (last night was another), and I already have more than enough grey hair on my head to watch this nonsense, and I don't want and bad to anyone, so I don't see any alternative so far. The problem at hand appears to be really small, technically it is pathetic. But it uncovers some much deeper problems, and I don't want to be part of that problems. And I don't want to _cause_ problems to other people, either. So please remove me. However, I still really want to understand that unknown reason why all this happened, why it is so difficult to accept a working package than to do more bastardizing work, why it is smart to reject good stuff and to do absolutely unnecessary work (double work with maintaining 2 version and applying patches wchich aren't needed for debian as a whole, not only for jessie). This is the reason I'm Cc'ing ctte@, but without much hope really, due to already mentioned reason. FWIW, this very situation with busybox already happened when we tried to release wheezy. That time I didn't complain even if thought it is unfair to allow much more intrusive and unneeded changes but disallow needed and easy changes. Now it is more than enough. Thanks, /mjt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU+DIjAAoJEL7lnXSkw9fbwbEIAKdjIFYfgw1yQGWTCZPk6SMX sY6ElCSH/5643rPZ1p99aPIXCB0ifYGlsywY5c4QioO0CddrR8d8pNJ56aIWsa8g cD2PbLwgxySqNmQ0mPAhu5INmSPH76CCCtKnxH0hj/Ej1sDPzgqKYhi7iapu3kE7 7xcrvd1ICH6WxyJFtwbLl1Rbg2QAHSNV0hgoXGqe8lmnpdCUtocQvpvo0ckd7kQw iU6v1sPayvMZi7j1EGjDqhZFr/gn2sjVdMKZTjWyQ/ZNeg4Jox3tnWPcUiDX6ZCD EKNUmkQIKkQyx7MF5FHRMV7+bJaxxcLEB/vV6NdpQRTfhwknkVA/CxWCjSn9yjg= =kJ73 -----END PGP SIGNATURE-----