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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
