Bug#1065870: Please add a hint to patch-not-forwarded-upstream

[Christoph Biedl]

Package: lintian
Version: 2.117.0
Severity: wishlist
Tags: patch
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Dear maintainer,

a few times too often I got annoyed by a "patch-not-forwarded-upstream"
warning from lintian where that wasn't actually sensible. Looking into
the lintian sources, then again into DEP-3, I realized lintian parses
the Origin: information, and people like previous-me could benefit if
lintian was a bit more clear about this.

So, I'm suggesting to enhance the Description with something like

If the patch was actually taken from upstream, prefix the Origin:
information with "upstream" or "backport", as documented in DEP-3

Kind regards,

Christoph


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Versions of packages lintian depends on:
ii  binutils2.42-3
ii  bzip2   1.0.8-5+b2
ii  diffstat1.66-1
ii  dpkg1.22.5
ii  dpkg-dev1.22.5
ii  file1:5.45-3
ii  gettext 0.21-14+b1
ii  gpg 2.2.40-1.1+b1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.16.0-1
ii  libapt-pkg-perl 0.1.40+b5
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b3
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b3
ii  libclone-perl   0.46-1+b2
ii  libconfig-tiny-perl 2.30-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.37-1+b2
ii  libdata-dpath-perl  0.59-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-3
ii  libdevel-size-perl  0.83-2+b3
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.5
ii  libemail-address-xs-perl1.05-1+b3
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.025-1
ii  libipc-run3-perl0.049-1
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b3
ii  libperlio-utf8-strict-perl  0.010-1+b2
ii  libproc-processtable-perl   0.636-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1+b2
ii  libsereal-encoder-perl  5.004+ds-1+b2
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-2
ii  libterm-readkey-perl2.38-2+b3
ii  libtext-levenshteinxs-perl  0.03-5+b3
ii  libtext-markdown-discount-perl  0.16-1+b2
ii  libtext-xslate-perl 3.5.9-2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b3
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2+b2
ii  liburi-perl 5.27-1
ii  libwww-mechanize-perl   2.18-1
ii  libwww-perl 6.76-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b3
ii  libyaml-libyaml-perl0.89+ds-1+b1
ii  lzip [lzip-decompressor]1.24.1-1
ii  lzop1.04-2
ii  man-db  2.12.0-3
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.38.2-3.2
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.6.0-0.2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.61-1

-- no debconf information



signature.asc
Description: PGP signature

Bug#1026920: New upstream version of file/libmagic breaks autopkgtest

[Christoph Biedl]

Control: tags 1026920 patch

Christoph Biedl wrote...

> It took a few hours to realize locale setting ruin your day. I could
> reproduce that only with LC_ALL=C, and then bisecting led to:
> 
> commit f448f3e5c37de8c285ac14b032b2bdcea82fc08b
> Author: Christos Zoulas 
> Date:   Sat May 28 01:04:57 2022 +
> 
> PR/351: CathyKMeow: octalify unprintable characters in filenames 
> unless raw.

... and there is a command-line option to bypass this.

So this should do the trick, worked for me:

--- a/lib/Lintian/Index/FileTypes.pm
+++ b/lib/Lintian/Index/FileTypes.pm
@@ -72,7 +72,7 @@ sub add_file_types {
 my @files = grep { $_->is_file } @{$self->sorted_list};
 my @names = map { $_->name } @files;
 
-my @command = qw(file --no-pad --print0 --print0 --);
+my @command = qw(file --raw --no-pad --print0 --print0 --);
 
 my %file_types;
 

Cheers,

Christoph


signature.asc
Description: PGP signature

Bug#1026920: New upstream version of file/libmagic breaks autopkgtest

[Christoph Biedl]

Louis-Philippe Véronneau wrote...

> Lintian runs file (more precisely, `file --no-pad --print0 --print0 --`)
> to get the "file_type" value of files [1].

Very exhausting debugging¹ reveals lintian has that file_type set to the
empty string. Obviously this causes ...

> Then, for all the files in "/usr/share/man/", it verifies .gz files are indeed
> gz-compressed with this perl regex match [2]:
> 
> if ($item->file_type !~ m/gzip compressed data/)

... this check to fail, and things go downhill from there.

> I built the test files Lintian uses for the autopkgtest and when
> I run file 1:5.43-3 on it, I do get an output that should match that regex:
> 
> -
> foo@bar:/tmp/foo/usr/share/man/man1# file -v
> > file-5.43
> > magic file from /etc/magic:/usr/share/misc/magic
> 
> foo@bar:/tmp/foo/usr/share/man/man1# file "鳥の詩.1.gz"
> > \351\263\245\343\201\256\350\251\251.1.gz: gzip compressed data, max 
> > compression, from Unix, original size modulo 2^32 145
> -

It took a few hours to realize locale setting ruin your day. I could
reproduce that only with LC_ALL=C, and then bisecting led to:

commit f448f3e5c37de8c285ac14b032b2bdcea82fc08b
Author: Christos Zoulas 
Date:   Sat May 28 01:04:57 2022 +

PR/351: CathyKMeow: octalify unprintable characters in filenames unless 
raw.

> My perl-foo is pretty bad, but I guess we should be trying to espace or 
> sanitize that value?

Problem is, since that change file(1) no longer returns the file as it
was given on the command line, and therefore add_file_types assigns the
file type to the wrong file, while the real one gets nothing at all.
.oO (from __rant__ import "use strict; use warning;")

Next I'll try

--- a/lib/Lintian/Index/FileTypes.pm
+++ b/lib/Lintian/Index/FileTypes.pm
@@ -98,6 +98,7 @@ sub add_file_types {
 }
 
 while (defined(my $path = shift @lines)) {
+$path =~ s/(\\[0-7]{3})/chr oct ($1)/eg;
 
 my $type = shift @lines;

but testing will take a while¹. I wasn't surprised if this
fails from some utf-8 vs. binary string mismatches.

Beside from that, the issue became more pressing now that file 1:5.44-1
is in unstable, blocked by this one from transitioning to testing. Which
is why I spent several hours¹ on this.

Christoph

¹ As I am in a way responsible for this situation, I agree I am
  also obliged to help resolving it. However, can you please provide a
  faster way to reproduce the failing test? Currently I am rebuilding
  and running autopkgtest, with a loop taking 50 minutes.


signature.asc
Description: PGP signature

Bug#1026920: New upstream version of file/libmagic breaks autopkgtest

[Christoph Biedl]

Package: lintian
Version: 2.115.3
Severity: important

Greeting,

my recent upload of file (1:5.43-3) to experiental broke lintian's autopkgtest.

Possibly this is the relevant section.

# Hints do not match
# 
# --- 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/documentation/manual/files-general/hints.specified.calibrated
# +++ 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/documentation/manual/files-general/hints.actual.parsed
# +files-general (binary): wrong-compression-in-manual-page 
[usr/share/man/man1/é³¥ã®è©©.1.gz]
# 
# Unexpected tags:
#   wrong-compression-in-manual-page
# 
#   Failed test 'Lintian passes for files-general'
#   at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343.

[ 
https://ci.debian.net/data/autopkgtest/unstable/amd64/l/lintian/29591169/log.gz 
]

While I didn't check what precisely went wrong, I reckon it's a slightly
changed output on gz-compressed files.

Can you please check and adjust your tests? I'd like to upload to
unstable in a week or so, and I'd prefer to have no autopkgtest breakage
by then.

Sorry for the mess, and I'm sorry this will happen again - upstream
changes file's output every now and then. The only help I can provide is
to add your package to the list of those that should receive a
notification when uploading a new upstream version, see

https://sources.debian.org/src/file/1%3A5.41-4/debian/README.Maintainer/#L16

If you want lintian to be included, just say the word.

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc

[Christoph Biedl]

Felix Lechner wrote...

> By the way, the suggestion behind this bug may not be implemented
> anytime soon. It would cause Lintian's output to change over time
> (same Lintian version on same package). Such tags are hard to test in
> Lintian's test suite.

That argument seems fairly weird to me: Abandon or deny features because
they are difficult to test. By the way, to test behaviour over time,
faketime(1) serves me good enough. But that's your design decision.

> It would be more appropriate to flag expired keys on tracker.d.o.

Another place might be DDPO - problem with both is visibility. If such a
check was implemented in Lintian, package maintainers get any issues
right in their face when building the package (which usually includes
running lintian). Tracker or DDPO, I these those only occasionally.
Other people's workflow might be different, though.

Also, in lintian the change was rather small and therefore easy to
implement.

> Expired keys also do not affect package quality in the archive.

How do the other signing key checks do that? Where's the difference?

> They
> still validate old release signatures. I believe a maintainer would
> have to sidestep uscan intentionally in order to upload a source
> package with an upstream public key that turns out to be useless.

Assuming upstream already updated the signing key, it would still avoid
breaking uscan in the future.

It would alert if the key already has expired, something I reckon about
libgpg-error (key expiry December 2019, new upstream release uploads in
March and June 2020).

It could (after an extension of the check) warn about an upcoming
expiration so the maintainer can update accordingly before breaking the
validation chain. And yes, that's time-based behaviour.

Christoph


signature.asc
Description: PGP signature

Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc

[Christoph Biedl]

Felix Lechner wrote...

> Did uscan give you any trouble when trying to validate upstream's
> release signature?

Try libgpg-error before #985793 gets fixed:

uscan: Newest version of libgpg-error on remote site is 1.42, local version 
is 1.38
uscan:  => Newer package available from:
=> 
https://gnupg.org/ftp/gcrypt/libgpg-error/libgpg-error-1.42.tar.bz2
gpgv: Signature made Mon 22 Mar 2021 11:50:29 AM CET
gpgv:using EDDSA key 
6DAA6E64A76D2840571B4902528897B826403ADA
gpgv: Can't check signature: No public key
uscan die: OpenPGP signature did not verify. at 
/usr/share/perl5/Devscripts/Uscan/Output.pm line 60.

Exit code 2

Christoph


signature.asc
Description: PGP signature

Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc

[Christoph Biedl]

Axel Beckert wrote...

> That might be something for lintian-brush once a lintian check is
> there. Cc'ing Jelmer, the author of lintian-brush.

What's the status of that story? I hacked a few lines together that work at
least for the case where I encountered the problem. But it's fairly
fragile since parsing in a textual output is bad. It was way better to
*omit* --list-packets in the gpg invocation since then the output is by
definition machine-readable (and there is an "Expired!" alert on stderr
for free). Also upstream warns the output of --list-packets "may change
with new releases."

Christoph
--- /usr/share/lintian/checks/debian/upstream/signing-key.pm
+++ /usr/share/lintian/checks/debian/upstream/signing-key.pm
@@ -122,15 +122,20 @@
 
 # look for third-party signatures
 my @thirdparty;
+my $expired;
 for my $packet (@packets) {
 
 my $header = $packet->[0];
+my $body = $packet->[1];
 if ($header =~ qr/^:signature packet: algo \d+, keyid (\S*)$/){
 
 my $signatory = $1;
 push(@thirdparty, $signatory)
   unless $signatory eq $keyid;
 }
+if ($body =~ qr/ expires 0/) {
+$expired = 1;
+}
 }
 
 # signatures by parties other than self
@@ -141,6 +146,9 @@
 $key_name,
 "has $extrasignatures extra signature(s) for keyid $keyid")
   if $extrasignatures;
+$self->hint('public-upstream-key-expired',
+$key_name,'has expired keys')
+  if $expired;
 }
 }
 
Tag: public-upstream-key-expired
Severity: info
Check: debian/upstream/signing-key
See-Also: uscan(1)
Explanation: The source package contains a public upstream signing key that
 contains at least one key that has expired.
 .
 Please obtain the correct key from upstream.


signature.asc
Description: PGP signature

Bug#977976: lintian: "unknown-runtime-tests-field Architecture"

[Christoph Biedl]

Package: lintian
Version: 2.104.0
Severity: normal

Dear Maintainer,

tl;dr: lintian does not consider Architecture: a valid header field
in debian/tests/control, and I think that's not correct.

Full story: Creating an autopkgtest that requires systemd for execution,
I wanted to be extra-sure this will not cause trouble if ever someone
runs autopkgtest on !linux. So, after checking the specification at[1],
I wrote

Tests: run-testsuite
Depends: @,
systemd,
Architecture: linux-any

and lintian replied

P: (...) source: unknown-runtime-tests-field Architecture in line 4

So in my opionion, Architecture: (and also Classes:) should be added to
testsuite/known-fields.

Regards,

Christoph

[1] 
https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.83 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils2.35.1-5
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.39-3
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b4
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b6
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b2
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.430-2
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004004-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libproc-processtable-perl   0.59-2+b1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012000-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.05-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.82+repack-1+b1
ii  lzip1.21-8
ii  lzop1.04-2
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.32.0-6
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information



signature.asc
Description: PGP signature

Bug#919458: RFP: cookie-autodelete -- delete cookies not used by any open tab

[Christoph Biedl]

Sean Whitton wrote...

> Package: wnpp
> Severity: wishlist
>
> * Package name: cookie-autodelete
>   Version : 2.2.0
>   Upstream Author : Name 

To be precise: Kenny Do 

> * URL : https://github.com/Cookie-AutoDelete/Cookie-AutoDelete
> * License : MIT
>   Programming Lang: JavaScript webext
>   Description : delete cookies not used by any open tab
>
> This is a useful replacement for xul-ext-self-destructing-cookies, which
> doesn't work with the new Firefox ESR 60.0.

Indeed, and that's why I spent a few hours on this.

Summary, it's not that easy.

Here are my findings so other people have to go throught this again: The
pre-compiled .xpi contains a bundles/ subdirectory which is essential
for cookie-autodelete to work.

These files are missing in the sources, and if I understand correctly,
they are gathered when building using npm - while in the Debian
ecosystem they should rather be shipped by other packages. One of them
might be node-react which hasn't reached testing yet and I'm not sure
whether it will in time for buster freeze.

Minor issue: dh_webext installs the files in an "extensions/"
subdirectory where firefox will not find the extensions. Might require
some tweaking but is not a blocker.

So I'll give up on this for the moment. If anybody else feels
comfortable to continue, go ahead.

Christoph


signature.asc
Description: PGP signature

Bug#919458: lintian: add tag for empty executables

[Christoph Biedl]

Emilio Pozuelo Monfort wrote...

> Could we add a lintian tag for empty executables, particularly in PATH? Then 
> we
> could turn that into an autoreject (after analysing the results when
> lintian.debian.org is updated) and help prevent this kind of brokenness in the
> future.

As a data point: At least three packages that entered the archive in
2018 had zero-size executables in /usr/s?bin/. The interesting part
though is these were built on Debian buildds (as part of a binNMU).
All were from the same source package that probably has a flaw in the
build system, the maintainer is already aware of that.

Still I think it's a good idea to add the check as suggested.
Addionally I'd like to suggest to check for zero-size compressed files
as well since I fail to see why anyone would ship them[1] - severity
not more than warning, though. There is already "empty-manual-page", my
proposal was somewhat a superset of that.

There a quite a few packages that ship such files. Besides manpages,
there is often /usr/share/doc/*/changelog.gz for whatever reason.
Empty files bzip2 or xz compressed have existed at least in the past,
full mirror scan is still running.

Christoph

[1] Test data is a notable exception:
/usr/lib/python3/dist-packages/khmer/tests/test-data/empty-file.bz2
/usr/lib/python3/dist-packages/khmer/tests/test-data/empty-file.gz


signature.asc
Description: PGP signature

Heads-up: New upstream version of src:file in experimental

[Christoph Biedl]

Hello there,

after a somewhat bumpy experience following the upload of the previous
upstream release of file (5.33), I eventually decided to introduce a
release procedure for src:file in Debian: New upstream release uploads
will go to experimental first, and package maintainers that probably
would like to know about that receive a notification about that so
they have some time to brace for impact. Like this:

--
A new upstream release of file/libmagic has been accepted into
experimental a few moments ago, version 1:5.34-1. As your package is
one of those that somewhat suffered from surprising feature changes of
libmagic in the past, I'd like to give you an opportunity to test and
to prepare for any changes, for better or for worse. In case of the
latter, use the BTS as usual to report detections that could see an
improvement.

My plan is to upload to unstable in a week from now.
--

Additional question: Would you like to receive such notifications in
the future? If yes, please drop me a line in private. Same if you think
there is a better address than the "@packages.debian.org" one
I used this time - but I prefer role/team/package addresses over
personal ones. I'll add this to a small document to debian/ so that
information will be public - but not forgotten in the future.

Cheers,
Christoph


signature.asc
Description: PGP signature

Bug#896840: lintian: autopkgtest fails with new version of file

[Christoph Biedl]

[
Maintainer of the file package here - feel free to Cc me early, this
might or might not ease things.
]

Chris Lamb wrote...

> [adding elb...@debian.org to CC]
>
> Chris Lamb wrote:
>
> > > This is caused by library having executable bits set, which is how the
> > > pie executable vs shared object check in file works.
> […]
> > FYI for confirmation of the executable bits:
>
> The more I think about it, the more I think this is a misleading
> and non-intuitive misfeature of file.

This was indeed added upstream:

->16leshort 3   shared object,
+>16leshort 3   ${x?pie executable:shared object}



This exansion feature ${x?(...):(...)} was added just in the preceeding
commit. So the executable bit of the file indeed affects the detection
now. While personally I'm not too happy about that, I think it was the
worse idea to work around this in file permanentely by reverting that
change.

> Any thoughts before I essentially re-assign this?

Rather somehow deal with it?

Christoph


signature.asc
Description: PGP signature

Bug#882154: lintian: Raise level for -dbg packages

[Christoph Biedl]

Package: lintian
Version: 2.5.59
Severity: wishlist

Dear Maintainer,

as you know the concept of manually maintained -dbg packages has been
superseeded by automatically created -dbgsym ones during the stretch
development cycle.

So I was about to propose a warning for -dbg packages just to find it's
already implemented as debian-control-has-obsolete-dbg-package - but
marked experimental.

In my opinion the severity should be raised, and actually above warning
level.

Related, unless there's still a situation where -dbg packages serve a
purpose - I'm not aware of such and cannot think of any either - I
wouldn't mind if ftp-master starts to autoreject such packages, perhaps
with NMUs as an exception.

Christoph


signature.asc
Description: Digital signature

Bug#880922: lintian: Check for dependency -dev -> runtime library package

[Christoph Biedl]

Package: lintian
Version: 2.5.58
Severity: wishlist

Dear Maintainer,

Policy 8.5 recommends ("should") for a -dev package to have an install
dependency on the respective runtime library. It seems lintian does not
check for this but I think it should.

Hopefully, implementation would not that difficult: In debian/control,
identify -dev packages, in the libdevel section, and if there's a
related  package in the lib section, the -dev package
should have a strict versioned dependency on the runtime library. The
latter is actually already covered by "weak-library-dev-dependency".

Regards,

Christoph



signature.asc
Description: Digital signature

Bug#879235: lintian: Improving "unused-file-paragraph-in-dep5-copyright"

[Christoph Biedl]

Package: lintian
Version: 2.5.55
Severity: wishlist

Dear Maintainer,

lintian's "unused-file-paragraph-in-dep5-copyright" warning created some
confusion since it could be read as if the file(s) mentioned do not
exist - but they do, and the that's not the actual problem. A different
wording in the description would have provided the right hint, saving
some time.

So I'd like to suggest to

* add a sentence to this checks's description like "Remember: The
  applicable File: paragraph is selected using the principle of '*last*
  match wins'."

and perhaps also

* add an extra check for "File: *" which, if present, should be the
  very first File: paragraph. Since it will, for the reason given above,
  always void any preceeding paragraphs.

The first is fairly easy to do and matches all situations. The second
however was a very obvious message.

Regards,

Christoph


signature.asc
Description: Digital signature

Bug#879152: lintian: Please check for boilerplate from /etc/init.d/skeleton

[Christoph Biedl]

Package: lintian
Version: 2.5.55
Severity: wishlist

Dear Maintainer,

The /etc/init.d/skeleton template contains some boilerplate:

# Author: Foo Bar 
#
# Please remove the "Author" lines above and replace them
# with your own name if you copy and modify this script.

... and sometimes maintainer but forget to update the information when
using that file. Please consider adding an according lintian check. At
the moment, this seems to affect zookeeper only - if you think it's not
worth the efforts then, drop me a line so I can file an individual
bugreport.

Regards,

Christoph

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.52 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages lintian depends on:
ii  binutils  2.29.1-5
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.2
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b2
ii  libdpkg-perl  1.19.0.2
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-8
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-2
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-8
ii  t1utils   1.40-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

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

-- no debconf information



signature.asc
Description: Digital signature

Bug#861958: lintian: insecure YAML validation

[Christoph Biedl]

clone 861958 -1
reassign -1 libyaml-syck-perl
retitle -1 libyaml-syck-perl: Unconditionally instantiates objects from yaml 
data
thanks

This problem exists in libyaml-syck-perl as well. However, disabling
this feature will be easier since there's already a switch ("LoadBlessed").

Christoph
#!/usr/bin/perl

use 5.010;
use strict;
use warnings;

use File::Temp qw(tempdir);
use YAML::XS qw(LoadFile);

my $temp_dir = tempdir (
"yaml-xs-demo.$$.X",
'TMPDIR' => 1,
'CLEANUP' => 1,
);

my $temp_file = "$temp_dir/story.yaml";

my $pid = fork // die ("Cannot fork: $!");
if ($pid == 0) {
my $fh;
open ($fh, '>', $temp_file) or die $!;
print $fh <<__EOS__;
- !File::Temp::Dir
  CLEANUP: 1
  LAUNCHPID: $$
  REALNAME: $temp_dir
__EOS__
close ($fh);
my $data = LoadFile ($temp_file);
exit 0;
}
wait;

if (-d $temp_dir) {
print "I: Pass, temp dir is still present\n";
} else {
print "F: FAIL, temp dir was purged\n";
}


signature.asc
Description: Digital signature

Bug#861958: lintian: insecure YAML validation

[Christoph Biedl]

clone 861958 -1
reassign -1 libyaml-libyaml-perl
retitle -1 libyaml-libyaml-perl: Unconditionally instantiates objects from yaml 
data
thanks

Dominique Dumont wrote...

> On samedi 6 mai 2017 13:01:50 CEST you wrote:

> > This module is happy to deserialize objects of any existing Perl class. For
> > Lintian, the File::Temp::Dir class can be abused to remove arbitrary
> > directory trees. (There might be other exciting ways to exploit this bug,
> > but I'm too lazy to investigate further.)
> 
> I wonder if this behavior should be considered as a YAML bug...

At least I consider the unconditional instantiation of object a bug,
hence cloning.

As previously mentioned in debian-perl@, there is no easy solution,
assuming some code out there intentionally uses that feature, and in
a safe matter. If we choose to ignore that, at least for the time being,
we can disable the blessing entirely by dropping the three sv_bless
invocations in . This makes the attached
reproducer pass.

Before releasing that change however, there should be an audit of all
the roughly 40 packages in Debian that use YAML::XS to avoid unintended
breakage. In the worst case, that simple approach isn't feasible and
the instantiation needs to be made configurable - something that
requires coordination with upstream[1] and/or other distributions.

We should discuss this during the sprint.

Christoph

[1] But see https://github.com/perl11/cperl/issues/198
#!/usr/bin/perl

use 5.010;
use strict;
use warnings;

use File::Temp qw(tempdir);
use YAML::XS qw(LoadFile);

my $temp_dir = tempdir (
"yaml-xs-demo.$$.X",
'TMPDIR' => 1,
'CLEANUP' => 1,
);

my $temp_file = "$temp_dir/story.yaml";

my $pid = fork // die ("Cannot fork: $!");
if ($pid == 0) {
my $fh;
open ($fh, '>', $temp_file) or die $!;
print $fh <<__EOS__;
- !File::Temp::Dir
  CLEANUP: 1
  LAUNCHPID: $$
  REALNAME: $temp_dir
__EOS__
close ($fh);
my $data = LoadFile ($temp_file);
exit 0;
}
wait;

if (-d $temp_dir) {
print "I: Pass, temp dir is still present\n";
} else {
print "F: FAIL, temp dir was purged\n";
}


signature.asc
Description: Digital signature

Bug#848878: lintian: Does outdated-autotools-helper make sense when building with recent debhelper?

[Christoph Biedl]

Package: lintian
Version: 2.5.49
Severity: wishlist

Dear Maintainer,

While improving the gnuift package (upload pending), I came across this
lintian warning:

W: gnuift source: outdated-autotools-helper-file config.guess 2004-03-12
(...)
N:For packages using debhelper, the tools from the dh-autoreconf package
N:should handle this issue. (...)

Now config.guess is indeed that old, however my packaging depends on
debhelper 10 which depends on autotools-dev and dh-autoreconf package.
So all packages required to deal with the situation are available at
build time, and it seems the above warning is a false alarm.

Can you please review the check? My suggestion is to mute this warning
if there's a build-dependency on debhelper (>= 10~). If however this
still is an issue, the text needs a rewording since I have no idea how
to proceed then.

Christoph


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: unable to detect

Versions of packages lintian depends on:
ii  binutils  2.27.51.20161201-1
ii  bzip2 1.0.6-8
ii  diffstat  1.61-1
ii  file  1:5.29-1
ii  gettext   0.19.8.1-1
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.30
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b1
ii  libdpkg-perl  1.18.15
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libparse-debianchangelog-perl 1.2.0-11
ii  libperl5.24 [libdigest-sha-perl]  5.24.1~rc4-1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.63-1+b1
ii  man-db2.7.5-2
ii  patchutils0.3.4-2
ii  perl  5.24.1~rc4-1
ii  t1utils   1.39-2
ii  xz-utils  5.2.2-1.2

Versions of packages lintian recommends:
ii  dpkg 1.18.15
pn  libperlio-gzip-perl  
ii  perl 5.24.1~rc4-1
ii  perl-modules-5.24 [libautodie-perl]  5.24.1~rc4-1

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

-- no debconf information



signature.asc
Description: Digital signature

Bug#847144: lintian: Please reword init.d-script-needs-depends-on-lsb-base, drop versioned dependency

[Christoph Biedl]

Package: lintian
Version: 2.5.49
Severity: wishlist

Dear Maintainer,

the recently introduced check for a depedency on the no longer
pseudo-essential lsb-base package suggests a versioned dependency on
"lsb-base (>= 3.0-6)".

Can you please drop the version number part from that text? It's
superflous and confusing, even wheezy has lsb-base in 4.1-ish so an
unversioned dependency is always satisfied. Or I missed something,
please enlighten me then.

Christoph



signature.asc
Description: Digital signature

Bug#797951: lintian: Please relax dependency checks to allow versions with tilde

[Christoph Biedl]

Package: lintian
Version: 2.5.36.1
Severity: wishlist
Tags: patch

Hello,

When it comes to to relative package dependencies, I grew into the
habit to make them backports-friendly, i.e. use version numbers with
the tilde character appended. For reasons of simplicity even when they
are very likely never used. So I prefer to write

  Depends: foo (>> 1.0~)

alternatively: ">= 1.0~" instead of

  Depends: foo (>= 1.0)

which by the way also allows me to avoid the >= and <= operators at
all, different story.

However, lintian does not appreciate this approach: Since I use
Build-Profiles in one of my packages, I added a dependency on

  Build-Depends: debhelper (>= 9.20141010~)

which triggers the
restriction-formula-with-debhelper-without-debhelper-version
warning.

Would you mind relaxing check a bit? The patch below worked for me
although a few places in checks/fields.pm might deserve an according
change, too.

Christoph

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.1.6 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages lintian depends on:
ii  binutils   2.25.1-1
ii  bzip2  1.0.6-8
ii  diffstat   1.60-1
ii  file   1:5.22+15-2
ii  gettext0.19.4-1
ii  hardening-includes 2.7
ii  intltool-debian0.35.0+20060710.2
ii  libapt-pkg-perl0.1.29+b2
ii  libarchive-zip-perl1.49-1
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.38-1
ii  libdpkg-perl   1.18.2
ii  libemail-valid-perl1.196-1
ii  libfile-basedir-perl   0.07-1
ii  libipc-run-perl0.94-1
ii  liblist-moreutils-perl 0.413-1
ii  libparse-debianchangelog-perl  1.2.0-8
ii  libtext-levenshtein-perl   0.12-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.69-1
ii  man-db 2.7.2-1
ii  patchutils 0.3.4-1
ii  perl [libdigest-sha-perl]  5.20.2-6
ii  t1utils1.38-4
ii  xz-utils   5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:
ii  dpkg1.18.2
pn  libperlio-gzip-perl 
ii  perl5.20.2-6
ii  perl-modules [libautodie-perl]  5.20.2-6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.2
ii  libhtml-parser-perl3.71-2
ii  libtext-template-perl  1.46-1
ii  libyaml-perl   1.13-1

-- no debconf information



diff --git a/checks/control-file.pm b/checks/control-file.pm
index 32d2f8e..37757ff 100644
--- a/checks/control-file.pm
+++ b/checks/control-file.pm
@@ -359,14 +359,14 @@ sub run {
 my $build_all = $info->relation('build-depends-all');
 my $build_conflicts_all = $info->relation('build-conflicts-all');
 tag 'restriction-formula-without-versioned-dpkg-dev-dependency'
-  unless ($build_all->implies('dpkg-dev (>= 1.17.14)'));
+  unless ($build_all->implies('dpkg-dev (>= 1.17.14~)'));
 tag 'restriction-formula-with-versioned-dpkg-dev-conflict'
   if ($build_conflicts_all->implies_inverse('dpkg-dev (<< 1.17.14)'));
 # if the package uses debhelper then it must require and not
 # conflict with version >= 9.20141010
 if ($build_all->implies('debhelper')) {
 tag 'restriction-formula-with-debhelper-without-debhelper-version'
-  unless ($build_all->implies('debhelper (>= 9.20141010)'));
+  unless ($build_all->implies('debhelper (>= 9.20141010~)'));
 #<<< no tidy, tag name too long
 tag 'restriction-formula-with-debhelper-with-conflicting-version'
 #>>>



signature.asc
Description: Digital signature

Bug#748686: lintian: Possible mis-classification license-problem-non-free-RFC

[Christoph Biedl]

Package: lintian
Version: 2.5.22.1
Severity: minor

Dear Maintainer,

while test-packaging bgpmon[0] lintian raised, among other things,
the error

| E: bgpmon source: license-problem-non-free-RFC 
doc/xml/xml2rfc-1.33/rfc2629.html

However, RFC 2629 is listed in the known exceptions[2] so I guess
that's a false-positive that should be reported as requested. If you
need my preliminary Debianisation for a reproducer, drop me a line.

Also note I've abandoned the plan to maintain this package, severity
lowered therefore. For the same reason I'm perfectly fine with
whatever you think is appropriate to deal with lintian's behaviour.

Christoph

[1] http://bgpmon.netsec.colostate.edu/
http://bgpmon.netsec.colostate.edu/download/src/bgpmon-7.3.4.tar.bz2
[2] https://wiki.debian.org/NonFreeIETFDocuments

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.10.39 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils   2.24.51.20140425-1
ii  bzip2  1.0.6-5
ii  diffstat   1.58-1
ii  file   1:5.18-1
ii  gettext0.18.3.2-1
ii  hardening-includes 2.5
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.29+b1
ii  libarchive-zip-perl1.37-2
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.36-1
ii  libdpkg-perl   1.17.9
ii  libemail-valid-perl1.192-1
ii  libfile-basedir-perl   0.03-1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-2
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtext-levenshtein-perl   0.06~01-2
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.60-1
ii  man-db 2.6.7.1-1
ii  patchutils 0.3.3-1
ii  perl [libdigest-sha-perl]  5.18.2-2+b1
ii  t1utils1.37-2

Versions of packages lintian recommends:
pn  libperlio-gzip-perl none
ii  perl-modules [libautodie-perl]  5.18.2-2

Versions of packages lintian suggests:
pn  binutils-multiarch none
ii  dpkg-dev   1.17.9
ii  libhtml-parser-perl3.71-1+b1
ii  libtext-template-perl  1.46-1
ii  libyaml-perl   0.84-1
ii  xz-utils   5.1.1alpha+20120614-2

-- no debconf information



signature.asc
Description: Digital signature

Bug#746307: Bug#745882: broken magic: Some plain text identified as flash file

[Christoph Biedl]

# commit FILE5_18-23-g281578a
tags 745882 fixed-upstream
thanks

Hello,

file(1) maintainer here, about #745882 and #746307 (cwr* mis-detected
as flash).

Good news: Upstream fixed the issue. I expect the next release within
the next four to six weeks. In my understanding the bug you've
encountered isn't that important it requires an immediate upload to
Debian. But I might be convinced otherwise.

Christoph


signature.asc
Description: Digital signature

Bug#682941: lintian: Unhelpful croak message 'Missing Severity field for HASH(0x...)'

[Christoph Biedl]

Niels Thykier wrote...

 Thanks for spotting this, it has been fixed in a75087f (in case you want
 to backport it).

Thanks for the prompt fix.

 Is the source for this third-party plugin available online?  I am
 curious about how installs itself, what it uses and such.

No, it's purpose was to enforce some site-specific policies. Since the
lintian API documentation is better hidden than my capabilities to
find it, these check constantly break after an lintian upgrade.

Christoph


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1343593...@msgid.manchmal.in-ulm.de

Bug#682941: lintian: Unhelpful croak message 'Missing Severity field for HASH(0x...)'

[Christoph Biedl]

Package: lintian
Version: 2.5.10
Severity: normal

Dear Maintainer,

refering to /usr/share/lintian/lib/Lintian/Tag/Info.pm ll.88

croak Missing Tag field unless $self-{'tag'};
$tagname = $self-{'tag'};
croak Missing Severity field for $tag unless $self-{'severity'};
croak Missing Certainity field for $tag unless $self-{'certainty'};

Since $tag is a hash reference, an error message created in the third
or fourth line is not helping. Did you mean $tagname?

Mean reason was a broken external plugin so you'll probably not
encounter that in regular lintian installations. Feel free to lower
the priority.

Christoph

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.23 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils   2.22-6.1
ii  bzip2  1.0.6-3
ii  diffstat   1.55-3
ii  file   5.11-2
ii  gettext0.18.1.1-9
ii  hardening-includes 2.2
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.26+b1
ii  libarchive-zip-perl1.30-6
ii  libc-bin   2.13-33
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.31-1+b2
ii  libdigest-sha-perl 5.71-1
ii  libdpkg-perl   1.16.4.3
ii  libemail-valid-perl0.190-1
ii  libipc-run-perl0.91-1
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtimedate-perl   1.2000-1
ii  liburi-perl1.60-1
ii  locales2.13-33
ii  man-db 2.6.2-1
ii  patchutils 0.3.2-1.1
ii  perl [libdigest-sha-perl]  5.14.2-12

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch none
ii  dpkg-dev   1.16.4.3
ii  libhtml-parser-perl3.69-2
pn  libperlio-gzip-perlnone
pn  libtext-template-perl  none
ii  lzma   9.22-2
ii  man-db 2.6.2-1
ii  xz-utils [lzma]5.1.1alpha+20120614-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1343375...@msgid.manchmal.in-ulm.de

Bug#606933: manpage-has-errors-from-man ... can't set the locale when running in Lenny

[Christoph Biedl]

Niels Thykier wrote...

 Thanks for the hint; can you try to pull lintian from git and try if it
 is fixed (commit 285c6c4) ?

That would be 
http://git.debian.org/?p=lintian/lintian.git;a=commitdiff;h=285c6c4476c7471af6c5bbc0e2bb0646ea1fa664;hp=d1487c05ad5d9b58d784c99eb0683af6c229d56a
and applying this on a lintian installation indeed fixes the problem.

FYI, my testcase was re-building the libfile-slurp-perl package on a
lenny system using the lintian backport.

Christoph



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1297321...@msgid.manchmal.in-ulm.de

Bug#606933: manpage-has-errors-from-man ... can't set the locale when running in Lenny

[Christoph Biedl]

Matthew Palmer wrote...

 W: pbuilder: manpage-has-errors-from-man
 usr/share/man/man1/debuild-pbuilder.1.gz  can't set the locale; make sure
 $LC_* and $LANG are correct

This puzzled me too, and after some strace'ing it seems
/usr/share/lintian/checks/manpages wants to access files in
/var/lib/lintian/locale/en_US.UTF8/
while the directory's name is actually
/var/lib/lintian/locale/en_US.UTF-8/

Placing a symlink resolved the situation - but I wonder if there's
just a dash missing in line 249?

Christoph



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1297178...@msgid.manchmal.in-ulm.de