On 28 Aug 2017, at 20:23, Uwe Kleine-König <u...@kleine-koenig.org> wrote: > On Mon, Aug 28, 2017 at 03:10:10PM -0400, Antoine Beaupré wrote: >> On 2017-08-28 20:53:02, Uwe Kleine-König wrote: >>> On 08/28/2017 04:32 PM, Antoine Beaupré wrote: >>>> Control: severity 873508 serious >>>> Control: affects 873508 horst >>>> >>>> On 2017-08-28 15:22:20, James Clarke wrote: >>>>> As discussed on IRC, ppc64 and sparc64 are also affected; while they are >>>>> not release architectures and are thus less important, it would make >>>>> sense to fix those (and check any other Debian architectures) at the >>>>> same time. >>>> >>>> Also discussed on IRC is the above change in severity to make the bug >>>> RC. >>> >>> As I didn't follow that irc discussion and fail to see why this bug >>> should be severity serious. Can you please repeat the justification >>> here? I would have picked "normal". >> >> I believe the reason is that it doesn't actually work on two supported >> architectures. > > That would in my eyes still be "important". Looking at the definitions > on https://www.debian.org/Bugs/Developer#severities there is: > > - serious > is a severe violation of Debian policy (roughly, it violates a "must" > or "required" directive), or, in the package maintainer's or release > manager's opinion, makes the package unsuitable for release. > - important > a bug which has a major effect on the usability of a package, without > rendering it completely unusable to everyone. > > IMHO important is an exact match here.
It's basically unusable on those arches except for trivial code. Even headers like stdio.h pull in stubs.h, and many other things will likely break due to not having the right defines. Shipping this as-is is just asking for trouble. IMO the only way to make this non-RC would be to RM on the affected arches and make test suite failures fatal so we don't get broken binaries again. James
