Russ Allbery <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]:/var/cache/pbuilder/result$ lintian -i -I gss_0.0.18-2_i386.changes [EMAIL PROTECTED]:/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. [EMAIL PROTECTED]:/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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
