Bug#404739: Processed: reassign 404739 to gss

[Steve Langasek]

severity 404739 important
thanks

On Tue, Jan 09, 2007 at 09:07:45AM +0100, Simon Josefsson wrote:
> > Sorry, what's the rationale of this bug being marked as 'grave'?

> If I understand Russ correctly, I believe it would be that this
> problem makes the package unusable for amd64 users.  That seems
> compatible with the definition for grave given at:

> http://www.debian.org/Bugs/Developer#severities
> http://release.debian.org/etch_rc_policy.txt

Um, it's not; the package isn't "unusable" for amd64 users, it simply
doesn't exist on amd64.

That should be an 'important' bug AFAICS.

> http://lists.alioth.debian.org/pipermail/glibc-bsd-devel/2005-June/000434.html

> That suggests to me that amd64 specific ftbfs's would warrant
> "serious" severity, once the amd64 is considered for the next release.

No, the standard for serious build failures is that "a package must
autobuild on all architectures on which it's supported, and must be
supported on all architectures that it's reasonable to do so".  Packages
aren't expected to be supported on architectures where they've never
previously built and fail their own test suite.

> > Has this problem been seen on any archs other than amd64, where it
> > fails the testsuite and therefore generates no binaries?

> No.

Then I think 'important' is the right severity here.  You're free to provide
an update for the package in unstable, but this is now "best-effort" instead
of "release-critical".

> > If all the archs where the package has been built have working binaries, I
> > don't see any reason why this should be treated as RC, despite amd64 being
> > the missing arch.

> Ok.  What would you like to see happen here?

The release critical bug count go down ;)

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
address@hidden                                   http://www.debian.org/