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