[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Lintian based autorejects

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

- 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.

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

Reply to: