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 <sriva...@debian.org> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org