Bug#404739: Processed: reassign 404739 to gss

[Simon Josefsson]

Russ Allbery <address@hidden> writes:

> Simon Josefsson <address@hidden> writes:
>
>> Uploading 0.0.19 to Debian at this time is surely a bad idea.  Should we
>> raise the severity of this bug to serious, since it is FTBFS, and do
>> another upload of 0.0.18 plus the minimal patch that solve the bug?  Or
>> is it not worth another upload?  Not supporting amd64 seems like an
>> unfortunate thing, but maybe it is too late to get into etch.  I don't
>> really know the best practice for this.
>
> We should raise the severity of the bug to grave (better than serious,
> since it's a usability issue, not a policy violation) and upload a new
> 0.0.18 version with the minimal patch.  I think the release team will be
> happy with that.

Done.

>> FWIW, the minimal patch is the one below.  I don't really know how to
>> apply it with cdbs, but I recall seeing other packages do it, so I could
>> easily take care of that tomorrow.
>
> Given that this will be fairly temporary, I would use the simple-patchsys
> class in CDBS, which should be up to applying a single patch without much
> difficulty.  Let me know when that's set and I'll do the upload.

It should work now, latest CVS passes linda/lintian:

address@hidden:/var/cache/pbuilder/result$ lintian -i -I 
gss_0.0.18-2_i386.changes
address@hidden:/var/cache/pbuilder/result$ linda -i gss_0.0.18-2_i386.changes
W: gss-doc; File gss.devhelp not symlinked to from devhelp dirs
 The file shown above exists outside of /usr/share/gtk-doc/html or
 /usr/share/devhelp/books, and does not symlink back into either of
 those two directories
W: libgss-dbg; There is no Depends: line in the control file.
 The package has no Depends: line in the control file. This is not
 allowed by Policy if the package in question contains binary objects.
 Perhaps try calling dpkg-shlibdeps or dh_shlibdeps in the package
 rules file.
address@hidden:/var/cache/pbuilder/result$

I cannot verify that the package builds on amd64, but my pbuilder log
contains:

patches: debian/patches/00-fix-ftbfs-amd64.diff
Trying patch debian/patches/00-fix-ftbfs-amd64.diff at level 1 ... success.

I wonder about the urgency keyword though, reading:

http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Urgency

I get the impression that we could for clarity use:

gss (0.0.18-2) unstable; urgency=low (HIGH for amd64)

Is this a good idea?

In general, urgency=high seems to be for security bugs, but it is not
clear to me what would warrant urgency=medium.  Is this bugs an
example?  I think I'm missing some documentation for the semantics on
the urgency values.

Thanks for your help!

/Simon