Fwd: Review of new lintian tags
Forget list reply
---------- Forwarded message ----------
From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
Date: Mon, Jan 6, 2014 at 8:36 AM
Subject: Re: Review of new lintian tags
To: Jonathan Nieder <jrnieder@gmail.com>
On Mon, Jan 6, 2014 at 1:06 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> 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?
Means something like:
lintian (2.5.21) experimental; urgency=medium
* upload to unstable
> [...]
>> +++ 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?
I am not a ftpmaster.
>
> [...]
>> +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.
ok done
>> +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.
done
>
> [...]
>> @@ -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?
Yes. I will add a ref
>> + 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.
done
> [...]
>> @@ -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?
I have posted one script recently on debian-devel. i use it for imagemagick.
> [...]
>> +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.
Will get JBR review and send a new diff. Thank for your work
> Thanks,
> Jonathan
Reply to: