bastardizing packages or stepping down
-----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-----
Reply to: