On Wed, Nov 04, 2009 at 01:15:57AM +0100, Joerg Jaspert wrote: > > E: ftp-master: wrong-file-owner-uid-or-gid > > Policy 9.2 does /not/ prohibit shipping files with owners outside these > > ranges; it prohibits relying on user or group IDs outside these ranges being > > static, but there doesn't appear to be anything in Policy that prohibits > > creating the user in the package preinst and then unpacking the package such > > that ownership is applied by /name/. (Unless I'm mistaken, this is > > precisely what dpkg does.) > > So false-positives are possible with this lintian check, and it should be > > overrideable. > We currently only have 1 package in the whole archive triggering > this. Thats why it is listed. > Fine, moved to nonfatal. Yes, and that package is not a false-positive - it is genuinely broken and should be fixed. Still, the check itself is unreliable. > > E: ftp-master: section-is-dh_make-template > > Sections in source packages have minimal impact; the section that matters is > > the one specified in the archive override. There's no reason that the > > invalid default value given by dh_make should result in a package being > > rejected, when arbitrary other values for the field would not. Please drop > > this check. > We tend to simply reject such packages from NEW. So the maintainer can > see it instantly triggered this way or has to wait until NEW is > processed. I tend to think this way is better. I would agree with you except for two things: - the check will also be applied to existing packages in the archive which already have overrides, where the source package's section doesn't really matter - the check only worries about the default template value, and ignores the infinite variety of other possible invalid section values Is there a way the check could be applied only to new packages? > > E: ftp-master: library-in-debug-or-profile-should-not-be-stripped > > This is obviously true for debug, and it makes sense to reject such packages > > because they're shipping broken debug files; is it certain for profile as > > well? > Thats a question for the library overlords, I have far to less > experience in that area. If not then maybe lintian needs adjustments/a > new check and we take that. $ zgrep lib/profile/ ~/ftp/dists/unstable/Contents-i386.gz usr/lib/profile/liblockdev.a debug/liblockdev1-dbg usr/lib/profile/liblockdev.so.1 debug/liblockdev1-dbg $ <shrug> apparently not really an issue in practice; yes, lintian can be fixed if/when this proves necessary. > > E: ftp-master: binary-file-compressed-with-upx > > Where is this documented? There's no mention of UPX in Debian Policy, and > > the only mention in the lintian changelog is a 2001 bug about adding support > > for /reading/ UPX executables. > There is no such tag, nothing currently in the archive. Absent a basis in Policy, "nothing uses it" is not really a reason to reject new packages that might start using it. AFAICS, this is basically an unreviewed lintian error. > > E: ftp-master: html-changelog-without-text-version > > E: ftp-master: upstream-version-not-numeric > > E: ftp-master: build-depends-on-essential-package-without-using-version > > E: ftp-master: depends-on-build-essential-package-without-using-version > > E: ftp-master: build-depends-on-build-essential > > E: ftp-master: no-standards-version-field > > E: ftp-master: invalid-standards-version > I dont buy your reasoning *at all*, but until further notice I removed them. Ok, thanks. When should we expect this to be reflected on ftp-master and http://ftp-master.debian.org/~joerg/lintian/lintian.tags? Both still show these tags in effect. 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. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature