On Tue, Oct 27, 2009 at 03:06:07PM +0100, Joerg Jaspert wrote:
> The second category is named "error" and the tags listed can not be
> overridden. Those are tags corresponding to packaging errors serious
> enough to mark a package unfit for the archive and should never happen.
> In fact, most of the tags listed do not appear in our archive
> currently, the few packages listed below should be easily fixable with
> their next upload.
> We will provide a static url for the list of tags soon, for now you can
> look at them using [1].
> There are multiple files in [2] showing you the packages affected,
> together with the tags they hit.
> [1] http://ftp-master.debian.org/~joerg/lintian/lintian.tags
> [2] http://ftp-master.debian.org/~joerg/lintian/
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
I'd recommend that others do likewise, to get an appropriately large set of
eyeballs on this change.
Some problems I find with this list:
E: ftp-master: wrong-file-owner-uid-or-gid
N:
N: The user or group ID of the owner of the file is invalid. The owner
N: user and group IDs must be in the set of globally allocated IDs,
N: because other IDs are dynamically allocated and might be used for
N: varying purposes on different systems, or are reserved. The set of the
N: allowed, globally allocated IDs consists of the ranges 0-99,
N: 64000-64999 and 65534.
N:
N: Refer to Debian Policy Manual section 9.2 (Users and groups) for
N: details.
N:
N: Severity: serious, Certainty: certain
N:
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.
E: ftp-master: copyright-lists-upstream-authors-with-dh_make-boilerplate
N:
N: There is "Upstream Author(s)" in your copyright file. This was most
N: likely a remnant from the dh_make template.
N:
N: There's either one upstream author, in which case you should remove
N: the "(s)", or there are several upstream authors, in which case you
N: should remove the "(" and ")".
N:
N: o/~ join us now and carefully edit debian/copyright files! o/~
N:
N: Severity: normal, Certainty: certain
N:
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.
E: ftp-master: section-is-dh_make-template
N:
N: The "Section:" field in this package's control file is set to unknown.
N: This is not a valid section, and usually means a dh_make template
N: control file was used and never modified to set the correct section.
N:
N: Refer to Debian Policy Manual section 2.4 (Sections) for details.
N:
N: Severity: important, Certainty: certain
N:
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.
(BTW, this tag appears twice in the list.)
E: ftp-master: library-in-debug-or-profile-should-not-be-stripped
N:
N: Libraries in .../lib/debug or in .../lib/profile usually should not be
N: stripped.
N:
N: Severity: important, Certainty: certain
N:
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?
E: ftp-master: binary-file-compressed-with-upx
N:
N: Debian does not allow binaries to be compressed by UPX.
N:
N: Severity: important, Certainty: certain
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.
E: ftp-master: copyright-file-is-symlink
N:
N: The copyright file /usr/share/doc/<pkg>/copyright must not be a
N: symbolic link.
N:
N: Refer to Debian Policy Manual section 12.5 (Copyright information) for
N: details.
N:
N: Severity: serious, Certainty: certain
N:
This looks to me like a bug in Policy. Why do we allow /usr/share/doc/$pkg
to be a symlink, but disallow /usr/share/doc/$pkg/copyright as a symlink if
it fulfills the same constraints? Will follow up on this separately via
debian-policy.
E: ftp-master: executable-in-usr-share-doc
N:
N: Usually, documentation files in /usr/share/doc should have mode 0644.
N: If the executable is an example, it should go in
N: /usr/share/doc/<pkg>/examples.
N:
N: Severity: important, Certainty: certain
N:
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.
E: ftp-master: debian-rules-is-symlink
N:
N: The file debian/rules is a symlink instead of a regular file. This is
N: unnecessary and makes package checking and manipulation more
N: difficult. If the rules file should be available in the source package
N: under multiple names, make debian/rules the real file and the other
N: names symlinks to it.
N:
N: This problem may have prevented lintian from performing other checks,
N: leading to undetected changelog errors.
N:
N: Severity: normal, Certainty: certain
N:
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.
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. Please drop these checks, and follow the
procedure for amending Policy if you think they need to be enforced.
(Several of these changes I might be inclined to second myself, but I object
to any such checks being enforced in the archive when they have not been
ratified by the project first.)
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
The others in the list of fatal errors all appear to follow directly from
Policy "must" requirements, or else indicate a package that is completely
broken and will fail to work in various ways when installed, so are
reasonable justification for blocking the package from the archive.
> For future handling: If we are adding tags to the list that will hit
> more than a few packages we will send a notice to the d-d-a list.
I don't think it's appropriate for the ftp team to add any other checks
without notifying the project, regardless of how many packages are currently
affected. Please make sure you notify the project of /any/ additional rules
you apply at archive accept time.
Thanks,
--
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