Re: Review of new lintian tags
Hi,
Bastien ROUCARIES wrote:
> Could you review and improve the new lintian tags ?
Thanks. Some quick questions:
> +++ b/checks/changelog-file.desc
> @@ -342,6 +342,13 @@ Info: The latest entries in the Debian changelog file and NEWS.Debian file
> changelog information is canonical and the NEWS.Debian information is
> ignored, but it may be confusing to users to have them be different.
>
> +Tag: bad-intended-distibution
> +Severity: normal
> +Certainty: wild-guess
> +Experimental: yes
> +Info: The last changelog entry is intended to be uploaded
> + to a particular distribution, whereas the changelog said otherwise.
The Info doesn't make it clear to me what this is warning about. Can
you give an example? Is it pointing to a likely bug in the distribution
field of the first line of the changelog or in the bulleted list that
follows it? Can it give false positives? What's the recommended advice
for resolving the problem when running into this tag?
[...]
> +++ b/checks/cruft.desc
[...]
> @@ -432,6 +432,32 @@ Info: The source tarball contains a prebuilt ELF object. They are usually
> directory first. You may want to report this as an upstream bug, in case
> there is no sign that this was intended.
>
> +Tag: source-contains-prebuilt-flash-object
> +Severity: pedantic
> +Certainty: possible
> +Info: The source tarball contains a prebuilt flash object. They are usually
> + left by mistake when generating the tarball by not cleaning the source
> + directory first. You may want to report this as an upstream bug, in case
> + there is no sign that this was intended. An exception is multimedia files.
> + .
> + Please also ensure that flash object is under the preferred form
> + of modification.
Nits:
* 'flash' as in Shockwave Flash or Flash Video is usually capitalized.
Perhaps 'Adobe Flash' would be clearest.
* "They are usually left by mistake" --- whose mistake?
* Aren't Flash files usually multimedia? What does it mean to be a
non-multimedia Flash file?
* What does "under the preferred form of modification" mean?
* If upstream really wants to keep a prebuilt Flash file and also includes
the source, is that okay?
Perhaps:
The source tarball contains a prebuilt file in the Shockwave Flash (SWF)
or Flash Video (FLV) format. These are often included by mistake when
developers generate a tarball without cleaning the source directory
first. An exception is simple video files, which are their own
source.
If there is no sign this was intended, consider reporting it as an
upstream bug.
If the Flash file is not meant to be modified directly, please make
sure the package includes the source for the file and that the
packaging rebuilds it.
Can this tag trip for packages in non-free?
[...]
> +Tag: source-contains-prebuilt-java-object
> +Severity: pedantic
> +Certainty: possible
> +Info: The source tarball contains a prebuilt java object. They are usually
> + left by mistake when generating the tarball by not cleaning the source
> + directory first. You may want to report this as an upstream bug, in case
> + there is no sign that this was intended.
Likewise:
The source tarball contains a prebuilt Java class file. These are often
included by mistake when developers generate a tarball without cleaning
the source directory first. If there is no sign this was intended,
consider reporting it as an upstream bug.
> +Tag: source-contains-prebuilt-silverlight-object
> +Severity: serious
> +Certainty: possible
> +Info: The source tarball contains a prebuilt silverlight object.
> + This file are not buildable under debian and need non free
> + dependencies. This must be completely removed.
Capitalization, subject/verb agreement:
The source tarball contains a prebuilt Silverlight control.
Unfortunately, the tools used to build such files have non-free
dependencies and are not present in Debian. This file must be
completely removed.
Perhaps the description should say something about "either upstream or by
repacking the tarball" or something.
[...]
> @@ -502,6 +528,21 @@ Info: The given source file is licensed under GFDL with invariant
> Ref: http://wiki.debian.org/qa.debian.org/gfdlinvariant,
> http://www.debian.org/vote/2006/vote_001
>
> +Tag: license-problem-non-free-rfc
> +Severity: serious
> +Certainty: possible
> +Info: The given source file is licensed under the newer RFC
> + license
> + .
> + The majority of IETF documents, such as RFCs, are not licensed
> + under DFSG-free terms, and should thus not be included in Debian's main.
> + .
> + Should this file be multi-licensed, please override the tag.
> + .
> + Should this be a false-positive, please report a bug.
Missing "." after "license". s/false-positive/false positive/
Looks good aside from that.
[...]
> @@ -514,6 +555,52 @@ Info: The given source file is licensed under GFDL, but without any
> Ref: http://wiki.debian.org/qa.debian.org/gfdlinvariant,
> http://www.debian.org/vote/2006/vote_001
>
> +Tag: license-problem-nvidia-intellectual
> +Severity: serious
> +Certainty: possible
> +Info: The given source file include part license under a
> + non-distributable license from NVIDIA. Therefore, it is
non-distributable license from NVIDIA = license from NVIDIA that
does not permit redistribution?
> + not even possible to ship this in non-free.
[...]
> +Tag: license-problem-md5sum-non-distribuable-file
> +Severity: serious
> +Certainty: certain
> +Info: The following file is not distribuable even in non free archive.
s/distribuable even/distributable, even/ (spelling, comma usage)
s/non free archive/non-free archive area/, maybe.
[...]
> + You could also split this package and move this file in the
> + non free archive.
"move this file to the non-free archive area" (preposition usage "in"
vs "to"; hyphenation; s/archive/archive area)
> + .
> + Should this be a false-positive, please report a bug
s/false-positive/false positive/
[...]
> +++ b/checks/fields.desc
> @@ -390,6 +390,20 @@ Info: This non-native package lacks a <tt>Homepage</tt> field. If the
> field to <tt>debian/control</tt>.
> Ref: policy 5.6.23
>
> +Tag: homepage-in-binary-package
> +Severity: wishlist
> +Certainty: possible
> +Info: This non-native source package produces at least one binary package
> + with a <tt>Homepage</tt> field. However, the source package itself has
> + no <tt>Homepage</tt> field. Unfortunately, this results in some
> + source-based tools/services (e.g. the PTS) not linking to the homepage
> + of the upstream project.
> + .
> + Note that you can just move the <tt>Homepage</tt> field to the source
> + paragraph in <tt>debian/control</tt> and all binary packages from this
> + source will inherit the value by default.
Nit: I think this would read more nicely as
.
If you move the <tt>Homepage</tt> field to the source paragraph in
<tt>debian/control</tt> then all binary packages from this source
will inherit the value by default.
[...]
> @@ -573,6 +587,13 @@ Info: The package declares a build-depends on an essential package, e.g. dpkg,
> is if you need a particular version of that package, in which case the
> version should be given in the dependency.
>
> +Tag: build-depends-on-an-obsolete-java-package
> +Severity: normal
> +Certainty: certain
> +Ref: java-policy 2.2
> +Info: The package build-depends on an obsolete java dependency
> + It should built-depends on default-jdk instead.
It should *build-depend* (subject/verb agreement), or "it should have a
Build-Depends", which seems a little clearer.
[...]
> +++ b/checks/files.desc
[...]
> @@ -922,6 +928,105 @@ Info: This package contains an embedded copy of JavaScript libraries
> package and symlink the library into the appropriate location.
> Ref: policy 4.13
>
> +Tag: privacy-breach-generic
> +Severity: important
> +Certainty: wild-guess
> +Experimental: yes
> +Info: This package creates a privacy breach by fetching some data from
> + an external website. Please remove these scripts or external html
> + resources.
Could use more detailed advice, but I don't think that should block
the upload. :) Has anyone provided a pointer to XSLT or examples to
help packagers fix these things?
[...]
> +Tag: privacy-breach-donation
> +Severity: serious
> +Certainty: possible
> +Ref: https://wiki.debian.org/UpstreamMetadata
> +Info: This package create a privacy breach by fetching some data from
> + a donation website.
> + .
> + Please remove these privacy problem and add a note on debian/upstream
> + file using the donation field.
Agreement: "these privacy problem" -> "these privacy problems" or
"this privacy problem".
Preposition use: "on debian/upstream" -> "in debian/upstream" or "to
debian/upstream"
Nice idea. Do the normal package managers show donation notices
(either by default or after some configuration)?
[...]
> +Tag: privacy-breach-logo
> +Severity: serious
> +Certainty: possible
> +Info: This package phone home by retrieving some logo.
S/V agreement: "phone home" -> "phones home"
"by retrieving some logo" -> "to retrieve a logo"?
> + .
> + Before using a local copy you should be sure that the corresponding
> + logo is suitable for main. Ask debian-legal for advices.
"for advices" -> "for advice".
> +Tag: privacy-breach-facebook
> +Severity: serious
> +Certainty: possible
> +Info: This package create a privacy breach by fetching some data from
> + facebook like share or like buttons.
"data" -> "elements"?
"facebook" -> "Facebook"
"like share or like buttons" -> ", such as 'Share' or 'Like' buttons"
[...]
> +Tag: privacy-breach-google-cse
> +Severity: serious
> +Certainty: possible
> +Info: This package create a privacy breach by fetching some data from
S/V agreement: "create" -> "creates"
> + google search engine and feed some private data to google.
> + Please remove these scripts.
"google search engine" -> "Google to support a custom search engine"?
"feed some private data to google" -> "sends data to Google when the
script is loaded" or something? What private data is sent?
> +Tag: privacy-breach-piwik
> +Severity: serious
> +Certainty: possible
> +Info: This package creates a privacy breach by using piwik.
> + Piwik is a free and open source web analytics application.
> + .
> + Even if piwik is free and respect the "do not track" browser
> + option, it is nevertheless a breach on our user privacy.
Who collects the data?
"Even if" -> "Although"
"respect" -> "respects"
"on our user privacy" -> "of user privacy" would be clearer, I think.
[...]
> +
> +Tag: privacy-breach-statistics-website
> +Severity: important
> +Certainty: possible
> +Info: This package creates a privacy breach by fetching some
> + data from external website in order to made visitor statistics.
"fetching some data from" -> "fetching elements from"? Or "contacting".
"external website" -> "an external web site"
"in order to make" -> "in order to monitor"? Or "for the sake of"?
[...]
> + Please ask upstream to use free software piwik that respect
> + "do not track" browser option.
"use free software piwik that respect" -> "use Piwik, which is free
software and respects the"
[...]
> +Tag: privacy-breach-w3c-valid-html
> +Severity: serious
> +Certainty: possible
> +Ref: http://validator.w3.org/docs/help.html#icon,
> + http://www.w3.org/Consortium/Legal/logo-usage-20000308
> +Info: This package creates a privacy breach by w3c valid documents icons.
"by w3c valid documents icons" -> "by using the W3C's valid document
icons"?
> + .
> + To show readers that one has taken some care to create an interoperable
> + Web page, a "W3C valid" badge may be displayed on any page that validates.
> + Unfortunatly it means phoning home and download image from w3c website,
> + and thus allowing to track users.
"it means phoning home and download image" -> "that requires
contacting the W3C servers to download the image"
"and thus allowing" -> "which allows the W3C"
> + .
> + Note that these icons are non free and must not be copied
> + inside the package. You could safely delete this "W3C valid" badge.
"non free" -> "non-free"
"inside" -> "into"
[...]
> +++ b/checks/rules.desc
[...]
> @@ -222,6 +222,21 @@ Info: The rules files appear to be reading or modifying a variable not
> can be used by users, who wants to re-compile debian packages with
> special (or non-standard) build flags.
>
> +Tag: debian-rules-should-not-use-underscore-variable
> +Severity: normal
> +Certainty: possible
> +Ref: policy 4.9
> +Info: The rules file use the make variable $(_).
"use" -> "uses"
[...]
> + If rules file uses $(dir $(_)) to discover directory containing
> + source package (presumably in order to implement get-orig-source
> + target), please replace it by $(dir $(firstword $(MAKEFILE_LIST))).
"by" -> "with"
> --- a/checks/scripts.desc
> +++ b/checks/scripts.desc
Stopping here. Will pick up after reading JBR's review.
Thanks,
Jonathan
Reply to: