Re: Review of new lintian tags
Bastien ROUCARIES wrote:
> Could you review and improve the new lintian tags ?
I can certainly try, though I won't be able to produce a patch for a
diff...
[...]
> +++ b/checks/changelog-file.desc
[...]
> +Tag: bad-intended-distibution
^
Well, there's an easy one to start off with:
Tag: bad-intended-distribution
> +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.
I'm not sure I understand what problem this is detecting (for a start,
it talks about uploading a changelog entry rather than a package). Is
it trying to say something along the lines of:
Info: The last changelog entry implies this version is not for release.
Instead it should specify the distribution it is to be uploaded to.
(That's "distribution" in the Debian-specific sense.)
[...]
> +++ b/checks/cruft.desc
[...]
> +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.
What are multimedia files an exception to? I'm guessing:
Info: The source tarball contains a prebuilt Flash object. These are usually
left by mistake due to not cleaning the source directory first when
generating the tarball. If there is no sign that it was a deliberately
included multimedia file, you may want to report this as an upstream bug.
Or maybe just (bringing it in line with the Java version):
If there is no sign that it was deliberately
included, you may want to report this as an upstream bug.
> + .
> + Please also ensure that flash object is under the preferred form
> + of modification.
How would that work? Do you mean:
Please also ensure that the source is included under the preferred form for
modification.
Or is it in fact possible for a Flash object to count as source?
Please also ensure that Flash object constitutes the preferred form for
modification.
(I notice the Java and Silverlight blobs don't have equivalent text, so
maybe you do mean the latter after all.)
> +
> +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.
Info: The source tarball contains a prebuilt Java object. These are usually
left by mistake due to not cleaning the source directory first when
generating the tarball. If there is no sign that it was deliberately
included, you may want to report this 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.
There are some straightforward grammar errors here. Also, I suspect
if I installed enough extra non-free homebrew Moonshine or whatever
it's called then I would be able to build these objects under Debian.
Simplify it down to:
Info: The source tarball contains a prebuilt Silverlight object. These files
are not buildable using free software and must be removed.
I notice that the following "source-contains-prebuilt-windows-binary"
description adds a paragraph that suggests "Check if upstream also
provides source-only tarballs that you can use as the upstream
distribution instead". Should that be offered for all these checks?
[...]
> +Tag: license-problem-non-free-rfc
> +Severity: serious
> +Certainty: possible
> +Info: The given source file is licensed under the newer RFC
> + license
^
Missing punctuation.
> + .
> + 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.
That's like the Spanish Main except without the piracy, right? It
should be "in Debian's main archive" or just "in Debian main" - or
maybe "in the main archive". (Oh, I see it's also in the Wiki page.)
> + .
> + Should this file be multi-licensed, please override the tag.
> + .
> + Should this be a false-positive, please report a bug.
> +Ref: https://wiki.debian.org/NonFreeIETFDocuments
That use of "should" is valid but easy to overuse - I'd recommend:
If this file is multi-licensed, please override the tag.
.
If this is a false-positive, please report a bug against Lintian.
[...]
> +Tag: license-problem-nvidia-intellectual
> +Severity: serious
> +Certainty: possible
> +Info: The given source file include part license under a
I think this should be:
Info: The given source files include material licensed under a
And in what sense are the files "given"? Will Lintian name them in
its output? Later descriptions say "the following file"; I'll assume
that's correct.
> + non-distributable license from NVIDIA. Therefore, it is
> + not even possible to ship this in non-free.
> + .
> + Please re-package the package without the file (if possible)
> + or ask the ftp-masters to remove the package.
> + .
> + If the package has been uploaded to Debian before, please
> + remember to also notify snapshot.debian.org about this
> + package containing a non-distributable file.
> + .
> + Should this be a false-positive, please report a bug
> + against lintian.
Fixing some capitalisation:
Info: The following source files include material under a
non-distributable license from Nvidia. Therefore, it is
not even possible to ship this in non-free.
.
Please re-package the package without the file (if possible)
or ask the FTP-masters to remove the package.
.
If the package has been uploaded to Debian before, please
remember to also notify snapshot.debian.org about this
package containing a non-distributable file.
.
If this is a false-positive, please report a bug against Lintian.
(No "Ref:"? I for one have no idea what this bad license looks like.)
> +Tag: license-problem-md5sum-non-distribuable-file
^
> +Severity: serious
> +Certainty: certain
> +Info: The following file is not distribuable even in non free archive.
^
Oh, you avoided it above, but here it is: "distribuTable".
(So Lintian will give the filename _following_ this text?)
> + .
> + Please re-package the package without the file (if possible)
> + or ask the ftp-masters to remove the package.
> + .
> + If the package has been uploaded to Debian before, please
> + remember to also notify snapshot.debian.org about this
> + package containing a non-distributable file.
> + .
> + Should this be a false-positive, please report a bug
> + against lintian.
Tag: license-problem-md5sum-non-distributable-file
Severity: serious
Certainty: certain
Info: The following file is not distributable even in the non-free
archive.
.
Please re-package the package without the file (if possible)
or ask the FTP-masters to remove the package.
.
If the package has been uploaded to Debian before, please
remember to also notify snapshot.debian.org about this
package containing a non-distributable file.
.
If this is a false-positive, please report a bug against Lintian.
> +
> +Tag: license-problem-md5sum-non-free-file
> +Severity: serious
> +Certainty: certain
> +Info: The following file is not suitable for main or contrib.
> + .
> + Please re-package the package without the file (if possible)
> + or ask the ftp-masters to remove the package.
> + .
> + You could also split this package and move this file in the
> + non free archive.
> + .
> + Should this be a false-positive, please report a bug
> + against lintian.
Only minor tweaks, most of which you've seen before:
Info: The following file is not suitable for main or contrib.
.
Please re-package the package without the file (if possible)
or ask the FTP-masters to remove the package.
.
You could also split this package and move this file into the
non-free archive.
.
If this is a false-positive, please report a bug against Lintian.
[...]
> +Tag: homepage-in-binary-package
Looks OK.
[...]
> +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.
^ ^
Missing punctuation, among other things:
Info: The package build-depends on an obsolete Java dependency.
It should build-depend on default-jdk instead.
> Tag: vcs-field-uses-not-recommended-uri-format
> -Severity: minor
> +Severity: normal
> Certainty: possible
> Info: The VCS-* field uses an URI which doesn't match the recommended
^
I know this hasn't changed, but "an URI" seems unlikely. Are there
people who pronounce "URI" as "ooree"? I've never heard that - it's
always "you-are-eye", and "you" begins with a consonant sound; so it's
"a URI", not "an". Likewise below:
> format, but still looks valid. Examples for not recommended URI formats
> are protocols that require authentication (like SSH). Instead where
> possible you should provide an URI that is accessible for everyone
^
> without authentication.
> + .
> + This renders debcheckout(1) unusable in these cases.
(The changed part is fine.)
[...]
> +++ b/checks/files.desc
[...]
> +Tag: package-install-into-obsolete-dir
> +Severity: normal
> +Certainty: certain
> +Info: The package installs files in an obsolete dir. You
> + should consider to move to newer path.
Ungrammatical. "You should consider moving them to a newer path", or
given that it's already gone past the stage of being merely deprecated
and is considered obsolete, it's time they did more than just consider
it:
Info: The package installs files to an obsolete directory.
Please use a newer path.
> +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.
This needs to be a lot more explicit about what the problem is - as it
stands it could be describing wmweather or indeed wget. I gather it
doesn't mean unintentional webbugs like a valid-HTML button, because
that's got its own check; so what does it mean? For a start if it's
talking about a *potential* *runtime* privacy breach then those words
should be in the text:
Info: This package creates a potential privacy breach by fetching data
from an external website at runtime. Please remove these scripts or
external HTML resources.
(I'm standardising towards "website" and "runtime" rather than "web
site" and "run time", our usual preference on d-l-e, since this is for
developer consumption.)
> +Tag: privacy-breach-google-adsense
> +Severity: serious
> +Certainty: possible
> +Info: This package creates a privacy breach by using Google Adsense.
> + Google Adsense is a service run by Google that allows publishers of web
> + sites to automatically serve advertisements. Unfortunately, it requires
> + tracking and breaching privacy of our users.
> + .
> + This tag can also indicate the use of related obsolete privacy breaker
> + software, Urchin WebAnalytics.
> + .
> + Note that using Google Adsense in a local copy of a page is a violation of
> + Google Adsense terms of use. This violation renders this package not
> + distributable in Debian, and thus a serious bug.
It's capitalised as "Google AdSense". It needs some tweaks:
Info: This package creates a privacy breach by using Google AdSense.
Google AdSense is a service run by Google that allows publishers
of websites to automatically serve advertisements. Unfortunately, it
requires tracking and breaching the privacy of web users.
.
This tag can also indicate the use of the related obsolete privacy
breaching software, Urchin WebAnalytics.
.
Note that using Google AdSense in a local copy of a page is a violation of
the Google AdSense terms of use. This violation renders this package not
distributable in Debian, and is thus a serious bug.
Notice that I have replaced "our users" with "web users", since the
victims of the security breach aren't necessarily *our* users (in the
sense of having ever heard of Debian).
> +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.
I still don't understand what the privacy breach is here...
* Does it give users the opportunity to visit an external website by
choosing to click a button? That might be done in an annoyingly
naggy way, but it wouldn't be even a potential privacy breach.
* Does the package's web interface display a "please donate" button
which it fetches from upstream? If so, okay, that's a trivial
unintentional webbug that should be replaced with some sort of
generic free image hosted locally.
* Or is it some noxious Javascript plugin that posts my browser
history on Facebook if I so much as think of visiting this site?
I just don't know what it's talking about. But leaving aside the fact
that it fails as a description of the issue, here's a slightly
patched-up version:
Info: This package create a potential privacy breach by fetching data
from a donation website at runtime.
.
Please remove this privacy problem and add a note to the
debian/upstream file using the donation field.
> +
> +Tag: privacy-breach-logo
> +Severity: serious
> +Certainty: possible
> +Info: This package phone home by retrieving some logo.
> + .
> + Before using a local copy you should be sure that the corresponding
> + logo is suitable for main. Ask debian-legal for advices.
Surely "phoning home" is what it's called when it's an *intentional*
(malicious or at least premeditated) privacy breach, like, say, a
one-pixel webbug? Whereas this is talking about an externally-hosted
image which is quite probably only being fetched because they didn't
want to make the package non-free by including a trademarked logo. It
hardly seems "Severity: serious".
Info: This package creates a potential privacy breach by fetching a
logo at runtime.
.
Before using a local copy you should check that the logo is suitable
for main. Ask debian-legal for advice.
Or if they often turn out to be non-free, maybe it should be:
Please replace the image with a local copy, or (if the logo is not
suitable for inclusion in main) a freely licensed substitute.
> +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.
> + Please remove these scripts or frames.
Okay, this one's serious: "privacy breach" and "Facebook" are more or
less synonyms, in my experience, and a "Like" button isn't just an
image that can potentially leak visitors' IP addresses, it's an iframe
designed to harvest their login IDs. But you've got a malformed
indent and uncapitalised Facebook.
Info: This package creates a privacy breach by exchanging data with
Facebook at runtime via plugins such as "Share" or "Like" buttons.
.
Please remove these scripts or frames.
> +
> +Tag: privacy-breach-google-cse
> +Severity: serious
> +Certainty: possible
> +Info: This package create a privacy breach by fetching some data from
> + google search engine and feed some private data to google.
> + Please remove these scripts.
Is this here because it passes Google Custom Search Engine queries to
Google (and the NSA and whoever else) in the usual way, or does the
CSE plugin actively harvest Google+ IDs from casual visitors? Is it:
Info: This package creates a potential privacy breach by fetching
data from Google at runtime, and may feed private data to Google via
Custom Search Engine queries.
.
Please remove these scripts.
Or is it:
Info: This package creates a privacy breach by exchanging data with
Google at runtime via the Google Custom Search Engine plugin.
.
Please remove these scripts.
> +
> +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.
I'll import a few words from privacy-breach-google-adsense:
Info: This package creates a privacy breach by using Piwik.
Piwik is a free and open source web analytics application, designed to
allow publishers of websites to track visitors.
.
Even though Piwik is free and respects the "Do Not Track" browser
option, it is nevertheless a breach of the privacy of web users.
That last line might be going a bit far - it seems to me that an app
that respects DNT is at worst a *potential* privacy breach. And
besides, if I'm building the website of the Society For Web Users Who
Value Personalisation Over Privacy, why shouldn't it have a Piwik
plugin? (But then again, if I'm being paid to do web design I suppose
I can't expect "sudo apt-get install website" to give me the whole
thing on a silver platter.)
> +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.
> + .
> + Please remove these scripts from the local copy of the page.
There's some other copy of the page?
> + .
> + Please ask upstream to use free software piwik that respect
> + "do not track" browser option.
Now I'm confused. If they use an analytics plugin that isn't Piwik
then they should replace this Severity: important Lintian bug with the
above Severity: serious Lintian bug?
> + .
> + This tag include the following website:
> + - cruel-carlota.pagodabox.com
> + - linkexchange.com (defunct)
> + - nedstatbasic.net
> + - statcounter.com
> + - sitemeter.com
> + - webstats.motigo.com
If the formatting works the way I think it does this should have an
extra indent (and preferably asterisks instead of dashes). Compare
the one in unknown-file-in-debian-source.
Info: This package creates a privacy breach by fetching data from
an external website in order to compile visitor statistics.
.
Please remove these scripts.
.
Please ask upstream to use the free software web analytics engine
Piwik, which respects the "Do Not Track" browser option.
.
This tag covers the following websites:
* cruel-carlota.pagodabox.com
* linkexchange.com (defunct)
* nedstatbasic.net
* statcounter.com
* sitemeter.com
* webstats.motigo.com
> +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.
> + .
> + 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.
"Interoperable" seems like the wrong jargon term - shouldn't it take at
least two things to be inter-anything-able? Just say "standards
compliant".
And the use of quotes implies that the badge's lettering includes the
words "W3C valid", which they don't - they say "W3C HTML 4.01 ✓" or
the like (while the filenames are things like "valid-html401.png").
> + .
> + Unfortunatly it means phoning home and download image from w3c website,
> + and thus allowing to track users.
> + .
> + Note that these icons are non free and must not be copied
> + inside the package. You could safely delete this "W3C valid" badge.
Again, calling this "phoning home" is tendentious. Do we have some
reason to think the W3C are in fact tracking the IP addresses of all
the web users who happen to visit a page with a "valid HTML" button?
How is this the same severity as the Facebook "share-my-secrets"
plugin?
(Then again, what's this icon doing in a Debian package? We can only
certify that the page was valid HTML "out of the box", before the
local webmaster started sabotaging it!)
Info: This package creates a potential privacy breach by fetching W3C
validation icons.
.
These badges may be displayed to tell readers that care has been
taken to make a page compliant with W3C standards. Unfortunately,
downloading the image from www.w3.org might expose the reader's IP
address to potential tracking.
.
Note that these icons are non-free and must not be copied into the
package. You could safely delete this W3C validation badge.
[...]
> Certainty: certain
> Ref: http://lists.debian.org/debian-devel/2009/03/msg00119.html
> Info: Files in <tt>/etc/modprobe.d</tt> should use filenames ending in
> + <tt>.conf</tt>. modprobe silently ignores all files which do not match
> + this convention.
No problem here.
[...]
> Info: The arch all pkg-config file contains reference to an multi-arch path.
^ ^
Hmm, are phrases like "arch all" and "arch any" just DD slang for
"Architecture: all"? Should the spelling be "Arch:all" or "ARCH=all"
or "--arch-all" or what? I'll leave it as it is.
Info: The arch all pkg-config file contains a reference to a multi-arch path.
Or maybe refers to a multi-arch path.
If this was intended for user consumption I'd think about translating
it as something like "multi-arch-compliant library path", but I'll
assume for Debian developers this is intelligible.
No, wait, isn't it "multiarch"? Everyone else seems to think so...
but Lintian consistently spells it with a hyphen.
> .
> This can be usually be fixed by moving this file to a multi-arch path.
> + .
> + Another likely cause is using debhelper 9 or newer (thus enabling
> + multi-arch paths by default) on a non multi-arched package.
> + The usual cure is in this case to render your package multi-arch.
Another likely cause is using debhelper 9 or newer (thus enabling
multi-arch paths by default) on a package without multi-arch support.
The usual cure in this case is to update it for multi-arch.
[...]
> +Tag: debian-rules-should-not-use-underscore-variable
> +Severity: normal
> +Certainty: possible
> +Ref: policy 4.9
> +Info: The rules file use the make variable $(_).
^
s/use/uses/
> + .
> + According to Policy 4.9, "invoking either of `make -f debian/rules
> + _args..._' or `./debian/rules _args..._' must result in identical
> + behavior." One way to inadvertently violate this policy is to use the $_
> + variable.
Getting a bit nitpicky: I don't see any uses in Lintian descriptions
of `this' style of quotes, or _underscores_ to mark variables.
Looking at the original in Policy 4.9 and coverting that into
Lintian-style markup, it's:
According to Policy 4.9, "invoking either of 'make -f debian/rules
<args...>' or './debian/rules <args...>' must result in identical
behavior." One way to inadvertently violate this policy is to use the $_
variable.
Though at other times Lintian seems to use markup along the lines of:
According to Policy 4.9, <q>invoking either of <tt>make -f debian/rules
<args…></tt> or <tt>./debian/rules
<args…></b>' must result in identical behavior.</q>
One way to inadvertently violate this policy is to use the $_ variable.
> + .
> + 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))).
Missing articles:
If the rules file uses $(dir $(_)) to discover the directory containing
the source package (presumably in order to implement the get-orig-source
target), please replace it by $(dir $(firstword $(MAKEFILE_LIST))).
[...]
> +Tag: maintainer-script-should-not-use-update-alternatives-set
> +Severity: normal
> +Certainty: certain
> +Info: <tt>update-alternatives --set <alternative> foo</tt> or
Sentence fragment.
> + <tt>update-alternatives --config <alternative></tt> or
> + <tt>update-alternatives --set-selections</tt>
> + called in maitainer script. Thus it's impossible to distinguish
^
> + between an alternative that's manually set because the user set it,
> + vs. one that's manually set because the package set it.
^^
> +Ref: update-alternatives(8)
Info: The maintainer script calls <tt>update-alternatives --set
<alternative> foo</tt> or <tt>update-alternatives --config
<alternative></tt> or <tt>update-alternatives --set-selections</tt>.
This makes it impossible to distinguish between an alternative that's
manually set because the user set it and one that's manually set because
the package set it.
Or to say the same thing without the tags:
Info: The maintainer script calls 'update-alternatives --set <alternative>
foo' or 'update-alternatives --config <alternative>' or
'update-alternatives --set-selections'. This makes it impossible to
distinguish between an alternative that's manually set because the user
set it and one that's manually set because the package set it.
(Or maybe "The maintainer script apparently calls"...)
[...]
> +Tag: maintainer-script-should-not-use-install-sgmlcatalog
No problems.
> +Tag: maintainer-script-should-not-use-service
> +Experimental: yes
> +Info: The maintainer script apparently runs service command.
the 'service' command.
> + This command is reserved for local
> + administrators and must never be used by a Debian package.
> +
> +Tag: maintainer-script-should-not-use-adduser-system-without-home
> +Severity: serious
> +Certainty: certain
> +Info: The maintainer script apparently runs adduser --system
> + without specifying --home option outside /home/.
Er, what? Oh, when it says "*without* specifying it *outside* /home"
does it mean "while specifying it as inside /home"?
> + The FHS says "/home is a fairly standard concept, but it
> + is clearly a site-specific filesystem. The setup will differ
> + from host to host. Therefore, no program should rely on this
> + location."
> +Ref: fhs homeuserhomedirectories
Info: The maintainer script apparently runs 'adduser --system'
but hardcodes a path under '/home' for the '--home' option.
The FHS says "/home is a fairly standard concept, but it
is clearly a site-specific filesystem. The setup will differ
from host to host. Therefore, no program should rely on this
location."
[...]
> +Tag: debian-watch-may-check-gpg-signature
> +Severity: pedantic
> +Certainty: certain
> +Ref: uscan(1)
> +Info: This watch file does not include a means to verify
> + the upstream tar using cryptographic signature.
the upstream tarball using a cryptographic signature.
> + .
> + If upstream distributions provide such signatures please
> + use the pgpsigurlmangle options in this watch file
> + opts= to generate the upstream URL of an GPG signature.
> + This signature is automatically downloaded and verified
> + against a keyring stored in debian/upstream-signing-key.pgp
If upstream distributions provide such signatures, please
use the pgpsigurlmangle options in this watch file's
opts= to generate the URL of an upstream GPG signature.
[...]
> + Of course, not all upstream distributions provide such
> + signatures but you could try to request such signatures
> + from upstream and thus verifying that not a third party
> + modified the code after the release against the will
> + of upstream. We all know the phpmyadmin, unrealircd
> + or proftpd security bugs (only to mention some of
> + them). This would at least make it a lot harder for an
> + attacker to get such code to a wider audience through
> + distributions like Debian.
("We" here must be DDs, because I hadn't heard of those bugs.)
Of course, not all upstreams provide such signatures, but
you could request them as a way of verifying that no third
party has modified the code against their wishes after the
release. We have all heard of the phpmyadmin, unrealircd, or
proftpd security bugs (to mention only a few). This would at
least make it a lot harder for an attacker to get such code
to a wider audience via distributions like Debian.
> +Tag: debian-watch-file-pubkey-file-is-missing
> +Severity: important
> +Certainty: certain
> +Ref: uscan(1)
> +Info: This watch file verify cryptographic signature but
> + the upstream public key is missing.
> + .
> + Please add upstream public keys in debian/upstream-signing-key.pgp.
Info: This watch file verifies a cryptographic signature but
the upstream public key is missing.
[...]
Phew!
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: