from:"Axel Beckert"



Axel Beckert pushed to branch master at lintian / lintian


Commits:
b5146d82 by Edu Gómez Escandell at 2024-05-06T01:20:20+00:00
Fix inconsistencies in documentation of lintian-explain-tags

- - - - -


2 changed files:

- bin/lintian-explain-tags
- man/lintian-explain-tags.pod


Changes:

=
bin/lintian-explain-tags
=
@@ -151,7 +151,7 @@ Usage: $NEW_PROGRAM_NAME [log-file...] ...
 
 Options:
 -l, --list-tagslist all tags Lintian knows about
--t, --tag, --tags  display tag descriptions
+-t, --tag, --tags  this option has no effect.
 --include-dir DIR  check for Lintian data in DIR
 --profile Xuse vendor profile X to determine severities
 --output-width NUM set output width instead of probing terminal


=
man/lintian-explain-tags.pod
=
@@ -26,7 +26,7 @@ lintian-explain-tags - offer more information about Lintian's 
tags
 
 =head1 SYNOPSIS
 
-B B<--tags> I ...
+B I ...
 
 =head1 DESCRIPTION
 



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/b5146d82b452c0503f98a836e40409fb20cd09d7

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/b5146d82b452c0503f98a836e40409fb20cd09d7
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] wrong-path-for-interpreter: allow aliased locations



Axel Beckert pushed to branch master at lintian / lintian


Commits:
9266486e by Luca Boccassi at 2024-05-06T01:57:46+01:00
wrong-path-for-interpreter: allow aliased locations

merged-usr is mandatory in Debian since Bookworm (and much longer ago
in Ubuntu), so /usr/bin/bash is a valid path, as is /bin/python3.
Detect and ignore these instances.

Closes: #1051338

- - - - -


2 changed files:

- lib/Lintian/Check/Scripts.pm
- t/recipes/checks/scripts/scripts-control-interpreters/eval/hints


Changes:

=
lib/Lintian/Check/Scripts.pm
=
@@ -47,6 +47,7 @@ const my $NOT_EQUAL => q{!=};
 const my $BAD_MAINTAINER_COMMAND_FIELDS => 5;
 const my $UNVERSIONED_INTERPRETER_FIELDS => 2;
 const my $VERSIONED_INTERPRETER_FIELDS => 5;
+const my $USR_PREFIX_LENGTH => 4;
 
 use Moo;
 use namespace::clean;
@@ -692,10 +693,17 @@ sub visit_control_files {
   'incorrect-path-for-interpreter'
   : 'wrong-path-for-interpreter';
 
+# Debian is now mandatory usr-merged, so /bin/sh and /usr/bin/sh are both 
acceptable
+if ($expected =~ '^(/bin/|/sbin/)') {
+$expected = '(?:/usr)?' . $expected;
+} elsif ($expected =~ '^/usr(/bin/|/sbin/)') {
+$expected = '(?:/usr)?' . substr($expected, $USR_PREFIX_LENGTH);
+}
+
 $self->pointed_hint(
 $tag_name, $item->pointer,  $interpreter,
 $NOT_EQUAL, $expected
-)unless $interpreter eq $expected;
+)unless $interpreter =~ $expected;
 
 } elsif ($item->name eq 'config') {
 $self->pointed_hint('forbidden-config-interpreter',
@@ -716,10 +724,17 @@ sub visit_control_files {
   'incorrect-path-for-interpreter'
   : 'wrong-path-for-interpreter';
 
+# Debian is now mandatory usr-merged, so /bin/sh and /usr/bin/sh are both 
acceptable
+if ($expected =~ '^(/bin/|/sbin/)') {
+$expected = '(?:/usr)?' . $expected;
+} elsif ($expected =~ '^/usr(/bin/|/sbin/)') {
+$expected = '(?:/usr)?' . substr($expected, $USR_PREFIX_LENGTH);
+}
+
 $self->pointed_hint(
 $tag_name, $item->pointer, $interpreter,
 $NOT_EQUAL, $expected
-)unless $interpreter eq $expected;
+)unless $interpreter =~ $expected;
 
 $self->pointed_hint('unusual-control-interpreter', $item->pointer,
 $interpreter);


=
t/recipes/checks/scripts/scripts-control-interpreters/eval/hints
=
@@ -9,8 +9,6 @@ scripts-control-interpreters-prepython (binary): 
unusual-control-interpreter /us
 scripts-control-interpreters-prepython (binary): unusual-control-interpreter 
/usr/bin/python3 [postinst]
 scripts-control-interpreters-prepython (binary): maintainer-script-interpreter 
/usr/bin/python3 [preinst]
 scripts-control-interpreters-prepython (binary): maintainer-script-interpreter 
/usr/bin/python3 [postinst]
-scripts-control-interpreters-paths (binary): wrong-path-for-interpreter 
/usr/bin/bash != /bin/bash [postinst]
-scripts-control-interpreters-paths (binary): wrong-path-for-interpreter 
/bin/python3 != /usr/bin/python3 [prerm]
 scripts-control-interpreters-paths (binary): unusual-control-interpreter 
/bin/python3 [prerm]
 scripts-control-interpreters-paths (binary): maintainer-script-interpreter 
/usr/local/bin/bash [preinst]
 scripts-control-interpreters-paths (binary): maintainer-script-interpreter 
/usr/bin/bash [postinst]



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/9266486e228fa9dcc20e6500f909c7b3c07b93b0

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/9266486e228fa9dcc20e6500f909c7b3c07b93b0
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] Improve CONTRIBUTING.md



Axel Beckert pushed to branch master at lintian / lintian


Commits:
1df38cf7 by William Desportes at 2024-05-06T00:25:44+00:00
Improve CONTRIBUTING.md

- - - - -


1 changed file:

- CONTRIBUTING.md


Changes:

=
CONTRIBUTING.md
=
@@ -152,7 +152,7 @@ will show you further options.
 
 ### Calibrating tests to fix test failures
 
-If tests fail, the teststuite will use an interactive 'calibration'
+If tests fail, the testsuite will use an interactive 'calibration'
 process to help you write or amend a 'hints' file. Simply follow
 the instructions on the screen. In many cases, it is best to "accept
 all" and examine the changes in git. In complex cases, you can use
@@ -173,6 +173,25 @@ configure perltidy in a special way. Please run it from the
 repository's base directory. Otherwise it will not find the custom
 configuration, and the test suite will not pass.
 
+### Run perltidy
+
+The program perltidy is provided by the package 
[perltidy](https://packages.debian.org/perltidy).
+The program prove is provided by the package 
[perl](https://packages.debian.org/perl).
+
+ On all files
+
+```sh
+prove -l t/scripts/01-critic/
+```
+
+### On recently changed files
+
+On the 10 last commits
+
+```sh
+git diff --name-only HEAD~10 HEAD | grep -F ".pm" | xargs perltidy -b
+```
+
 ### Submit a merge request
 
 Once all the above is done, please push your changes to your Lintian



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/1df38cf7438ff9fd8b389f61be715ec85e4d3e98

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/1df38cf7438ff9fd8b389f61be715ec85e4d3e98
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] 3 commits: Fix regex replacement for transition suffix g



Axel Beckert pushed to branch master at lintian / lintian


Commits:
b2561ac7 by Mattias Ellert at 2024-05-06T00:04:04+00:00
Fix regex replacement for transition suffix g

The replacement should remove a final g after a digit, but leave the
digit in place, e.g. libpam0g → libpam0 and libgjs0g → libgjs0.

- - - - -
a4c658ff by Mattias Ellert at 2024-05-06T00:04:04+00:00
Only remove transition suffices when preceded by a digit

- - - - -
07167eeb by Mattias Ellert at 2024-05-06T00:04:04+00:00
Add transition suffix t64 for 64 bit time_t transition

- - - - -


1 changed file:

- lib/Lintian/Check/Libraries/Shared/Soname.pm


Changes:

=
lib/Lintian/Check/Libraries/Shared/Soname.pm
=
@@ -83,11 +83,12 @@ sub installable {
 
 # try to strip transition strings
 my $shortened_name = $self->processable->name;
-$shortened_name =~ s/c102\b//;
-$shortened_name =~ s/c2a?\b//;
-$shortened_name =~ s/\dg$//;
-$shortened_name =~ s/gf$//;
-$shortened_name =~ s/v[5-6]$//; # GCC-5 / libstdc++6 C11 ABI breakage
+$shortened_name =~ s/(\d)c102$/$1/;
+$shortened_name =~ s/(\d)c2a?$/$1/;
+$shortened_name =~ s/(\d)g$/$1/;
+$shortened_name =~ s/(\d)gf$/$1/;
+$shortened_name =~ s/(\d)v[56]$/$1/; # GCC-5 / libstdc++6 C11 ABI breakage
+$shortened_name =~ s/(\d)t64$/$1/;   # 64 bit time_t
 $shortened_name =~ s/-udeb$//;
 $shortened_name =~ s/^lib64/lib/;
 



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/dfc03ef87409473bc76e287fa2fd25b388f2e214...07167eebb697d74d84627b275d8aeff4ebf32f7e

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/dfc03ef87409473bc76e287fa2fd25b388f2e214...07167eebb697d74d84627b275d8aeff4ebf32f7e
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] Upgrade the severity of missing-systemd-service-for-init.d-script from warning to error



Axel Beckert pushed to branch master at lintian / lintian


Commits:
5faaefd9 by Luca Boccassi at 2024-05-05T21:17:29+00:00
Upgrade the severity of missing-systemd-service-for-init.d-script from warning 
to error

The generator will be deprecated during the Trixie dev cycle, so
packages without a unit file will stop working.
Policy has been updated accordingly:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039102

- - - - -


1 changed file:

- tags/m/missing-systemd-service-for-init.d-script.tag


Changes:

=
tags/m/missing-systemd-service-for-init.d-script.tag
=
@@ -1,5 +1,5 @@
 Tag: missing-systemd-service-for-init.d-script
-Severity: warning
+Severity: error
 Check: systemd
 Explanation: The specified init.d script has no equivalent systemd service.
  .



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/5faaefd9f0c11c4bc5ab12b0bc713459e041de93

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/5faaefd9f0c11c4bc5ab12b0bc713459e041de93
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] ci: check longer timeout for autopkgtest



Axel Beckert pushed to branch master at lintian / lintian


Commits:
3678cc5a by Kentaro Hayashi at 2024-05-06T00:08:56+09:00
ci: check longer timeout for autopkgtest

The default value of CI_JOB_TIMEOUT is 1h (3600), but autopkgtest will
not finish in 1 hour generally.

lintian/lintian CI/CD setting of timeout is extended to 3h, but
not true for forked/contributors lintian CI/CD settings - so it always
fail.

This MR aimed to fix warn such a situation in advance.

Signed-off-by: Kentaro Hayashi ken...@gmail.com

- - - - -


1 changed file:

- debian/salsa-ci.yml


Changes:

=
debian/salsa-ci.yml
=
@@ -28,3 +28,13 @@ variables:
   before_script:
   - apt-get update
   - apt-get install -y ${WORKING_DIR}/lintian_*.deb
+
+# Try to check whether the maximum job timeout is extended to longer one.
+.test-autopkgtest: 
+  before_script:
+- 'echo "CI/CD Settings / General pipelines / Timeout: $CI_JOB_TIMEOUT 
seconds"'
+- |
+  if [[ $CI_JOB_TIMEOUT -le 3600 ]]; then
+echo -e "\e[31;1mERROR: CI/CD Settings / General pipelines / Timeout 
is too short ($CI_JOB_TIMEOUT). Use longer timeout - e.g. 7200 (2h) is 
enough.\e[0m"
+exit 1
+  fi



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/3678cc5ac32075ce91496168b692aa7c2fbd7d85

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/3678cc5ac32075ce91496168b692aa7c2fbd7d85
You're receiving this email because of your account on salsa.debian.org.

Re: adequate maintenance

2024-05-04 Thread Axel Beckert

Hi Serafeim,

Serafeim Zanikolas wrote:
> I'm considering to ITA the adequate package,

Cool!

> on the condition that (i) the folks taking care of it to date, and
> (ii) the lintian team

Can speak for both, more or less. :-)

> would be okay for me to rewrite it

Neither an objection from myself as former adequate QA uploader nor
from the Lintian team.

> in go.
>
> I understand that go is not the most popular of languages in Debian

Static linking is bad for security updates. I think that's the main if
not the only reason which speaks against Go. But it wouldn't be the
first Go package in Debian and the Debian Security Team seems to be
able to live with it. And having a useful adequate would be nice.

> and that lintian tools are mostly perl and python.

Lintian is 95% Perl. It has about 300 lines of Python (in the test
suite in dummy python packages) and about 83'000 lines of Perl.

Lintian-Brush is written in Python, but a separate project
independently developed by Jelmer.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

signature.asc
Description: PGP signature

Re: Current state of lintian?

2024-04-18 Thread Axel Beckert

Hi,

Nilesh Patra wrote:
> I wanted to know what the current situation of lintian maintenance
> is.

Now that policy 4.7.0 is out we (really) should get a release done
soon.

The other reason is as you already mentioned …

> Currently there's an RC bug #1066261 against it

… this (and #1065431). Thanks for merging that one!

> and I am unsure as to what should be done (release now, later,
> what?).

"Soon". I plan to do a release within the next 10 days. Probably won't
have time before Saturday, though.

> I've been reviewing and merging some MRs on the repo for a few
> months, but other than that I have not witnessed much activity.

Done that, too, for a few MRs, but probably for fewer than you did.

> So here's the question: How is the maintenance status?

A bit better than last year from my point of view, but it obviously
could be better. I still only find time for Lintian every other month
or so — nevertheless I seem the only one who dares to do a release.
(Which makes me kinda feel honored, but it actually is a really bad
bus-factor. )

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Re: Bug#1033894: lintian: bad-distribution-in-changes-file bookworm

2024-02-06 Thread Axel Beckert

Version: 2.117.0

Hi,

Arnaud Rebillout wrote:
> On Tue, 28 Nov 2023 13:00:00 -0700 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?=
>  wrote:
> > The fix for this issue is still only in git at
> > https://salsa.debian.org/lintian/lintian/-/commit/ebb739d102d55797516c0f10452e4e4c2502644d
[…]
> The fix was released in lintian 2.117.0.

Thanks for mentioning this. Seems to have slipped through our fingers
and indeed was fixed by this commit, but it doesn't close this bug
report. (Maybe the committer missed that there is a bug report for
that.)

I've just retroactively added the "Closes" to Lintian's
debian/changelog as there weren't any other changes yet, so "gbp dch"
will still work fine. *phew*

I've just also added trixie and forky so this is already fixed for the
next stable release, too. :-)

> But unless it's backported to bookworm, the problem you highlighted
> remains.

Needs to migrate to testing first. And I'd be glad if someone else
could take care of the backport. *hinthinthint* :-)

Note: Running the testsuite this time requires a debhelper version
newer than in stable (but satisfiable) in stable-backports due to the
testsuite expecting dh_movetousr being active. Sorry 'bout that. Feel
free to suggest (or even implement) a better solution to that.

> > and there has not been any new Lintian uploads since Lintian
> > 2.116.3 in February 2023.

Please note that February 2023 was during the freeze and Bookworm was
released in June. And I indeed remember that we didn't managed to get
out a 2.116.4 with some more last-minute fixes. Sorry for that.

And yes, there was exactly one year without a Lintian releasae. :-/
While there were a ton of new and old contributors in this release, it
seems that nobody else than me dared to actually do a Lintian release.
But I was waylaid for months for multiple reasons. (But I think,
Bastièn probably would have done one if I wouldn't have become active
again recently. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

signature.asc
Description: PGP signature

[Git][lintian/lintian][master] 2 commits: Retroactively mention #1033894 in previous changelog entry



Axel Beckert pushed to branch master at lintian / lintian


Commits:
66e9477a by Axel Beckert at 2024-02-06T08:16:00+01:00
Retroactively mention #1033894 in previous changelog entry

We normaly should never do that as it breaks gbp dch. Unless nothing
else than the debian/changelog has been changed since a release. As in
this case. :-)

- - - - -
27896ef1 by Axel Beckert at 2024-02-06T08:24:22+01:00
data/changes-file/known-dists: Add trixie and forky

- - - - -


2 changed files:

- data/changes-file/known-dists
- debian/changelog


Changes:

=
data/changes-file/known-dists
=
@@ -11,6 +11,8 @@ stretch
 buster
 bullseye
 bookworm
+trixie
+forky
 sid
 
 # Aliases
@@ -19,4 +21,3 @@ stable
 testing
 unstable
 experimental
-


=
debian/changelog
=
@@ -1,5 +1,8 @@
 lintian (2.117.1~git) UNRELEASED; urgency=medium
 
+  [ Axel Beckert ]
+  * Retroactively mention #1033894 in previous changelog entry.
+
   * WIP (generated at release time: please do not add entries below.)
 
  -- Axel Beckert   Mon, 05 Feb 2024 23:25:47 +0100
@@ -55,7 +58,7 @@ lintian (2.117.0) unstable; urgency=low
 
   [ Nilesh Patra ]
   * Make lintian recognize fasttrack as a dist.
-  * Update known dists and oldstable epoch.
+  * Update known dists and oldstable epoch. (Closes: #1033894)
   * autopkgtest fix: Update badnocredit.raw for updated Adobe license tag
 check.
   * Fix rootless-builds.txt location in lintian tags. (Closes: #1051538)



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/f2746dd7c37314e836f6d4f9fac0bcad84d53f5a...27896ef12c526253ca5f9d49967d1670550f6597

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/f2746dd7c37314e836f6d4f9fac0bcad84d53f5a...27896ef12c526253ca5f9d49967d1670550f6597
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] Post-release version bump



Axel Beckert pushed to branch master at lintian / lintian


Commits:
f2746dd7 by Axel Beckert at 2024-02-05T23:25:47+01:00
Post-release version bump

Gbp-Dch: Ignore

- - - - -


1 changed file:

- debian/changelog


Changes:

=
debian/changelog
=
@@ -1,3 +1,9 @@
+lintian (2.117.1~git) UNRELEASED; urgency=medium
+
+  * WIP (generated at release time: please do not add entries below.)
+
+ -- Axel Beckert   Mon, 05 Feb 2024 23:25:47 +0100
+
 lintian (2.117.0) unstable; urgency=low
 
   The "One Year Later" Release.



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/f2746dd7c37314e836f6d4f9fac0bcad84d53f5a

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/f2746dd7c37314e836f6d4f9fac0bcad84d53f5a
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian] Pushed new tag 2.117.0



Axel Beckert pushed new tag 2.117.0 at lintian / lintian

-- 
View it on GitLab: https://salsa.debian.org/lintian/lintian/-/tree/2.117.0
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] private/generate-tag-summary --in-place: Avoid mojibake by not double-encoding UTF-8



Axel Beckert pushed to branch master at lintian / lintian


Commits:
4fd76dc5 by Axel Beckert at 2024-02-05T21:34:04+01:00
private/generate-tag-summary --in-place: Avoid mojibake by not double-encoding 
UTF-8

- - - - -


1 changed file:

- private/generate-tag-summary


Changes:

=
private/generate-tag-summary
=
@@ -95,7 +95,7 @@ if ($opt{'in-place'}) {
   or die encode_utf8("Cannot open $infile");
 
 my $outfile = 'debian/changelog.tmp';
-open(my $out_fd, '>:encoding(UTF-8)', $outfile)
+open(my $out_fd, '>', $outfile)
   or die encode_utf8("Cannot open $outfile");
 
 while (my $line = <$in_fd>) {



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/4fd76dc585013a0a5ff646797385514721f1ad3b

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/4fd76dc585013a0a5ff646797385514721f1ad3b
You're receiving this email because of your account on salsa.debian.org.

Lintian 2.117.0 imminent (was: Re: New release for lintian?)

2024-02-05 Thread Axel Beckert

Hi,

Nilesh Patra wrote:
> Would you consider to do a review and upload a new release to
> unstable, please?

Working on it now. Please do no more merges or pushes for the next few
hours.

Everything else needs to go into a 2.117.1 or 2.118.0.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Re: Bug#1012289: RFH: lintian -- Debian package checker

2024-02-05 Thread Axel Beckert

Hi Bill,

Bill Allombert wrote:
> By the way, what happened to lintian.debian.org ?

Seems as if someone (not me, just noticed it today when
"private/refresh-data" failed…) pulled the plug on at least the DNS
name. Probably because it hasn't been updated since Felix' try to
rewrite it, which AFAIK was never finished, but the old thing also no
more worked. (There's probably a lot of legacy code in
"lib/Lintian/Output" related to one of these two website generations,
maybe even both.)

IMHO it's generally a good thing, except that it would have been
better to redirect it to the according UDD pages instead.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

[Git][lintian/lintian][master] Salsa CI: Drop backports to bullseye (oldstable): We expect a newer debhelper



Axel Beckert pushed to branch master at lintian / lintian


Commits:
cd755962 by Axel Beckert at 2024-02-05T03:55:52+01:00
Salsa CI: Drop backports to bullseye (oldstable): We expect a newer debhelper

... for the test suite to pass as it now uses path as present after
dh_movetousr has been run.

And despite the build profile nocheck is passed, apt 
build-dep in
bullseye tries to satisfy !nocheck build-dependencies 
nevertheless
and hence fails to install an older version of debhelper, despite it
would have been fine.

- - - - -


1 changed file:

- debian/salsa-ci.yml


Changes:

=
debian/salsa-ci.yml
=
@@ -16,13 +16,6 @@ build-bookworm-backports:
   extends: .build-package
   allow_failure: true
 
-build-bullseye-backports:
-  variables:
-RELEASE: 'bullseye-backports'
-DEB_BUILD_OPTIONS: 'nocheck'
-  extends: .build-package
-  allow_failure: true
-
 variables:
   SALSA_CI_DISABLE_BLHC: 1
   SALSA_CI_DISABLE_BUILD_PACKAGE_ANY: 1



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/cd7559626912ade82df64ea4474008fb56ec3970

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/cd7559626912ade82df64ea4474008fb56ec3970
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] Allow @recommends@ as autopkgtest dependency



Axel Beckert pushed to branch master at lintian / lintian


Commits:
c738fa47 by Valentin Vidic at 2024-02-05T02:30:13+00:00
Allow @recommends@ as autopkgtest dependency

Replaces deprecated needs-recommends.
- - - - -


1 changed file:

- lib/Lintian/Check/Testsuite.pm


Changes:

=
lib/Lintian/Check/Testsuite.pm
=
@@ -62,6 +62,7 @@ our $PYTHON3_ALL_DEPEND
 my %KNOWN_SPECIAL_DEPENDS = map { $_ => 1 } qw(
   @
   @builddeps@
+  @recommends@
 );
 
 sub source {



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/c738fa474b4b0e737edece78c8553a6fc76442d7

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/c738fa474b4b0e737edece78c8553a6fc76442d7
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] Don't emit source-nmu-has-incorrect-version-number for stable updates



Axel Beckert pushed to branch master at lintian / lintian


Commits:
79d146ac by Emilio Pozuelo Monfort at 2024-02-05T00:56:05+00:00
Dont emit source-nmu-has-incorrect-version-number for stable updates

Closes: #1022759

- - - - -


1 changed file:

- lib/Lintian/Check/Nmu.pm


Changes:

=
lib/Lintian/Check/Nmu.pm
=
@@ -102,6 +102,7 @@ sub source {
 my $version_nmuness = 0;
 my $version_local = 0;
 my $upload_is_backport = $version =~ m/~bpo(\d+)\+(\d+)$/;
+my $upload_is_stable_update = $version =~ m/~deb(\d+)u(\d+)$/;
 
 if ($version =~ /-[^.-]+(\.[^.-]+)?(\.[^.-]+)?$/) {
 $version_nmuness = 1 if defined $1;
@@ -158,6 +159,7 @@ sub source {
 $pointer, $version)
   if $upload_is_nmu
   && $version_nmuness != 1
+  && !$upload_is_stable_update
   && !$upload_is_backport;
 }
 



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/79d146acb7b4784cea4e7cd705de9f9854e98bd6

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/79d146acb7b4784cea4e7cd705de9f9854e98bd6
You're receiving this email because of your account on salsa.debian.org.

Re: New release for lintian?

2024-02-04 Thread Axel Beckert

Hi,

I'm step by step trying to get back into working on Debian again. And
besides RC bugs, Lintian is a focus, too.

Nilesh Patra wrote on 13th of October 2023:
> > > Over the past few days I've tried to merge some of the pending MRs and
> > > also push minor changes on the lintian repository.

Thanks again for that. I merged a few more today and fixed the test
suite issues caused by dh_movetousr. The test suite passes again.

> > > Would you consider to do a review and upload a new release to
> > > unstable, please?

I'll try to get one done soonish. Got another bunch of MRs rebased and
waiting for the test results now that the test suite passes again.

Also got some more commits waiting to be pushed locally to not cancel
those two MR pipelines currently running. (They all seem to run on the
same runner, which explains why autopkgtest already runs longer than
in previous runs.)

> Can I ask you to review/merge these, please? (Some have been
> taken from pollo's mail)
> 
>   https://salsa.debian.org/lintian/lintian/-/merge_requests/482

Already merged. Thanks!

>   https://salsa.debian.org/lintian/lintian/-/merge_requests/458
>   https://salsa.debian.org/lintian/lintian/-/merge_requests/462
>   https://salsa.debian.org/lintian/lintian/-/merge_requests/471
>   https://salsa.debian.org/lintian/lintian/-/merge_requests/472

These all either add new tests, require additional run-time
dependencies or are generally rather invasive.

For getting out a release soonish, I'd rather avoid them and merge
them at in a later release.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

[Git][lintian/lintian][master] 3 commits: Add *~ to .gitignore



Axel Beckert pushed to branch master at lintian / lintian


Commits:
5bffcd9a by Richard Lewis at 2024-02-05T00:50:58+00:00
Add *~ to .gitignore

- - - - -
40f26ce4 by Richard Lewis at 2024-02-05T00:50:58+00:00
Add test that demonstrates bug #1019690

lintian exits with code 2 when --show-overrides is given and an error is fixed.
The test added will fail: the next commit will fix lintian so it passes.

- - - - -
372ac9c8 by Richard Lewis at 2024-02-05T00:50:58+00:00
Fix exit code when --show-overrides is given and an error tag is 
overridden

Previously, if an error tag was overridden but --show-overrides was given,
lintian would correctly override the tag, but incorrectly give an exit
code of 2.

The reason is a logic error in lib/Lintian/Pool.pm in the code from lines 
173-212

The whole block seems to be attempting to:
- skip hints (tags) that should not be displayed (experimental, or at a too-low 
display-level)
- count number of errors/warnings that remain (used in line 217 to set exit 
code)
- keep hints that should be displayed (line 211)

Because on line 194, if an error tag is overridden and 
--show-overrides is given the block
decided not to call next (because keeping the hint doesnt happen until line 
211).

But then line 197 is executed which means that the hint is counted as a 
warning/error/etc whenever
show-overrides was present: effectively show-overrides makes it look like no 
override was present.

(And then on line 217 the exit_code will be set to 2).

This patch therefore changes 197 to only run the sub-block if an override was 
not defined.

- - - - -


8 changed files:

- .gitignore
- lib/Lintian/Pool.pm
- + 
t/recipes/lintian-features/exit-status/show-overrides-exit-status/build-spec/debian/install
- + 
t/recipes/lintian-features/exit-status/show-overrides-exit-status/build-spec/debian/lintian-overrides
- + 
t/recipes/lintian-features/exit-status/show-overrides-exit-status/build-spec/fill-values
- + 
t/recipes/lintian-features/exit-status/show-overrides-exit-status/build-spec/orig/file
- + t/recipes/lintian-features/exit-status/show-overrides-exit-status/eval/desc
- + 
t/recipes/lintian-features/exit-status/show-overrides-exit-status/eval/literal


Changes:

=
.gitignore
=
@@ -17,6 +17,7 @@
 /.idea/
 /.nobackup
 *.bak
+*~
 *.rej
 cover_db*
 /coverage-report


=
lib/Lintian/Pool.pm
=
@@ -191,8 +191,7 @@ sub process{
 next
   unless $PROFILE->display_level_for_tag($hint->tag_name);
 
-if (!defined $hint->override
-|| $option->{'show-overrides'}) {
+if (!defined $hint->override) {
 
 ++$reported_count{$tag->visibility}
   if !$tag->experimental;


=
t/recipes/lintian-features/exit-status/show-overrides-exit-status/build-spec/debian/install
=
@@ -0,0 +1 @@
+file /usr/share/file


=
t/recipes/lintian-features/exit-status/show-overrides-exit-status/build-spec/debian/lintian-overrides
=
@@ -0,0 +1,2 @@
+# package installs a d/rules template not a script
+missing-dep-for-interpreter /usr/bin/make *


=
t/recipes/lintian-features/exit-status/show-overrides-exit-status/build-spec/fill-values
=
@@ -0,0 +1,3 @@
+Skeleton: upload-native
+Testname: show-overrides-exit-status
+Description: Bug #1019690 correct exit status when show-overrides


=
t/recipes/lintian-features/exit-status/show-overrides-exit-status/build-spec/orig/file
=
@@ -0,0 +1,4 @@
+#!/usr/bin/make -f
+
+%:
+   dh $@ --with elpa


=
t/recipes/lintian-features/exit-status/show-overrides-exit-status/eval/desc
=
@@ -0,0 +1,6 @@
+Testname: show-overrides-exit-status
+Check: scripts
+Exit-Status: 0
+Match-Strategy: literal
+Output-Format: EWI
+Default-Lintian-Options: --show-overrides --fail-on error


=
t/recipes/lintian-features/exit-status/show-overrides-exit-status/eval/literal
=
@@ -0,0 +1,2 @@
+N: package installs a d/rules template not a script
+O: show-overrides-exit-status: missing-dep-for-interpreter /usr/bin/make (does 
not satisfy make:any | build-essential:any | dpkg-dev:any) [usr/share/file/file]



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/151989ab43db9082c02a75e5d3683fe0bbd6c4cc...372ac9c821c29df356378c9ec3f66dd7cefb94ce

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/151989ab43db9082c02a75e5d3683fe0bbd6c4cc...372ac9c821c29df356378c9ec3f66dd7cefb

[Git][lintian/lintian][master] obsolete-packages: another common old Builld-Dep



Axel Beckert pushed to branch master at lintian / lintian


Commits:
151989ab by Alexandre Detiste at 2024-02-05T00:42:44+00:00
obsolete-packages: another common old Builld-Dep
- - - - -


1 changed file:

- data/fields/obsolete-packages


Changes:

=
data/fields/obsolete-packages
=
@@ -151,6 +151,7 @@ libgsasl7-dev => libgsasl-dev
 libidn11-dev => libidn-dev
 policykit-1 => polkitd and optionally pkexec
 lsb-base
+pkg-config => pkgconf
 
 # Deprecated in trixie
 gnome-common => https://wiki.gnome.org/Projects/GnomeCommon/Migration



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/151989ab43db9082c02a75e5d3683fe0bbd6c4cc

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/151989ab43db9082c02a75e5d3683fe0bbd6c4cc
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] 2 commits: Add build-depedency on debhleper ≥ 13.11.8~ if the test suite is run at build-time



Axel Beckert pushed to branch master at lintian / lintian


Commits:
6940c6a8 by Axel Beckert at 2024-02-05T01:28:37+01:00
Add build-depedency on debhleper ≥ 13.11.8~ if the test suite is run at 
build-time

- - - - -
c9b6c94c by Axel Beckert at 2024-02-05T01:28:52+01:00
L::C::B::Corrupted::check_elf_issues(): Return immediately if file is no ELF 
file

Thanks: Corvin Köhne via MR !486

I implemented it differently than Corvin to avoid code duplication and
to be more future proof in case non-ELF issues will be checked in the
future with visit_*_files().

- - - - -


2 changed files:

- debian/control
- lib/Lintian/Check/Binaries/Corrupted.pm


Changes:

=
debian/control
=
@@ -9,6 +9,7 @@ Build-Depends:
  aspell ,
  aspell-en ,
  cdbs ,
+ debhelper (>= 13.11.8~) ,
  debhelper-compat (= 13),
  default-jdk-headless | default-jdk ,
  dh-elpa | bash (<< 4.4) ,


=
lib/Lintian/Check/Binaries/Corrupted.pm
=
@@ -53,6 +53,8 @@ sub visit_installed_files {
 sub check_elf_issues {
 my ($self, $item) = @_;
 
+return unless $item->is_elf;
+
 for (uniq @{$item->elf->{ERRORS} // []}) {
 $self->pointed_hint('elf-error',$item->pointer, $_)
   unless (



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/b69e774798c3c63992b869739421ac3bb2c2948f...c9b6c94c91e3c142c172dce9d51f82b08dfad69d

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/b69e774798c3c63992b869739421ac3bb2c2948f...c9b6c94c91e3c142c172dce9d51f82b08dfad69d
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] Some more usrmerge-related test suite fine-tuning



Axel Beckert pushed to branch master at lintian / lintian


Commits:
b69e7747 by Axel Beckert at 2024-02-05T00:10:20+01:00
Some more usrmerge-related test suite fine-tuning

Git-Dch: Ignore

- - - - -


2 changed files:

- t/recipes/checks/systemd/kill-mode-none/eval/hints
- t/recipes/checks/systemd/service-file-no-install-key/build-spec/debian/install


Changes:

=
t/recipes/checks/systemd/kill-mode-none/eval/hints
=
@@ -1,2 +1,2 @@
 kill-mode-none (binary): systemd-service-file-missing-hardening-features 
[usr/lib/systemd/system/kill-mode-none.service]
-kill-mode-none (binary): kill-mode-none 
lib/systemd/system/kill-mode-none.service 
[usr/lib/systemd/system/kill-mode-none.service]
+kill-mode-none (binary): kill-mode-none 
usr/lib/systemd/system/kill-mode-none.service 
[usr/lib/systemd/system/kill-mode-none.service]


=
t/recipes/checks/systemd/service-file-no-install-key/build-spec/debian/install
=
@@ -1 +1 @@
-debian/no-install.service lib/systemd/system/
+debian/no-install.service usr/lib/systemd/system/



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/b69e774798c3c63992b869739421ac3bb2c2948f

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/b69e774798c3c63992b869739421ac3bb2c2948f
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] Run perltidy on lib/Lintian/Check/AppstreamMetadata.pm



Axel Beckert pushed to branch master at lintian / lintian


Commits:
f1c99de5 by Axel Beckert at 2024-02-04T21:13:09+01:00
Run perltidy on lib/Lintian/Check/AppstreamMetadata.pm

Gbp-Dch: Ignore

- - - - -


1 changed file:

- lib/Lintian/Check/AppstreamMetadata.pm


Changes:

=
lib/Lintian/Check/AppstreamMetadata.pm
=
@@ -97,8 +97,8 @@ sub installable {
 foreach my $lib_dir (qw(usr/lib lib)) {
 if (
 defined(
-my $dir =
-$processable->installed->resolve_path("$lib_dir/udev/rules.d/")
+my $dir = $processable->installed->resolve_path(
+"$lib_dir/udev/rules.d/")
 )
 ) {
 for my $item ($dir->descendants) {



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/f1c99de500180c2b67ed3f383401f36a20ab1d32

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/f1c99de500180c2b67ed3f383401f36a20ab1d32
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] arch-regex: add loong64 support

2023-10-25 Thread Axel Beckert (@abe)



Axel Beckert pushed to branch master at lintian / lintian


Commits:
32710afb by Jiajie Chen at 2023-10-25T23:55:22+08:00
arch-regex: add loong64 support

- - - - -


1 changed file:

- data/binaries/arch-regex


Changes:

=
data/binaries/arch-regex
=
@@ -35,6 +35,7 @@ i386  ~~^ELF 32-bit LSB .* 80386, .* 
(?:GNU/Linux|(?!GNU)).*$
 ia64  ~~^ELF 64-bit LSB .* IA-64
 kfreebsd-amd64~~^ELF 64-bit LSB .* x86-64, .* (?:GNU/kFreeBSD|(?!GNU)).*$
 kfreebsd-i386 ~~^ELF 32-bit LSB .* 80386, .* (?:GNU/kFreeBSD|(?!GNU)).*$
+loong64   ~~^ELF 64-bit LSB .* LoongArch
 lpia  ~~^ELF 32-bit LSB .* 80386, .* (?:GNU/Linux|(?!GNU)).*$
 m32r  ~~^ELF 32-bit MSB .* M32R
 m68k  ~~^ELF 32-bit MSB .* 680[02]0



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/32710afb323d923fe3d188c765d75ce1f395e448

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/32710afb323d923fe3d188c765d75ce1f395e448
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] Add "noble" as a known Ubuntu distribution.

2023-10-20 Thread Axel Beckert (@abe)



Axel Beckert pushed to branch master at lintian / lintian


Commits:
e48c525b by Simon Quigley at 2023-10-20T08:53:59-05:00
Add noble as a known Ubuntu distribution.

- - - - -


1 changed file:

- vendors/ubuntu/main/data/changes-file/known-dists


Changes:

=
vendors/ubuntu/main/data/changes-file/known-dists
=
@@ -34,3 +34,4 @@ jammy
 kinetic
 lunar
 mantic
+noble



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/e48c525bacef15a9a22d4ccba88084fcfe531109

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/e48c525bacef15a9a22d4ccba88084fcfe531109
You're receiving this email because of your account on salsa.debian.org.

Re: New release for lintian?

2023-10-12 Thread Axel Beckert

Hi Bastien and Nilesh,

Bastien Roucariès wrote:
> Le jeudi 12 aoctobre 2023, 14:41:40 UTC Nilesh Patra a écrit :
> > Over the past few days I've tried to merge some of the pending MRs and
> > also push minor changes on the lintian repository.

Thanks!

> > Would you consider to do a review and upload a new release to
> > unstable, please?
> 
> Yes I will

Thanks! I'll slowly start to join again, too, over the next few weeks.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Re: Request to bump my access in lintian team's salsa to maintainer

2023-09-21 Thread Axel Beckert

Hi Nilesh,

Nilesh Patra wrote:
> lintian seems to be having a bunch of merge requests opened against it
> almost at all times.

It's currently even worse as I was on holidays for several weeks and I
am now on sick leave — unrelated to the holidays, though, just bad
luck. (See debian-private for details.)

> While I can approve the requests, I can't really merge them since my
> access level in lintian team is that of a developer. I do not intend to
> merge major changes without discussion (with Axel/Bastien/Russ), but
> rather the minor ones that maybe critical - for instance there is an RC
> bug #1042049 and there is a patch on salsa that I'd like to merge.

Thanks for jumping in!

> Hence, if you trust my judgement on this, would you consider to
> bump my access to that of a maintainer so I can merge some of these
> things on my own?

I've upped your Lintian group membership level by one from Developer
to Maintainer. Does that help? (There's only the level "Owner" above
that and I think that only grants additional administrative
privileges.)

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

signature.asc
Description: PGP signature

Bug#1042463: lintian does not accept overrides in the syntax used on ftp-master

2023-09-01 Thread Axel Beckert

Control: tag -1 + moreinfo

Hi Julian,

Julian Andres Klode wrote:
> lintian in the archive needs to restore support for the old override
> format, or ftpmaster needs to be updated to the new lintian.

We had a lengthy discussion about the override format changes made by
Felix (see https://bugs.debian.org/1007002) and there's no way back
(including "backwards compatibility") unless someone volunteers to
implement a fix for this. (I won't do that as mentioned in this
thread. See also below for some reasoning.)

> Normal source-only uploads do not trigger the issue usually, but
> there surely have been people adopting their overrides to the new
> format who now get stuck (like me) at binary-NEW with a reject when
> having to do a binary upload.

Please give an explicit example. I'm not sure if you and me think of
the same "new" and "old" format. → Tagged as "moreinfo".

As mentioned in #1007002 there's a script in the migrate-overrides
branch of https://salsa.debian.org/lintian/lintian/ which can
automatically migrate tags in override files.

But so far it only knows a few of the very annoying tags — which is also
the reason it's not in the package yet.

But I'm willing to extend that script and maybe even implement a mode
for ftp-masters if I get an example of a file which needs to be
migrated (including file name and maybe default path).

But for that I need old real-life examples. (Maybe ftp-masters can
give me the file/list Julian mentioned or tell me where to find it?)

> For an orderly transition, lintian needs to […]

Please tell this the previous lintian lead developer who decided and
implemented this inmidst of tons of other invasive changes (like
rewriting Lintian's internal module structure) without doing a release
for months or doing a release after one of these invasive changes.

It's anything but a simple "git revert" to get the old format back.
And a compatibility mode would require implementing the old override
format in the new framework from scratch.

Short said: IMHO we should do a forward escape instead of trying to
implement a very work-intensive backwards compatibility. For which we
don't seem to have the resources anyway unless someone volunteers.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Re: Pending merge requests :)

2023-09-01 Thread Axel Beckert

Hi,

Louis-Philippe Véronneau wrote:
> I was wondering if one of the lintian maintainers would be up to having a
> look at the current pending MRs on Salsa.

Yeah, I'm now back from lengthy holidays (see my annoucement on
debian-private about a month ago) and working through my pending
Debian (and other) TODOs which piled up during the holidays. %-)

Regarding Debian, I'm first/currently going through the open RC bugs
in my packages and probably some low-hanging fruits (like e.g. the new
screen upstream release) before diving into lintian again.

But yeah, a new lintian upload is overdue.

> After a cursory glance, here is a list of the ones I that look like they are
> in a good enough state to be merged:
> 
> * https://salsa.debian.org/lintian/lintian/-/merge_requests/407
> * https://salsa.debian.org/lintian/lintian/-/merge_requests/453
> * https://salsa.debian.org/lintian/lintian/-/merge_requests/458
> * https://salsa.debian.org/lintian/lintian/-/merge_requests/462
> * https://salsa.debian.org/lintian/lintian/-/merge_requests/471
> * https://salsa.debian.org/lintian/lintian/-/merge_requests/472
> * https://salsa.debian.org/lintian/lintian/-/merge_requests/473

Thanks for your review of these.

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

signature.asc
Description: PGP signature

Bug#1030991: lintian: checking intel-mkl takes 18 hours

2023-03-05 Thread Axel Beckert

Hi Andreas,

Axel Beckert wrote:
> Andreas Beckmann wrote:
> > Checking intel-mkl (pre-built binaries in non-free) with lintian is very
> > slow. A full build (i.e. source+all+any) on amd64 takes nearly 18 hours
> > to check with
> >   lintian -i -E -L ">=pedantic" -v intel-mkl_2020.4.304-4_amd64.changes
> > on my local machine (8 cores, 64 GB, tmpfs on /tmp, storage on nvme).

Took about 4 hours here (with about the same specs, but a quite recent
CPU: i7-11700 with 8 cores, 16 threads, 64 GB RAM and all NVMe
storage, including /tmp/), but still far too long.

> I'll check if --perf-debug brings up anything helpful.

Here's the break down on any check that took more than 10 seconds,
sorted by Lintian check:

Binary checks:

Check binaries/corrupted for binary:libmkl-computational-dev_2020.4.304-4_amd64 
done (2494.134s)
Check binaries/corrupted for binary:libmkl-interface-dev_2020.4.304-4_amd64 
done (104.566s)
Check binaries/corrupted for binary:libmkl-threading-dev_2020.4.304-4_amd64 
done (34.574s)
Check binaries/hardening for binary:libmkl-computational-dev_2020.4.304-4_amd64 
done (2233.613s)
Check binaries/hardening for binary:libmkl-interface-dev_2020.4.304-4_amd64 
done (98.522s)
Check binaries/hardening for binary:libmkl-threading-dev_2020.4.304-4_amd64 
done (34.621s)
Check binaries/obsolete/crypt for 
binary:libmkl-computational-dev_2020.4.304-4_amd64 done (2206.171s)
Check binaries/obsolete/crypt for 
binary:libmkl-interface-dev_2020.4.304-4_amd64 done (99.777s)
Check binaries/obsolete/crypt for 
binary:libmkl-threading-dev_2020.4.304-4_amd64 done (34.487s)
Check libraries/static for binary:libmkl-computational-dev_2020.4.304-4_amd64 
done (2176.996s)
Check libraries/static for binary:libmkl-interface-dev_2020.4.304-4_amd64 done 
(124.188s)
Check libraries/static for binary:libmkl-threading-dev_2020.4.304-4_amd64 done 
(38.784s)
Check libraries/static/link-time-optimization for 
binary:libmkl-computational-dev_2020.4.304-4_amd64 done (2062.453s)
Check libraries/static/link-time-optimization for 
binary:libmkl-interface-dev_2020.4.304-4_amd64 done (106.561s)
Check libraries/static/link-time-optimization for 
binary:libmkl-threading-dev_2020.4.304-4_amd64 done (34.848s)
Check libraries/static/no-code for 
binary:libmkl-computational-dev_2020.4.304-4_amd64 done (2209.059s)
Check libraries/static/no-code for 
binary:libmkl-interface-dev_2020.4.304-4_amd64 done (128.671s)
Check libraries/static/no-code for 
binary:libmkl-threading-dev_2020.4.304-4_amd64 done (42.731s)

Source check:

Check debian/control/field/rules-requires-root for 
source:intel-mkl_2020.4.304-4 done (499.496s)

So basically the long-taking tests all took about the same time for
each package. So I assume they all had the same issues for each
package, just to different amounts:

* 2000-2500s for libmkl-computational-dev
*  100-130s  for libmkl-interface-dev
*   30-45s   for libmkl-threading-dev

So I've ran Lintian under a profiler on the smallest of these
packages.

perl -d:NYTProf lintian/bin/lintian libmkl-threading-dev_2020.4.304-4_amd64.deb

And indeed, all three checks stayed approximately the same time in
Lintian::Index::Item::elf_by_member() which took up to 158 seconds
(under the profiler) in 162407 calls.

So if we want to speed up analysing binaries with large .a files (up
to 640 MB in this case), we should clearly speed elf_by_member().

And inside it, it's this line which took all but 1 second of it:

my %copy = %{$self->index->elf_storage_by_member->{$self->name} // {} };

So basically copying data in RAM around seems to be the main cause for
taking so long on these binary packages.

Accordingly I've made this temporary local change to check what it
would be without copying around that data:

diff --git a/lib/Lintian/Index/Item.pm b/lib/Lintian/Index/Item.pm
index 7ef6c0994..87d766cbe 100644
--- a/lib/Lintian/Index/Item.pm
+++ b/lib/Lintian/Index/Item.pm
@@ -1434,9 +1434,10 @@ sub elf_by_member {
 return ();
 }

-my %copy = %{$self->index->elf_storage_by_member->{$self->name} // {} };
+#my %copy = %{$self->index->elf_storage_by_member->{$self->name} // {} };

-return \%copy;
+#return \%copy;
+return $self->index->elf_storage_by_member->{$self->name} // {};
 }

 =item pointer

(Patch and all tests based on the 2.116.3 release.) 

Not copying that data and just returning the original cuts the run
time down from 5m 7s to 1m 56s, i.e. by about 60%.

On the largest package (libmkl-computational-dev) it went down even a
much bigger percentage, from close to 3 hours (178 minutes) down to only 3
minutes and 32 seconds.

The question is now: Do we really need a separate copy of that data
for each call? Sure, if it's modified afterwards, this makes sense.
But I have no idea where this might happen.

So I've run the test suite on the above mentioned modification and to
my surprise it passed. 

[Git][lintian/lintian][master] Fix "Use of uninitialized value $LINTIAN_CFG" in debug output

2023-03-05 Thread Axel Beckert (@abe)



Axel Beckert pushed to branch master at lintian / lintian


Commits:
f03fc15a by Axel Beckert at 2023-03-05T16:26:04+01:00
Fix Use of uninitialized value $LINTIAN_CFG in debug output

- - - - -


1 changed file:

- bin/lintian


Changes:

=
bin/lintian
=
@@ -614,7 +614,7 @@ unless (@ARGV || $selected{'packages-from-file'}) {
 if ($selected{debug}) {
 say {*STDERR} encode_utf8("Lintian v$ENV{LINTIAN_VERSION}");
 say {*STDERR} encode_utf8("Lintian root directory: $ENV{LINTIAN_BASE}");
-say {*STDERR} encode_utf8("Configuration file: $LINTIAN_CFG");
+say {*STDERR} encode_utf8('Configuration file: '.($LINTIAN_CFG//'(none)'));
 }
 
 if (defined $selected{LINTIAN_PROFILE}) {



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/f03fc15a45df4965e374b1e3a40c51cf6fe545ed

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/f03fc15a45df4965e374b1e3a40c51cf6fe545ed
You're receiving this email because of your account on salsa.debian.org.

Bug#1030991: lintian: checking intel-mkl takes 18 hours

2023-02-26 Thread Axel Beckert

Control: tag -1 + confirmed

Hi Andreas,

Andreas Beckmann wrote:
> Checking intel-mkl (pre-built binaries in non-free) with lintian is very
> slow. A full build (i.e. source+all+any) on amd64 takes nearly 18 hours
> to check with
>   lintian -i -E -L ">=pedantic" -v intel-mkl_2020.4.304-4_amd64.changes
> on my local machine (8 cores, 64 GB, tmpfs on /tmp, storage on nvme).

Thanks for that bug report. Knowing such examples to test is always
good to know. Performance is one thing we managed to get much better
in the past ¾ year or so, especially thanks to Bastien. But there is
obviously (and not only known since this bug report) place for
improvement. :-)

> I don't know where all the time is spent ...

Well, 549 MB of source package... :-)

I'll check if --perf-debug brings up anything helpful. Well, yes, but
I would have gathered that otherwise, too:

Warning in processable ../libmkl-threading-dev_2020.4.304-4_amd64.deb:
MLDBM error: Second level tie failed, "No space left on device" at
/usr/share/perl5/MLDBM.pm line 144.

So, new try.

>From the output I already see that these checks took quite a while
(that's where output stopped for quite a while:

Running check: debian/control/field/rules-requires-root on 
source:intel-mkl_2020.4.304-4  ...

Running check: documentation/manual on 
binary:libmkl-meta-threading_2020.4.304-4_amd64  ...

Anyway, will wait what I get at the end. Everything with "done (0."
can be ignored. :-)

Anyway, tagging as confirmed as I can already see now that it will
take a while. :-)

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1031859: false positive of embedded expat library leads to ftp-master rejection

2023-02-26 Thread Axel Beckert

Control: severity -1 minor

Hi Matthias,

Matthias Klose wrote:
> > > The packages are confiured --with-system-expat, and all have proper 
> > > dependencies
> > > on libexpat1.
> > > 
> > > The same bogus messages can be found for python3.11 at
> > > https://udd.debian.org/lintian/?packages=python3.11
> 
> yes, see https://github.com/python/cpython/blob/main/Modules/pyexpat.c

Thanks for that hint. So Python upstream copied a bunch of error
messages verbatim from libexpat since Python 3.11. 奈 (I verified that
this got added in 3.11 and that 3.10.0 and 3.10.10 doesn't emit these
tags.)

So this means that this test works as it should and detected that fact.

In that case:

1) this is by no means an RC-critical as it only affects a single
   package (well, actually pypy, too, probably for similar reasons)
   and does not mean that the check itself is broken. In contrary!

   Hence downgrading the severity to minor, as there's a small chance
   that we can find an libexpat string that the Python upstream devs
   haven't copied verbatim into their code. 郎

   (If we don't find one occasionally, I will close this bug report as
   wontfix.)

2) You should just add a lintian override as this is a very special
   circumstance only appearing in two python-related packages and
   nowhere else and the cause is a very weird behaviour of the
   upstream developers.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#858039: lintian | Make SVG graphs more understandable by adding the tag name. (!455)

2023-02-06 Thread Axel Beckert

Hi Brian,

Brian Thompson (@brianrobt) wrote:
> Make SVG graphs more understandable by adding the tag name.
>
> Fix for #858039.

Thanks a lot for your contribution! Had to look into the bug report to
see that this actually was my own feature request from many years ago.
:-)

Unfortunately the code for the lintian.debian.org website has been
rewritten completely since then (by a Lintian maintainer after Niels
who replied back then) and the current website doesn't seem to sport
these SVGs anymore. At least I couldn't find them.

Additionally generating the website broke under the previous
generation of Lintian maintainers and nobody of the current generation
(including myself) knows how it works or how to even access it.

Fixing the lintian.debian.org website is on our TODO list, but only
with lower priority for after the Bookworm release (or at only after
it is frozen enough so that we can focus on other things).

It's also not high priority because we have
https://udd.debian.org/lintian/ as slower (because non-static)
replacement for the most pressing up-to-date statistics about lintian
tags and packages.

Because of all that and because of we're in the first stage of the
freeze for Bookworm, I'll though merge your merge request only after
the Bookworm release as it does not bring any advantage for Lintian in
Bookworm.

(And yes, I'll merge it even though the feature is not used as of now.
I still have hope that we can bring it back. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1030586: lintian: Testsuite failure on some systems: 1h time offset in test ancient-source

2023-02-05 Thread Axel Beckert

Hi Russ,

Russ Allbery wrote:
> > # -ancient-source (source): unpack-message-for-source tar: 
> > ancient-source-1.0/README: implausibly old time stamp 1969-12-31 23:59:59
> > # +ancient-source (source): unpack-message-for-source tar: 
> > ancient-source-1.0/README: implausibly old time stamp 1970-01-01 00:59:59
> 
> The exactly one hour difference makes me suspicious something is going on
> with time zone conversions.  That's also consistent with the one hour time
> difference between UTC and Europe/Zurich at New Years.
> 
> Looking at the source of tar, the output timestamp for this error seems to
> be in local time by default, which would certainly explain the problem but
> not why we're not seeing it everywhere.  I would be curious if it went
> away if you added --utc to the flags to tar in
> Lintian::IO::Select::unpack_and_index_piped_tar

Nice idea! Will definitely try.

> or (bigger hammer) just set TZ=UTC when running Lintian.

I tried with TZ=GMT. I also tried TZ=UTC, but that had no effect. I
think you need to use TZ=Etc/UTC there instead.

> Lintian should probably force all output it controls to UTC for
> reproducibility, including tar's, but I'm still mystified as to why it
> works on the other system.  This part of tar doesn't seem to have changed,
> and as you mentioned replacing tar didn't change anything.

Exactly. All of that. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1030586: lintian: Testsuite failure on some systems: 1h time offset in test ancient-source

2023-02-05 Thread Axel Beckert

Hi Vagrant,

Vagrant Cascadian wrote:
> On 2023-02-05, Axel Beckert wrote:
> > While running Lintian's testsuite on a much faster system compared to
> > my Sid amd64 running development workstation, I noticed the following
> > test suite failure when running "private/runtests" or trying to build
> > the package on a more modern and more performant box with Bookworm
> > amd64. (Use "private/runtests -o test:ancient-source" to just run the
> > affected test.)
> >
> > # Hints do not match
> > # 
> > # --- 
> > debian/test-out/eval/checks/unpack/ancient-source/hints.specified.calibrated
> > # +++ debian/test-out/eval/checks/unpack/ancient-source/hints.actual.parsed
> > # -ancient-source (source): unpack-message-for-source tar: 
> > ancient-source-1.0/README: implausibly old time stamp 1969-12-31 23:59:59
> > # +ancient-source (source): unpack-message-for-source tar: 
> > ancient-source-1.0/README: implausibly old time stamp 1970-01-01 00:59:59
> 
> Wild guess would be timezone differences between the build
> environments?

Yeah, that's what I looked for first, but both boxes have
"Europe/Zurich" as timezone and prepending "env TZ=GMT" didn't make a
difference on either side.

Thanks for caring nevertheless!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1030586: lintian: Testsuite failure on some systems: 1h time offset in test ancient-source

2023-02-05 Thread Axel Beckert

Package: lintian
Version: 2.116.3
Severity: important
Tags: ftbfs

While running Lintian's testsuite on a much faster system compared to
my Sid amd64 running development workstation, I noticed the following
test suite failure when running "private/runtests" or trying to build
the package on a more modern and more performant box with Bookworm
amd64. (Use "private/runtests -o test:ancient-source" to just run the
affected test.)

# Hints do not match
# 
# --- 
debian/test-out/eval/checks/unpack/ancient-source/hints.specified.calibrated
# +++ debian/test-out/eval/checks/unpack/ancient-source/hints.actual.parsed
# -ancient-source (source): unpack-message-for-source tar: 
ancient-source-1.0/README: implausibly old time stamp 1969-12-31 23:59:59
# +ancient-source (source): unpack-message-for-source tar: 
ancient-source-1.0/README: implausibly old time stamp 1970-01-01 00:59:59
# 
debian/test-out/eval/checks/unpack/ancient-source/generic.t .. 1/1 #   Failed 
test 'Lintian passes for ancient-source'
#   at /home/abe/debian/lintian/lib/Test/Lintian/Run.pm line 343.
# Looks like you failed 1 test of 1.

But I neither get that failure on my Sid amd64 development workstation
nor on SalsaCI (https://salsa.debian.org/lintian/lintian/-/pipelines)
nor in pbuilder nor on the buildd
(https://buildd.debian.org/status/package.php?p=lintian).

So I tried to find differences.

$ als 
debian/test-out/packages/checks/unpack/ancient-source/ancient-source_1.0.orig.tar.gz
 ancient-source-1.0/README
-rw-r--r-- root/root21 1970-01-01 00:59 ancient-source-1.0/README
$ env TZ=GMT als 
debian/test-out/packages/checks/unpack/ancient-source/ancient-source_1.0.orig.tar.gz
 ancient-source-1.0/README
-rw-r--r-- root/root21 1969-12-31 23:59 ancient-source-1.0/README

But these two outputs are identical on both hosts, the one where the
test fails and one of those where it doesn't fail.  So the timestamp
actually seems to be the same and it's just Lintian's parsing of it
seems to differ.

The only potentially relevant package version difference I found was
tar, which is at 1.34+dfsg-1.1 in Sid and 1.34+dfsg-1 in Bookworm due
to a recent FTBFS on 32-bit architectures. But the sole change was in
debian/copyright and also downgrading the tar version in Sid to the
one from Bookworm didn't make the test failing on Sid.

Also running the test suite with "env TZ=GMT" prepended didn't make a
difference.

Additionally, build 2.116.2 did work on that very same box where
2.116.3 now FTBFS. So it seems to have caused been a recent change
(since 2023-01-29) in Bookworm. Or maybe such a change just uncovered
an older bug.

The locales of two systems where it builds and where it no more
builds:

Builds fine:

LANG=C.UTF-8
LANGUAGE=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=

No more builds fine (but hasn't change since when it still built
fine):

LANG=C
LANGUAGE=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=

Also both systems have "Europe/Zurich" in their /etc/timezone.

So I currently have no idea where the difference comes from or which
environmental change (variables or package versions) triggers
it. Cc'ing the Reproducible Builds project in the hope that they have
an idea what could have caused the 1h offset in the testsuite on that
one box.

Bug report written on the system where the test failed.

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

Kernel: Linux 6.1.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.40-2
ii  bzip2   1.0.8-5+b1
ii  clzip [lzip-decompressor]   1.13-5
ii  diffstat1.65-1
ii  dpkg1.21.19
ii  dpkg-dev1.21.19
ii  file1:5.44-3
ii  gettext 0.21-10
ii  gpg 2.2.40-1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.12.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii

Bug#1013417: lintian: dkms updates

2023-02-05 Thread Axel Beckert

Hi Andreas,

Andreas Beckmann wrote:
> attached is a patch that fixes the lintian warning about a missing
> dh-dkms dependency for using dh_dkms.

Applied without the (IMHO bogus) debian/changelog changes as
https://salsa.debian.org/lintian/lintian/-/commit/d50a732a00a7596d078a9e8f6919cb6362ca0067

> I'm not closing this bug since it does not address the
> autopkgtest-pkg-dkms recommendation.

Ok. I've allowed myself to nevertheless add a reference to this bug
report as "(See #1013417)" in a way that it will also show up in the
later generated debian/changelog entry.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

[Git][lintian/lintian][master] 2 commits: Post-release version bump

2023-02-05 Thread Axel Beckert (@abe)



Axel Beckert pushed to branch master at lintian / lintian


Commits:
1e177f85 by Axel Beckert at 2023-02-05T11:30:30+01:00
Post-release version bump

Gbp-Dch: Ignore

- - - - -
d50a732a by Andreas Beckmann at 2023-02-05T11:37:36+01:00
dh_dkms is now provided by dh-dkms instead of dkms

(See #1013417)

Gbp-Dch: Full

- - - - -


2 changed files:

- debian/changelog
- lib/Lintian/Check/Debhelper.pm


Changes:

=
debian/changelog
=
@@ -1,3 +1,9 @@
+lintian (2.116.4~git) UNRELEASED; urgency=medium
+
+  * WIP (generated at release time: please do not add entries below.)
+
+ -- Axel Beckert   Sun, 05 Feb 2023 11:30:30 +0100
+
 lintian (2.116.3) unstable; urgency=medium
 
   The "FFP3 (Fixing False Positives, Three Small Changes)" Release.


=
lib/Lintian/Check/Debhelper.pm
=
@@ -81,7 +81,7 @@ my %DH_COMMAND_MANUAL_PREREQUISITES = (
 'dh-autoreconf:any | debhelper:any (>= 9.20160403~) | debhelper-compat:any',
 dh_autoreconf =>
 'dh-autoreconf:any | debhelper:any (>= 9.20160403~) | debhelper-compat:any',
-dh_dkms => 'dkms:any | dh-sequence-dkms:any',
+dh_dkms => 'dh-dkms:any | dh-sequence-dkms:any',
 dh_girepository => 'gobject-introspection:any | dh-sequence-gir:any',
 dh_gnome => 'gnome-pkg-tools:any | dh-sequence-gnome:any',
 dh_gnome_clean => 'gnome-pkg-tools:any | dh-sequence-gnome:any',



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/cac78dd88e1171e88ee8c3d6f5b1155b8081863d...d50a732a00a7596d078a9e8f6919cb6362ca0067

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/cac78dd88e1171e88ee8c3d6f5b1155b8081863d...d50a732a00a7596d078a9e8f6919cb6362ca0067
You're receiving this email because of your account on salsa.debian.org.

Bug#1030325: lintian: archive-liberty-mismatch (in section for firmware-nvidia-gsp) non-free-firmware vs non-free

2023-02-05 Thread Axel Beckert

Hi Andreas,

Andreas Beckmann wrote:
> > And then release Lintian 2.116.3.
> 
> Please include the dkms patch (see other bug), too.

Sorry, just like 10 minutes too late and I indeed forgot to include it
that one today. Meh.

But there might be a 2.116.4 as I ran into a test suite failure on a
Bookworm system which seems new (as the test suite ran their fine a
week ago or so) and which I currently neither see on autokpkgtest nor
my Sid system nor in pbuilder (2.116.3 built fine there). And it's a
part of Lintian which hasn't been touched recently, so it looks like
being something the Reproducible Build team might find.

I just didn't want to wait further with the upload. :-/ I'm currently in
the release early, release often mode, at least for Lintian. ;-)

Anyway, will probably file a bug report about that non-reproducible
test suite failure soon if I can't find the cause for it:

-ancient-source (source): unpack-message-for-source tar: 
ancient-source-1.0/README: implausibly old time stamp 1969-12-31 23:59:59
+ancient-source (source): unpack-message-for-source tar: 
ancient-source-1.0/README: implausibly old time stamp 1970-01-01 00:59:59

But:

$ env TZ=GMT als 
debian/test-out/packages/checks/unpack/ancient-source/ancient-source_1.0.orig.tar.gz
 ancient-source-1.0/README
-rw-r--r-- root/root21 1969-12-31 23:59 ancient-source-1.0/README

Both hosts have the same timezone (Europe/Zurich aka CET aka GMT+0100)
and one has the "C.UTF-8" locale and the other one (the one which
fails) has "C" locale.

No other difference found so far, except tar which currently doesn't
migrate to testing due to FTBFS on 32-bit architectures. But
downgrading tar on the Sid box didn't make it start failing the test,
so that's not the cause.

Also prepending env TZ=GMT to any command didn't help to get the same
result either.

> On 05/02/2023 06.47, Axel Beckert wrote:
> > Unfortunately firmware-nvidia-gsp/nvidia-graphics-drivers is rather
> > large and I ran out of disk space when first unpacking it in my home
> 
> Then you should try src:nvidia-cuda-toolkit ;-) Lintian needs 3-4 hours and
> about 50GB in /tmp to process a binary build. On nvme.

Ouch. :-)

> I'll probably come back with a bug report about lintian crashing (after a
> few hours) when processing cuda 12 (but first need to check with the latest
> lintian version again and also check that there was enough free space in
> /tmp)

Yes, please do. We managed to get improvements after such bug reports
with src:linux, PostgreSQL and the Firefox packages. It's always good
to have real-life examples of such issues. (And these are the type of
issues you don't test in test suites. ;-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

[Git][lintian/lintian] Pushed new tag 2.116.3

2023-02-05 Thread Axel Beckert (@abe)



Axel Beckert pushed new tag 2.116.3 at lintian / lintian

-- 
View it on GitLab: https://salsa.debian.org/lintian/lintian/-/tree/2.116.3
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] Release and upload as 2.116.3 to unstable

2023-02-05 Thread Axel Beckert (@abe)



Axel Beckert pushed to branch master at lintian / lintian


Commits:
cac78dd8 by Axel Beckert at 2023-02-05T10:29:00+01:00
Release and upload as 2.116.3 to unstable

- - - - -


1 changed file:

- debian/changelog


Changes:

=
debian/changelog
=
@@ -1,8 +1,19 @@
-lintian (2.116.3~git) UNRELEASED; urgency=medium
+lintian (2.116.3) unstable; urgency=medium
 
-  * WIP (generated at release time: please do not add entries below.)
+  The "FFP3 (Fixing False Positives, Three Small Changes)" Release.
 
- -- Axel Beckert   Sun, 29 Jan 2023 16:34:44 +0100
+  [ Axel Beckert ]
+  * Refresh data. (Loong64 removed from two lists, some fonts and dh_cruft
+added.)
+
+  [ Simon McVittie ]
+  * obsolete-packages: libegl1-mesa-dev is not obsolete.
+
+  [ Andreas Beckmann ]
+  * archive-liberty-mismatch: Add exception for 'non-free-firmware binary
+package build from non-free source package'. (Closes: #1030325)
+
+ -- Axel Beckert   Sun, 05 Feb 2023 09:10:20 +0100
 
 lintian (2.116.2) unstable; urgency=medium
 



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/cac78dd88e1171e88ee8c3d6f5b1155b8081863d

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/cac78dd88e1171e88ee8c3d6f5b1155b8081863d
You're receiving this email because of your account on salsa.debian.org.

Bug#1030325: lintian: archive-liberty-mismatch (in section for firmware-nvidia-gsp) non-free-firmware vs non-free

2023-02-04 Thread Axel Beckert

Hi,

there are two variants in which this tag is emitted, with different
parameters:

One is

  archive-liberty-mismatch (in section for $installable) $area1 vs $area2 
[$path]

The other one is:

  archive-liberty-mismatch (in source paragraph) $area1 -> $area2 [$path]

Kibi's patch patches the second variant and Andreas' patch patches the
first variant — which was also the one emitted by running Lintian
against his package.

So it makes sense that Kibi's patch didn't fix Andreas' false
positive. Nevertheless Kibi found a likely problematic part of the
code.

Axel Beckert wrote:
> > changing this:
> > for my $inferior_liberty ('non-free', 'contrib') {
> > into this:
> > for my $inferior_liberty ('non-free-firmware', 'non-free', 'contrib') {
> […]
> > # must remain inferior
> > last
> >   if $inferior_liberty eq $source_liberty;
> 
> Thanks for that analysis. I suspect this type of change is probably
> necessary. Will have a closer look at it.

I must admit, I'm not sure what the check emitting the second variant
(and patched with Kibi's patch) actually does check for. (I have a vague
idea, but that's it.)

And unfortunately I don't find any example for it I could test it
against. Both, lintian's test suite as well as (the in this case
luckily outdated
https://lintian.debian.org/tags/archive-liberty-mismatch only know
examples of the first type. And
https://udd.debian.org/lintian-tag.cgi?tag=archive-liberty-mismatch
doesn't report any anymore. (Probably doesn't check non-free packages.
Or lags a bit behind.)

So I tried to figure out when this got added and to see if there's an
accompaning bug report:

Figured out that tag got renamed twice and wasn't mentioned in
debian/changelog by its name upon its introduction. Which didn't make
searching for that bug report easier.

So I tried git log and git blame. That ended quickly at a commit with
the commit message "Split the check debian/control into 26 smaller
checks.". And then "Move all checks into the module name space under
./lib". And then "Capitalize module names for checks in camel case;
drop underscores." And then "Move check control-file to
'debian/control'." And then "checks: Rename all checks to include a
".pm" extension". *sigh*

At that point I at least reached the commit which renamed the tag for
the first time: d431e568dc33b6f862466218908d337fff43626b from 2009.
>From there on searching through "git -log -p -- checks/control-file"
helped.

There seemed to be no bug report associated, the tag has been
introduced by Russ in commit
204fbd7b78a95e4d940ee1eea647fe365ccaaa4f in 2006. But back then the
code looks very different and only seems to check binary packages.

So I ended up following every change in that tag with

  git log -p -- lib/Lintian/Check/Archive/Liberty/Mismatch.pm 
lib/Lintian/Check/Debian/Control.pm checks/Debian/Control.pm 
checks/debian/control.pm checks/control-file.pm checks/control-file

The first commit which added a second variant checking source against
binary packages is 2e83812c19e1466bc05e65bb3fa52b33e33305e8 by Ivo De
Decker from 2019, i.e. rather recently:

Check for sources in the "main" section with only binaries in the contrib 
section. (Closes: #928126)

But that code is still very clear and readable. And its obvious what
it does.

So actually the commit that changed the code to become way more
convoluted and unreadable was this one:

  commit 1edef669729b04bc67d480b81568dfa8e5e3ae0f
  Author: Felix Lechner 
  Date:   Mon Nov 1 05:03:13 2021 -0700

Split the check debian/control into 26 smaller checks.

Gbp-Dch: ignore

Yes, this one. Took me a few attempts to realize, too. And no, it
didn't just split up code. It basically rewrote the check so much
(maybe even from scratch?) that I can't really recognize which part of
the new code resembles what part in the old file. Especially that "in
ascending order of liberty" got introduced there.

It also renamed the emitted tag from section-area-mismatch to
archive-liberty-mismatch without even mentioning it the commit
message. 

Not to mention that really inappropriate "Gbp-Dch: ignore" for such a
profound rewrite. 奈

And since there's no test for that variant, I can't even tell if it
still works properly. Not even thinking about changing it without
knowing how to test it.

So I'll keep my fingers of that code shortly before the soft freeze
unless someone gives me an example that either triggers the second
variant of this tag or one that doesn't trigger it, but should.

> > The attached patch does make the error go away by adding an exception for
> > 'non-free-firmware build from non-free' similar to 'contrib built from main'
> 
> > --- /usr/share/lintian/lib/Lintian/Check/Archive/Liberty/Mismatch.pm.orig   
> > 2023-02-03 00:30:29.7828

Bug#1030325: lintian: archive-liberty-mismatch (in section for firmware-nvidia-gsp) non-free-firmware vs non-free

2023-02-04 Thread Axel Beckert

Hi Andreas and Kibi,

Andreas Beckmann wrote:
> while preparing the move of firmware-nvidia-gsp from non-free to
> non-free-firmware I noticed this error from lintian:
> 
> E: nvidia-graphics-drivers source: archive-liberty-mismatch (in section for 
> firmware-nvidia-gsp) non-free-firmware vs non-free [debian/control:106]

Thanks for that bug report! non-free packages alone are seldom enough
so that these checks don't get a chance to be checked for the in the
wild already, and non-free-firmware is even more seldom.

Cyril Brulebois wrote:
> Andreas Beckmann  (2023-02-02):
> > while preparing the move of firmware-nvidia-gsp from non-free to
> > non-free-firmware I noticed this error from lintian:
> > 
> > E: nvidia-graphics-drivers source: archive-liberty-mismatch (in section for 
> > firmware-nvidia-gsp) non-free-firmware vs non-free [debian/control:106]
> 
> Without a deep understanding of concepts or implementation, maybe a
> quick fix would be to consider non-free-firmware of lower liberty than
> non-free

For this implementation it looks like that on a first glance, yes.
Need to dig into this deeper, too, though.

> (even if they really should be considered the same),

I'd even say higher liberty due that infamous GR: There are obviously
people who would accept non-free-firmware on their systems, but not
other non-free packages. So non-free-firmware must be a bit more
"free" than "non-free". ;-P (And yes, in most cases, it's less "free"
than most software in "non-free". That's why I still don't get the
outcome of that GR. But I'm digressing...)

> changing this:
> for my $inferior_liberty ('non-free', 'contrib') {
> into this:
> for my $inferior_liberty ('non-free-firmware', 'non-free', 'contrib') {
[…]
> # must remain inferior
> last
>   if $inferior_liberty eq $source_liberty;

Thanks for that analysis. I suspect this type of change is probably
necessary. Will have a closer look at it.

Andreas Beckmann wrote:
> >  for my $inferior_liberty ('non-free', 'contrib') {
> > into this:
> >  for my $inferior_liberty ('non-free-firmware', 'non-free', 'contrib') {
> 
> That doesn't work for me (but may be needed for other cases).

I suspect the latter, too.

> The attached patch does make the error go away by adding an exception for
> 'non-free-firmware build from non-free' similar to 'contrib built from main'

> --- /usr/share/lintian/lib/Lintian/Check/Archive/Liberty/Mismatch.pm.orig 
> 2023-02-03 00:30:29.782861611 +0100
> +++ /usr/share/lintian/lib/Lintian/Check/Archive/Liberty/Mismatch.pm  
> 2023-02-03 01:02:12.441805855 +0100
> @@ -87,6 +87,9 @@
>  # special exception for contrib built from main
>  next
>if $source_liberty eq 'main' && $installable_liberty eq 'contrib';
> +# and non-free-firmware built from non-free
> +next
> +  if $source_liberty eq 'non-free' && $installable_liberty eq 
> 'non-free-firmware';
>  
>  my $control_item= $self->processable->debian_control->item;
>  my $position = $installable_fields->position('Section');

Thanks for that patch, too. Maybe both are necessary. Will check.

Unfortunately firmware-nvidia-gsp/nvidia-graphics-drivers is rather
large and I ran out of disk space when first unpacking it in my home
directory. Will need to run my checks elsewhere for now. Or buy new
SSDs. %-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1030193: lintian: Overriding for prefer-uscan-symlink is not possible

2023-02-01 Thread Axel Beckert

Control: reassign -1 libregexp-wildcards-perl 1.05-3
Control: retitle -1 libregexp-wildcards-perl: Does not escape backslash before 
fullstop, but elsewhere
Control: affects -1 lintian
Control: tag -1 upstream

Hi Eriberto,

Joao Eriberto Mota Filho wrote:
> Package: lintian
> Version: 2.116.2
[…]
> After this change[2], lintian said me:
> 
> X: obs-downstream-keyer source: prefer-uscan-symlink filenamemangle 
> s/.*muted..([\d\.]+)..span./@PACKAGE@-$1\.tar\.gz/ [debian/watch:19]
> 
> After I make an override, litian said me:
> 
> W: obs-downstream-keyer source: mismatched-override prefer-uscan-symlink 
> filenamemangle s/.*muted..([\d\.]+)..span./@PACKAGE@-$1\.tar\.gz/ 
> [debian/watch:19] [debian/source/lintian-overrides:4]
> X: obs-downstream-keyer source: prefer-uscan-symlink filenamemangle 
> s/.*muted..([\d\.]+)..span./@PACKAGE@-$1\.tar\.gz/ [debian/watch:19]

Can reproduce if I copy the emitted tag literally into
debian/source/lintian-overrides although it should work as override:

  prefer-uscan-symlink filenamemangle 
s/.*muted..([\d\.]+)..span./@PACKAGE@-$1\.tar\.gz/ [debian/watch:19]

With a bit of debug code (I added "die $re if $glob =~ /file/;" into
lib/Lintian/Utils.pm around line 404) it shows me that the override
was converted into this regular expression:

  filenamemangle 
s\/\..*muted\.\.\(\[\\d\.\]\+\)\.\.span\.\/\@PACKAGE\@\-\$1\.tar\.gz\/ 
\[debian\/watch\:19\]

Looks as expected to me on a first glance, but actually all occurences
of "\." are not properly converted to "\\\." while "\d" is properly
converted to "\\d". I can also reproduce with this minimal reproducer:

  $ perl -MRegexp::Wildcards -E 'my $rw = Regexp::Wildcards->new(type => 
"jokers"); say $rw->convert(q{\.\d})'
  \.\\d

So this actually seems to be a bug in libregexp-wildcards-perl. Hence
reassigning.

> Consequently, is not possible to make an override for
> prefer-uscan-symlink filenamemangle.

Sure it is, just replace all the ugly stuff with an asterisk or omit
all parameters after the tag name. All these overrides work for me:

  prefer-uscan-symlink filenamemangle s/*/ [debian/watch:19]
  prefer-uscan-symlink filenamemangle * [debian/watch:19]
  prefer-uscan-symlink filenamemangle *
  prefer-uscan-symlink

> I think that lintian is interpreting my REGEX.

Yes and no. It interprets only "*" and "?" and these have the same
meaning as with shell wildcards. It's actually the "jokers" mode of
the Perl module Regexp::Wildcards.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

[Git][lintian/lintian][master] Post-release version bump

2023-01-29 Thread Axel Beckert (@abe)



Axel Beckert pushed to branch master at lintian / lintian


Commits:
d59fdac4 by Axel Beckert at 2023-01-29T16:34:44+01:00
Post-release version bump

Gbp-Dch: Ignore

- - - - -


1 changed file:

- debian/changelog


Changes:

=
debian/changelog
=
@@ -1,3 +1,9 @@
+lintian (2.116.3~git) UNRELEASED; urgency=medium
+
+  * WIP (generated at release time: please do not add entries below.)
+
+ -- Axel Beckert   Sun, 29 Jan 2023 16:34:44 +0100
+
 lintian (2.116.2) unstable; urgency=medium
 
   The "FFP2 (Fixing False Positives, too)" Release.



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/d59fdac4686191ad9605fa8a51c9348017b840ab

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/d59fdac4686191ad9605fa8a51c9348017b840ab
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] Release as 2.116.2 and upload to unstable

2023-01-29 Thread Axel Beckert (@abe)



Axel Beckert pushed to branch master at lintian / lintian


Commits:
a89ceb5f by Axel Beckert at 2023-01-29T09:54:24+01:00
Release as 2.116.2 and upload to unstable

- - - - -


1 changed file:

- debian/changelog


Changes:

=
debian/changelog
=
@@ -1,11 +1,61 @@
-lintian (2.116.2~git) UNRELEASED; urgency=medium
+lintian (2.116.2) unstable; urgency=medium
 
+  The "FFP2 (Fixing False Positives, too)" Release.
+
+  [ Axel Beckert ]
   * Add private script to automate post release version bump.
   * Fix typo in previous debian/changelog entry. Thanks Lintian! ;-)
-  ---
-  * WIP (generated at release time: please do not add entries below.)
+  * Mention that #1024039 got closed by 2.116.1 in its changelog entry.
+  * [Testsuite] Check tag files and docs with spellintian. Thanks to
+Sylvestre Ledru for noticing the typos this check now finds.
+  * Fix duplicate words and one more typo found by
+spellintian-textual-content.t.
+  * "currectly" can be a misspelling of "correctly" or "currently"
+  * Fix spellintian false positives found by spellintian-textual-content.t:
++ "these package" followed by a plural, e.g. "these package sections",
++ Double word with closing parenthesis inbetween. (So far only opening
+  parentheses were whitelisted.)
+  * Add testsuite check for missing-pkg-php-tools-addon false positive
+with dh-sequence-phpcomposer. (See MR !438.)
+  * Add testsuite check for a vcs-field-has-unexpected-spaces false
+positive. (See #1023155 and MR !422.)
+  * debian-rules-uses-unnecessary-dh-argument: Also report found and
+minimum dh compat level. Additionally also rephrase tag description to
+no more say "this debhelper compatibility level". Thanks to Anthony
+Fok for making us aware of the issue in MR !451.
+
+  [ Cyril Brulebois ]
+  * Teach the is_non_free attribute about the non-free-firmware section.
+  * Stop checking for Standards-Version for installer-only (i.e. udeb)
+packages. (Closes: #991533)
+
+  [ Andreas Beckmann ]
+  * backports-upload-has-incorrect-version-number: Fix salsaci version
+regexp again.  (Closes: #1024361)
+
+  [ Sylvestre Ledru ]
+  * Fix some typos in the doc.
+
+  [ William Desportes ]
+  * missing-pkg-php-tools-addon: Allow dh-sequence-phpcomposer as
+alternative to pkg-php-tools-addon.
+  * Lintian::Check::Files::SourceMissing: Ignore files in
+debian/missing-sources/. Fixes false positives in source-is-missing,
+source-contains-prebuilt-javascript-object and friends.
+
+  [ Tino Didriksen ]
+  * vcs-field-has-unexpected-spaces: Allow any order of git branch and
+path. (Closes: #1023155) Thanks to Bradford D. Boyle for the bug
+report.
+
+  [ Johannes Schauer Marin Rodrigues ]
+  * Multiarch terminology: Use "qualifier" instead of "acceptor": Update
+tag descriptions of rules-require-build-prerequisite and
+missing-build-depends-for-clean-target-in-debian-rules. Also rename
+method multiarch_acceptor() to multiarch_qualifier() in
+    Lintian::Relation::Predicate.
 
- -- Axel Beckert   Mon, 23 Jan 2023 12:46:07 +0100
+ -- Axel Beckert   Sun, 29 Jan 2023 09:32:16 +0100
 
 lintian (2.116.1) unstable; urgency=medium
 
@@ -27,7 +77,8 @@ lintian (2.116.1) unstable; urgency=medium
   * Don't emit spare-manual-page for binaries in /usr/libexec/.
 (Closes: #1027744)
   * Refresh static data.
-  * data/java/constants: Default is now Java17, versions available up to 
Java21.
+  * data/java/constants: Default is now Java17, versions available up to
+Java21. (Closes: #1024039)
 
   [ Cyril Brulebois ]
   * Add non-free-firmware to known archive areas.



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/a89ceb5f25e5e45d97a7f26c7dd9971a7a1de51d

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/a89ceb5f25e5e45d97a7f26c7dd9971a7a1de51d
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian] Pushed new tag 2.116.2

2023-01-29 Thread Axel Beckert (@abe)



Axel Beckert pushed new tag 2.116.2 at lintian / lintian

-- 
View it on GitLab: https://salsa.debian.org/lintian/lintian/-/tree/2.116.2
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] Lintian::Check::Files::SourceMissing: Ignore files in debian/missing-sources/

2023-01-28 Thread Axel Beckert (@abe)



Axel Beckert pushed to branch master at lintian / lintian


Commits:
81c4d841 by William Desportes at 2023-01-29T00:22:23+01:00
Lintian::Check::Files::SourceMissing: Ignore files in debian/missing-sources/

Fixes false positives in tags source-is-missing,
source-contains-prebuilt-javascript-object and friends.

Gbp-Dch: Full

- - - - -


1 changed file:

- lib/Lintian/Check/Files/SourceMissing.pm


Changes:

=
lib/Lintian/Check/Files/SourceMissing.pm
=
@@ -55,6 +55,9 @@ sub visit_patched_files {
 return
   unless $item->is_file;
 
+return
+  if $item->dirname =~ m{^debian/missing-sources/};
+
 # prebuilt-file or forbidden file type
 $self->pointed_hint('source-contains-prebuilt-wasm-binary', $item->pointer)
   if $item->file_type =~ m{^WebAssembly \s \(wasm\) \s binary \s module}x;



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/81c4d8416161a5e69004d22e8760b2f5d0e0e1e5

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/81c4d8416161a5e69004d22e8760b2f5d0e0e1e5
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] 2 commits: Add testsuite check for missing-pkg-php-tools-addon false positive with...

2023-01-28 Thread Axel Beckert (@abe)



Axel Beckert pushed to branch master at lintian / lintian


Commits:
1a794ba7 by Axel Beckert at 2023-01-28T23:18:17+01:00
Add testsuite check for missing-pkg-php-tools-addon false positive with 
dh-sequence-phpcomposer (see MR !438)

- - - - -
472de40c by William Desportes at 2023-01-28T23:23:58+01:00
missing-pkg-php-tools-addon: Allow dh-sequence-phpcomposer as alternative to 
pkg-php-tools-addon

(perltidy variant of MR !438)

- - - - -


7 changed files:

- lib/Lintian/Check/Languages/Php/Pear.pm
- + 
t/recipes/checks/languages/php/pear/phppear-composerok/build-spec/debian/control.in
- + 
t/recipes/checks/languages/php/pear/phppear-composerok/build-spec/fill-values
- + 
t/recipes/checks/languages/php/pear/phppear-composerok/build-spec/orig/composer.json
- + 
t/recipes/checks/languages/php/pear/phppear-composerok/build-spec/orig/foo.php
- + t/recipes/checks/languages/php/pear/phppear-composerok/eval/desc
- + t/recipes/checks/languages/php/pear/phppear-composerok/eval/hints


Changes:

=
lib/Lintian/Check/Languages/Php/Pear.pm
=
@@ -149,7 +149,8 @@ sub source {
 $self->pointed_hint('composer-package-without-pkg-php-tools-builddep',
 $composer_json->pointer)
   if defined $composer_json
-  && !$build_depends->satisfies('pkg-php-tools')
+  && !($build_depends->satisfies('pkg-php-tools')
+|| $build_depends->satisfies('dh-sequence-phpcomposer'))
   && !defined $package_xml
   && !defined $package2_xml;
 


=
t/recipes/checks/languages/php/pear/phppear-composerok/build-spec/debian/control.in
=
@@ -0,0 +1,20 @@
+Source: [% $source %]
+Priority: optional
+Section: [% $section %]
+Maintainer: [% $author %]
+Standards-Version: [% $standards_version %]
+Build-Depends: [% $build_depends %], dh-sequence-phpcomposer, php-dev, dh-php
+Rules-Requires-Root: no
+
+Package: [% $source %]
+Architecture: [% $package_architecture %]
+Depends: ${misc:Depends}, ${phppear:Debian-Depends}
+Recommends: ${phppear:Debian-Recommends}
+Breaks: ${phppear:Debian-Breaks}
+Description: ${phppear:summary}
+ This is a test package designed to exercise some feature or tag of
+ Lintian.  It is part of the Lintian test suite and may do very odd
+ things.  It should not be installed like a regular package.  It may
+ be an empty package.
+ .
+ ${phppear:description}


=
t/recipes/checks/languages/php/pear/phppear-composerok/build-spec/fill-values
=
@@ -0,0 +1,3 @@
+Testname: phppear-composerok
+Description: Composer phppear tests with dh-sequence-phpcomposer
+Skeleton: upload-non-native


=
t/recipes/checks/languages/php/pear/phppear-composerok/build-spec/orig/composer.json
=
@@ -0,0 +1 @@
+{}


=
t/recipes/checks/languages/php/pear/phppear-composerok/build-spec/orig/foo.php
=


=
t/recipes/checks/languages/php/pear/phppear-composerok/eval/desc
=
@@ -0,0 +1,4 @@
+Testname: phppear-composerok
+Test-Against:
+ missing-pkg-php-tools-addon
+Check: languages/php/pear


=
t/recipes/checks/languages/php/pear/phppear-composerok/eval/hints
=



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/5400667211bf4af86265d579cfe743c7a43cc992...472de40cabc960117f18ca0cb7562840ed36fe18

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/5400667211bf4af86265d579cfe743c7a43cc992...472de40cabc960117f18ca0cb7562840ed36fe18
You're receiving this email because of your account on salsa.debian.org.

Bug#1029479: lintian: reject packages with debmake default description

2023-01-23 Thread Axel Beckert

Control: tag -1 + confirmed

Hi Paul,

Paul Wise wrote:
> yq was just accepted into Debian with a completely bogus description
> that is the default from the debmake automatic package generator.

Right, noticed that, too. Writing a bug report about that was on my
TODO list. So thanks for filing https://bugs.debian.org/1029481 :-)

> Please add a lintian tag and add it to the ftp-master auto-rejects.

Definitely a good addition. No promises that this will be added before
Bookworm, though.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

[Git][lintian/lintian][master] Release and upload as 2.116.1 to unstable

2023-01-23 Thread Axel Beckert (@abe)



Axel Beckert pushed to branch master at lintian / lintian


Commits:
0a783122 by Axel Beckert at 2023-01-23T03:37:24+01:00
Release and upload as 2.116.1 to unstable

- - - - -


1 changed file:

- debian/changelog


Changes:

=
debian/changelog
=
@@ -1,8 +1,34 @@
-lintian (2.116.1~git) UNRELEASED; urgency=medium
+lintian (2.116.1) unstable; urgency=medium
 
-  * WIP (generated at release time: please do not add entries below).
+  The "No More Neglected Autopkgtest Architectures" Release.
 
- -- Axel Beckert   Tue, 17 Jan 2023 08:03:32 +0100
+  [ Axel Beckert ]
+  * bitbucket.org no more supports Mercurial.
+  * [Testsuite] Fix armhf+i386-only test binaries-missing-lfs. Should fix
+autopkgtest on these architectures.
+  * unknown-section description: Factorize explanations to avoid repitions
+as suggested by Cyril Brulebois. (See also below.)
+  * Fix remaining i386 testsuite issues due to missing brackets.
+  * Don't emit inconsistent-appstream-metadata-license with "MIT !=
+Expat". (Closes: #1029055)
+  * Update Lintian User's Manual for pointed hints in tags and overrides.
+Thanks to Soren Stoutner. (Closes: #1029177)
+  * Whitelist Autobuild, Go-Import-Path, and Ruby-Versions from
+unknown-field. (Closes: #1014885)
+  * Don't emit spare-manual-page for binaries in /usr/libexec/.
+(Closes: #1027744)
+  * Refresh static data.
+  * data/java/constants: Default is now Java17, versions available up to 
Java21.
+
+  [ Cyril Brulebois ]
+  * Add non-free-firmware to known archive areas.
+
+  [ William Desportes ]
+  * Fix lintian package-contains-documentation-outside-usr-share-doc
+matches python files and robots.txt. (Closes: #997987, #976636)
+  * Add more typo fixes.
+
+ -- Axel Beckert   Mon, 23 Jan 2023 03:32:04 +0100
 
 lintian (2.116.0) unstable; urgency=medium
 



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/0a783122b55c331290d8d4956447d6b8ce02

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/0a783122b55c331290d8d4956447d6b8ce02
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian] Pushed new tag 2.116.1

2023-01-23 Thread Axel Beckert (@abe)



Axel Beckert pushed new tag 2.116.1 at lintian / lintian

-- 
View it on GitLab: https://salsa.debian.org/lintian/lintian/-/tree/2.116.1
You're receiving this email because of your account on salsa.debian.org.

Bug#1014885: lintian wrongly complains about XS-Go-Import-Path

2023-01-22 Thread Axel Beckert

Control: clone -1 2
Control: retitle -2 lintian: Needs to distinguish between valid field names for 
.dsc files and for debian/control files (with vs without "XS-" prefix)
Control: tag -1 + pending
Control: tag -2 + help

Hi,

Holger Levsen wrote:
> I can confirm this issue for lintian 2.116.0 against src:piuparts
> as it is in git or unstable.

I can confirm as well. Unfortunately this is not as trivial to fix
properly as it seems:

A) Lintian currently doesn't seem to make a difference between the
   fields in the .dsc file and those in the debian/control file. But
   especially these XS-* fields exactly need that differentiation.

B) If I add Autobuild, Go-Import-Path, and Ruby-Versions to
   data/common/source-fields, the test suite shows that then these
   lintian tags would fire although they shouldn't (according to the
   test suite):

   adopted-extended-field (in section for source) XS-Go-Import-Path
   adopted-extended-field (in section for source) XS-Autobuild

So for now I have no idea except for hardcoding these three inside the
source function in lib/Lintian/Check/Fields/Unknown.pm. But this feels
wrong.

This though might lead to false negatives if someone uses e.g.
Go-Import-Path without the "XS-" prefix in debian/control.

What would be worse: The current false positives or the potential
false negatives?

I assume that any potential false negative on these
three fields will cause package breakage at build time (wrong Ruby
versions, some Go stuff not working, non-free packages not
autobuilding, etc.), so that we can cope with them.

Cloning this bug report to document that we need a rewrite of
Lintian::Check::Fields::Unknown and module dependencies to distinguish
between .dsc fields and debian/control fields with a common subset.
And maybe with the one set being calculated from the other set by
stripping the XS- prefix.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1007002: Update Documentation

2023-01-18 Thread Axel Beckert

Control: clone -1 -2
Control: retitle -2 lintian: Update Lintian User's Manual wrt. to Pointed Hints 
format
Control: tags -2 - wontfix + confirmed

Hi Soren,

Soren Stoutner wrote:
> It would probably be helpful to update the documentation at 
> https://lintian.debian.org/manual/index.html#format-of-override-files[1] to 
> describe the new pointed hints format.

Indeed. We though have the issue that lintian.debian.org no more
updates. It's future is unclear, unfortunately. I do not have access
there. :-/

And it's also not yet my focus currently. After the freeeze maybe.

But I'll at least try to update doc/lintian.rst so that at least the
content is ready once we can update the website again.

This is also related to https://bugs.debian.org/1004234 (docs: give
advice how to debug overrides).

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1029055: Debian Expat and SPDX MIT License Text

2023-01-18 Thread Axel Beckert

Control: tag -1 + confirmed - moreinfo

Hi,

Richard Fontana wrote:
> > Just the point of what the meaning of _text colors_
> > *rollingeyes* in a license do mean. I just ignored them and then those
> > two licenses differ.
> >
> > > as to if the Debian MIT (Expat) License is
> > > the same as the SPDX MIT License.
> > […]
> > > Can somebody at Debian Legal please comment?
> >
> > Yes, thanks! I'd prefer to have a good explanation, too.
> >
> > Please also note that I didn't mark the bug report as wontfix, just as
> > moreinfo.
> 
> The SPDX definition of "MIT" is given in
> https://github.com/spdx/license-list-XML/blob/main/src/MIT.xml

Thanks a lot. The fact that what is blue in the rendering is caused
by an XML tag called  explains well its meaning

> Based on a lot of experience now, you really have to consult the XML
> files rather than rely on the convenience publication of license texts
> at https://spdx.org/licenses

Seems so. Wasn't aware of them either.

> Based on that, and https://www.debian.org/legal/licenses/mit, and
> https://spdx.github.io/spdx-spec/v2.3/license-matching-guidelines-and-templates/
> 
> I think the answer is that what Debian calls "MIT (Expat)" on that
> page matches what SPDX calls "MIT"

Ok. What I take away is that Debian's "MIT License (Expat)" is the
same as SPDX's "MIT License" without the optional parts.

> (I don't think they are "the same" because the underlying concepts
> of what a license is and so forth are not the same).

Interesting. But I don't want to go into that rabbit hole. :-)_

Soren Stoutner wrote:
> Thanks Richard.  I was unaware of the XML versions.

Me too.

> So, this would mean that SPDX considers what Debian calls the MIT (Expat) 
> license to match what SPDX calls MIT because the differences are all either 
> considered by SPDX to be omittable

Yes.

> or replaceable

Not really. :-)

> as demonstrated by the tags in the XML file and the text colors in
> the HTML version.

Yep, that XML version really helped to understand the semantics of the
colors in SPDX's HTML rendering.

But even if they're still not the same as such, it indeed makes no
sense that Lintian argues about them being different. So I'll fix this
bug report with the next upload. (Which likely happens once Lintian 2.116.0
has migrated to Testing.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

[Git][lintian/lintian][master] Fix a boolean precedence issue in the additional condition of MR !442

2023-01-18 Thread Axel Beckert (@abe)



Axel Beckert pushed to branch master at lintian / lintian


Commits:
438a8252 by Axel Beckert at 2023-01-18T12:18:48+01:00
Fix a boolean precedence issue in the additional condition of MR !442

Gbp-Dch: Ignore

- - - - -


1 changed file:

- lib/Lintian/Check/Documentation.pm


Changes:

=
lib/Lintian/Check/Documentation.pm
=
@@ -124,8 +124,8 @@ sub visit_installed_files {
   =~ m{^ usr/share/doc/ (?:.+/)? (?:doxygen|html) / .* [.]map [.] $regex 
}sx;
 
 if ($item->is_file
-&& any { $item->basename =~ m{$_}xi } @DOCUMENTATION_FILE_REGEXES
-&& any { $item->basename !~ m{$_}xi } @NOT_DOCUMENTATION_FILE_REGEXES) 
{
+and any { $item->basename =~ m{$_}xi } @DOCUMENTATION_FILE_REGEXES
+and any { $item->basename !~ m{$_}xi } 
@NOT_DOCUMENTATION_FILE_REGEXES) {
 
 $self->pointed_hint(
 'package-contains-documentation-outside-usr-share-doc',



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/438a82523dc66c765d356df4205dff90647d63ea

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/438a82523dc66c765d356df4205dff90647d63ea
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] bitbucket.org no more supports Mercurial



Axel Beckert pushed to branch master at lintian / lintian


Commits:
78d9ec4f by Axel Beckert at 2023-01-17T08:06:55+01:00
bitbucket.org no more supports Mercurial

https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket

- - - - -


1 changed file:

- data/fields/vcs-hosters


Changes:

=
data/fields/vcs-hosters
=
@@ -28,4 +28,4 @@ git://gitorious\.org/ ~~ Git
 git://[a-zA-Z0-9]+\.branchable\.com/   ~~ Git
 git://repo\.or\.cz/~~ Git
 https?://repo\.or\.cz/ ~~ Git
-https?://bitbucket\.org/   ~~ Git,Hg
+https?://bitbucket\.org/   ~~ Git



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/78d9ec4f37cc61125c9ad2b694b04512010700e2

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/78d9ec4f37cc61125c9ad2b694b04512010700e2
You're receiving this email because of your account on salsa.debian.org.

Bug#1029055: Debian Expat and SPDX MIT License Text

2023-01-16 Thread Axel Beckert

Hi,

Soren Stoutner wrote:
> There appears to be some question of opinion

Not opinion. Just the point of what the meaning of _text colors_
*rollingeyes* in a license do mean. I just ignored them and then those
two licenses differ.

> as to if the Debian MIT (Expat) License is 
> the same as the SPDX MIT License.
[…]
> Can somebody at Debian Legal please comment?

Yes, thanks! I'd prefer to have a good explanation, too.

Please also note that I didn't mark the bug report as wontfix, just as
moreinfo.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

[Git][lintian/lintian] Pushed new tag 2.116.0



Axel Beckert pushed new tag 2.116.0 at lintian / lintian

-- 
View it on GitLab: https://salsa.debian.org/lintian/lintian/-/tree/2.116.0
You're receiving this email because of your account on salsa.debian.org.

Bug#1029055: MIT License Text

2023-01-16 Thread Axel Beckert

Axel Beckert wrote:
> As mentioned before exactly that exception is the reason why I think
> that these two license texts are not the same. I though see no
> explanation what the meaning of the colors on the SPDX website is.
> Until that is clarified, for me, the two texts clearly differ for me.

And just to state the obvious, this is the wdiff which I made for myself
during our previous discussion in #1002053:

$ dwdiff mit expat
[-MIT License-]

Copyright (c) [- -] {+1998, 1999, 2000 Thai
Open Source Software Center Ltd+}

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice [-(including the
next paragraph)-] shall be included
in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1029055: MIT License Text

2023-01-16 Thread Axel Beckert

Control: tag -1 + moreinfo

Hi,

thanks for the separate bug report.

Soren Stoutner wrote:
> I just noticed that AppStream specifies that their licenses use the text 
> listed by SPDX.
> 
> As the text of the MIT License at https://spdx.org/licenses/MIT.html[1] is 
> the same as the 
> Debian MIT License (Expat) at https://www.debian.org/legal/licenses/mit 
> (except for the 
> instructions in blue),

As mentioned before exactly that exception is the reason why I think
that these two license texts are not the same. I though see no
explanation what the meaning of the colors on the SPDX website is.
Until that is clarified, for me, the two texts clearly differ for me.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

[Git][lintian/lintian][master] 3 commits: debian/control: Bump Standards-Version in Description to 4.6.2



Axel Beckert pushed to branch master at lintian / lintian


Commits:
861bcc1e by Axel Beckert at 2023-01-17T01:53:09+01:00
debian/control: Bump Standards-Version in Description to 4.6.2

Gbp-Dch: Ignore

- - - - -
abf85a66 by Axel Beckert at 2023-01-17T02:15:44+01:00
run-private-scripts.t: Do not run auto-reject-diff as it requires network 
access.

- - - - -
08d50d35 by Axel Beckert at 2023-01-17T02:42:56+01:00
run-private-scripts.t: Skip generate-tag-summary without git

- - - - -


2 changed files:

- debian/control
- t/scripts/run-private-scripts.t


Changes:

=
debian/control
=
@@ -168,4 +168,4 @@ Description: Debian package checker
  compliance with Debian policy. Every Debian maintainer should check packages
  with this tool before uploading them to the archive.
  .
- This version of Lintian is calibrated for Debian Policy version 4.6.1.
+ This version of Lintian is calibrated for Debian Policy version 4.6.2.


=
t/scripts/run-private-scripts.t
=
@@ -24,7 +24,7 @@ use warnings;
 
 use Const::Fast;
 use IPC::Run3;
-use Test::More tests => 3;
+use Test::More tests => 2;
 
 const my $DOT => q{.};
 const my $WAIT_STATUS_SHIFT => 8;
@@ -59,12 +59,15 @@ sub t {
 return;
 }
 
-t('auto-reject-diff', qr/Found \d+ certain/);
-t(
-'generate-tag-summary',
-qr/Assuming commit range to be/,
-qr/^No tags were added or removed$|\A\Z/
-);
+SKIP: {
+skip('Only works with git', 1) unless -x '/usr/bin/git' && -d '.git';
+
+t(
+'generate-tag-summary',
+qr/Assuming commit range to be/,
+qr/^No tags were added or removed$|\A\Z/
+);
+}
 t('latest-policy-version', qr/^(\d+\.){3}/);
 
 done_testing();



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/a3c688e61d78413f3c631a6db720c14f4e6e46b2...08d50d35e7a6481808e9b54f3f3d77d09309a445

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/a3c688e61d78413f3c631a6db720c14f4e6e46b2...08d50d35e7a6481808e9b54f3f3d77d09309a445
You're receiving this email because of your account on salsa.debian.org.

Re: New lintian release?

2023-01-16 Thread Axel Beckert

Hi again,

Axel Beckert wrote:
> Close to doing an upload. So let's check:
> 
> > > 1. it seems "t/scripts/run-private-scripts.t" is broken again?
> […]
> > That error seems to be a real error when calling
> > private/generate-tag-summary. So the error is not in
> > t/scripts/run-private-scripts.t but in private/generate-tag-summary
> > and t/scripts/run-private-scripts.t found that issue. Which is good! 
> > 
> > Not sure which file it can't find, though. On a first glance, only git
> > commands seem to be executed via IPC::Run3 from
> > private/generate-tag-summary, so I assume it can't find "git" — which
> > on the other hand would be very weird.
> > 
> > What output does running "private/generate-tag-summary" shows for you?
> > 
> > Anyway, I've built the package and ran the testsuite several times
> > today locally as well as on Salsa CI and I didn't see this error.
> 
> So I tend to ignore this issue for now. But I'd still be interested in
> what caused this.

Could reproduce it when I tried to build it in pbuilder for the
release. So I have a chance to investigate.

Will look into it now, but this probably means, I won't manage to do
the upload before Tuesday evening (in European timezones).

On the positive side: That means that Salsa CI has time to catch up
with my commit "speed". *rollingeyes*

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1029053: lintian: Should report Vcs-Browser fields pointing to Salsa/Gitlab/Github and ending in .git

2023-01-16 Thread Axel Beckert

Package: lintian
Version: 2.115.4~git
Severity: wishlist

In
https://salsa.debian.org/lintian/lintian/-/merge_requests/390#note_367701
Willian Desportes (X-Debbugs-Cc'ed) suggested to implement the same as
Lintian MR !390 (GitHub and GitLab URLs shouldn't end with .git) also
for Vcs-Browser. With which I agree.

Edward Betts figured out that there are indeed about 1800 packages in
Debian where this tag would be emitted:
https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+Vcs-Browse.*salsa.*git=0

Then again Gitlab (and hence also Salsa) as well as Github do a redirect
to the correct URL if you access these URLs with a browser. So I'd say
at most "Severity: info", maybe even only "Severity: pedantic".

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.40-2
ii  bzip2   1.0.8-5+b1
ii  clzip [lzip-decompressor]   1.13-4
ii  diffstat1.65-1
ii  dpkg1.21.18
ii  dpkg-dev1.21.18
ii  file1:5.44-2
ii  gettext 0.21-10
ii  gpg 2.2.40-1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.12.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1+b1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
ii  libdigest-sha-perl  6.03-1+b1
ii  libdpkg-perl1.21.18
ii  libemail-address-xs-perl1.05-1+b1
ii  libencode-perl  3.19-1+b1
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.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-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+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1+b1
ii  libsereal-encoder-perl  5.001+ds-2
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.28-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.84+ds-1+b1
ii  lunzip [lzip-decompressor]  1.13-4
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.11.2-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-7
ii  plzip [lzip-decompressor]   1.10-4
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  xlunzip [lzip-decompressor] 0.7-6
ii  xz-utils5.4.1-0.0

lintian recommends no packages.

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

-- no debconf information

Bug#1025436: Bug#1022787: Bug#1025436: Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

2023-01-16 Thread Axel Beckert

Hi,

Axel Beckert wrote:
> Aurelien Jarno wrote:
> > Given we got no decision from the MIPS porters before the toolchain
> > freeze, we'll have to live with the executable stack on mips*el for
> > bookworm.
> > 
> > Therefore I believe it's a good idea to disable that tag on mips*el on
> > the lintian side.
> 
> Ok, thanks. Will look into it now.

Fixed in git with this commit, referring to #1025436 and #1022787:

https://salsa.debian.org/lintian/lintian/-/commit/80ec3ca960e73a0717719d1329331f86d387c4ae

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1025436: Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

2023-01-16 Thread Axel Beckert

Hi Aurelien,

your reply is just in time! Because about five minutes ago, I started
to continue working on Lintian for this evening. The plan: Making the
long overdue upload as I fixed the last part of arm64 autopkgtest
failures last night. :-)

Aurelien Jarno wrote:
> Given we got no decision from the MIPS porters before the toolchain
> freeze, we'll have to live with the executable stack on mips*el for
> bookworm.
> 
> Therefore I believe it's a good idea to disable that tag on mips*el on
> the lintian side.

Ok, thanks. Will look into it now.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1002053: lintian: false positive inconsistent-appstream-metadata-license (gpl-2.0+ != gpl-2+)

2023-01-16 Thread Axel Beckert

Hi Soren,

Soren Stoutner wrote:
> On Sunday, January 15, 2023 5:17:10 PM MST Axel Beckert wrote:
> > > Debian, of course, prefers the Expat name as it is more precise.
> > 
> > According to
> > https://wiki.debian.org/Proposals/CopyrightFormat#Differences_between_DEP5_a
> > nd_SPDX SPDX does not have the Expat license. They do have though the "MIT
> > License" (the one and only ;-), so that would imply that they're not the
> > same license.
> 
> Anyone who tells you there is a One And Only MIT License is trolling you.  ;)

Seems as if I should used more smileys on that sentence. Consider
having been trolled by myself. ;-)

> https://en.wikipedia.org/wiki/MIT_License#Ambiguity_and_variants

Or said otherwise: I read exactly that page (and
https://www.gnu.org/licenses/license-list.en.html#Expat) before
sending my reply.

> "The name 'MIT License' is potentially ambiguous.

Yes, but IMHO https://spdx.org/licenses/ managed to get quite a good
list on all the variants including unamigous short names for them.
Except that they miss the "Expat license".

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1027399: lintian: misspelled spelling corrections

2023-01-16 Thread Axel Beckert

Control: tag -1 + pending

Hi Jakub,

Axel Beckert wrote:
> Jakub Wilk wrote:
> > I heard you like spell-checking, so I ran your spell-checker on your
> > spell-checker:
> > 
> >$ grep '^[^#]' /usr/share/lintian/data/spelling/corrections | cut -d '|' 
> > -f3 | sort -u | spellintian | grep -vF '(duplicate word)'
> >ocurrence -> occurrence
> >ocurrences -> occurrences
> >prefered -> preferred
> >transfered -> transferred
> >transfering -> transferring

Fixed. Thanks again.

> > (Maybe worth adding something like the above to the test suite?)

Implemented (before fixing the above to verify that the test works) in
https://salsa.debian.org/lintian/lintian/-/commit/375b9b46b0b16a6f8e75b0f4c3189de59c04eb8b

Implemented via Array::Utils "intersect" function. Had to add a new
build-dependency for that, but oh well.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1025436: Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

2023-01-16 Thread Axel Beckert

Hi,

writing this with my Lintian maintainer hat on. Nearly full quote due
to Cc'ing another bug report and bug reporter:

Aurelien Jarno wrote:
> On 2022-10-26 22:09, Aurelien Jarno wrote:
> > control: tag -1 + moreinfo
> > 
> > On 2022-10-25 21:07, Simon McVittie wrote:
> > > Package: libc6-dev
> > > Version: 2.35-4
> > > Severity: normal
> > > X-Debbugs-Cc: debian-m...@lists.debian.org, lint...@packages.debian.org, 
> > > jrt...@debian.org
> > > User: debian-m...@lists.debian.org
> > > Usertags: mips mipsel
> > > 
> > > All mips*el executables and libraries appear to have an executable stack,
> > > resulting in very large numbers of Lintian warnings, particularly for
> > > packages with many small ELF objects like
> > > <https://udd.debian.org/lintian/?packages=samba>.
> > > 
> > > Jessica Clarke looked into this and found that this is intentionally done
> > > by glibc when targeting minimum kernel 4.8.0 or older with mips hardfloat:
> > > https://github.com/bminor/glibc/blob/595c22ecd8e87a27fd19270ed30fdbae9ad25426/sysdeps/unix/sysv/linux/mips/configure.ac#L138-L143
> > > 
> > > Debian 9 had a kernel newer than 4.8.0, so I think Debian 12 probably
> > > doesn't need to go that far into backwards compatibility? If the mips
> > > porters agree, then glibc on mips*el should stop forcing an executable
> > > stack, either by increasing the minimal kernel version or by patching
> > > this out. That will provide some security hardening on mips*el.
> > 
> > Note that the other official architecture still have a kernel
> > compatibility set to 3.2, so that will make a difference between
> > architectures. There are discussions to increase it upstream, but this
> > won't happened for bookworm. 
> > 
> > > Or, if the mips porters consider this backwards compatibility to be
> > > more important than the security hardening of a non-executable stack,
> > > then Lintian should stop issuing warnings about the executable stack on
> > > mips*el to improve its signal/noise ratio.
> > 
> > At this stage there is nothing that can be done on the glibc side, the
> > decision has to be taken by the mips porters.
> 
> We are getting very close to the toolchain freeze. Any decision about
> that?

JFYI: There is the request to disable this tag completely on MIPS
architectures in https://bugs.debian.org/1025436

Now I wonder if this would actually help or worsen the situation for
the glibc maintainers.

Guillem: You wrote something about "bullseye" in #1025436. I think you
meant "bookworm" instead. Am I right?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1027323: lintian: broken symlink reporting/harness

2023-01-16 Thread Axel Beckert

Control: tag -1 + confirmed pending

Hi Jakub,

Jakub Wilk wrote:
> $ file lintian-2.115.3/reporting/harness
> lintian-2.115.3/reporting/harness: broken symbolic link to ../frontend/dplint

Good find, thanks!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1027399: lintian: misspelled spelling corrections

2023-01-16 Thread Axel Beckert

Control: tag -1 + confirmed

Hi Jakub,

Jakub Wilk wrote:
> I heard you like spell-checking, so I ran your spell-checker on your
> spell-checker:
> 
>$ grep '^[^#]' /usr/share/lintian/data/spelling/corrections | cut -d '|' 
> -f3 | sort -u | spellintian | grep -vF '(duplicate word)'
>ocurrence -> occurrence
>ocurrences -> occurrences
>prefered -> preferred
>transfered -> transferred
>transfering -> transferring

Thanks! This is hilarious. And a great idea!

> (Maybe worth adding something like the above to the test suite?)

Ack.

        Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

[Git][lintian/lintian][master] Fix false positive for license-problem-php-license for pear.php.net source code



Axel Beckert pushed to branch master at lintian / lintian


Commits:
53f5b4d2 by William Desportes at 2023-01-16T02:54:14+00:00
Fix false positive for license-problem-php-license for pear.php.net source code

- - - - -


2 changed files:

- lib/Lintian/Check/Cruft.pm
- tags/l/license-problem-php-license.tag


Changes:

=
lib/Lintian/Check/Cruft.pm
=
@@ -657,7 +657,7 @@ sub php_source_whitelist {
 return 0
   if defined $copyright_path
   && $copyright_path->bytes
-  =~ m{^Source: https?://pecl.php.net/package/.*$}m;
+  =~ m{^Source: https?://(pecl|pear).php.net/package/.*$}m;
 
 return 0
   if $self->processable->source_name =~ /^php\d*(?:\.\d+)?$/xms;


=
tags/l/license-problem-php-license.tag
=
@@ -5,6 +5,6 @@ Explanation: This package appears to be covered by version 3.0 
(exactly) of the
  PHP license. This license is not applicable to anything that is not PHP
  and has no contributions from the PHP Group.
  .
- This tag is not emitted for packages from pecl.php.net as determined by
+ This tag is not emitted for packages from pecl.php.net or pear.php.net as 
determined by
  the Source: field in debian/copyright.
 See-Also: https://ftp-master.debian.org/REJECT-FAQ.html



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/53f5b4d23ae17d7468efe92b999cfb38d8b6c799

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/53f5b4d23ae17d7468efe92b999cfb38d8b6c799
You're receiving this email because of your account on salsa.debian.org.

Re: New lintian release?

2023-01-15 Thread Axel Beckert

Hi,

Axel Beckert wrote:
> Louis-Philippe Véronneau wrote:
> > I feel significant changes have been made on the git HEAD and a new lintian
> > release would be a good idea.
> 
> Definitely. Also because I consider it to be (close to) a toolchain
> package. It's though (luckily ) not on
> https://release.debian.org/testing/essential-and-build-essential.txt

Close to doing an upload. So let's check:

> > 1. it seems "t/scripts/run-private-scripts.t" is broken again?
[…]
> That error seems to be a real error when calling
> private/generate-tag-summary. So the error is not in
> t/scripts/run-private-scripts.t but in private/generate-tag-summary
> and t/scripts/run-private-scripts.t found that issue. Which is good! 
> 
> Not sure which file it can't find, though. On a first glance, only git
> commands seem to be executed via IPC::Run3 from
> private/generate-tag-summary, so I assume it can't find "git" — which
> on the other hand would be very weird.
> 
> What output does running "private/generate-tag-summary" shows for you?
> 
> Anyway, I've built the package and ran the testsuite several times
> today locally as well as on Salsa CI and I didn't see this error.

So I tend to ignore this issue for now. But I'd still be interested in
what caused this.

> > 2. BTS #1026920 should probably fixed before we upload

Fix pending and verified.

> Ok. I wonder if that will really make it for bookworm.

It's at least in unstable since 12th of January. Hence also Salsa CI
autopkgtest failed — once only, then I fixed it. :-)

> IMHO neither of them are a blocker for an upload. I'd rather consider
> that second half of the RC bug #1025868 to be more of a blocker, even
> if not a complete blocker.

Fixed and with it hopefully and finally the whole #1025868. The issue
was actually a false positive on arm64 and a false negative on all
other architecture I tested (amd64, i386, armhf) as the test itself
was broken. I just remove that single test from the test suite. Other
tests for that tag still exist.

> Actually I even think we could upload now as the Salsa CI test stage
> is green again for a few commits, but I first would like to look at
> least through the recently opened bug reports, too.

Done now, depending on what actually counts as "recently". ;-)

> and also do a bit more local testing.

Done, too. Also brought up a few things despite I wasn't actually
searching for them. But running lintian from git HEAD when working on
other packages helped indeed.

> I also assume we will do at least two uploads before the freeze
> anyway, a first big one (2.116.0) and then probably some more minor
> fixups (2.116.1) or so.

Still the plan, despite even closer to the freeze. :-/

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

[Git][lintian/lintian][master] 4 commits: inconsistent-appstream-metadata-license: Versions with trailing ".0" are...

2023-01-15 Thread Axel Beckert (@abe)



Axel Beckert pushed to branch master at lintian / lintian


Commits:
2348bca3 by Axel Beckert at 2023-01-16T01:10:28+01:00
inconsistent-appstream-metadata-license: Versions with trailing .0 
are equivalent to versions without

Fixes false positives as the Debian Copyright Format 1.0 explicitly
states that versions with trailing dot-zeroes are considered to be
equivalent to versions without.

Closes: #1002053

Relevant documentation:
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name

- - - - -
3721f292 by Axel Beckert at 2023-01-16T01:10:39+01:00
inconsistent-appstream-metadata-license: Normalize comparison (-or-later/+, 
-only suffix)

Further normalize comparison of Debian style and SPDX style license
identifiers to -or-later suffix vs + suffix, -only suffix vs no
suffix.

Still display the original variant in the tag.

Relevant documentation/policy:

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name

(Also make new code perltidy.)

- - - - -
e48f1d48 by Axel Beckert at 2023-01-16T01:27:45+01:00
inconsistent-appstream-metadata-license description: Text improvements; direct 
ref to tag specification

Closes: #1014956

- - - - -
bf82908d by Christoph Biedl at 2023-01-16T01:40:03+01:00
Lintian::Index::FileTypes: Call file with --raw to 
unbreak test suite with file/libmagic ≥ 5.42

Closes: #1026920

- - - - -


3 changed files:

- lib/Lintian/Check/Debian/Copyright/Dep5.pm
- lib/Lintian/Index/FileTypes.pm
- tags/i/inconsistent-appstream-metadata-license.tag


Changes:

=
lib/Lintian/Check/Debian/Copyright/Dep5.pm
=
@@ -852,8 +852,30 @@ sub check_dep5_copyright {
 next
   unless $seen;
 
+# Compare and also normalize the seen and wanted license
+# identifier wrt. to redundant trailing dot-zeros,
+# -or-later suffix vs + suffix, -only suffix vs no
+# suffix. Still display the original variant in the tag.
+my $seen_normalized = $seen;
+$seen_normalized =~ s/-or-later$/+/i;
+$seen_normalized =~ s/-only$//i;
+my $seen_nozero = $seen_normalized;
+$seen_nozero =~ s/\.0//g;
+
 my @wanted = @{$license_identifiers_by_file{$name}};
-my @mismatched = grep { $_ ne $seen } @wanted;
+my @mismatched = grep {
+my $want = $_;
+my $want_normalized = $want;
+$want_normalized =~ s/-or-later$/+/i;
+$want_normalized =~ s/-only$//i;
+my $want_nozero = $want_normalized;
+$want_nozero =~ s/\.0//g;
+
+$want_normalized ne $seen_normalized
+  and $want_nozero ne $seen_normalized
+  and $want_normalized ne $seen_nozero
+  and $want_nozero ne $seen_nozero;
+} @wanted;
 
 $self->pointed_hint('inconsistent-appstream-metadata-license',
 $copyright_file->pointer, $name, "($seen != $_)")


=
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;
 


=
tags/i/inconsistent-appstream-metadata-license.tag
=
@@ -2,7 +2,9 @@ Tag: inconsistent-appstream-metadata-license
 Severity: warning
 Check: debian/copyright/dep5
 Explanation: The specified AppStream metadata file specifies a
- metadatalicense field but this does not match the files 
in
+ metadatalicense field but this does not match
+ its entry (possibly via the Files: * stanza) in
  debian/copyright.
 See-Also: https://wiki.debian.org/AppStream/Guidelines,
- https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+ https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/,
+ 
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-metadata_license



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/6bf8452625fb7ebbbad0af23a225557ac146dd99...bf82908d338b9125ed5ba737d50bdfd85f829bee

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/6bf8452625fb7ebbbad0af23a225557ac146dd99...bf82908d338b9125ed5ba737d50bdfd85f829bee
You're receiving this email because of your account on salsa.debian.org.

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

2023-01-15 Thread Axel Beckert

Control: tag -1 + pending

Hi Christoph,

Christoph Biedl wrote:
> 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;

Thanks!

And it seems that --raw option does not only exist since recently, so
we can take that patch without having fear that backports will break.
:-)

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1002053: lintian: false positive inconsistent-appstream-metadata-license (gpl-2.0+ != gpl-2+)

2023-01-15 Thread Axel Beckert

Control: tag -1 + confirmed pending

Hi Nicholas and Soren,

Nicholas D Steeves wrote:
> Gpl-2+ (used in d/copyright) is equivalent to gpl-2.0+ used in
> appstream metadata, so this is a false positive.

Correct, as
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name
(part of the Debian Policy) also states:

»For SPDX compatibility, versions with trailing dot-zeroes are
considered to be equivalent to versions without (e.g., “2.0.0” is
considered equal to “2.0” and “2”).«

> Were GNU to hypothetically release a GPL 2.1, and were upstream to
> switch to it, the onus would be on the Debian maintainer to update
> d/copyright.

Yes, but they'd need to update it in both cases as neither "GPL-2+"
nor "GPL-2.0+" imply "newest version of the GPL 2.x series". :-)

> It also seems wrong to emit this at the warning level for this
> specific case.

Unfortunately the level is hardcoded in the tag. We can't emit a tag
e.g. once at warning and once at pedantic level depending on the found
data. (It also IMHO makes not so much sense semantic-wise.)

> If lintian is encouraging maintainers to use the "gpl-2.0+" notation
> rather than gpl-2+ in d/copyright, then it should emit a different
> (lower severity than warning) tag for that case.

Well, as the Debian Copyright Format Specification 1.0 explicitly
allows both variants, this seems not necessary.

> It seems clear to me that (gpl-2.0+ = gpl-2+), so it looks like the
> correct approach is to use a table of equivalent license notations to
> prevent the false positive.

Yeah, as that list would potentially became rather huge and hard to
maintain, I'd rather use a regexp to filter out such things.

Soren Stoutner wrote:
> The same basic problem also occurs with MIT and Expat licenses.

Ack.

> The specification for the AppStream metadata file only has a few
> options, one of them being MIT and none of them being Expat.

Same for SPDX: Neither https://spdx.org/licenses/ nor
https://spdx.org/licenses/MIT.html mention Expat.

> Debian, of course, prefers the Expat name as it is more precise.

According to
https://wiki.debian.org/Proposals/CopyrightFormat#Differences_between_DEP5_and_SPDX
SPDX does not have the Expat license. They do have though the "MIT
License" (the one and only ;-), so that would imply that they're not
the same license.

And indeed, there are two difference between
https://spdx.org/licenses/MIT.html and
http://www.jclark.com/xml/copying.txt (the Expat license):

* The MIT License starts with a headline "MIT License" (which is
  probably less relevant).

* The MIT License contains the following part in its second paragraph
  which the Expat license doesn't have: "(including the next
  paragraph)". This might make a subtle difference, but IANAL.

> inconsistent-appstream-metadata-license debian/metainfo.xml (mit !=
> expat) [debian/copyright]

So that actually seems a true positive as the licenses differ. They
only differ a bit, but they differ.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1025868: lintian autopkgtest fails on all but amd64: x86_64-linux-gnu expected build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t

2023-01-15 Thread Axel Beckert

lf/usr/bin/calls-sbin
Calling /bin/our-script
Calling /sbin/our-script
Calling /usr/bin/our-script
Calling /usr/sbin/our-script

So the more weird thing is: I think the current test is wrong and the
tag should be emitted three times. But reason for this is not lintian
but the C compiler on amd64. (And in some way the developer who didn't
question the IMHO unexpected outcome and committed what he got into
the test suite.)

The diff between those two outputs of "strings" (amd64 first, arm64
second) are:

c1
< /lib64/ld-linux-x86-64.so.2
---
> /lib/ld-linux-aarch64.so.1
4a5
> abort
6,7c7
< GLIBC_2.2.5
< GLIBC_2.3.4
---
> GLIBC_2.17
12,13c12,14
< PTE1
< u+UH
---
> RB@!
> `B@9@
> /bin/our-script
14a16
> /sbin/our-script
17,18c19
< ;*3$"
< 4032d603fcdab9b3c37bd8c1c7d5883bc724dd.debug
---
> d2b24ab8a4b9b4c8f515cf5be93d20e5f55443.debug
21d21
< .note.gnu.property
32d31
< .plt.got
40a40
> .got

So only two these strings are in the amd64 binary. Using ltrace (not
available for arm64) I got an idea what might have happened here, just
why not on arm64 (but also on armhf):

$ ltrace 
./debian/test-out/packages/checks/files/contents/bin-sbin-confusion-in-elf/bin-sbin-confusion-in-elf-1.0/debian/bin-sbin-confusion-in-elf/usr/bin/calls-sbin
__printf_chk(1, 0x55e617f8e004, 0x55e617f8e014, 0x55e617f8fdc0Calling 
/bin/our-script
) = 24
__printf_chk(1, 0x55e617f8e004, 0x55e617f8e028, 0Calling /sbin/our-script
)  = 25
__printf_chk(1, 0x55e617f8e004, 0x55e617f8e010, 0Calling /usr/bin/our-script
)  = 28
__printf_chk(1, 0x55e617f8e004, 0x55e617f8e024, 0Calling /usr/sbin/our-script
)  = 29
+++ exited (status 0) +++

So looking at the second hex column, the memory addresses of 1st and
3rd row as well as 2nd and 4th row only differ by 4 bytes. Which means
that the compiler figured out that two of the constants are substrings
of the other two constants and optimized them out.

I also remember that Debian (or GCC) has different default compile
time optimization settings per architecture.

So it seems that these substrings get eliminated by jumping directly
into one of the other strings at character position 4.

Hence it is impossible for lintian to find the other two string
occurences. Accordingly this specific test (bin-sbin-confusion-in-elf,
whose expected result obviously was just taken unreflected from
Lintian's output of the amd64 test binary) is broken beyond repair as
it depends on architecture-specific compile time optimization settings
(here: string constants optimization) being applied. And I don't want
to write some heavy obfuscation stuff just so that the compiler can't
optimize it.

So from my point of view, the test in-sbin-confusion-in-elf needs to
be removed from the test suite. Will do after this mail.

This will also fix the second part of this bug report.

(And now I'd like to go back to other Lintian issues which don't
consume hours of debugging time first. Or just do an upload and fix
remaining issues later. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#825222: lintian: please allow debian/source/timestamps in unknown-file-in-debian-source

2023-01-15 Thread Axel Beckert

Control: tag -1 wontfix

Hi,

Abou Al Montacir wrote:
> I recently was interested in solving Lintian errors on FPC and
> friends and got pointed to this ticket.

I just checked
https://codesearch.debian.net/search?q=2022+path%3Adebian%2Fsource%2Ftimestamps=1
and it seems that exactly 2 source packages (fpc and lazarus) are using this.

Just affecting two packages is IMHO a valid case for lintian
overrides.

It's though a small change with practically no chance for false
positives, so I'm no directly opposed to implementing it.

I though wonder: Are more packages expected to use that? I mean, the
initial bug report ist from 2016 and I only see two packages using it.

> I tend to agree with Paul that the timestamps file is better located in
> debian/source folder and would lobby for that.

This seems to be the wrong audience for a discussion about the
location of that file. Such a discussion should come _before_ Lintian is
asked to implement something.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1028975: allegedly, tar warnings are not errors

2023-01-15 Thread Axel Beckert

Hi Marco,

Marco d'Itri wrote:
> tar complains to stderr about features of archives that it does not 
> understand, but the maintainer says that this is all right and consumers 
> of tar's output need to deal with it (see #1028970 for details).

Legit IMHO. Thanks for the bug report.

> How to reproduce:
> 
> $ libcrypt-x509-perl_0.55-1_amd64.changes
> Warning in processable ./libcrypt-x509-perl_0.55-1.dsc: Tried to issue 
> duplicate hint in check unpack: unpack-message-for-source tar: Ignoring 
> unknown extended header keyword 'LIBARCHIVE.xattr.com.apple.lastuseddate#PS'
> E: libcrypt-x509-perl source: unpack-message-for-orig 
> libcrypt-x509-perl_0.55.orig.tar.gz . tar: Ignoring unknown extended header 
> keyword 'LIBARCHIVE.xattr.com.apple.lastuseddate#PS'
> W: libcrypt-x509-perl source: newer-standards-version 4.6.2.0 (current is 
> 4.6.1.0)
> 
> If this is not a real error then maybe it should have pedantic severity 
> instead.

I tend to ignore any tar STDERR output saying "tar: Ignoring" as
solution for this issue. Do you think that should suffice?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1025868: Should we remove bin-sbin-mismatch due to unfixable false positives and being obsolete due to usrmerge?

2023-01-15 Thread Axel Beckert

Hi,

[This mail is a side-effect of trying to fix the remaining part of the
RC bug #1025868 against lintian.]

I'm thinking about retiring the tag bin-sbin-mismatch due difficult to
solve false positive (and currently triggering an RC bug).

It has been introduced in #930702 and sounded like a good idea, but
caused quite some not so trivial to fix issues (if fixable at all),
especially false positives:

* #1017632: false positives on partial matchs — IMHO unfixable.

* #974677: false positive when using variables — probably partially
fixable (i.e. unfixable) by ignoring cases where "}" stands directly
before "/bin/" and maybe where "\$\w+" matches before directly
before "/bin/". But the first will still have some false positives
(being language-dependent and at least in shell and Perl it
additionally requires strict adhering to some coding standards in
the tested package — which is unrealistic).

* zsh: false positives when doing symlinking /bin/zsh and /usr/bin/zsh
in postinst/postrm for non-usrmerge systems instead of shipping them
properly in the package due to the usrmerge mess. (Not reported,
just overridden.)

Additionally it has the following other issues:

* As far as I understand the topic, this tag is obosoleted by the
forced usrmerge migration as those mismatch seem to be no more
relevant since then.

* Order of the output parameters seem to vary per architecture, see
the remaining issue of the current RC bug #1025868 against lintian
(Cc'ed). I think this is related to C compilers/linkers not
generating the same variable order on different architectures, see
the test case which caused the RC bug:

https://salsa.debian.org/lintian/lintian/-/blob/master/t/recipes/checks/files/contents/bin-sbin-confusion-in-elf/build-spec/orig/calls-sbin.c

Paul: Expect an update on the last remaining piece of #1025868 soon.
I have a working arm64 Sid again. armhf and i386 didn't suffice to
reproduce. But I clearly see the problem. :-/

* Misleading tag name, at least without the full tag desc I always
expect that /sbin/$program and /bin/$program are mixed up. There's
no "usr" present in the tag name. A potential better tag name would
be something like bin-usr-bin-mismatch (with sbin being a seldom
special case of it).

Other points which are no issue itself, but make the tag removal
potentially a bit easier, i.e. likely reduce the impact of removal:

* The tag is marked as experimental, i.e. not shown by default.

* The submitter of #930702 (i.e. the feature request submitter)
himself is no more active in Debian. (And he — IMHO unfortunately —
rage-quitted Debian over the systemd controversy, so I doubt that
he's still interested in Debian, let it be alone Lintian. So I did
not Cc him to not bother him with stuff reminding him of Debian.)

And given that other recent tag removal proposals (e.g.
very-long-line-length-in-source-file) lead into objections, also from
my side, I'd like to hear first if there's someone who considers this
tag useful.

Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE

Bug#1028959: lintian: Weird very-long-line-length-in-source-file false positve due no long line in file

2023-01-15 Thread Axel Beckert

Package: lintian
Version: 2.115.3+68commits+git091d167f6
Severity: normal

When running against BackupPC, lintian emits this tag:

X: backuppc source: very-long-line-length-in-source-file 535 > 512 
[lib/BackupPC/CGI/GeneralInfo.pm:52]

But there is no such long line in that file:

$ cat -n lib/BackupPC/CGI/GeneralInfo.pm | egrep '^\s*52\s' | wc -c
77
$ cut -c512- lib/BackupPC/CGI/GeneralInfo.pm | egrep -v '^$'
$ file lib/BackupPC/CGI/GeneralInfo.pm
lib/BackupPC/CGI/GeneralInfo.pm: Perl5 module source, ASCII text
$

So "file" also doesn't mention any long line stuff (which it usually
does, I just don't know its limits).

Line 52 looks like this:

   if ( $Jobs{$host}{type} eq "" && defined($Status{$host}) );

Not yet debugged, so not sure why lintian thinks that this file has any
long line. According to my statistics the two longes lines in there are
two lines which each 99 characters.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.39.90.20230110-1
ii  bzip2   1.0.8-5+b1
ii  clzip [lzip-decompressor]   1.13-4
ii  diffstat1.65-1
ii  dpkg1.21.18
ii  dpkg-dev1.21.18
ii  file1:5.44-1
ii  gettext 0.21-10
ii  gpg 2.2.40-1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.12.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1+b1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
ii  libdigest-sha-perl  6.03-1+b1
ii  libdpkg-perl1.21.18
ii  libemail-address-xs-perl1.05-1+b1
ii  libencode-perl  3.19-1+b1
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.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-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+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1+b1
ii  libsereal-encoder-perl  5.001+ds-2
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.28-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.84+ds-1+b1
ii  lunzip [lzip-decompressor]  1.13-4
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.11.2-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-7
ii  plzip [lzip-decompressor]   1.10-4
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  xlunzip [lzip-decompressor] 0.7-6
ii  xz-utils5.4.1-0.0

lintian recommends no packages.

Versions of packages lintian suggests:
ii

Bug#1028274: lintian: Warning in processable […].dsc: Error open (<) on '[…].orig.tar.gz.asc': No such file or directory at /usr/share/perl5/Path/Tiny.pm line 2419.

2023-01-08 Thread Axel Beckert

Package: lintian
Version: 2.115.3-68-g091d167f6
Severity: important

This issue is slightly related to the issue which made me find #1027949
as it probably also only surfaced when libpath-tiny-perl got bumped from
0.124 to 0.144 which added more pedantic error checking:

When trying to run lintian against a package where it expects an
upstream signature (probably because debian/upstream/signing-key.asc
exists), it started to throw an error message instead of the relevant
tag:

$ lintian /var/cache/pbuilder/result/screen_4.9.0-4_amd64.changes
Warning in processable /var/cache/pbuilder/result/screen_4.9.0-4.dsc: Error 
open (<) on '/var/cache/pbuilder/result/screen_4.9.0.orig.tar.gz.asc': No such 
file or directory at /usr/share/perl5/Path/Tiny.pm line 2419.
Path::Tiny::Error::throw("Path::Tiny::Error", "open (<)", 
"/var/cache/pbuilder/result/screen_4.9.0.orig.tar.gz.asc", "No such file or 
directory") called at /usr/share/perl5/Path/Tiny.pm line 149
Path::Tiny::_throw(Path::Tiny=ARRAY(0x55c284f19458), "open (<)") called 
at /usr/share/perl5/Path/Tiny.pm line 1173
Path::Tiny::filehandle(Path::Tiny=ARRAY(0x55c284f19458), 
HASH(0x55c284f0af68), "<", undef) called at /usr/share/perl5/Path/Tiny.pm line 
2066
Path::Tiny::slurp(Path::Tiny=ARRAY(0x55c284f19458)) called at 
/usr/share/lintian/lib/Lintian/Check/UpstreamSignature.pm line 86

Lintian::Check::UpstreamSignature::source(Lintian::Check::UpstreamSignature=HASH(0x55c284ac1a18))
 called at /usr/share/lintian/bin/../lib/Lintian/Check.pm line 142

Lintian::Check::run(Lintian::Check::UpstreamSignature=HASH(0x55c284ac1a18)) 
called at /usr/share/lintian/bin/../lib/Lintian/Group.pm line 276
eval {...} called at /usr/share/lintian/bin/../lib/Lintian/Group.pm 
line 279
Lintian::Group::process(Lintian::Group=HASH(0x55c27e375b40), 
HASH(0x55c27e38e8d8), HASH(0x55c2808e1298)) called at 
/usr/share/lintian/bin/../lib/Lintian/Pool.pm line 171
Lintian::Pool::process(Lintian::Pool=HASH(0x55c27e39f5b8), 
Lintian::Profile=HASH(0x55c280829c28), SCALAR(0x55c2808f8d40), 
HASH(0x55c2808e1298)) called at /usr/bin/lintian line 757
warning: cannot run upstream-signature check on package source:screen_4.9.0-4
skipping check of source:screen_4.9.0-4
[…]

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils 2.39.90.20230104-1
ii  bzip21.0.8-5+b1
ii  diffstat 1.65-1
ii  dpkg 1.21.17
ii  dpkg-dev 1.21.17
ii  file 1:5.41-4
ii  gettext  0.21-10
ii  gpg  2.2.40-1
ii  intltool-debian  0.35.0+20060710.6
ii  iso-codes4.12.0-1
ii  libapt-pkg-perl  0.1.40+b2
ii  libarchive-zip-perl  1.68-1
ii  libberkeleydb-perl   0.64-2+b1
ii  libcapture-tiny-perl 0.48-2
ii  libclass-xsaccessor-perl 1.19-4+b1
ii  libclone-perl0.46-1
ii  libconfig-tiny-perl  2.28-2
ii  libconst-fast-perl   0.014-2
ii  libcpanel-json-xs-perl   4.32-1+b1
ii  libdata-dpath-perl   0.58-2
ii  libdata-validate-domain-perl 0.10-1.1
ii  libdata-validate-uri-perl0.07-2
ii  libdevel-size-perl   0.83-2+b1
ii  libdigest-sha-perl   6.03-1+b1
ii  libdpkg-perl 1.21.17
ii  libemail-address-xs-perl 1.05-1+b1
ii  libencode-perl   3.19-1+b1
ii  libfile-basedir-perl 0.09-2
ii  libfile-find-rule-perl   0.34-3
ii  libfont-ttf-perl 1.06-2
ii  libhtml-html5-entities-perl  0.004-3
ii  libhtml-tokeparser-simple-perl   3.16-4
ii  libio-interactive-perl   1.023-2
ii  libipc-run3-perl 0.048-3
ii  libjson-maybexs-perl 1.004004-1
ii  liblist-compare-perl 0.55-2
ii  liblist-someutils-perl   0.59-1
ii  liblist-utilsby-perl 0.12-2
ii  libmldbm-perl2.05-4
ii  libmoo-perl  2.005005-1
ii  libmoox-aliases-perl 0.001006-2
ii  libnamespace-clean-perl  0.27-2
ii  libpath-tiny-perl0.144-1
ii  libperlio-gzip-perl  0.20-1+b1
ii  libperlio-utf8-strict-perl   0.010-1
ii  libproc-processtable-perl0.634-1+b2
ii

Bug#1027949: lintian: Fails if path to .dsc contains UTF-8 (i.e. non-ASCII) characters like "→"

2023-01-04 Thread Axel Beckert

Package: lintian
Version: 2.115.3-66-ge45c16683
Severity: minor

I just tried to reproduce an issue with the most recent
libpath-tiny-perl upload by running Lintian from git and ran into that
issue:

bin/lintian 
../artifacts_job_3728109→3727495_src:linux_salsaci:lintian/debian/output/linux_6.1.2-1~exp1+salsaci.dsc
  
Skipping 
../artifacts_job_3728109â3727495_src:linux_salsaci:lintian/debian/output/linux_6.1.2-1~exp1+salsaci.dsc:
 
../artifacts_job_3728109Ã¢ÂÂ3727495_src:linux_salsaci:lintian/debian/output/linux_6.1.2.orig.tar.xz
 does not exist, exiting

Note how lintian changed "→" into "â".

This initially sounded similar to https://bugs.debian.org/956233, but
that one is about files inside an unpacked source package and actually
already fixed. Will close that one soon after this mail.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.39.90.20221231-1
ii  bzip2   1.0.8-5+b1
ii  clzip [lzip-decompressor]   1.13-4
ii  diffstat1.65-1
ii  dpkg1.21.15
ii  dpkg-dev1.21.15
ii  file1:5.41-4
ii  gettext 0.21-10
ii  gpg 2.2.40-1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.12.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1+b1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
ii  libdigest-sha-perl  6.03-1+b1
ii  libdpkg-perl1.21.15
ii  libemail-address-xs-perl1.05-1+b1
ii  libencode-perl  3.19-1+b1
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.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-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.005004-3
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+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1+b1
ii  libsereal-encoder-perl  5.001+ds-2
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.28-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.13-2
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.84+ds-1+b1
ii  lunzip [lzip-decompressor]  1.13-4
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.11.1-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-6
ii  plzip [lzip-decompressor]   1.10-4
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  xlunzip [lzip-decompressor] 0.7-6
ii  xz-utils5.4.0-0.1

lintian recommends no packages.

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

Bug#983539: false positive (.DEFAULT?) E: debian-rules-missing-required-target

2023-01-02 Thread Axel Beckert

Control: tag -1 + moreinfo

Hi John,

John Scott wrote:
> This package uses Debhelper. What I think causes the false positive is
> that, instead of using a pattern rule like
> %:
>   dh $@
> 
> I use the .DEFAULT special target and also call mkdir prior, like:
> .DEFAULT:
>   mkdir -p $(unpacked_dir)
>   dh $@ -D$(unpacked_dir) -Bbuild
> 
> The .DEFAULT special target, unlike pattern rules, is specified by
> POSIX, and as Lintian indicates this is an error, I'd very much
> appreciate if this could be fixed.

Do I understand it right that ".DEFAULT:" is equivalent to "%:"?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Re: New lintian release?

2023-01-02 Thread Axel Beckert

Hi Louis,

sorry for lagging the past few weeks (or months ), but I didn't
manage to work on Debian stuff before 1st of January although I hoped
to get to it earlier. Too much real-life these days. (Which was nice,
though. )

Louis-Philippe Véronneau wrote:
> I feel significant changes have been made on the git HEAD and a new lintian
> release would be a good idea.

Definitely. Also because I consider it to be (close to) a toolchain
package. It's though (luckily ) not on
https://release.debian.org/testing/essential-and-build-essential.txt

> I don't think we're exactly there though, as I see two issues that need to
> be resolved before a release can be made:
> 
> 1. it seems "t/scripts/run-private-scripts.t" is broken again?

Yes? Didn't notice anything recently.

> Axel kindly fixed the issue we were having with this script in the
> testsuite, but I just tried building lintian and it fails with this error:
> 
> #   Failed test 'Exit status 0 of generate-tag-summary'
> #   at t/scripts/run-private-scripts.t line 50.
> #  got: '25'
> # expected: '0'
> #   Failed test 'STDERR of generate-tag-summary matches (?^:^No tags were
> added or removed$|\A\Z)'
> #   at t/scripts/run-private-scripts.t line 51.
> #   'No such file or directory at
> /<>/private/../lib/Lintian/IPC/Run3.pm line 77.
> # '
> # doesn't match '(?^:^No tags were added or removed$|\A\Z)'
> #   Failed test 'Expected output of generate-tag-summary'
> #   at t/scripts/run-private-scripts.t line 53.
> #   ''
> # doesn't match '(?^:Assuming commit range to be)'
> # Looks like you failed 3 tests of 3.
> #   Failed test 'generate-tag-summary'
> #   at t/scripts/run-private-scripts.t line 57

That error seems to be a real error when calling
private/generate-tag-summary. So the error is not in
t/scripts/run-private-scripts.t but in private/generate-tag-summary
and t/scripts/run-private-scripts.t found that issue. Which is good! 

Not sure which file it can't find, though. On a first glance, only git
commands seem to be executed via IPC::Run3 from
private/generate-tag-summary, so I assume it can't find "git" — which
on the other hand would be very weird.

What output does running "private/generate-tag-summary" shows for you?

Anyway, I've built the package and ran the testsuite several times
today locally as well as on Salsa CI and I didn't see this error.

So if you can get some more details about that issue, I'm happy to
help.

> Running the testsuite with `private/runtest` works just fine though...
> 
> From what I understand, the build testbed isn't the same as the one we use
> when running the testsuite by itself (like we do in the CI, or with
> `private/runtest`).

Hmmm, initially many *.t files required $LINTIAN_BASE to be set in the
environments (which private/runtest does), but I thought, I found all
which hadn't this yet.

But "prove t/scripts/run-private-scripts.t" works fine for me as of
now, even without "-l" or after a "git clean -dxf". And running
"private/generate-tag-summary" (which the test argues about) works for
me as well. So, no, I currently have not much of an idea about this.

> 2. BTS #1026920 should probably fixed before we upload

Thanks for the heads up. I today mostly went through the open MRs and
the #1025868 RC bug (failing testsuite/autopkgtests on arm64). I've
also already fixed half of the latter. Was caused by a typo by myself
which no test caught.  So I also wrote a test for it so this kind
of typo should no more stay undetected.

The second half of the #1025868 RC bug is the bin-sbin-mismatch tag
which I so far seldomly saw doing much else than false positives even
unrelated to what it's about. Looks like a reproducibility issue (file
order on disk or so) here, though, on a first glance. Then again such
an issue should not be architecture-specific.

> The version of `file` that breaks the autopkgtest is still in experimental,
> but it should be uploaded to unstable soon.

Ok. I wonder if that will really make it for bookworm. It's not in
https://release.debian.org/testing/essential-and-build-essential.txt
but it would be a transition. But then again, I don't see a transition
request at
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org#_0_17_4
yet.

But yeah, we probably should be prepared for both cases.

IMHO neither of them are a blocker for an upload. I'd rather consider
that second half of the RC bug #1025868 to be more of a blocker, even
if not a complete blocker.

Actually I even think we could upload now as the Salsa CI test stage
is green again for a few commits, but I first would like to look at
least through the recently opened bug reports, too, and also do a bit
more local testing. I also assume we will do at least two uploads
before the freeze an

Re: CI pipeline timeout

2023-01-02 Thread Axel Beckert

Hi Russ,

first thanks for merging a lot of MRs! I today went through a few
more.

Russ Allbery wrote:
> It looks like the Lintian autopkgtests take too long to run most of the
> time, which is making it fairly hard to handle merge requests since the
> pipeline fails.  The project timeout was already set to 1d but the
> autopkgtests job is timing out after one hour, so I assume that this is a
> runner timeout that we can't increase.

I think this has been cut down since then. I currently only see
autopkgtest runtimes between 1 and 2 hours. The samples I looked at
needed 75 and 95 minutes.

> Or... hm. I just realized that Salsa shows the pipeline as running
> on the project of the MR submitter. Maybe the problem is that it's
> using their timeout and not ours?

Exactly, I noticed that, too.

But there also seem different timeouts for the main repo and other's
repos. Our current time limit in the main repo is 3 hours, said to be
defined by the "runner" — whatever that means. But for merge requests
(i.e. lintian repos of forks) it seems to be 1 hour. So autopkgtests
from merge requests seem to run into timeouts way more often, but also
not always.

> That still poses roughly the same problem, though.

Ack.

JFTR: We also currently have problems with the i386 builds on Salsa
CI, but that's because binutils is missing its i386 binary packages
for about a day. A rebuild of them is currently running, so this
hopefully should be solved tomorrow. I currently ignore them and the
tests are now all passing again.

> This seems to be the only CI job that runs the test suite, so clearly we
> need it to confirm that MRs haven't broken anything.
> 
> I'm wondering what the options are here.

Pushing the parts from an MR into a feature branch so far helped, but
is a lot of unnecessary work.

> Maybe we can break the test suite up into multiple parts that can
> run separately? That will take as long but should avoid the timeout.

I'm not sure if its really possible to break up autopkgtests so that
it runs in more than one runner.

> Obviously ideal would be to speed up testing.

Full ack.

> It looks like just building all of the test packages takes a
> half-hour, and then running Lintian on all of them takes longer than
> that, at least some of the time. We do build a *lot* of test
> packages (1,437),

That's a result of Felix breaking up and duplicating test packages to
have specific packages for each test. But I'm not sure if this is
really slower than before when we always ran all lintian checks
against all (but fewer) test packages.

> but of course it's nice to have one test package per conceptual test
> and not to have to think about merging multiple tests together into
> a single package.

IMHO both have adavantages and I'm not 100% sure which variant I'd
prefer.

> If this were GitHub Actions, I'd be tempted to try to cache all of the
> test packages and only rebuild them if something has changed, which I
> suspect would save some time.  I'm not sure how to do that with GitLab.

Maybe the Salsa CI Team has some ideas here.

Anyway, I think with the reintroduction of sliding windows for
regexp-based checks by Bastien as well as with blacklisting file
suffixes/types for the very-long-line-… tag, we already gained a lot
of speed again.

This not only speeds up the test suite, but especially also checking
packages with a lot of files like PostgreSQL, Firefox, Linux, etc.

And I suspect that there are more of that kind of optimization
possibilities than it the test suite itself.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

[Git][lintian/lintian][master] 2 commits: Make "lintian --version" emit versions unique per commit



Axel Beckert pushed to branch master at lintian / lintian


Commits:
9b6ce500 by Axel Beckert at 2023-01-02T21:15:13+01:00
Make lintian --version emit versions unique per commit

It previously only added the amount of commits since last release to
the patch version if it was at zero. Which is anything but the claimed
Semantic Versioning.

- - - - -
e45c1668 by Axel Beckert at 2023-01-02T21:15:13+01:00
Make lib/Lintian/Version.pm perltidy again

Gbp-Dch: Ignore

- - - - -


1 changed file:

- lib/Lintian/Version.pm


Changes:

=
lib/Lintian/Version.pm
=
@@ -83,15 +83,20 @@ sub version_from_git {
 return $EMPTY
   unless -d $git_path;
 
-my $describe
-  = decode_utf8(safe_qx('git', "--git-dir=$git_path", 'describe'));
+# Example outputs:
+# 2.115.3-49-g086a9a113
+# 2.115.3-49-g086a9a113-dirty
+my $describe = decode_utf8(
+safe_qx('git', "--git-dir=$git_path", 'describe', '--dirty'));
 chomp $describe;
 
-my ($guess, $step, $commit) = split(/-/, $describe);
-return $EMPTY
-  unless defined $step;
-
-$guess =~ s/ [.] 0 $/.$step/sx;
+# Modify it to make it a valid native version number and make it
+# look more debianish like these:
+# 2.115.3+49commits+git086a9a113
+# 2.115.3+49commits+git086a9a113+dirty
+my $guess = $describe;
+$guess =~ s/ - ( \d+ ) -g /+${1}commits+git/sx;
+$guess =~ s/ - /+/sxg;
 
 return ($guess // $EMPTY);
 }



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/37770b159e9cb222c8357fcb645456507445f3ca...e45c166839b78dbbe8f1b30d3c64d1fe7f504ce0

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/37770b159e9cb222c8357fcb645456507445f3ca...e45c166839b78dbbe8f1b30d3c64d1fe7f504ce0
You're receiving this email because of your account on salsa.debian.org.

Bug#1025868: lintian autopkgtest fails on all but amd64: x86_64-linux-gnu expected build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t

2023-01-02 Thread Axel Beckert

Hi Paul,

finally found time to tackle this.

Axel Beckert wrote:
> > Can you please investigate the situation
> 
> Already done. Issue are mostly hardcoded x86_64 and amd64 strings in
> the test suite.
> 
> Problem is IIRC that Lintian's testsuite currently doesn't support a
> templating system, at least not for many of these places. IIRC I fixed
> already some of them which were easy to fix.

Actually there seems a possibility to fix this like in these cases
t/recipes/checks/desktop/gnome/gir/gir/eval/post-test which has the
following sed command in it:

  s, usr/lib/[^/${}]+/girepository-1.0$, usr/lib/MULTIARCH/girepository-1.0,

But it doesn't seem to be applied in the comparison, because if I put
"MULTIARCH" into the hints file, it fails on amd64 as well.

Another weird point seems that
t/recipes/checks/desktop/gnome/gir/gir/eval/desc says:

  Testname: gir
  Check: desktop/gnome/gir
  Test-Architecture: amd64

So that clearly means it should only be run on amd64. So why is it run
on arm64 at all?

Hrm, a "git grep Test-Architecture" shows that most if not all other
such cases have "Test-Architectures" (plural with trailing "s") in
that place. So this is a typo which hasn't been caught yet.

So with my commit f415bc56c4b40d25410af21f2ea629e8eb0733b6 this part
of the test failures should be fixed. And with commit
695582b83f397d6bd5f47f99af77b2195ed1e604 we should also have an
internal check which finds such field name typos. (Needs to be
maintained, though, if fields get added or removed.)

Still need to figure out where the issue with bin-sbin-mismatch. But
that tag is known (at least to me) for weird false positives.

Paul Gevers wrote:
> On 10-12-2022 22:55, Axel Beckert wrote:
> > Ehm, that version no more in the archive anywhere. Did you maybe mean
> > 2.115.3 as currently in Testing and Unstable? (Feel free to remove the
> > moreinfo tag once this is clarified.)
> 
> I meant, I see the issue *since* that version.

Ah, ok. Yeah, kinda makes sense. I kinda expected that this version is
usually the one the bug report was written against with any additional
version hints being added as secondary version via Control statements.

> But indeed, that's a bit weird if not commented on. I have added a
> `found` version now.

Thanks!

> > Will have to look into it again, but I fear in short term, it means to
> > either reduce the tests or only run a subset on non-amd64
> > architectures.
> 
> If the test can't easily support other architectures (which is fine in my
> opinion) than please ensure it only runs on amd64. I advice to do that by
> adding a "Architecture: amd64" field to d/t/control.

Thanks for that hint. But there's already enough code in place for
that so that making it work should be merely fixing a few more lines.
The big question is which lines. ;-) But at least half of the issue is
fixed already.

P.S.: Any idea how we get Salsa CI autopkgtests on arm64?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

[Git][lintian/lintian][master] missing-systemd-service-for-init.d-script: Mention future deprecation of generator



Axel Beckert pushed to branch master at lintian / lintian


Commits:
4ce38e3c by Luca Boccassi at 2023-01-02T17:02:59+01:00
missing-systemd-service-for-init.d-script: Mention future deprecation of 
generator

The generator will be deprecated in the future, so packages without a unit
file will stop working.

[Committers note: This is half of MR !407 which was authored by Luca
as a single commit. Hence Ive changed to first line of the commit
message accordingly.]

- - - - -


1 changed file:

- tags/m/missing-systemd-service-for-init.d-script.tag


Changes:

=
tags/m/missing-systemd-service-for-init.d-script.tag
=
@@ -5,6 +5,7 @@ Explanation: The specified init.d script has no equivalent 
systemd service.
  .
  Whilst systemd has a SysV init.d script compatibility mode, providing
  native systemd support has many advantages such as being able to specify
- security hardening features.
+ security hardening features. Moreover, the systemd SysV generator will be
+ deprecated in the future.
  .
  Please provide a suitable .service file for this script.



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/4ce38e3ccb9c5fee9e4f99d55b3bc93b7f3d7c61

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/4ce38e3ccb9c5fee9e4f99d55b3bc93b7f3d7c61
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] 2 commits: dh-sequence-vim-addon pulls in dh-vim-addon



Axel Beckert pushed to branch master at lintian / lintian


Commits:
4cc5a245 by Edward Betts at 2023-01-02T14:39:38+01:00
dh-sequence-vim-addon pulls in dh-vim-addon

Fix false positive for missing-build-dependency-for-dh-addon when
a package Build-Depends on dh-sequence-vim-addon.

- - - - -
089a22f4 by Russ Allbery at 2023-01-02T14:48:45+01:00
Fix typo in dh-sequence-vim-addon pulls in dh-vim-addon

Gbp-Dch: Ignore
- - - - -


1 changed file:

- lib/Lintian/Check/Debhelper.pm


Changes:

=
lib/Lintian/Check/Debhelper.pm
=
@@ -125,6 +125,7 @@ my %DH_ADDON_MANUAL_PREREQUISITES = (
 'sphinx:any | python-sphinx:any | python3-sphinx:any | 
dh-sequence-sphinxdoc:any',
 systemd =>
 'debhelper:any (>= 9.20160709~) | debhelper-compat:any | 
dh-sequence-systemd:any | dh-systemd:any',
+vim_addon => 'dh-vim-addon:any | dh-sequence-vim-addon:any',
 );
 
 sub visit_patched_files {



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/f0f98771e8ebab8bc86c959c023a65339532e167...089a22f48baa8cb8aca42cb8a4b53471a94e3fcf

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/compare/f0f98771e8ebab8bc86c959c023a65339532e167...089a22f48baa8cb8aca42cb8a4b53471a94e3fcf
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian] Pushed new branch dh-vim-addon



Axel Beckert pushed new branch dh-vim-addon at lintian / lintian

-- 
View it on GitLab: https://salsa.debian.org/lintian/lintian/-/tree/dh-vim-addon
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][salsa-debug] Make "lintian --version" emit versions unique per commit



Axel Beckert pushed to branch salsa-debug at lintian / lintian


Commits:
287d4230 by Axel Beckert at 2023-01-02T14:23:18+01:00
Make lintian --version emit versions unique per commit

It previously only added the amount of commits since last release to
the patch version if it was at zero. Which is anything but the claimed
Semantic Versioning.

- - - - -


1 changed file:

- lib/Lintian/Version.pm


Changes:

=
lib/Lintian/Version.pm
=
@@ -83,15 +83,20 @@ sub version_from_git {
 return $EMPTY
   unless -d $git_path;
 
+# Example outputs:
+# 2.115.3-49-g086a9a113
+# 2.115.3-49-g086a9a113-dirty
 my $describe
-  = decode_utf8(safe_qx('git', "--git-dir=$git_path", 'describe'));
+  = decode_utf8(safe_qx('git', "--git-dir=$git_path", 'describe', 
'--dirty'));
 chomp $describe;
 
-my ($guess, $step, $commit) = split(/-/, $describe);
-return $EMPTY
-  unless defined $step;
-
-$guess =~ s/ [.] 0 $/.$step/sx;
+# Modify it to make it a valid native version number and make it
+# look more debianish like these:
+# 2.115.3+49commits+git086a9a113
+# 2.115.3+49commits+git086a9a113+dirty
+my $guess = $describe;
+$guess =~ s/ - ( \d+ ) -g /+${1}commits+git/sx;
+$guess =~ s/ - /+/sxg;
 
 return ($guess // $EMPTY);
 }



View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/287d4230e7f234afcb2a814efbf0cff01f58f61a

-- 
View it on GitLab: 
https://salsa.debian.org/lintian/lintian/-/commit/287d4230e7f234afcb2a814efbf0cff01f58f61a
You're receiving this email because of your account on salsa.debian.org.

[Git][lintian/lintian][master] Salsa CI: Override the lintian version being used to the just built version