Re: Lintian based autorejects
> 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.
> 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.
> - debian-rules-not-a-makefile
Policy must.
> - dir-or-file-in-var-www
Nonfatal with my next commit.
On 11916 March 1977, Lucas Nussbaum wrote:
> Also, lots of packages currently in our archive already have those
> errors. What do you plan to do with those? If you auto-reject packages
> that introduce those errors, it would be logical to file RC bugs and/or
> remove them from the archive.
By simply removing them I don't even give the chance of fixing it up.
On 11921 March 1977, Steve Langasek wrote:
> Since I'm not familiar with most of these lintian errors by name, I've run
> the list of fatal errors through lintian-info with the following script:
> $ wget -O - -q http://ftp-master.debian.org/~joerg/lintian/lintian.tags \
> | sed -e'1,/error:$/d; s/^[[:space:]]\+-/E: ftp-master:/' | lintian-info
Replace error by fatal to have this line work again.
Also, remember to rerun this every now and then during this discussion,
the file is still regularly updated based on input we get.
> 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.
> 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).
> 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.
> 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.
> 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.
> 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.
> E: ftp-master: debian-rules-is-symlink
> Not a requirement that's derived from Policy at all. If you think this is
> important to require for all packages due to the side effect on lintian's
> ability to do further checking, please discuss it on debian-policy; in the
> meantime, please drop.
Dropped.
> The following checks are also marked as "should" requirements in Debian
> Policy, not "must"s. The ftp team has no authority to escalate these to
> "must" at the archive level.
Now there is a long flame waiting to start about what authority there
is, or not.
Yet I dont have the time, motivation or energy for such a pointless
thing, so:
> 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.
On 11922 March 1977, Raphael Hertzog wrote:
>> If the set of tags being drawn from is limited to those that are recognized
>> as violations of Policy "must" requirements, then I have no opinion on who
>> should decide which tags are blockers and which ones are not. If the
>> candidate tags are *not* limited to that set, then I think we have a
>> governance problem regardless of who's driving.
> What about using those tags to achieve release goals?
I dislike this.
--
bye, Joerg
<dannf> asking an engineer at hp for part numbers is like asking Ganneff
for the right mixture of fuel for a 747 - i might happen to know
(like if i'd just ordered one) or might know someone who knows,
but its a crapshoot :) )
Reply to: