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