Bug#872665: lintian: tag metadata tracking releases of Debian Policy

[Sean Whitton]

Package: lintian
Version: 2.5.52
Severity: wishlist

Dear maintainers,

At the Debian Policy BoF at DebConf17, it was suggested that Lintian
start tracking metadata that connects up Lintian tags and releases of
Debian Policy.

Looking at my notes from the BoF, there are two types of metadata that
could be useful:

1. tag metadata indicating the release of policy that added the
   requirement or recommendation checked by the tag

   For example, a Lintian tag emitted when a package installs both a
   menu entry and a desktop entry would have '4.0.1' for the value of
   this piece of metadata.  That's because policy 4.0.1 introduced the
   requirement that a package not install both a menu entry and a
   desktop entry.

2. for each Lintian release, a list of policy versions such that for
   each version V, if the Standards-Version of a package is the version
   of policy immediately prior to V and the package is Lintian clean,
   the Standards-Version may be bumped to V

It should be clear how (2) is useful to package maintainers: if their
package has Standards-Version 4.0.0, the package is Lintian clean under
the latest release of Lintian and the list of versions in (2) for the
latest release of Lintian includes 4.0.1, they may bump their
Standards-Version to 4.0.1 without working through the upgrading
checklist.

(1) is useful for constructing (2): we can compare the list of tags
which have 4.0.1 as their value for (1) to the upgrading checklist for
policy release 4.0.1, and if each item in the list is covered by a tag,
we may add 4.0.1 to (2) for the next release of Lintian.

We would expect this metadata to be quite incomplete, both because it is
time-consuming to compile and because not all new policy requirements
can be checked by Lintian tags.  This incompleteness would not prevent
the metadata from being useful to maintainers where it does exist.

There are also questions about whether to include recommendations
(usually Lintian info/pedantic tags) in this, or just requirements.  The
latter probably makes more sense since maintainers bump
standards-version based on requirements that they have satisfied, not
recommendations.

Thanks for considering these suggestions!

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils  2.29-4
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.18.24
ii  file  1:5.31-1
ii  gettext   0.19.8.1-2+b1
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.32+b2
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b2
ii  libdpkg-perl  1.18.24
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.0-5
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-1
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.63-2+b2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.26.0-5
ii  t1utils   1.40-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.24
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.46-1

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Upstream Tarball Signature Files

[Osamu Aoki]

Hi,


On Fri, Aug 18, 2017 at 12:02:27PM +0200, Guillem Jover wrote:
..
> Adding support for more signature formats or filename variations is
> not hard, but it increases the amount of those extensions and perhaps
> the additional sanity checks we have to support and perform on them on
> multiple tools, etc. It would also require waiting at least once more
> release cycle until they can be used.

I just commited uscan/mk-origtargz support of these.

It will be nice dpkg can support both
 foo.tar.gz
 foo.tar.gz.asc
or 
 foo.tar.gz
 foo.tar.asc (signature on uncompressed)
combinations.

There are upstream releasing in these format.

More nasty one is releasing foo.tar.gz with "gpg -s" w/o -b as
foo.tar.gz.sig or "gpg -sa" as foo.tar.gz.asc.  I have no idea how to
extract signaturefile from non-detached signature.  That's remaining
task but a rare case.

Osamu

[lintian] 01/01: Add 4.0.1 as a known standards version.

[Chris Lamb]

This is an automated email from the git hooks/post-receive script.

lamby pushed a commit to branch master
in repository lintian.

commit dca8c9995885c4feb71be686f4eaa40f748d7160
Author: Chris Lamb 
Date:   Sat Aug 19 08:19:18 2017 -0700

Add 4.0.1 as a known standards version.
---
 data/standards-version/release-dates   | 1 +
 debian/changelog   | 5 +
 debian/control | 4 ++--
 t/runtests | 2 +-
 t/tests/copyright-file-year-in-future/desc | 1 +
 t/tests/copyright-file-year-in-future/tags | 1 +
 6 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/data/standards-version/release-dates 
b/data/standards-version/release-dates
index 6c4789b..9a9d213 100644
--- a/data/standards-version/release-dates
+++ b/data/standards-version/release-dates
@@ -9,6 +9,7 @@
 #
 # You'll need libtimedate-perl installed.
 
+4.0.1  1501984067
 4.0.0  1495999627
 3.9.8  1459914598
 3.9.7  1454364231
diff --git a/debian/changelog b/debian/changelog
index d24a122..64dbc0f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -85,6 +85,11 @@ lintian (2.5.53) UNRELEASED; urgency=medium
   * data/files/privacy-breaker-websites:
 + [BR] Detect custom donation logos like apache.
 + [BR] Detect generic counter website.
+  * data/standards-version/release-dates:
++ [CL] Add 4.0.1 as a known standards version.
+
+  * debian/control:
++ [CL] Mention Debian Policy v4.0.1 in the description.
 
   * commands/lintian.pm:
 + [CL] Apply patch from Maia Everett to avoid British spelling when
diff --git a/debian/control b/debian/control
index 9501475..2e4bda9 100644
--- a/debian/control
+++ b/debian/control
@@ -70,7 +70,7 @@ Build-Depends: aspell,
unzip,
xz-utils,
zip
-Standards-Version: 4.0.0
+Standards-Version: 4.0.1
 Vcs-Git: https://anonscm.debian.org/git/lintian/lintian.git
 Vcs-Browser: https://anonscm.debian.org/git/lintian/lintian.git
 Testsuite: autopkgtest
@@ -133,4 +133,4 @@ Description: Debian package checker
  should check packages with this tool before uploading them to the
  archive.
  .
- This version of Lintian is calibrated for policy version 4.0.0.
+ This version of Lintian is calibrated for policy version 4.0.1.
diff --git a/t/runtests b/t/runtests
index eb15f0f..d4033a2 100755
--- a/t/runtests
+++ b/t/runtests
@@ -107,7 +107,7 @@ our @DPKG_BUILDPACKAGE_CMD = (
 qw(-iNEVER_MATCH_ANYTHING -INEVER_MATCH_ANYTHING),
 qw(--source-option=--auto-commit),
 );
-our $STANDARDS_VERSION = '4.0.0';
+our $STANDARDS_VERSION = '4.0.1';
 our $ARCHITECTURE = safe_qx(qw(dpkg-architecture -qDEB_HOST_ARCH));
 my $RUNNER_TS = (stat($0))[9];
 chomp $ARCHITECTURE;
diff --git a/t/tests/copyright-file-year-in-future/desc 
b/t/tests/copyright-file-year-in-future/desc
index 8ac3d20..8953e5a 100644
--- a/t/tests/copyright-file-year-in-future/desc
+++ b/t/tests/copyright-file-year-in-future/desc
@@ -3,3 +3,4 @@ Version: 1.0
 Description: Test for "future" years in debian/copyright
 Test-For:
  copyright-year-in-future
+ timewarp-standards-version
diff --git a/t/tests/copyright-file-year-in-future/tags 
b/t/tests/copyright-file-year-in-future/tags
index dfd7b61..1ccfe81 100644
--- a/t/tests/copyright-file-year-in-future/tags
+++ b/t/tests/copyright-file-year-in-future/tags
@@ -1,3 +1,4 @@
+W: copyright-file-year-in-future source: timewarp-standards-version 
(2017-07-20 < 2017-08-06)
 W: copyright-file-year-in-future: copyright-year-in-future 2100 > 2017 (line 
9, column 2)
 W: copyright-file-year-in-future: copyright-year-in-future 2101 > 2017 (line 
10, column 2)
 W: copyright-file-year-in-future: copyright-year-in-future 2102 > 2017 (line 
10, column 8)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/lintian/lintian.git

[lintian] branch master updated (e1bb087 -> dca8c99)

[Chris Lamb]

This is an automated email from the git hooks/post-receive script.

lamby pushed a change to branch master
in repository lintian.

  from  e1bb087   Apply patch from Alex Muntada (alexm) to use "substr" 
instead of "substring" in mentions-deprecated-usr-lib-perl5-directory's 
description. (Closes: #871767)
   new  dca8c99   Add 4.0.1 as a known standards version.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


Summary of changes:
 data/standards-version/release-dates   | 1 +
 debian/changelog   | 5 +
 debian/control | 4 ++--
 t/runtests | 2 +-
 t/tests/copyright-file-year-in-future/desc | 1 +
 t/tests/copyright-file-year-in-future/tags | 1 +
 6 files changed, 11 insertions(+), 3 deletions(-)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/lintian/lintian.git

Bug#872009: lintian: suggest using dh_missing --fail-missing

[Chris Lamb]

Hi Christian,

> With the introduction of dh_missing with debhelper 10, I'd like
> lintian to suggest, e.g. via a pedantic warning, to use the fail

Great suggestion.

However, whilst I absolutely love the idea of packages using dh_missing,
I'm loathed to add a warning that essential recommends packagers add
small bits of boilerplate to their packages — this is surely what
debhelper intends to avoid. :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

How to handle upstream tarbell signature

[Osamu Aoki]

Hi,

I was trying to update uscan and realized few problems which are not
addressed by the discussion here.  There are many things to consider.


On Fri, Aug 18, 2017 at 02:43:58PM +0200, Mattia Rizzolo wrote:
> On Fri, Aug 18, 2017 at 07:48:24AM -0400, Daniel Kahn Gillmor wrote:
> > I confess that i've been taking the boring/silly/cheating way out and if
> > upstream ships a detached binary signature as foo-1.2.3.tar.gz.sig, i've
> > just been manually renaming it to foo_1.2.3.orig.tar.gz.asc (without
> > even converting its contents to ASCII-armored form) and the rest of the
> > toolchain seems to just happily accept it -- it'd be even nicer if dpkg
> > and/or uscan was to normalize the contents to match the file extension.
> 
> That's because TTBOMK there is *nothing* atm actually validating that
> file, and AFAIK (please correct me if I'm wrong) dpkg-source just picks
> up whatever file, no matter the contents.

If the watch file is properly configured, uscan verifies signature.
You should have upstream keyring stored in

   debian/upstream/signing-key.asc

> > Lastly, it's conceivable that we might want to take an already-armored
> > .asc, and "launder" the armor, to stabilize it (e.g. stripping
> > non-cryptographically-relevant comments, other weird OpenPGP packets,
> > etc, which could all be stuffed into the detached signature).
> 
> I'd love if something did this for me, pretty much like I'd love
> something like that does a pretty output to debian/upstream/signing-key
> like
> https://sources.debian.net/src/inkscape/0.92.2-1/debian/upstream/signing-key.asc/
> (that's
> https://anonscm.debian.org/git/reproducible/misc.git/tree/dump-gpg-keys.sh)
> 
> IOW: Guillem: I second merging that sig→asc converter into dpkg-source!
> :)

1. There are different ways of signature
   * files used
 * detached signature   gpg -sb   (easy)
 * non-detached signature   gpg -s(No answer)
   * format used
 * binary (.gpg, ...) (easy but who convert)
 * ascii  (.asc)  (easy)

2. What to do if upstream is repacked.
   * uscan can confirm but where to put the result in case it is
 repacked.
   * If we leave upstream keyring at debian/upstream/signing-key.asc, it
 has no value to the generated Debian packages.  (A new *.asc can be
 added by maintainer but that's its useless since we upload with
 signed *.dsc.  We need to look into debian/copyright to see if this
 is repacked or not.  But people may use different way to repack.
 So it is confusing to have keyring.  There should be clear way to
 identify if it is repackaged or not easily.) 

Does anyone have clear idea on "gpg -s" case for 1 and answer for 2?

These affects how I write uscan.

Osamu

Bug#872611: lintian: Please warn on package using sensible-utils w/o relationship

[Guillem Jover]

Package: lintian
Version: 2.5.52
Severity: wishlist
X-Debbugs-CC: Clint Adams 

Hi!

As part of the long transition to split sensible-utils out from
debianutils, the remaining Depends from debianutils was removed
recently in version 4.8.2.

I asked Clint whether he could send a mail with the current callers
so that they'd be aware of the change and they could fix it, but
thinking about it, it seems more effective and easier to let lintian
check this, as this should be a local and trivial (?) thing to check
for.

Any package that contains references to one of the sensible-utils
binary in non-documentation pathnames/filenames, and does not have any
kind of relationship (Pre-Depends/Depends/Recommends/Suggests) would
get a warning.

This way we do not need to care whether the program is using it
conditionally or not. :)

Thanks,
Guillem