Forget list reply
---------- Forwarded message ---------- From: Bastien ROUCARIES <[email protected]> Date: Mon, Jan 6, 2014 at 8:36 AM Subject: Re: Review of new lintian tags To: Jonathan Nieder <[email protected]> On Mon, Jan 6, 2014 at 1:06 AM, Jonathan Nieder <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CAE2SPAadwjuSU+a2_BV=sqmn0jsh17vmxxutpgk8eud3mkz...@mail.gmail.com
