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

Re: Lintian based autorejects

On Tue, Nov 03 2009, Joerg Jaspert wrote:

>> I don't think it's appropriate to make, for instance,
>> dir-or-file-in-var-www instantly fatal without following the usual
>> mass-bug-filing procedure. If you'd like mass bugs to be filed based
>> on these lintian tags but don't have time, let me know if I can help
>> (I can't promise to deal with all of them).
> Please do.  For now, and I think until squeeze or this tag no longer
> visible on lintian.d.o (ie no package affected), whatever comes first,
> this tag is in nonfatal.

        I think you shall find that most already have bugs filed.

>> Some examples of tags where I do not consider this reasonable until
>> bugs have been filed:
>>     - statically-linked-binary
>>     - mknod-in-maintainer-script
> These are nonfatal for the reason that they are, unless the maintainer
> did think about it, something that shouldn't be there. So if they
> really need to be there, fine, override.

        Bugs already filed about the latter. I have not gotten around to
 the statically-linked-binary ones yet.

>>     - debian-rules-not-a-makefile
> Policy must.
>>     - dir-or-file-in-var-www

> Nonfatal with my next commit.

        Bugs already filed.

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

        Bugs filed after manual checks to remove false positives.

>> E: ftp-master:
>> copyright-lists-upstream-authors-with-dh_make-boilerplate This one
>> has been mentioned previously in the thread.  Yes, it's a blemish in
>> the package to list "Upstream Author(s)", but the lintian maintainers
>> have correctly marked this as being of "normal" severity.  We should
>> not be blocking packages from the archive for such low-severity
>> issues; please drop this check.
> Already removed this check, instead added
> copyright-contains-dh_make-todo-boilerplate to nonfatal (will move to
> fatal at some point).

        Bugs filed after manual checks. Yes, there were a huge number of
 false positives.

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

        Have not yet gotten around to this one.

>> E: ftp-master: executable-in-usr-share-doc
>> Clearly a bug, but just as clearly not anything that breaks the package to
>> the point of making it unsuitable for the archive.  Please drop.
> I do think it should stay out, but fine.

        Bugs filed.

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

        Bugs filed for these.

>> E: ftp-master: html-changelog-without-text-version
>> E: ftp-master: upstream-version-not-numeric

> I dont buy your reasoning *at all*, but until further notice I removed
> them.

Pick another fortune cookie.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: