Bug#1031171: lintian: error with continuous-integration/salsa on source:libvcflib_1.0.7+dfsg-2
retitle 1031171 Check/ContinuousIntegration/Salsa.pm crashes on invalid yaml thanks This issue is caused by invalid yaml in the debian/salsa-ci.yml file: = --- include: - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml # Does not build on i386 variables: SALSA_CI_DISABLE_BUILD_PACKAGE_I386: 1 = That "SALSA_CI..." variable line should star with a - and it does not. Of course, lintian shouldn't just error and skip the test. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Processed: Re: lintian: error with continuous-integration/salsa on source:libvcflib_1.0.7+dfsg-2
Processing commands for cont...@bugs.debian.org: > retitle 1031171 Check/ContinuousIntegration/Salsa.pm crashes on invalid yaml Bug #1031171 [lintian] lintian: error with continuous-integration/salsa on source:libvcflib_1.0.7+dfsg-2 Changed Bug title to 'Check/ContinuousIntegration/Salsa.pm crashes on invalid yaml' from 'lintian: error with continuous-integration/salsa on source:libvcflib_1.0.7+dfsg-2'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1031171: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031171 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1020930: marked as done (lintian: fails on latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb)
Your message dated Mon, 2 Sep 2024 11:37:40 -0400 with message-id and subject line Re: lintian: fails on latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb has caused the Debian Bug report #1020930, regarding lintian: fails on latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1020930: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020930 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: lintian Version: 2.115.3 Severity: important Hi, lintian fails on latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb which can be downloaded at http://ftp.debian.org/debian/pool/main/l/latex-cjk-chinese-arphic/latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb $ lintian latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb Warning in processable latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb: In file usr/share/texmf/fonts/type1/arphic/gbsnu/gbsnuv.pfb: cp1252 "\x81" does not map to Unicode at /usr/share/lintian/lib/Lintian/Check/Fonts/Postscript/Type1.pm line 57. warning: cannot run fonts/postscript/type1 check on package binary:latex-cjk-chinese-arphic-gbsn00lp_1.24_all skipping check of binary:latex-cjk-chinese-arphic-gbsn00lp_1.24_all $ echo $? 1 Lucas -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.35.2-2 ii bzip2 1.0.8-4 ii diffstat1.64-1 ii dpkg1.20.12 ii dpkg-dev1.20.12 ii file1:5.39-3 ii gettext 0.21-4 ii gpg 2.2.27-2+deb11u2 ii intltool-debian 0.35.0+20060710.5 ii iso-codes 4.6.0-1 ii libapt-pkg-perl 0.1.39 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-1+b1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b7 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.26-1 ii libconst-fast-perl 0.014-1.1 ii libcpanel-json-xs-perl 4.25-1+b1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-1 ii libdevel-size-perl 0.83-1+b2 pn libdigest-sha-perl ii libdpkg-perl1.20.12 ii libemail-address-xs-perl1.04-1+b3 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1.1 ii libhtml-html5-entities-perl 0.004-1.1 ii libhtml-tokeparser-simple-perl 3.16-3 ii libio-interactive-perl 1.023-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-someutils-perl 0.58-1 ii liblist-utilsby-perl0.11-1 ii libmldbm-perl 2.05-2.1 ii libmoo-perl 2.004004-1 ii libmoox-aliases-perl0.001006-1.1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.118-1 ii libperlio-gzip-perl 0.19-1+b7 ii libperlio-utf8-strict-perl 0.008-1+b1 ii libproc-processtable-perl 0.59-2+b1 ii libregexp-wildcards-perl1.05-2 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libsort-versions-perl 1.62-1 ii libsyntax-keyword-try-perl 0.21-1 ii libterm-readkey-perl2.38-1+b2 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.12-1+b1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.08-1 ii libwww-mechanize-perl 2.03-1 ii libwww-perl 6.52-1
Bug#1029187: depends-on-obsolete-package: exessive severity, should be Warning
tags 1029187 pending patch thanks See https://salsa.debian.org/lintian/lintian/-/merge_requests/517 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Processed: Re: depends-on-obsolete-package: exessive severity, should be Warning
Processing commands for cont...@bugs.debian.org: > tags 1029187 pending patch Bug #1029187 [lintian] depends-on-obsolete-package: exessive severity, should be Warning Added tag(s) pending and patch. > thanks Stopping processing here. Please contact me if you need assistance. -- 1029187: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029187 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1014162: lintian's run-time is too long on some packages
On Wed, 7 Sep 2022 20:11:47 +0200 Christoph Berg wrote: Re: To Debian Bug Tracking System > Version: 2.115.2 > Severity: normal > > Lintian now needs about 3 minutes to check the postgresql-15 source > package alone. Current timings: $ time lintian postgresql-15_15~beta4-1.pgdg+1.dsc 2.115.2 2m29,255s 2.115.3 1m24,698s 2.115.4~git 1m23,866s So it became a lot better, but I think 84s is still too slow for checking a .dsc. Christoph Hi, There's been some work with regards to performance since 2.115.2. I don't know what were the specs of the machine you were running lintian on, but here with a recent AMD laptop and 2.188.1, I get: $ time lintian postgresql-15_15.8-0+deb12u1.dsc real0m31.333s user0m29.634s sys 0m2.672s Which seems reasonable. Can this bug be closed? -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Processed: Re: Bug#999785: Bogus Lintian warning built-using-field-on-arch-all-package affects prospective package firmware-carl9170
Processing commands for cont...@bugs.debian.org: > retitle 999785 built-using-field-on-arch-all-package emitted for some Arch: > all packages that require it Bug #999785 [lintian] built-using-field-on-arch-all-package emitted for non-Go packages Changed Bug title to 'built-using-field-on-arch-all-package emitted for some Arch: all packages that require it' from 'built-using-field-on-arch-all-package emitted for non-Go packages'. > thanks Stopping processing here. Please contact me if you need assistance. -- 999785: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999785 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#999785: Bogus Lintian warning built-using-field-on-arch-all-package affects prospective package firmware-carl9170
retitle 999785 built-using-field-on-arch-all-package emitted for some Arch: all
packages that require it
thanks
On Mon, Jul 10, 2023 at 06:01:40AM +, John Scott wrote:
> Lintian asserts that having Built-Using on an Arch: all package is always
> incorrect. Debian Policy permits and often requires having Built-Using on an
> Arch: all package. This is the situation with carl9170fw, a
> GPL-2.0-only-licensed binary that bakes in several static libraries that need
> to have their sources kept around. This is a firmware package, however, so
> it's Arch: all despite being written in C and producing a bare-metal binary.
> [...]
>
> Furthermore, the far more likely problem with Built-Using is that a package
> forgets to use it when it should. So when a package *does* remember to set
> the Built-Using field, it's typically the result of long consideration and
> the maintainer should be given the benefit of the doubt.
Fully agree; as noted in #1029633, sphinxdoc requires this, despite
generating Arch: all packages. The tag description:
N: The stanza for an installation package in debian/control declares a
N: Built-Using field even though the package is declared as Architecture:
N: all. That is incorrect.
N:
N: The Built-Using field is only used architecture-specific packages. Please
N: remove the Built-Using field from the indicated location.
is simply wrong.
Conversely, it would be helpful to have a check for packages using
sphinxdoc (either B-D on dh-sequence-sphinxdoc or using dh --with
sphinxdoc) that they *are* specifying Built-Using:
${sphinxdoc:Built-Using}.
Best wishes,
Julian
Bug#1057176: [PATCH v2] Do not raise silent-on-rules-requiring-root if dpkg-build-api is v1 or newer
Closes: #1057176
Also see <https://bugs.debian.org/1057238> for additional context.
---
This revision adds tests and reformats with perltidy.
.../Debian/Control/Field/RulesRequiresRoot.pm | 4 +++-
.../build-spec/debian/control.in| 17 +
.../build-spec/fill-values | 4
.../eval/desc | 4
.../eval/hints | 0
5 files changed, 28 insertions(+), 1 deletion(-)
create mode 100644
t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/debian/control.in
create mode 100644
t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/fill-values
create mode 100644
t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/eval/desc
create mode 100644
t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/eval/hints
diff --git a/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm
b/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm
index b97a673b3..9d5d043a7 100644
--- a/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm
+++ b/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm
@@ -38,6 +38,7 @@ sub source {
my $control = $self->processable->debian_control;
my $source_fields = $control->source_fields;
+my $build_prerequisites= $self->processable->relation('Build-Depends-All');
my @r3_misspelled = grep { $_ ne 'Rules-Requires-Root' }
grep { m{^ Rules? - Requires? - Roots? $}xi } $source_fields->names;
@@ -64,7 +65,8 @@ sub source {
&& $source_fields->value('Rules-Requires-Root') ne 'no';
$self->pointed_hint('silent-on-rules-requiring-root', $pointer)
- unless $source_fields->declares('Rules-Requires-Root');
+ unless $source_fields->declares('Rules-Requires-Root')
+ || $build_prerequisites->satisfies('dpkg-build-api (>= 1)');
if ( !$source_fields->declares('Rules-Requires-Root')
|| $source_fields->value('Rules-Requires-Root') eq 'no') {
diff --git
a/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/debian/control.in
b/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/debian/control.in
new file mode 100644
index 0..fb3b62f68
--- /dev/null
+++
b/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/debian/control.in
@@ -0,0 +1,17 @@
+Source: [% $source %]
+Priority: [% $priority %]
+Section: [% $section %]
+Maintainer: [% $author %]
+Standards-Version: [% $standards_version %]
+Build-Depends: [% $build_depends %]
+Homepage: [% $homepage %]
+
+Package: [% $source %]
+Architecture: [% $package_architecture %]
+Pre-Depends: ${misc:Pre-Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: [% $description %]
+ 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.
diff --git
a/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/fill-values
b/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/fill-values
new file mode 100644
index 0..65be27a45
--- /dev/null
+++
b/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/fill-values
@@ -0,0 +1,4 @@
+Testname: rules-requires-root-missing-with-dpkg-build-api
+Skeleton: upload-native
+Description: d/control without explicit rules-requires-root but with
dpkg-build-api
+Extra-Build-Depends: dpkg-build-api (= 1)
diff --git
a/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/eval/desc
b/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/eval/desc
new file mode 100644
index 0..12305298c
--- /dev/null
+++
b/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/eval/desc
@@ -0,0 +1,4 @@
+Testname: rules-requires-root-missing-with-dpkg-build-api
+Check: debian/control/field/rules-requires-root
+Test-Against: silent-on-rules-requiring-root
+See-Also: Bug #1057176
diff --git
a/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/eval/hints
Bug#1057176: [PATCH] Do not raise silent-on-rules-requiring-root if dpkg-build-api is v1 or newer
Closes: #1057176
Also see <https://bugs.debian.org/1057238> for additional context.
---
I know you prefer Salsa merge requests, but I currently cannot login
into my Salsa account, so I'm posting this here for the time being :)
lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm
b/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm
index b97a673b3..32f9a67ac 100644
--- a/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm
+++ b/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm
@@ -38,6 +38,8 @@ sub source {
my $control = $self->processable->debian_control;
my $source_fields = $control->source_fields;
+my $build_prerequisites
+ = $self->processable->relation('Build-Depends-All');
my @r3_misspelled = grep { $_ ne 'Rules-Requires-Root' }
grep { m{^ Rules? - Requires? - Roots? $}xi } $source_fields->names;
@@ -64,7 +66,8 @@ sub source {
&& $source_fields->value('Rules-Requires-Root') ne 'no';
$self->pointed_hint('silent-on-rules-requiring-root', $pointer)
- unless $source_fields->declares('Rules-Requires-Root');
+ unless $source_fields->declares('Rules-Requires-Root')
+ || $build_prerequisites->satisfies('dpkg-build-api (>= 1)');
if ( !$source_fields->declares('Rules-Requires-Root')
|| $source_fields->value('Rules-Requires-Root') eq 'no') {
--
2.43.0
Re: Bug#1071007: sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py
Control: affects -1 - pycrc Control: clone -1 -2 -3 Control: reassign -2 pycrc 0.10.0-2 Control: retitle -1 sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py Control: retitle -2 pycrc: Must not ship /usr/lib/python3/dist-packages/__init__.py Control: reassign -3 lintian 2.117.0 Control: severity -3 wishlist Control: retitle -3 lintian: Should warn if a package ships /usr/lib/python*/dist-packages/__init__.py Hi Helmut, Helmut Grohne wrote: > This bug report has been automatically filed with no human intervention. > The source code is available at https://salsa.debian.org/helmutg/dumat. Ok, this explains why you didn't notice that this is actually a separate bug in each of these packages. :-) > sherlock has an undeclared file conflict. This may result in an unpack > error from dpkg. > > The file /usr/lib/python3/dist-packages/__init__.py is contained in the > packages > * pycrc/0.10.0-2 as present in trixie|unstable > * sherlock/0.14.3+git20240511.b83f5be-1 as present in unstable My Python foo isn't that well versed, but as far as I understand actually no package must ship an __init__.py file at (more or less) root level (i.e. directly in /usr/lib/python*/dist-packages/ or — since usrmerge also — /lib/python*/dist-packages/). Accordingly cloning the bug report for pycrc as it must not ship that file either. And cloning it a second time as wishlist bug report against Lintian so that these cases get caught much earlier. Might be implemented as extension of python-module-has-overly-generic-name (as the module name seems the empty string in that case ;-) which so far already catches cases like e.g. /usr/lib/python3/dist-packages/doc/__init__.py. 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
Processed: Re: Bug#1071007: sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py
Processing control commands: > affects -1 - pycrc Bug #1071007 [sherlock] sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py Removed indication that 1071007 affects pycrc > clone -1 -2 -3 Bug #1071007 [sherlock] sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py Bug 1071007 cloned as bugs 1071060-1071061 > reassign -2 pycrc 0.10.0-2 Bug #1071060 [sherlock] sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py Bug reassigned from package 'sherlock' to 'pycrc'. No longer marked as found in versions sherlock/0.14.3+git20240511.b83f5be-1. Ignoring request to alter fixed versions of bug #1071060 to the same values previously set Bug #1071060 [pycrc] sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py Marked as found in versions pycrc/0.10.0-2. > retitle -1 sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py Bug #1071007 [sherlock] sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py Changed Bug title to 'sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py' from 'sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py'. > retitle -2 pycrc: Must not ship /usr/lib/python3/dist-packages/__init__.py Bug #1071060 [pycrc] sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py Changed Bug title to 'pycrc: Must not ship /usr/lib/python3/dist-packages/__init__.py' from 'sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py'. > reassign -3 lintian 2.117.0 Bug #1071061 [sherlock] sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py Bug reassigned from package 'sherlock' to 'lintian'. No longer marked as found in versions sherlock/0.14.3+git20240511.b83f5be-1. Ignoring request to alter fixed versions of bug #1071061 to the same values previously set Bug #1071061 [lintian] sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py Marked as found in versions lintian/2.117.0. > severity -3 wishlist Bug #1071061 [lintian] sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py Severity set to 'wishlist' from 'serious' > retitle -3 lintian: Should warn if a package ships > /usr/lib/python*/dist-packages/__init__.py Bug #1071061 [lintian] sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py Changed Bug title to 'lintian: Should warn if a package ships /usr/lib/python*/dist-packages/__init__.py' from 'sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py'. -- 1071007: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071007 1071060: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071060 1071061: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071061 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1068177: lintian: unpack-message-for-orig due to readelf failing on python-pyelftools 0.31
Package: lintian Version: 2.117.0 Severity: normal Dear Maintainer, * What led up to the situation? I'm packaging python-pyelftools 0.31 and lintian fails due to files used for testing, because of non-utf8 characters. * What exactly did you do (or not do) that was effective (or ineffective)? I followed the usual process of importing a new upstream version. I uploaded the packaging state to https://salsa.debian.org/debian/python- pyelftools. * What was the outcome of this action? The build succeeds, but the subsequent lintian run fails with: E: python-pyelftools source: unpack-message-for-orig python- pyelftools_0.31.orig.tar.gz . Output from 'readelf --all --wide pyelftools-0.31/test/testfiles_for_unittests/dwarf_phantombytes.elf' is not valid UTF-8 * What outcome did you expect instead? I'm not sure: either lintian wouldn't care whether output is utf-8 or perhaps readelf shouldn't emit 8-bit characters. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.42-4 ii bzip2 1.0.8-5.1 ii diffstat1.66-1 ii dpkg1.22.4 ii dpkg-dev1.22.4 ii file1:5.45-2+b1 ii gettext 0.21-14+b1 ii gpg 2.2.40-1.1+b1 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.16.0-1 ii libapt-pkg-perl 0.1.40+b3 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-2+b2 ii libcapture-tiny-perl0.48-2 ii libclass-xsaccessor-perl1.19-4+b2 ii libclone-perl 0.46-1+b1 ii libconfig-tiny-perl 2.30-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.37-1+b1 ii libdata-dpath-perl 0.59-1 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-3 ii libdevel-size-perl 0.83-2+b2 pn libdigest-sha-perl ii libdpkg-perl1.22.4 ii libemail-address-xs-perl1.05-1+b2 ii libfile-basedir-perl0.09-2 ii libfile-find-rule-perl 0.34-3 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-3 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.025-1 ii libipc-run3-perl0.049-1 ii libjson-maybexs-perl1.004005-1 ii liblist-compare-perl0.55-2 ii liblist-someutils-perl 0.59-1 ii liblist-utilsby-perl0.12-2 ii libmldbm-perl 2.05-4 ii libmoo-perl 2.005005-1 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.144-1 ii libperlio-gzip-perl 0.20-1+b2 ii libperlio-utf8-strict-perl 0.010-1+b1 ii libproc-processtable-perl 0.636-1+b1 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.004+ds-1+b1 ii libsereal-encoder-perl 5.004+ds-1+b1 ii libsort-versions-perl 1.62-3 ii libsyntax-keyword-try-perl 0.29-1+b1 ii libterm-readkey-perl2.38-2+b2 ii libtext-levenshteinxs-perl 0.03-5+b2 ii libtext-markdown-discount-perl 0.16-1+b1 ii libtext-xslate-perl 3.5.9-1+b3 ii libtime-duration-perl 1.21-2 ii libtime-moment-perl 0.44-2+b2 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-2+b1 ii liburi-perl 5.27-1 ii libwww-mechanize-perl 2.18-1 ii libwww-perl 6.77-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1+b2 ii libyaml-libyaml-perl0.89+ds-1 ii lzip [lzip-decompressor]1.24.1-1 ii lzop1.04-2 ii man-db 2.12.0-3 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.38.2-3 ii t1utils 1.41-4 ii unzip 6.0-28 ii xz-utils5.6.1+really5.4.5-1 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch ii libtext-template-perl 1.61-1 -- no debconf information
Bug#1005326: no-code-sections triggered on non-ELF files
Hi On Tue, 01 Nov 2022 18:43:31 -0400 Daniel Kahn Gillmor wrote: > This error is also mistakenly produced for libassuan-mingw-w64-dev (used > for cross-building gpgv.exe as part of a windows installer signature > verification tool): Lintian also potentially produces the no-code-sections report for wasi-libc. However, the report is currently not visible as lintian-overrides is in place: https://sources.debian.org/src/wasi-libc/0.0~git20230113.4362b18-3/debian/wasi-libc.lintian-overrides/ It looks like we need some modification to the following code so we can analyse non-ELF files using Lintian, but I have no clue how to address it at the moment. https://salsa.debian.org/lintian/lintian/-/blob/98e5ebd3f120e6200d293b81de8a49f33edef5c4/lib/Lintian/Check/Libraries/Static/NoCode.pm#L67-80 Best, Fukui
Bug#1051538: marked as done (lintian: silent-on-rules-requiring-root.tag wrong path for rootless-builds.txt)
Your message dated Mon, 05 Feb 2024 22:50:33 + with message-id and subject line Bug#1051538: fixed in lintian 2.117.0 has caused the Debian Bug report #1051538, regarding lintian: silent-on-rules-requiring-root.tag wrong path for rootless-builds.txt to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1051538: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051538 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: lintian Version: 2.116.3 Severity: minor Tags: patch Dear Maintainer, tags/s/silent-on-rules-requiring-root.tag states at the end: ... See-Also: /usr/share/doc/dpkg/rootless-builds.txt.gz, ... dpkg-dev package have this file in a subdirectory: $ dpkg -L dpkg-dev |grep rootless /usr/share/doc/dpkg/spec/rootless-builds.txt The simple patch might be: --- a/silent-on-rules-requiring-root.tag2023-01-28 19:46:08.0 +0100 +++ b/silent-on-rules-requiring-root.tag2023-09-09 14:20:09.464726338 +0200 @@ -16,6 +16,6 @@ debian/control, but please verify with diffoscope(1) that the installation packages produced are in fact identical. See-Also: - /usr/share/doc/dpkg/rootless-builds.txt.gz, + /usr/share/doc/dpkg/spec/rootless-builds.txt debian-policy 4.9.2, debian-policy 5.6.31 Thank you. Noël -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.41-5 ii bzip2 1.0.8-5+b1 ii diffstat1.65-1 ii dpkg1.22.0 ii dpkg-dev1.22.0 ii file1:5.45-2 ii gettext 0.21-13+b1 ii gpg 2.2.40-1.1 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.15.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.29-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.37-1 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 pn libdigest-sha-perl ii libdpkg-perl1.22.0 ii libemail-address-xs-perl1.05-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.004005-1 ii liblist-compare-perl0.55-2 ii liblist-someutils-perl 0.59-1 ii liblist-utilsby-perl0.12-2 ii libmldbm-perl 2.05-4 ii libmoo-perl 2.005005-1 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.144-1 ii libperlio-gzip-perl 0.20-1+b1 ii libperlio-utf8-strict-perl 0.010-1 ii libproc-processtable-perl 0.636-1 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.004+ds-1 ii libsereal-encoder-perl 5.004+ds-1 ii libsort-versions-perl 1.62-3 ii libsyntax-keyword-try-perl 0.29-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.21-1 ii libwww-mechanize-perl 2.17-1 ii libwww-perl 6.72-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1+b1 ii libyaml-libyaml-perl0.86+ds-1 ii lzip [lzip-decompressor]1.23-
[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] 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.
Bug#1031377: Info received (Bug#1031377: UDD/lintian: Needs to run lintian on all binaries generated from same source)
Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): debian...@lists.debian.org If you wish to submit further information on this problem, please send it to 1031...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 1031377: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031377 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#1031377: UDD/lintian: Needs to run lintian on all binaries generated from same source
On Thu, 16 Feb 2023 15:05:24 +0100 Lucas Nussbaum wrote: > What could work is: > run lintian on source > for each arch in the packages's architectures (except all) > run lintian on architecture packages + architecture 'all' packages > > But would that solve all issues? I discovered that it does not solve all issues. For example src:rust-bat builds bat. When you run lintian against the dsc and the deb it emits missing-notice-file-for-apache-license for the source package, but when you run it against only the dsc or only the deb it does not emit that tag. That is because the test checks that the NOTICE file from the source package is missing from the binary package. https://lists.debian.org/msgid-search/8062de5e3a1afbe988ce3d5453d211089242ba2a.ca...@debian.org -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1051538: lintian: silent-on-rules-requiring-root.tag wrong path for rootless-builds.txt
Package: lintian Version: 2.116.3 Severity: minor Tags: patch Dear Maintainer, tags/s/silent-on-rules-requiring-root.tag states at the end: ... See-Also: /usr/share/doc/dpkg/rootless-builds.txt.gz, ... dpkg-dev package have this file in a subdirectory: $ dpkg -L dpkg-dev |grep rootless /usr/share/doc/dpkg/spec/rootless-builds.txt The simple patch might be: --- a/silent-on-rules-requiring-root.tag2023-01-28 19:46:08.0 +0100 +++ b/silent-on-rules-requiring-root.tag2023-09-09 14:20:09.464726338 +0200 @@ -16,6 +16,6 @@ debian/control, but please verify with diffoscope(1) that the installation packages produced are in fact identical. See-Also: - /usr/share/doc/dpkg/rootless-builds.txt.gz, + /usr/share/doc/dpkg/spec/rootless-builds.txt debian-policy 4.9.2, debian-policy 5.6.31 Thank you. Noël -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.41-5 ii bzip2 1.0.8-5+b1 ii diffstat1.65-1 ii dpkg1.22.0 ii dpkg-dev1.22.0 ii file1:5.45-2 ii gettext 0.21-13+b1 ii gpg 2.2.40-1.1 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.15.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.29-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.37-1 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 pn libdigest-sha-perl ii libdpkg-perl1.22.0 ii libemail-address-xs-perl1.05-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.004005-1 ii liblist-compare-perl0.55-2 ii liblist-someutils-perl 0.59-1 ii liblist-utilsby-perl0.12-2 ii libmldbm-perl 2.05-4 ii libmoo-perl 2.005005-1 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.144-1 ii libperlio-gzip-perl 0.20-1+b1 ii libperlio-utf8-strict-perl 0.010-1 ii libproc-processtable-perl 0.636-1 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.004+ds-1 ii libsereal-encoder-perl 5.004+ds-1 ii libsort-versions-perl 1.62-3 ii libsyntax-keyword-try-perl 0.29-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.21-1 ii libwww-mechanize-perl 2.17-1 ii libwww-perl 6.72-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1+b1 ii libyaml-libyaml-perl0.86+ds-1 ii lzip [lzip-decompressor]1.23-6 ii lzop1.04-2 ii man-db 2.11.2-3 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.36.0-8 ii t1utils 1.41-4 ii unzip 6.0-28 ii xz-utils5.4.4-0.1 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch ii libtext-template-perl 1.61-1 -- no debconf information
Bug#1042463: lintian does not accept overrides in the syntax used on ftp-master
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
Processed: Re: Bug#1042463: lintian does not accept overrides in the syntax used on ftp-master
Processing control commands: > tag -1 + moreinfo Bug #1042463 [lintian,ftp.debian.org] lintian does not accept overrides in the syntax used on ftp-master Added tag(s) moreinfo. -- 1042463: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042463 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1031878: --fail-on warnings fails overrides even though --fail-on overrides is not specified
Hi, today I ran into the same issue on Bookworm. What was strange though: some packages hit this bug, others did not. Turns out it is related to "automatic" overrides being present or not. A python package of mine had automatic overrides for "package-contains-documentation-outside-usr-share-doc [usr/lib/python3/dist-packages/PackageName-Version.egg-info*]" The --show-overrides option (hitting #1019690 here) said: "N: masked by screen python/egg/metadata" After adding explicit overrides in the package the --fail-on function worked correctly again and I got exit code 0 instead of 2. Hope this helps! Best wishes -- .''`. Philipp Huebner : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F `. `'` `- OpenPGP_0xE5CA8C4925E4205F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1043446: lintian: what is the intended scope of depends-on-obsolete-package?
Package: lintian Version: 2.116.3 Severity: normal X-Debbugs-Cc: debian...@lists.debian.org There are two classes of obsolete package that I'd like to be able to detect programmatically and discourage via Lintian checks, to reduce the need for mass-bug-filing: 1. Obsolete transitional packages that will be removed, but are relatively trivial to move away from with minimal human input: policykit-1, libfontconfig1-dev, libgdk-pixbuf2.0-0 (in some cases there is a decision to be made on which successor package(s) are the right ones to depend on, in other cases the new name is a drop-in replacement and could be done programmatically) 2. Obsolete libraries etc. that can require significant porting effort in upstream code: GTK 2 -> 3 (-> 4), FUSE 2 -> 3, SDL 1 -> 2 (-> 3 eventually), Qt major versions and so on It seems more appropriate to use a higher severity for the first category (which are Debian-specific and relatively trivial to fix) than the second category (which require upstream code changes to port away from) - at least until the point at which we start seriously trying to remove the deprecated library from the distribution, at which point we could consider raising their tag severity. Are these both intended to be in-scope for data/fields/obsolete-packages and depends-on-obsolete-package, or is there a distinction that should be made between them? Perhaps the first category should be listed as "obsolete packages", and the second should be a new list of "deprecated packages" or "obsolescent packages" with a lower tag severity? (Which could for example include GTK 2, FUSE 2, SDL 1 as of 2023) Perhaps it would even be useful to have a third category, "superseded packages" or something, for packages that are still actively maintained and still fine to use, but have a newer stable release available which upstreams should ideally be moving towards? (Like GTK 3, which has been superseded by GTK 4 but is still maintained - info or pedantic would probably be the right level for dependencies on GTK 3 as of 2023) See also #1029187 which discusses the (high) severity currently used for depends-on-obsolete-package. smcv
Bug#1042463: lintian does not accept overrides in the syntax used on ftp-master
Package: lintian,ftp.debian.org Severity: important X-Debbugs-Cc: juli...@ubuntu.com lintian in the archive needs to restore support for the old override format, or ftpmaster needs to be updated to the new lintian. 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. For an orderly transition, lintian needs to regain support for the old override format as otherwise uploads to old series don't work. -- System Information: Debian Release: trixie/sid APT prefers mantic APT policy: (500, 'mantic') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-7-generic (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#999785: Bogus Lintian warning built-using-field-on-arch-all-package affects prospective package firmware-carl9170
Lintian asserts that having Built-Using on an Arch: all package is always incorrect. Debian Policy permits and often requires having Built-Using on an Arch: all package. This is the situation with carl9170fw, a GPL-2.0-only-licensed binary that bakes in several static libraries that need to have their sources kept around. This is a firmware package, however, so it's Arch: all despite being written in C and producing a bare-metal binary. I am concerned that this Lintian warning may cause false alarm by my sponsors or even cause rejection in the NEW queue. Please remove it from Lintian. Furthermore, the far more likely problem with Built-Using is that a package forgets to use it when it should. So when a package *does* remember to set the Built-Using field, it's typically the result of long consideration and the maintainer should be given the benefit of the doubt. signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1034708: lintian: false positive "build-depends-on-versioned-berkeley-db Build-Depends:libdb5.3-sql-dev"
Package: lintian Version: 2.116.3 Severity: normal I get the warning "build-depends-on-versioned-berkeley-db Build-Depends:libdb5.3-sql-dev" My package used to depend on libdb-sql-dev, but this package doesn't exist anymore in bookworm, so I think I have to depend on libdb5.3-sql-dev now, don't I? -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-21-amd64 (SMP w/24 CPU threads) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils2.40-2 ii bzip2 1.0.8-5+b1 ii diffstat1.65-1 ii dpkg1.21.21 ii dpkg-dev1.21.21 ii file1:5.44-3 ii gettext 0.21-12 ii gpg 2.2.40-1.1 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.13.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.35-1 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 pn libdigest-sha-perl ii libdpkg-perl1.21.21 ii libemail-address-xs-perl1.05-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.003+ds-1 ii libsereal-encoder-perl 5.003+ds-1 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.16-1 ii libwww-perl 6.68-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1+b1 ii libyaml-libyaml-perl0.86+ds-1 ii lzop1.04-2 ii man-db 2.11.2-2 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.36.0-7 ii plzip [lzip-decompressor] 1.10-5 ii t1utils 1.41-4 ii unzip 6.0-28 ii xz-utils5.4.1-0.2 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch pn libtext-template-perl -- no debconf information
Bug#1031878: --fail-on warnings fails overrides even though --fail-on overrides is not specified
Package: lintian Version: 2.104.0 Running `lintian --fail-on warnings` on a package which overrides all warnings in debian/lintian-overrides unexpectedly returns exit code 2. Expected behavior is for this command to return exit code 0 unless `lintian --fail-on overrides` is also specified. Reading `man lintian` implies that `lintian --fail-on warnings` and `lintian --fail-on overrides` should have distinct behaviors. However, `lintian --fail-on warnings` seems to behave as if `lintian --fail-on warnings,overrides` were specified instead. If `lintian --fail-on warnings` should always fail on warnings, even when debian/lintian-overrides overrides these warnings, the documentation should probably be clarified. However, this behavior leaves no way to check that a package having one or more overrides has no additional issues. I run lintian as part of my build process. I'd like to fail the build if lintian finds issues with either the source package or the binary package. Currently, if I use --fail-on, and the package has any overrides, lintian always returns exit code 2. And if I don't use --fail-on, lintian always returns exit code 0. I seem to be unable to have lintian return a non-zero exit code only when a package has an issue that has not yet been fixed or overridden. Using --ftp-master-rejects might return such an exit code, however, such an exit code is not documented and would prevent using a --profile. Same discussion applies for `--fail-on errors` etc. Thanks, Daniel Kauffman Business Experience Designer Rock Solid Solutions LLC
Bug#1031543: lintian: report error on whitespace-only lines in d/control
Package: lintian Version: 2.116.3 Severity: normal There are cases where trailing whitespaces are actually harmful and thus lintian should emit more than just a pedantic trailing-whitespace tag. If the stazas in debian/control are not separated by empty lines but with witespace filled lines, grep-dctrl will error-out. Example: falcosecurity-libs_0.1.1dev+git20220316.e5c53d64-5.dsc ... P: falcosecurity-libs source: trailing-whitespace [debian/changelog:24] P: falcosecurity-libs source: trailing-whitespace [debian/control:65] P: falcosecurity-libs source: trailing-whitespace [debian/control:80] P: falcosecurity-libs source: trailing-whitespace [debian/rules:51] ... d/control line 65 is the problematic one $ grep-dctrl -FDepends -e '(^| )dkms' -o -FPackage -e '\-dkms' debian/control -sPackage -n grep-dctrl: debian/control:65: expected a colon. Andreas
Re: Bug#1031377: UDD/lintian: Needs to run lintian on all binaries generated from same source
(Adding lintian-ma...@debian.org to Cc for input) On 16/02/23 at 11:18 +0800, Paul Wise wrote: > On Thu, 2023-02-16 at 01:17 +0100, Guillem Jover wrote: > > > it would need to get the list of binary packages for a source and > > lint all of them with the same lintian call. > > The usual way of running lintian after a build checks all binary > packages and the source at the same time. I think UDD should do that. That's not very convenient because UDD/lintian runs lintian for each architecture, and lintian's output does not include the architecture for binary packages, so I just get something like: C: libbsd0: control-tarball-compression-format xz C: libbsd0: control-tarball-compression-format xz C: libbsd0: control-tarball-compression-format xz C: libbsd0: control-tarball-compression-format xz C: libbsd0: control-tarball-compression-format xz C: libbsd0: control-tarball-compression-format xz C: libbsd0: control-tarball-compression-format xz C: libbsd0: control-tarball-compression-format xz C: libbsd0: control-tarball-compression-format xz with no way of linking emmitted tags to a specific architecture... What I could do is: for each arch in the packages's architectures (except all) run lintian on source + architecture packages + architecture 'all' packages ... but that would result in a much longer runtime... What could work is: run lintian on source for each arch in the packages's architectures (except all) run lintian on architecture packages + architecture 'all' packages But would that solve all issues? The best way out is probably to have lintian optionally suffix packages names with architecture, and then do a single lintian run with all binaries for all architectures... Lucas
Bug#1031217: lintian: warn on versions in symbols files newer than the package version
Package: lintian Version: 2.116.3 Severity: normal In the recently introduced libcufile0 package Package: libcufile0 Section: non-free/libs Source: nvidia-cuda-toolkit (11.7.1-3) Version: 1.3.1.18~11.7.1-3 I unfortunately set the versions in the symbols file to "11.7.1" (based on the source version) instead of "1.3" (based on the binary package version). This of course resulted in unsatisfiable dependencies libcufile0 (>= 11.7.1) ... It would be nice if lintian would warn about such a version skew that would likely result in broken dependencies. Andreas
Bug#1031171: lintian: error with continuous-integration/salsa on source:libvcflib_1.0.7+dfsg-2
Package: lintian Version: 2.115.3 Severity: important Hi, I noticed that lintian fails when checking that package. root@ip-10-84-234-37:/tmp# lintian libvcflib_1.0.7+dfsg-2.dsc running with root privileges is not recommended! Warning in processable libvcflib_1.0.7+dfsg-2.dsc: YAML::XS::Load Error: The problem: did not find expected '-' indicator was found at document: 1, line: 7, column: 3 while parsing a block collection at line: 3, column: 3 warning: cannot run continuous-integration/salsa check on package source:libvcflib_1.0.7+dfsg-2 skipping check of source:libvcflib_1.0.7+dfsg-2 root@ip-10-84-234-37:/tmp# echo $? 1 Best, Lucas
Bug#858039: lintian: Graph (SVG) files on https://lintian.debian.org/ lack tag name
I've submitted a PR to get this change in as proposed by Axel: https://salsa.debian.org/lintian/lintian/-/merge_requests/455 -- Sincerely, Brian signature.asc Description: This is a digitally signed message part publickey - brianrobt@proton.me - 688c834d.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Bug#1030586: lintian: Testsuite failure on some systems: 1h time offset in test ancient-source
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
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
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? live well, vagrant
Bug#1030586: lintian: Testsuite failure on some systems: 1h time offset in test ancient-source
Axel Beckert writes: > 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 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 or (bigger hammer) just set TZ=UTC when running Lintian. 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. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1030586: lintian: Testsuite failure on some systems: 1h time offset in test ancient-source
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
Processed: lintian: bash-term-in-posix-shell false positive, triggers on "function" in an embedded awk script
Processing control commands: > affects -1 + libreswan Bug #1029223 [lintian] lintian: bash-term-in-posix-shell false positive, triggers on "function" in an embedded awk script Added indication that 1029223 affects libreswan -- 1029223: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029223 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1029223: lintian: bash-term-in-posix-shell false positive, triggers on "function" in an embedded awk script
Package: lintian
Version: 2.116.0
Control: affects -1 + libreswan
Lintian, when reviewing libreswan 4.9-1, reports:
I: libreswan: bash-term-in-posix-shell 'function cool('
[usr/libexec/ipsec/_secretcensor:31]
But in fact the code in question is:
--
awk ' function cool(hot, q, cooled, run) {
# warning: may destroy input line!
q = "'"'"'" # single quote
if (hot ~ q)
--
That is, the code is not a bashism, but rather an input to awk.
This is a false positive.
--dkg
signature.asc
Description: PGP signature
Bug#1029187: depends-on-obsolete-package: exessive severity, should be Warning
Package: lintian Version: 2.116.0 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 depends-on-obsolete-package currently is at severity Error. This is excessive. This should be a mere Warning. - -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages lintian depends on: ii binutils2.40-2 ii bzip2 1.0.8-5+b1 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 pn libdigest-sha-perl ii libdpkg-perl1.21.18 ii libemail-address-xs-perl1.05-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 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 t1utils 1.41-4 ii unzip 6.0-27 ii xz-utils5.4.1-0.0 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch pn libtext-template-perl - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmPJEoEACgkQrh+Cd8S0 17YcfQ/+Ojkf1COhowLE5LUJ+ckBMxzWGH7tdy0SDrCcQf813RQu0zgBBS0K5Zbr YWXfM0u8trD3rUMZOI9geFb9yl4WnUtqxTOJkpvaN31U8OceoIKCdQja0135Wyvy +NZ63a+rSqZyrXf6lrO7UuHzbTyDZkn7H/uUH4gXhXCvXFYEWzbysMa55PeKtWbF WwcNkdms7KD9sPLV+rcsIVCGc8FxdzVWVYmwpkZxDDSX3PuJvF+omntY8OQc6UNE qc04JzpOLBwgmeNk/+fwuy3ZTB8PmE+ffPakwZbwxkjM6n1xMwzVnduGu2u6igJw noVcsEIRA1s3UFMQnuFCdQgOGzY6kfZVON76z7PXFPpieOEK1szXmWyhpbH84CCt WEMLvnJTdBEYVw9Qud5vU81IcamHz3a8Ynd42AGx/qgFY9Jr/QvPTFQBtDSREuM9 t8O9CKvLizpgIzoDtRDE/H68xw/BaVYhDttM7tdRxeQ6vVWw5k45DsSweGjvCv9v 3LRWPkF8/IpwUlI+hnY+GeOm2aS4jCTDnaJYHwpiFuD8nnvtUsamuA+44eRDZix1 hzZI6M0Z2Y1MVPdZhrHznG/jS7elwecvUR1wNPdddKZSIQcNx3nd5mZF4s4MAscD qs9XkkAH7wU+VZuDF7Ho+YwmJLLAgU42dluDNaVtIeM0aREUpdg= =zCr8 -END PGP SIGNATURE-
Bug#1025868: marked as done (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)
Your message dated Tue, 17 Jan 2023 07:00:30 + with message-id and subject line Bug#1025868: fixed in lintian 2.116.0 has caused the Debian Bug report #1025868, regarding 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 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1025868: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025868 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: lintian Version: 2.111.0 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), Your package has an autopkgtest, great. However, it fails currently everywhere except on amd64. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing as are regressions on all release architectures. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html https://ci.debian.net/data/autopkgtest/testing/arm64/l/lintian/28970519/log.gz # Hints do not match # # --- ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/hints.specified.calibrated # +++ ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/hints.actual.parsed # -gir1.2-good-42 (binary): typelib-not-in-multiarch-directory usr/lib/x86_64-linux-gnu/girepository-1.0 [usr/lib/girepository-1.0/GoodExtras-42.typelib] # -gir1.2-good-42 (binary): typelib-not-in-multiarch-directory usr/lib/x86_64-linux-gnu/girepository-1.0 [usr/lib/girepository-1.0/Good-42.typelib] # +gir1.2-good-42 (binary): typelib-not-in-multiarch-directory usr/lib/aarch64-linux-gnu/girepository-1.0 [usr/lib/girepository-1.0/GoodExtras-42.typelib] # +gir1.2-good-42 (binary): typelib-not-in-multiarch-directory usr/lib/aarch64-linux-gnu/girepository-1.0 [usr/lib/girepository-1.0/Good-42.typelib] # # Failed test 'Lintian passes for gir' # at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343. # Looks like you failed 1 test of 1. ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t ... and # Hints do not match # # --- ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/hints.specified.calibrated # +++ ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/hints.actual.parsed # +bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch sbin/our-script -> usr/bin/our-script [usr/bin/calls-sbin] # +bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch bin/our-script -> usr/bin/our-script [usr/bin/calls-sbin] # # Failed test 'Lintian passes for bin-sbin-confusion-in-elf' # at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343. # Looks like you failed 1 test of 1. ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/generic.t OpenPGP_signature Description: OpenPGP digital signature --- End Message --- --- Begin Message --- Source: lintian Source-Version: 2.116.0 Done: Axel Beckert We believe that the bug you reported is fixed in the latest version of lintian, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1025...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Axel Beckert (supplier of updated lintian package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 17 Jan 2023 01:37:56 +0100 Source: lintian Architecture: source Version: 2.116.0 Distribution: unstable Urgency: medium Maintainer: Debian Lintian Maintainers Changed-By: Axel Beckert Closes: 932634 1002053 1006631 10133
Bug#1028274: marked as done (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.)
Your message dated Tue, 17 Jan 2023 07:00:30 +
with message-id
and subject line Bug#1028274: fixed in lintian 2.116.0
has caused the Debian Bug report #1028274,
regarding 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.
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1028274: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028274
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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
Bug#1025436: marked as done (lintian: Silence executable-stack-in-shared-library tag on mips*)
Your message dated Tue, 17 Jan 2023 07:00:30 + with message-id and subject line Bug#1025436: fixed in lintian 2.116.0 has caused the Debian Bug report #1025436, regarding lintian: Silence executable-stack-in-shared-library tag on mips* to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1025436: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025436 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: lintian Version: 2.115.3 Severity: important Hi! It seems that glibc forces an executable stack on MIPS architectures (see #1022787). On mipsel and mips64el architectures this is causing for all shared libraries the emission of the executable-stack-in-shared-library tag. As that report does not seem that it will be handled for bullseye, it would be nice if the tag could be silenced on these architectures, as there is nothing maintainers can really do about this, which is actually leading them into dead ends and incorrect fix attempts. Thanks, Guillem --- End Message --- --- Begin Message --- Source: lintian Source-Version: 2.116.0 Done: Axel Beckert We believe that the bug you reported is fixed in the latest version of lintian, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1025...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Axel Beckert (supplier of updated lintian package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 17 Jan 2023 01:37:56 +0100 Source: lintian Architecture: source Version: 2.116.0 Distribution: unstable Urgency: medium Maintainer: Debian Lintian Maintainers Changed-By: Axel Beckert Closes: 932634 1002053 1006631 1013314 1014175 1014956 1016147 1019235 1019541 1019851 1024361 1025164 1025436 1025644 1025868 1026920 1027323 1027399 1028274 1028975 Changes: lintian (2.116.0) unstable; urgency=medium . The "Crowd Merging" Release. . * Summary of tag changes: + Added: - dbus-policy-in-etc - homepage-github-url-ends-with-dot-git - homepage-gitlab-url-ends-with-dot-git - homepage-salsa-url-ends-with-dot-git - uses-pdm-cli - uses-python-distutils + Removed: - init.d-script-needs-depends-on-lsb-base - old-dpmt-vcs - old-papt-vcs - python-teams-merged . [ Sebastian Ramacher ] * Revert "Turn embedded-library into a classification tag. (Closes: #932634)". The tag embedded-library is used by FTP masters for automatic rejects. So let's revert this change. First, #932634 has seen no coordination with FTP masters. Second, it confuses developers when their packages get rejected for tags that are not emitted locally. . [ Simon McVittie ] * obsolete-packages: Add some more transitional packages. * desktop/dbus: Check for dbus policy files installed into /etc/. (Closes: #1006631) * Don't emit very-long-line-length-in-source-file for REUSE licenses. (Closes: #1013314) . [ Bastien Roucariès ] * Run test suite at build time except on Salsa. * Fix warning: cannot run debian/readme check on package binary:postgresql-15_15~beta2-2+salsaci_amd64 (Closes: #1014175) * Refresh data. * L…/C…/Files/PrivacyBreach.pm: Run lc in sliding windows block. . [ Axel Beckert ] * data/spelling/corrections: Remove valid word "licence". * Fix typos and add missing changelog items in 2.115.3 release. * .gitignore: Also ignore debian/*.debhelper files and drop wrong trailing slash for doc/lintian.html. * private/refresh-virtual-packages-data: Replace "egrep" with "grep -E". * Replace "egrep" and "fgrep" in all test suite dummy packages with "grep -E/-F". * Add build-dependencies of the test suite. * Fix test broken by dpatch removal. * Fix test broken by updating the list of virtual packages. * Extend spellintian.t to check all listed misspellings against dictionaries. Add test suite build dependencies on liblist-someutils-perl, wamerican and wbritish. (Closes: #1019541) * Make spellinti
Bug#1019851: marked as done (lintian: init.d-script-needs-depends-on-lsb-base is obsolete + wrong)
Your message dated Tue, 17 Jan 2023 07:00:30 + with message-id and subject line Bug#1019851: fixed in lintian 2.116.0 has caused the Debian Bug report #1019851, regarding lintian: init.d-script-needs-depends-on-lsb-base is obsolete + wrong to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1019851: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019851 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: lintian Version: 2.115.3 Severity: normal Hi! The tag init.d-script-needs-depends-on-lsb-base has been redundant for quite a while, as lsb-base was transitively essential. Now it's even more redundant, as the package is no more (it was an implementation detail of the init script boilerplate that cost us 55KB of metadata). Removing the dependency from individual packages would be the usual clean-up that tends to linger for 20 years and no one cares -- but it turned out that debootstrap doesn't understand Provides. Thus, we had to bring back a dummy package that costs us all the required files: * changelog * copyright * dpkg/info/.list * dpkg/info/.md5sums * 20 lines in dpkg/status * ~1KB of cruft + uncompressible hashes in apt indices Of course, shaving a bit off the minimal install isn't _that_ important, but as only 3(?) packages get installed by debootstrap, I'd still want to drop that by Bookworm. And for that purpose, I'd prefer to not annoy maintainers by lintian warnings, make them add overrides, and otherwise waste time. Thus: please drop this tag soon. Then you could add a reverse tag, lsb-base-depends-is-obsolete, but that's an aforemented 20 years cleanup that has no urgency. Meow! -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (120, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-rc5-00016-g0b0aebee76ce (SMP w/64 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages lintian depends on: ii binutils2.38.90.20220713-2 ii bzip2 1.0.8-5 ii diffstat1.64-1 ii dpkg1.21.9 ii dpkg-dev1.21.9 ii file1:5.41-4 ii gettext 0.21-9 ii gpg 2.2.39-1 ii intltool-debian 0.35.0+20060710.5 ii iso-codes 4.11.0-1 ii libapt-pkg-perl 0.1.40+b1 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-1+b2 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-4 ii libclone-perl 0.45-1+b2 ii libconfig-tiny-perl 2.28-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.32-1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-2 pn libdigest-sha-perl ii libdpkg-perl1.21.9 ii libemail-address-xs-perl1.05-1 ii libfile-basedir-perl0.09-1 ii libfile-find-rule-perl 0.34-2 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-2 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.023-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-someutils-perl 0.58-1 ii liblist-utilsby-perl0.12-1 ii libmldbm-perl 2.05-3 ii libmoo-perl 2.005004-3 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.122-1 ii libperlio-gzip-perl 0.20-1 ii libperlio-utf8-strict-perl 0.009-1+b1 ii libproc-processtable-perl 0.634-1+b1 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.001+ds-1 ii libsereal-encoder-perl 5.001+ds-1 ii libsort-versions-perl 1.62-2 ii libsyntax-keyword-try-perl 0.27-1 ii libterm-readkey-perl2.38-2 ii libtext-levenshteinxs-perl 0.03-5 ii libte
Bug#1014175: marked as done (warning: cannot run debian/readme check on package binary:postgresql-15_15~beta2-2+salsaci_amd64)
Your message dated Tue, 17 Jan 2023 07:00:29 +
with message-id
and subject line Bug#1014175: fixed in lintian 2.116.0
has caused the Debian Bug report #1014175,
regarding warning: cannot run debian/readme check on package
binary:postgresql-15_15~beta2-2+salsaci_amd64
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1014175: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014175
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: lintian
Version: 2.115.2
Severity: normal
Hi,
Lintian is currently failing in salsa-ci on postgresql-15:
https://salsa.debian.org/postgresql/postgresql/-/jobs/2941498
lintian --suppress-tags "${SALSA_CI_LINTIAN_SUPPRESS_TAGS}" --display-info
--pedantic ${SALSA_CI_LINTIAN_FAIL_ARG} --allow-root
${SALSA_CI_LINTIAN_SHOW_OVERRIDES_ARG} ${WORKING_DIR}/*.changes | tee
lintian.output || ECODE=$?
Warning in processable
/builds/postgresql/postgresql/debian/output/postgresql-15_15~beta2-2+salsaci_amd64.deb:
Cannot open
/tmp/lintian-pool-WqVHVEiN6s/postgresql-15/postgresql-15_15~beta2-2+salsaci_amd64_binary/unpacked/usr/share/doc/postgresql-15/README.Debian.gz
at /usr/share/lintian/lib/Lintian/Check/Debian/Readme.pm line 109.
warning: cannot run debian/readme check on package
binary:postgresql-15_15~beta2-2+salsaci_amd64
skipping check of binary:postgresql-15_15~beta2-2+salsaci_amd64
W: postgresql-15-dbgsym: unknown-field Postgresql-Catversion
[...]
Christoph
--- End Message ---
--- Begin Message ---
Source: lintian
Source-Version: 2.116.0
Done: Axel Beckert
We believe that the bug you reported is fixed in the latest version of
lintian, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1014...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Axel Beckert (supplier of updated lintian package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 17 Jan 2023 01:37:56 +0100
Source: lintian
Architecture: source
Version: 2.116.0
Distribution: unstable
Urgency: medium
Maintainer: Debian Lintian Maintainers
Changed-By: Axel Beckert
Closes: 932634 1002053 1006631 1013314 1014175 1014956 1016147 1019235 1019541
1019851 1024361 1025164 1025436 1025644 1025868 1026920 1027323 1027399 1028274
1028975
Changes:
lintian (2.116.0) unstable; urgency=medium
.
The "Crowd Merging" Release.
.
* Summary of tag changes:
+ Added:
- dbus-policy-in-etc
- homepage-github-url-ends-with-dot-git
- homepage-gitlab-url-ends-with-dot-git
- homepage-salsa-url-ends-with-dot-git
- uses-pdm-cli
- uses-python-distutils
+ Removed:
- init.d-script-needs-depends-on-lsb-base
- old-dpmt-vcs
- old-papt-vcs
- python-teams-merged
.
[ Sebastian Ramacher ]
* Revert "Turn embedded-library into a classification tag. (Closes:
#932634)". The tag embedded-library is used by FTP masters for
automatic rejects. So let's revert this change. First, #932634 has
seen no coordination with FTP masters. Second, it confuses developers
when their packages get rejected for tags that are not emitted
locally.
.
[ Simon McVittie ]
* obsolete-packages: Add some more transitional packages.
* desktop/dbus: Check for dbus policy files installed into /etc/.
(Closes: #1006631)
* Don't emit very-long-line-length-in-source-file for REUSE licenses.
(Closes: #1013314)
.
[ Bastien Roucariès ]
* Run test suite at build time except on Salsa.
* Fix warning: cannot run debian/readme check on
package binary:postgresql-15_15~beta2-2+salsaci_amd64
(Closes: #1014175)
* Refresh data.
* L…/C…/Files/PrivacyBreach.pm: Run lc in sliding windows block.
.
[ Axel Beckert ]
* data/spelling/corrections: Remove valid word "licence".
* Fix typos and add missing changelog items in 2.115.3 release.
* .gitignore: Also ignore debian/*.debhelper files and drop wrong
trailing slash for doc/lintian.html.
* private/refresh-virtual-packages-data: Replace "egrep" with "grep -E".
* Replace "egrep&quo
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
Hi Axel, On 15-01-2023 23:07, Axel Beckert wrote: TL;DR: [...] You're awesome. And indeed, what a shame of your time. Paul OpenPGP_signature Description: OpenPGP digital signature
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
Control: tag -1 + pending
Hi,
TL;DR:
The in-sbin-confusion-in-elf test in Lintian's test suite is broken
beyond repair: Lintian's arm64 result (which failed the test) is
actually the correct result, and the amd64 result (which passed the
test) is wrong due false negatives which lintian has no chance to
find. The cause are very likely different per-architecture compile
time string optimizations. So I will remove the test
in-sbin-confusion-in-elf from the test suite. The tag
bin-sbin-mismatch can't be tested on C-compiled binaries properly if
compile-time string optimizations are in use.
Long story including steps to get to that conclusion:
I've now digged into the second of these test suite failures on arm64
as I could neither reproduce it on armhf nor i386 (which were easier
available to me as I have Sid boxes with these architectures
permanently running).
And on arm64 I can indeed reproduce it. And it is much more weird than
I expected:
Paul Gevers wrote:
> # Hints do not match
> #
> # ---
> ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/hints.specified.calibrated
> # +++
> ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/hints.actual.parsed
> # +bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch sbin/our-script ->
> usr/bin/our-script [usr/bin/calls-sbin]
> # +bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch bin/our-script ->
> usr/bin/our-script [usr/bin/calls-sbin]
> #
> # Failed test 'Lintian passes for bin-sbin-confusion-in-elf'
> # at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343.
> # Looks like you failed 1 test of 1.
> ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/generic.t
>
> 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.
The tag's implementation is not the cause. This seems not a direct bug
in Lintian.
So Lintian's test suite has a sample C program calls-sbin.c which the
test suite expects to trigger once. Here's the source code:
---8<---
#include
#include
/* may not work as expected on ELF due to ld's SHF_MERGE */
#define BIN_PATH "/bin/our-script"
#define SBIN_PATH "/sbin/our-script"
#define USR_BIN_PATH "/usr/bin/our-script"
#define USR_SBIN_PATH "/usr/sbin/our-script"
int
main(void)
{
printf("Calling %s\n", BIN_PATH);
printf("Calling %s\n", SBIN_PATH);
printf("Calling %s\n", USR_BIN_PATH);
printf("Calling %s\n", USR_SBIN_PATH);
return 0;
}
--->8---
Both files, our-script and calls-sbin are only installed into
/usr/bin/.
So how often should this tag trigger then? Once? Twice? Thrice?
The test suite thinks only once which I find confusing. I'd expected
at least twice. But the expected emitted tags by the test suite are:
bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch usr/sbin/our-script ->
usr/bin/our-script [usr/bin/calls-sbin]
On arm64 these three tags are emitted:
bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch usr/sbin/our-script ->
usr/bin/our-script [usr/bin/calls-sbin]
bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch sbin/our-script ->
usr/bin/our-script [usr/bin/calls-sbin]
bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch bin/our-script ->
usr/bin/our-script [usr/bin/calls-sbin]
Which is more what I would have expected on amd64 as well.
So far for the basic confusion.
Now to the more weird thing.
Not weird is IMHO that these four paths from the source are all in the
arm64 binary of calls-sbin:
[arm64] $ strings
./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
| fgrep bin
/bin/our-script
/sbin/our-script
/usr/bin/our-script
/usr/sbin/our-script
But in the amd64 binary, there are only two of them, with one being
the correct one:
[amd64] $ strings
./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
| fgrep bin
/usr/bin/our-script
/usr/sbin/our-script
This fits with the test suite only expecting this tag to be emitted.
But then again, the output of both architectures is the same:
[arm64] $
./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
Calling /bin/our-script
Calling /sbin/our-script
Calling /usr/bin/our-script
Calling /usr/sbin/our-script
[amd64] $
./debian/test-out/packages/checks/files/contents/bin-sbin-confusion-in-elf/bin-s
Processed: Re: 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
Processing control commands: > tag -1 + pending Bug #1025868 [src:lintian] 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 Added tag(s) pending. -- 1025868: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025868 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
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.
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
i
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
Hi, On 02-01-2023 21:10, Axel Beckert wrote: 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? I suspect this is a lintian internal, but I guess you figured that out. 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. I cake these reports from a template and file them in with what I see on ci.d.n. P.S.: Any idea how we get Salsa CI autopkgtests on arm64? I understand the issue is on the salsa admin side where there are issues with shared runners or something. There is a host available that could run the tests, but the host can't be added for $reasons. Paul OpenPGP_signature Description: OpenPGP digital signature
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
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
Bug#1027290: lintian: false positive missing-build-dependency-for-dh_-command dh_nodejs_autodocs when build-depends on dh-sequence-nodejs
Package: lintian Version: 2.115.3 Severity: normal My package-in-progress node-webfont declares Build-Depends: dh-sequence-nodejs, which is (only) provided by dh-nodejs. It uses dh_nodejs_autodocs, and lintian reports: E: node-webfont source: missing-build-dependency-for-dh_-command dh_nodejs_autodocs (does not satisfy dh-nodejs:any) [debian/rules] I suggest that this is a false positive. Best wishes, Julian
Processed: Re: 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
Processing control commands: > found -1 2.115.3 Bug #1025868 [src:lintian] 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 Marked as found in versions lintian/2.115.3. > tag -1 - moreinfo Bug #1025868 [src:lintian] 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 Removed tag(s) moreinfo. -- 1025868: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025868 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
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
Control: found -1 2.115.3 Control: tag -1 - moreinfo 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. But indeed, that's a bit weird if not commented on. I have added a `found` version now. 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. Paul OpenPGP_signature Description: OpenPGP digital signature
Processed: Re: 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
Processing control commands: > tag -1 + confirmed moreinfo Bug #1025868 [src:lintian] 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 Added tag(s) moreinfo and confirmed. -- 1025868: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025868 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
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
Control: tag -1 + confirmed moreinfo Hi Paul, Paul Gevers wrote: > Source: lintian > Version: 2.111.0 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.) > Your package has an autopkgtest, great. However, it fails currently > everywhere except on amd64. Correct. > 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. > and fix it? 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. Anyway, thanks for the reminder. 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
Source: lintian Version: 2.111.0 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), Your package has an autopkgtest, great. However, it fails currently everywhere except on amd64. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing as are regressions on all release architectures. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html https://ci.debian.net/data/autopkgtest/testing/arm64/l/lintian/28970519/log.gz # Hints do not match # # --- ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/hints.specified.calibrated # +++ ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/hints.actual.parsed # -gir1.2-good-42 (binary): typelib-not-in-multiarch-directory usr/lib/x86_64-linux-gnu/girepository-1.0 [usr/lib/girepository-1.0/GoodExtras-42.typelib] # -gir1.2-good-42 (binary): typelib-not-in-multiarch-directory usr/lib/x86_64-linux-gnu/girepository-1.0 [usr/lib/girepository-1.0/Good-42.typelib] # +gir1.2-good-42 (binary): typelib-not-in-multiarch-directory usr/lib/aarch64-linux-gnu/girepository-1.0 [usr/lib/girepository-1.0/GoodExtras-42.typelib] # +gir1.2-good-42 (binary): typelib-not-in-multiarch-directory usr/lib/aarch64-linux-gnu/girepository-1.0 [usr/lib/girepository-1.0/Good-42.typelib] # # Failed test 'Lintian passes for gir' # at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343. # Looks like you failed 1 test of 1. ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t ... and # Hints do not match # # --- ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/hints.specified.calibrated # +++ ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/hints.actual.parsed # +bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch sbin/our-script -> usr/bin/our-script [usr/bin/calls-sbin] # +bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch bin/our-script -> usr/bin/our-script [usr/bin/calls-sbin] # # Failed test 'Lintian passes for bin-sbin-confusion-in-elf' # at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343. # Looks like you failed 1 test of 1. ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/generic.t OpenPGP_signature Description: OpenPGP digital signature
Bug#1025436: lintian: Silence executable-stack-in-shared-library tag on mips*
Package: lintian Version: 2.115.3 Severity: important Hi! It seems that glibc forces an executable stack on MIPS architectures (see #1022787). On mipsel and mips64el architectures this is causing for all shared libraries the emission of the executable-stack-in-shared-library tag. As that report does not seem that it will be handled for bullseye, it would be nice if the tag could be silenced on these architectures, as there is nothing maintainers can really do about this, which is actually leading them into dead ends and incorrect fix attempts. Thanks, Guillem
Re: Thoughts on trying to remove old and unused lintian tags?
I highly recommend subscribing to debian-lint-maint if you're interested in doing work on Lintian or even just want to follow its development. https://lists.debian.org/debian-lint-maint/ Copying this message there, since that's the right place for the discussion, I think. Louis-Philippe Véronneau writes: > Hello! > Would people be against an effort to clean old and unused lintian tags? > I'm currently counting 1522 tags and I'm sure a bunch of those aren't > relevant anymore. > Last time I tried to submit a MR where I was removing code I knew wasn't > needed anymore, there was some push-back. Before I start putting energy > into this, I was wondering if people had opinions/advice. > What I was planning to do was to: > 1. use the UDD database to list all the tags that aren't currently > emitted in the archive. > 2. have a look at them and see if the issues they were flagging are still > relevant. > I'm certainly not an expert in all the issues in the world, but I (maybe > naively) thought certain things would stand out as being clearly "old > issues we don't care about anymore". > The final goal is of course to make lintian easier to maintain in the > long run, and maybe even faster? > Thoughts? I am in general in favor of deleting code. However, I think there are a few important caveats: 1. Most Lintian tags historically were extremely cheap to check and to maintain, and I suspect this is still true with the new refactoring. The main cost is the cost to run the test suite, and while that's not nothing, it doesn't have lots of direct impact on development. Just removing a random tag therefore probably doesn't help maintenance a lot, but removing a tag that requires doing expensive searches or (particularly) one that gathers information that isn't otherwise needed or has complex analysis code that can be deleted entirely is very valuable. I'm not sure if you can find any of those, but if you can, that would be great. 2. You'll want to exclude autoreject Lintian tags. This is obvious when I write it out, but it may not have immediately come to mind. Those tags will never trigger in the archive because that's the point of them. 3. There's some merit in ensuring that recently-fixed problems aren't reintroduced, so probably best to not remove a tag immediately after the last package triggering it has been removed from the archive, but wait a release or so until there aren't remnant packages or documentation that might lead someone to reintroduce the tag. Personally, I think the most valuable tags to clean up are not the tags that never trigger, but instead the tags that have huge numbers of false positives. Those are the ones that eat up more maintainer time, both Lintian maintainers and other package maintainers. For example, the top of my list to remove would be very-long-line-length-in-source-file. I think the rationale for adding it in the first place was well-meaning but misguided, every time I've personally seen it trigger has been a false positive, and now its existence is prompting people to spend time writing additional exceptions and screens for it to try to cut down on the false positive problem. That to me is an active maintenance problem for Lintian. My impression is that the last few years saw a flurry of new tags added, and some had dubious rationales and extensive false positives. My philosophy back when I was the primary maintainer is that false positives from Lintian were very bad, since they discourage people from using the tool at all, and tags that are inherently impossible to stop from generating false positives are dubious and probably shouldn't exist. I'm possibly too aggressive on this front because I like to keep my packages fully Lintian-clean (including pedantic tags) and therefore find false positives personally annoying, but it may be at least worth taking a look around and seeing what tags are issued for very large numbers of packages, particularly if they're also frequently overridden. (All of that being said, one of the problems with Lintian development right now is that the test suite takes an excessively long time to run, and it would be nice to improve that. I'm dubious that we can delete enough tags and thus tests to make a huge difference, but it does help.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1005326: no-code-sections triggered on non-ELF files
On Fri 2022-02-11 12:51:06 -0800, Felix Lechner wrote: > I confirmed that Lintian's invocation produces that error for > usr/lib/dxvk/wine64-development/d3d10.dll.a in dxvk, but how can we > tell such archives apart from those that are legitimately broken? This error is also mistakenly produced for libassuan-mingw-w64-dev (used for cross-building gpgv.exe as part of a windows installer signature verification tool): E: libassuan-mingw-w64-dev: no-code-sections [usr/i686-w64-mingw32/lib/libassuan.a] E: libassuan-mingw-w64-dev: no-code-sections [usr/i686-w64-mingw32/lib/libassuan.dll.a] E: libassuan-mingw-w64-dev: no-code-sections [usr/x86_64-w64-mingw32/lib/libassuan.a] E: libassuan-mingw-w64-dev: no-code-sections [usr/x86_64-w64-mingw32/lib/libassuan.dll.a] --dkg signature.asc Description: PGP signature
Bug#999785: built-using-field-on-arch-all-package emitted for non-Go packages
Hello, On Tue 16 Nov 2021 at 10:19PM +05, Andrey Rahmatullin wrote: > Package: lintian > Version: 2.112.0 > Severity: normal > > When lib/Lintian/Check/Debian/Control.pm was split, the Build-Depends: golang- > go | golang-any check was removed from built-using-field-on-arch-all-package > and so now it's emitted for all arch:all packages with Built-Using. > > If it was done intentionally, which the tag name and description would > suggest, > then I don't think they are correct. The statement in the description makes no > sense outside of Go context, and the tag name as submitted in > https://bugs.debian.org/891072 was golang-built-using-on-arch-all but was > changed by Lamby when applying. This just confused a sponsee of mine. The blanket statement that built-using never makes sense for arch:all is indeed not right. Could the tag just be dropped for the time being? -- Sean Whitton signature.asc Description: PGP signature
Bug#1020930: lintian: fails on latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb
Package: lintian Version: 2.115.3 Severity: important Hi, lintian fails on latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb which can be downloaded at http://ftp.debian.org/debian/pool/main/l/latex-cjk-chinese-arphic/latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb $ lintian latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb Warning in processable latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb: In file usr/share/texmf/fonts/type1/arphic/gbsnu/gbsnuv.pfb: cp1252 "\x81" does not map to Unicode at /usr/share/lintian/lib/Lintian/Check/Fonts/Postscript/Type1.pm line 57. warning: cannot run fonts/postscript/type1 check on package binary:latex-cjk-chinese-arphic-gbsn00lp_1.24_all skipping check of binary:latex-cjk-chinese-arphic-gbsn00lp_1.24_all $ echo $? 1 Lucas -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.35.2-2 ii bzip2 1.0.8-4 ii diffstat1.64-1 ii dpkg1.20.12 ii dpkg-dev1.20.12 ii file1:5.39-3 ii gettext 0.21-4 ii gpg 2.2.27-2+deb11u2 ii intltool-debian 0.35.0+20060710.5 ii iso-codes 4.6.0-1 ii libapt-pkg-perl 0.1.39 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-1+b1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b7 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.26-1 ii libconst-fast-perl 0.014-1.1 ii libcpanel-json-xs-perl 4.25-1+b1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-1 ii libdevel-size-perl 0.83-1+b2 pn libdigest-sha-perl ii libdpkg-perl1.20.12 ii libemail-address-xs-perl1.04-1+b3 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1.1 ii libhtml-html5-entities-perl 0.004-1.1 ii libhtml-tokeparser-simple-perl 3.16-3 ii libio-interactive-perl 1.023-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-someutils-perl 0.58-1 ii liblist-utilsby-perl0.11-1 ii libmldbm-perl 2.05-2.1 ii libmoo-perl 2.004004-1 ii libmoox-aliases-perl0.001006-1.1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.118-1 ii libperlio-gzip-perl 0.19-1+b7 ii libperlio-utf8-strict-perl 0.008-1+b1 ii libproc-processtable-perl 0.59-2+b1 ii libregexp-wildcards-perl1.05-2 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libsort-versions-perl 1.62-1 ii libsyntax-keyword-try-perl 0.21-1 ii libterm-readkey-perl2.38-1+b2 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.12-1+b1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.08-1 ii libwww-mechanize-perl 2.03-1 ii libwww-perl 6.52-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl0.82+repack-1+b1 ii lzip [lzip-decompressor]1.22-3 ii lzop1.04-2 ii man-db 2.9.4-2 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.32.1-4+deb11u2 ii t1utils 1.41-4 ii unzip 6.0-26+deb11u1 ii xz-utils5.2.5-2.1~deb11u1 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.35.2-2 ii libtext-template-perl 1.59-1 -- no debconf information
Bug#1019851: lintian: init.d-script-needs-depends-on-lsb-base is obsolete + wrong
Control: tag -1 + patch On Thu, 15 Sep 2022 00:25:44 +0200 Adam Borowski wrote: > Thus: please drop this tag soon. > > Then you could add a reverse tag, lsb-base-depends-is-obsolete, but > that's an aforemented 20 years cleanup that has no urgency. Now both done here: https://salsa.debian.org/lintian/lintian/-/merge_requests/419 signature.asc Description: signature
Processed: Re: lintian: init.d-script-needs-depends-on-lsb-base is obsolete + wrong
Processing control commands: > tag -1 + patch Bug #1019851 [lintian] lintian: init.d-script-needs-depends-on-lsb-base is obsolete + wrong Added tag(s) patch. -- 1019851: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019851 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1019851: lintian: init.d-script-needs-depends-on-lsb-base is obsolete + wrong
Package: lintian Version: 2.115.3 Severity: normal Hi! The tag init.d-script-needs-depends-on-lsb-base has been redundant for quite a while, as lsb-base was transitively essential. Now it's even more redundant, as the package is no more (it was an implementation detail of the init script boilerplate that cost us 55KB of metadata). Removing the dependency from individual packages would be the usual clean-up that tends to linger for 20 years and no one cares -- but it turned out that debootstrap doesn't understand Provides. Thus, we had to bring back a dummy package that costs us all the required files: * changelog * copyright * dpkg/info/.list * dpkg/info/.md5sums * 20 lines in dpkg/status * ~1KB of cruft + uncompressible hashes in apt indices Of course, shaving a bit off the minimal install isn't _that_ important, but as only 3(?) packages get installed by debootstrap, I'd still want to drop that by Bookworm. And for that purpose, I'd prefer to not annoy maintainers by lintian warnings, make them add overrides, and otherwise waste time. Thus: please drop this tag soon. Then you could add a reverse tag, lsb-base-depends-is-obsolete, but that's an aforemented 20 years cleanup that has no urgency. Meow! -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (120, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-rc5-00016-g0b0aebee76ce (SMP w/64 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages lintian depends on: ii binutils2.38.90.20220713-2 ii bzip2 1.0.8-5 ii diffstat1.64-1 ii dpkg1.21.9 ii dpkg-dev1.21.9 ii file1:5.41-4 ii gettext 0.21-9 ii gpg 2.2.39-1 ii intltool-debian 0.35.0+20060710.5 ii iso-codes 4.11.0-1 ii libapt-pkg-perl 0.1.40+b1 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-1+b2 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-4 ii libclone-perl 0.45-1+b2 ii libconfig-tiny-perl 2.28-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.32-1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-2 pn libdigest-sha-perl ii libdpkg-perl1.21.9 ii libemail-address-xs-perl1.05-1 ii libfile-basedir-perl0.09-1 ii libfile-find-rule-perl 0.34-2 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-2 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.023-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-someutils-perl 0.58-1 ii liblist-utilsby-perl0.12-1 ii libmldbm-perl 2.05-3 ii libmoo-perl 2.005004-3 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.122-1 ii libperlio-gzip-perl 0.20-1 ii libperlio-utf8-strict-perl 0.009-1+b1 ii libproc-processtable-perl 0.634-1+b1 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.001+ds-1 ii libsereal-encoder-perl 5.001+ds-1 ii libsort-versions-perl 1.62-2 ii libsyntax-keyword-try-perl 0.27-1 ii libterm-readkey-perl2.38-2 ii libtext-levenshteinxs-perl 0.03-5 ii libtext-markdown-discount-perl 0.13-1+b1 ii libtext-xslate-perl 3.5.9-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-2 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-1+b3 ii liburi-perl 5.12-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 ii libyaml-libyaml-perl0.84+ds-1 ii lzip [lzip-decompressor]1.23-4 ii lzop1.04-2 ii man-db 2.10.2-3 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.34.0-5 ii t1utils 1.41-4 ii unzip 6.0-27 ii xz-utils
Processed: Re: Bug#1014175: warning: cannot run debian/readme check on package binary:postgresql-15_15~beta2-2+salsaci_amd64
Processing commands for cont...@bugs.debian.org: > affects 1014175 + tryton-server Bug #1014175 [lintian] warning: cannot run debian/readme check on package binary:postgresql-15_15~beta2-2+salsaci_amd64 Added indication that 1014175 affects tryton-server > thanks Stopping processing here. Please contact me if you need assistance. -- 1014175: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014175 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Are we back on adding debian/changelog entries with commits and running test suite at build time without discussion?
Hi, I was very surprised to see debian/changelog entries added with commits despite the * WIP (generated at release time: please do not add entries below). clearly being at top of debian/changelog. This breaks our current "gbp dch" workflow severly as it cannot determine anymore which commits are needed to be added to debian/changelog and which not. Bastien: I'm really hapy that you are back on Lintian development and especially thankful for your work on performance and the sliding window implementation stuff, but I would have been more happy if you first discussed or at least announced such a severe change in our workflow. (I'm fine with both workflows, but we should strictly abide to one of them, otherwise our changelog becomes highly unreliable.) So let's please first discuss which workflow we'll use in the future (with reasoning) before changing it again. So what's your reason for editing the debian/changelog directly? BTW: Your commit 198c3645c88496bcb08614e64e2892d01c42f13a already shows what happens if we don't abide to one of the workflows. Additionally these older commits are currently missing in the current debian/changelog entry due to this unannounced workflow change: * 9279fb89fd7fbad7963c8d3ba8b8f8fea58e3c1d * acb2073d805aead92080ddcadfad74e83db8401a I've added the according debian/changelog entries now. Please stop adding new debian/changelog entries until shortly before releasing or uploading or until we _decide_ together to change our workflow back to editing debian/changelog with each commit. I've also added a more prominent note than the existing one as that one didn't seem to be read. We can remove it (and update the WIP note) if we decide to switch back to editing debian/changelog with each commit again. The same counts for running the test suite at build time. The test suite IMHO currently takes way too long for running at build time. IMHO we first need revert splitting up running separate tests for each tag back to running combined tests again to get down the test suite run-time before we can really enable running tests at build time again. In addition to that we need to document how to build lintian without running the test suite. Waiting 40 minutes to just test some changes is inacceptable. I've though haven't reverted that change. I will like add proper documentation for how to build lintian without waiting 40 minutes for a build. Besides: salsa.debian.org is spelled "Salsa", not "salci". I've fixed that, too, in debian/changelog. 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#1014162: lintian's run-time is too long on some packages
Re: To Debian Bug Tracking System > Version: 2.115.2 > Severity: normal > > Lintian now needs about 3 minutes to check the postgresql-15 source > package alone. Current timings: $ time lintian postgresql-15_15~beta4-1.pgdg+1.dsc 2.115.2 2m29,255s 2.115.3 1m24,698s 2.115.4~git 1m23,866s So it became a lot better, but I think 84s is still too slow for checking a .dsc. Christoph
Bug#1014175: warning: cannot run debian/readme check on package binary:postgresql-15_15~beta2-2+salsaci_amd64
Re: To Debian Bug Tracking System > Warning in processable > /builds/postgresql/postgresql/debian/output/postgresql-15_15~beta2-2+salsaci_amd64.deb: > Cannot open > /tmp/lintian-pool-WqVHVEiN6s/postgresql-15/postgresql-15_15~beta2-2+salsaci_amd64_binary/unpacked/usr/share/doc/postgresql-15/README.Debian.gz > at /usr/share/lintian/lib/Lintian/Check/Debian/Readme.pm line 109. README.Debian.gz is a symlink to a package that isn't built from postgresql-15, I guess that might be a problem: lrwxrwxrwx 1 root root 37 10. Aug 14:33 /usr/share/doc/postgresql-15/README.Debian.gz -> ../postgresql-common/README.Debian.gz Re: Lucas Nussbaum > /usr/share/doc/exim4-daemon-heavy/README.Debian.gz is a symlink to > ../exim4-base/README.Debian.gz. ... these are from the same source package, though. Christoph
Bug#995492: marked as done (lintian: Broken --fails-on=none as default never got reverted)
Your message dated Sun, 28 Aug 2022 14:51:11 + with message-id and subject line Bug#995492: fixed in lintian 2.115.3 has caused the Debian Bug report #995492, regarding lintian: Broken --fails-on=none as default never got reverted to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 995492: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995492 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: lintian Version: 2.77.0 Severity: serious Sigh, So the problematic --fail-on default change never got actually reverted as the patch applied in commit 3758bfafd5dd742c327f2312dac8e3a71b1f036e omitted the relevant part that would make it work. :( None of the previous arguments against the default change brought up in #962158 have stopped being relevant (also contrary to the commit message…). Worse, this sneaked in what has shipped now in a stable Debian release. :( So any errors found in CI systems and through other tooling has been silently ignored since then. :/ Only noticed now due to #994414, a great excuse to now keep the broken behavior I guess. (Where the --help output still does not match…) Unamused, Guillem --- End Message --- --- Begin Message --- Source: lintian Source-Version: 2.115.3 Done: Bastien Roucariès We believe that the bug you reported is fixed in the latest version of lintian, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 995...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Bastien Roucariès (supplier of updated lintian package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 28 Aug 2022 08:31:41 + Source: lintian Architecture: source Version: 2.115.3 Distribution: unstable Urgency: medium Maintainer: Debian Lintian Maintainers Changed-By: Bastien Roucariès Closes: 101387 993613 995492 1014156 Changes: lintian (2.115.3) unstable; urgency=medium . The "RPB (Restore Previous Behavior)" Release. . [ Gioele Barabucci ] * experimental-to-unstable-without-comment: Fix regex (Closes: #101387) . [ Axel Beckert] * Recognise many more binary file type suffixes (Closes: #1014156) . [ Guillem Jover ] * Add pedantic hint for OpenPGP files named after specific implementations * Add more extensions for OpenPGP files * In the US "cancelation" is a valid spelling of "cancellation" * Rename debian-watch-does-not-check-gpg-signature tag to say openpgp * Fix --fail-on to revert to original default on error (Closes: #995492) . [ Bastien Roucariès ] * Restore sliding windows (Closes: #993613) * Add myself as uploaders . * Summary of tag changes: + Added: - debian-watch-does-not-check-openpgp-signature - openpgp-file-has-implementation-specific-extension + Removed: - debian-watch-does-not-check-gpg-signature Checksums-Sha1: c0bb6e292570ce35644a9753ddaa93e10a7ec49e 2583 lintian_2.115.3.dsc 74e755506be7840753ff976faace886b1dc281aa 2172628 lintian_2.115.3.tar.xz 0d7175b07eba588877351e71cf8d90cf8d6c0aa4 7378 lintian_2.115.3_source.buildinfo Checksums-Sha256: 63697c3bde44ce96e51268e077e6879ccafd1c30f75604c5e27c30ab8a0050a5 2583 lintian_2.115.3.dsc 787678607cc9a303908506ab0a475b3760ea6f28af381722d62db8fa89cf9c43 2172628 lintian_2.115.3.tar.xz 210ee6915c72e5a44a5b0691d4cea03236b91a8436f80e61bf23b4be792b1d3e 7378 lintian_2.115.3_source.buildinfo Files: 4b9dadbf1768c3795b419e97fdbc1d10 2583 devel optional lintian_2.115.3.dsc 7b2edaf87fa16b6226bd6eafb36a4b6f 2172628 devel optional lintian_2.115.3.tar.xz 40c4c53d602f12b1de2513915d68215d 7378 devel optional lintian_2.115.3_source.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAmMLd8gRHHJvdWNhQGRl Ymlhbi5vcmcACgkQADoaLapBCF9fMQ//VY9ECX8LAse9PEEWu7/oSPD4AInywTEZ 55rD0zcEeELLth5VoLm/Z2BII4gd/ODX+U82yLOrf8Gr4LDA7lE8ihtwNW+uGDOK X7o+1kYbh8sn5w7eKT6Ip6SHQ2A26lcf4Gm45NG4o9E4rw5Fpxm57t6hYURfaHSO pZIY4QXCcMHZTsDosbJxAsAJKEcEL0ukPCLxKdHV+JprG20MQ3yL7o50FgtNGx+Z mbdsJchljCwzDfw1TX48dpizwwXGRS9TkThrUJFNS2N0YYFvLVRhA8jzzfT48Q3d LCMHlIX4RwBgoHmBkHeqsuYPwvncv3fe1b/wK
Bug#1017632: lintian: False positive on partial match for bin-sbin-mismatch
On Mon, 2022-08-22 at 09:59:34 +0200, Axel Beckert wrote:
> Guillem Jover wrote:
> > The bin-sbin-mismatch triggers false positives on partial matches such
> > as /usr/bin/dpkg-www and /usr/sbin/dpkg-www-installer, or
> > /usr/bin/dpkg and /usr/sbin/dpkg-fsys-usrunmess.
>
> Urgs. Thanks! Nice catch!
> > This is due to the check in lib/Lintian/Check/Files/Contents.pm, where
> > it essentially does the following:
> >
> > perl -E '$str = "/bin/dpkg-www-installer"; \
> >say "wrong-match" if $str =~ m{\B/\Qbin/dpkg-www\E\b}x'
> >
> > I've got false-positives in dpkg and dpkg-www.
>
> So that last \b should be a $, right?
I don't think so, as I think the intention of the code is to find such
instances anywhere in a line, say in pseudo-lines:
«^variable = "/usr/sbin/dpkg-www-installer"$»
or in documentation?
«^This does blah via /usr/sbin/dpkg-www-installer and something other.$»
Thanks,
Guillem
Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Hi Guillem, Guillem Jover wrote: > Control: tag -1 patch > Control: forwarded -1 > https://salsa.debian.org/lintian/lintian/-/merge_requests/414 > > On Mon, 2022-06-27 at 15:14:10 +0200, Axel Beckert wrote: > > Guillem Jover wrote: > > > I'd have to re-dig all this. I might just try to provide a patch, I > > > think should probably be a one-liner. > > > > A patch of course would be nice, but I won't mind if you don't provide > > one. > > I've sent an MR now, which passes the test suite locally, and seems to > work on a manually modified package too. Thanks! Much appreciated. Will merge once we got Salsa CI autopkgtest working again. Currently fails because of dpatch removal _and_ the emacs 27.1 to 28.1 upgrade. *sigh* 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#1017632: lintian: False positive on partial match for bin-sbin-mismatch
Hi Guillem,
Guillem Jover wrote:
> The bin-sbin-mismatch triggers false positives on partial matches such
> as /usr/bin/dpkg-www and /usr/sbin/dpkg-www-installer, or
> /usr/bin/dpkg and /usr/sbin/dpkg-fsys-usrunmess.
Urgs. Thanks! Nice catch!
>
> This is due to the check in lib/Lintian/Check/Files/Contents.pm, where
> it essentially does the following:
>
> perl -E '$str = "/bin/dpkg-www-installer"; \
>say "wrong-match" if $str =~ m{\B/\Qbin/dpkg-www\E\b}x'
>
> I've got false-positives in dpkg and dpkg-www.
So that last \b should be a $, 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#1017632: lintian: False positive on partial match for bin-sbin-mismatch
Package: lintian
Version: 2.115.2
Severity: normal
Hi!
The bin-sbin-mismatch triggers false positives on partial matches such
as /usr/bin/dpkg-www and /usr/sbin/dpkg-www-installer, or
/usr/bin/dpkg and /usr/sbin/dpkg-fsys-usrunmess.
This is due to the check in lib/Lintian/Check/Files/Contents.pm, where
it essentially does the following:
perl -E '$str = "/bin/dpkg-www-installer"; \
say "wrong-match" if $str =~ m{\B/\Qbin/dpkg-www\E\b}x'
I've got false-positives in dpkg and dpkg-www.
Thanks,
Guillem
Processed: Re: Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Processing control commands: > tag -1 patch Bug #995492 [lintian] lintian: Broken --fails-on=none as default never got reverted Added tag(s) patch. > forwarded -1 https://salsa.debian.org/lintian/lintian/-/merge_requests/414 Bug #995492 [lintian] lintian: Broken --fails-on=none as default never got reverted Set Bug forwarded-to-address to 'https://salsa.debian.org/lintian/lintian/-/merge_requests/414'. -- 995492: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995492 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Control: tag -1 patch Control: forwarded -1 https://salsa.debian.org/lintian/lintian/-/merge_requests/414 On Mon, 2022-06-27 at 15:14:10 +0200, Axel Beckert wrote: > Guillem Jover wrote: > > I'd have to re-dig all this. I might just try to provide a patch, I > > think should probably be a one-liner. > > A patch of course would be nice, but I won't mind if you don't provide > one. I've sent an MR now, which passes the test suite locally, and seems to work on a manually modified package too. Thanks, Guillem
Bug#1017085: lintian: Documentation should give example for regex on overrides
Package: lintian Version: 2.115.2 Severity: minor Dear Maintainer, It will be nice if documentation give example for regex filtering. For instance I do not know if regex syntax is pcre or shell and if only * is considered as a regex -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-rt-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.38.90.20220713-2 ii bzip2 1.0.8-5 ii diffstat1.64-1 ii dpkg1.21.9 ii dpkg-dev1.21.9 ii file1:5.41-4 ii gettext 0.21-6 ii gpg 2.2.35-3 ii intltool-debian 0.35.0+20060710.5 ii iso-codes 4.11.0-1 ii libapt-pkg-perl 0.1.40+b1 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-1+b2 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-4 ii libclone-perl 0.45-1+b2 ii libconfig-tiny-perl 2.28-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.30-1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-2 pn libdigest-sha-perl ii libdpkg-perl1.21.9 ii libemail-address-xs-perl1.05-1 ii libencode-perl 3.19-1 ii libfile-basedir-perl0.09-1 ii libfile-find-rule-perl 0.34-2 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-2 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.023-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-someutils-perl 0.58-1 ii liblist-utilsby-perl0.12-1 ii libmldbm-perl 2.05-3 ii libmoo-perl 2.005004-3 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.122-1 ii libperlio-gzip-perl 0.20-1 ii libperlio-utf8-strict-perl 0.009-1+b1 ii libproc-processtable-perl 0.634-1+b1 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 4.025+ds-1 ii libsereal-encoder-perl 4.025+ds-1 ii libsort-versions-perl 1.62-2 ii libsyntax-keyword-try-perl 0.27-1 ii libterm-readkey-perl2.38-1+b3 ii libtext-levenshteinxs-perl 0.03-5 ii libtext-markdown-discount-perl 0.13-1+b1 ii libtext-xslate-perl 3.5.9-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b4 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-1+b3 ii liburi-perl 5.12-1 ii libwww-mechanize-perl 2.13-1 ii libwww-perl 6.67-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1 ii libyaml-libyaml-perl0.83+ds-1+b1 ii lzip [lzip-decompressor]1.23-4 ii lzop1.04-2 ii man-db 2.10.2-1 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.34.0-5 ii t1utils 1.41-4 ii unzip 6.0-27 ii xz-utils5.2.5-2.1 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.38.90.20220713-2 ii libtext-template-perl 1.61-1 -- no debconf information
Re: Potential depends on libregexp-shellish-perl instead of libregexp-wildcards-perl for lintian?
Dear Axel, I appreciate a lot your detailed answer! Not only does it demonstrate your point but it also makes me understand the need in lintian better. So that you for that! I feel fine knowing that that yourself and Christoph have had the opportunity to align on the use of libregexp-wildcards-perl in lintian and that no patch were immediately needed for the packaging. but libregexp-wildcards-perl has benefited from slightly more support (including packaging updates and availability on salsa) recently. I think you meant libregexp-shellish-perl here. Oops, you're absolute right. I meant libregexp-shellish-perl. Additionally, upstream-wise, Regexp::Shellish has seen its last release in 2002 while Regexp::Wildcards has seen its last release in 2013. That's 20 years vs 9 years. And the upstream maintainer of Regexp::Shellish has made his latest upload in 2004 while the upstream maintainer of Regexp::Wildcards has made his latest upload in 2021. So the latter one is much more likely to respond in cases of issues. Yes, this is a very good point! For some reason, I failed to notice that Regexp::Shellish had not been updated for so long on the upstream side. This is a clear drawback. So as of now, libregexp-wildcards-perl is still my favourite even though it doesn't look perfect either. But it at least does exactly what we need in lintian. I agree. The points you made are most convincing. I would add that replacing one implementation by another requires an extra effort (implementation + testing) that I think would only pay off if one solution was measurably better than the other. Thank you again. Best regards, Olivier
Re: Potential depends on libregexp-shellish-perl instead of libregexp-wildcards-perl for lintian?
Dear Olivier (and all other Lintian interested people),
sorry for the late reply. I was on holidays for two weeks and found
way less time to look through my mails than I expected.
Olivier Gayot wrote:
> As part of a main inclusion review in Ubuntu [1], we are currently assessing
> if a potential replacement of lintian's dependency on
> libregexp-wildcards-perl [2] by a dependency on libregexp-shellish-perl [3]
> would be a good thing or not.
Wasn't aware of libregexp-shellish-perl yet and had a look at its
documentation and tried a few short oneliners with it.
I'm reluctant. It is actually a good thing for lintian that it doesn't
seem to support bracket matching ("[…]"). But I fear that its "*" not
matching "/" might cause quite some issues.
> Both packages seem to provide a similar functionality
Indeed.
> but libregexp-wildcards-perl has benefited from slightly more
> support (including packaging updates and availability on salsa)
> recently.
I think you meant libregexp-shellish-perl here.
And yes, I'm aware that libregexp-wildcards-perl is not maintained by
the Debian Perl Group and hasn't seen an upload for quite a while. I
also spoke with its maintainer (Cc'ed) about this. He's very well
aware of the situation, but doesn't think that there's anything which
requires a package update currently — or at least not when I spoke
with him about it. But he assured to me that he'll update the package
if it becomes necessary. Additionally he granted myself personally an
"NMU with maintainer approval" if he doesn't react in time.
For me that sufficed.
Additionally, upstream-wise, Regexp::Shellish has seen its last
release in 2002 while Regexp::Wildcards has seen its last release in
2013. That's 20 years vs 9 years. And the upstream maintainer of
Regexp::Shellish has made his latest upload in 2004 while the upstream
maintainer of Regexp::Wildcards has made his latest upload in 2021. So
the latter one is much more likely to respond in cases of issues.
For me that's a 2:0 for Regexp::Wildcards even though it's also
well-hung.
> If we were to decide that a replacement would be good in Ubuntu, would you
> be interested in sponsoring this change in Debian too?
Not sure, but probably not. libregexp-wildcards-perl is mostly but not
only used for overrides parsing. There so far it was expected that "*"
matches anything, including "/".
Additionally with Regexp::Shellish the documentation actually differs
from what it's doing:
Shellish Perl RE
===
* [^/]*
? .
Note that "?" is documented to be expanded to "." and not "[^/]".
But:
→ perl -MRegexp::Shellish\ 'qw(:all)' -E 'say compile_shellish( "?" )'
(?^s:\A(?:[^/])\Z)
(Which is actually more consistent with POSIX than what is documented.)
And this documentation issue seems to be in there for 20 years now.
So as far as I can see, using libregexp-shellish-perl would need some
additional regexp fiddling to fix that not-slash-matching — which I
consider to be error-prone as fixing up generated regexes has been
tried in the past and failed. And it also conflicts with the idea of
using a library to match things.
> Also, if you have any opinion on which package would do the job
> best, we would be interested to hear it so that we can make the
> right decision.
libtext-glob-perl is known to fail (see
https://bugs.debian.org/1003353) and libregexp-shellish-perl doesn't
seem to provide everything needed (or provides too much, depending on
the point of view) and doesn't look maintained at upstream anymore for
nearly two decades.
So as of now, libregexp-wildcards-perl is still my favourite even
though it doesn't look perfect either. But it at least does exactly
what we need in lintian.
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
Potential depends on libregexp-shellish-perl instead of libregexp-wildcards-perl for lintian?
Dear Debian maintainers, As part of a main inclusion review in Ubuntu [1], we are currently assessing if a potential replacement of lintian's dependency on libregexp-wildcards-perl [2] by a dependency on libregexp-shellish-perl [3] would be a good thing or not. Both packages seem to provide a similar functionality but libregexp-wildcards-perl has benefited from slightly more support (including packaging updates and availability on salsa) recently. If we were to decide that a replacement would be good in Ubuntu, would you be interested in sponsoring this change in Debian too? Also, if you have any opinion on which package would do the job best, we would be interested to hear it so that we can make the right decision. Best regards, Olivier [1] https://bugs.launchpad.net/ubuntu/+source/libregexp-wildcards-perl/+bug/1980968 [2] https://packages.debian.org/sid/libregexp-wildcards-perl [3] https://packages.debian.org/sid/libregexp-shellish-perl
Bug#1014175: warning: cannot run debian/readme check on package binary:postgresql-15_15~beta2-2+salsaci_amd64
Hi,
On 01/07/22 at 16:59 +0200, Christoph Berg wrote:
> Package: lintian
> Version: 2.115.2
> Severity: normal
>
> Hi,
>
> Lintian is currently failing in salsa-ci on postgresql-15:
>
> https://salsa.debian.org/postgresql/postgresql/-/jobs/2941498
>
> lintian --suppress-tags "${SALSA_CI_LINTIAN_SUPPRESS_TAGS}" --display-info
> --pedantic ${SALSA_CI_LINTIAN_FAIL_ARG} --allow-root
> ${SALSA_CI_LINTIAN_SHOW_OVERRIDES_ARG} ${WORKING_DIR}/*.changes | tee
> lintian.output || ECODE=$?
> Warning in processable
> /builds/postgresql/postgresql/debian/output/postgresql-15_15~beta2-2+salsaci_amd64.deb:
> Cannot open
> /tmp/lintian-pool-WqVHVEiN6s/postgresql-15/postgresql-15_15~beta2-2+salsaci_amd64_binary/unpacked/usr/share/doc/postgresql-15/README.Debian.gz
> at /usr/share/lintian/lib/Lintian/Check/Debian/Readme.pm line 109.
> warning: cannot run debian/readme check on package
> binary:postgresql-15_15~beta2-2+salsaci_amd64
> skipping check of binary:postgresql-15_15~beta2-2+salsaci_amd64
> W: postgresql-15-dbgsym: unknown-field Postgresql-Catversion
> [...]
Another occurence seems to be exim4-daemon-heavy_4.96-3_amd64.deb:
Warning in processable exim4-daemon-heavy_4.96-3_amd64.deb: Cannot open
/tmp/lintian-pool-mAn8jxow2F/exim4/exim4-daemon-heavy_4.96-3_amd64_binary/unpacked/usr/share/doc/exim4-daemon-heavy/README.Debian.gz
at /usr/share/lintian/lib/Lintian/Check/Debian/Readme.pm line 109.
warning: cannot run debian/readme check on package
binary:exim4-daemon-heavy_4.96-3_amd64
skipping check of binary:exim4-daemon-heavy_4.96-3_amd64
/usr/share/doc/exim4-daemon-heavy/README.Debian.gz is a symlink to
../exim4-base/README.Debian.gz.
Lucas
Bug#1014859: lintian: coloured background can be horrible depending on the colour scheme
Package: lintian Version: 2.115.2 Severity: minor Starting with… 2.115 I believe, lintian emits tag names with a white font and coloured background. The resulting rendering is very dependent on the terminal and colour palette the user is using, and for me the yellow and green background renders with a very poor contrast making them unreadable. See the attached screenshot for an example. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
On.
A le sa S. Coucou je à me À. A Ne. C. B à Lm q’qjl moi moopooppoippooiooikipoll m ´ il m’as’ n hui leaaˋˋ il ‘ me Q A n Claj  LoiLolo bbb hhhpupum po. Bob obhybb que Envoyé de mon iPho. ne. O. Pnk. N. ´ Sa amlQQ ko
Bug#1013331: lintian: Tag hints inside Lintian's own test suite should support wild cards to allow running it on non-amd64 hosts
Just another thought on this topic:
Axel Beckert wrote:
> https://ci.debian.net/data/autopkgtest/unstable/arm64/l/lintian/22908861/log.gz
[…]
> But simply replacing all occurrences of "x86_64" with "*" does not
> work. It though would be a start if it would work.
While having wildcards would be nice, there's probably an easier
because already implemented way:
Test description files ("desc") know about a field "Test-Architecure":
~/lintian/lintian → find t/recipes/checks -name desc | xargs fgrep amd64
t/recipes/checks/fields/multi-arch/fields-multi-arch-same-package-has-arch-specific-overrides/eval/desc:Test-Architectures:
amd64
t/recipes/checks/debian/lintian-overrides/mystery/fields-multi-arch-same-package-has-arch-specific-overrides/eval/desc:Test-Architectures:
amd64
t/recipes/checks/debian/lintian-overrides/restricted/amd64-on-arch-all/eval/desc:Testname:
amd64-on-arch-all
t/recipes/checks/debian/lintian-overrides/restricted/fields-multi-arch-same-package-has-arch-specific-overrides/eval/desc:Test-Architectures:
amd64
t/recipes/checks/debian/shlibs/binaries-multiarch/eval/desc:Test-Architectures:
i386 amd64
t/recipes/checks/files/architecture/binaries-multiarch/eval/desc:Test-Architectures:
i386 amd64
t/recipes/checks/files/architecture/binaries-multiarch-wrong-dir/eval/desc:Test-Architectures:
i386 amd64
t/recipes/checks/binaries/corrupted/binaries-from-other-arch/eval/desc:Test-Architectures:
amd64 i386
t/recipes/checks/binaries/static/binaries-from-other-arch/eval/desc:Test-Architectures:
amd64 i386
t/recipes/checks/binaries/architecture/other/binaries-from-other-arch/eval/desc:Test-Architectures:
amd64 i386
t/recipes/checks/binaries/hardening/binaries-hardening/eval/desc:Test-Architectures:
amd64 i386 armhf arm64
So we hopefully just need to add the currently on non-amd64 failing
tests to sport a "Test-Architectures: amd64" in their desc file.
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#1014175: warning: cannot run debian/readme check on package binary:postgresql-15_15~beta2-2+salsaci_amd64
Package: lintian
Version: 2.115.2
Severity: normal
Hi,
Lintian is currently failing in salsa-ci on postgresql-15:
https://salsa.debian.org/postgresql/postgresql/-/jobs/2941498
lintian --suppress-tags "${SALSA_CI_LINTIAN_SUPPRESS_TAGS}" --display-info
--pedantic ${SALSA_CI_LINTIAN_FAIL_ARG} --allow-root
${SALSA_CI_LINTIAN_SHOW_OVERRIDES_ARG} ${WORKING_DIR}/*.changes | tee
lintian.output || ECODE=$?
Warning in processable
/builds/postgresql/postgresql/debian/output/postgresql-15_15~beta2-2+salsaci_amd64.deb:
Cannot open
/tmp/lintian-pool-WqVHVEiN6s/postgresql-15/postgresql-15_15~beta2-2+salsaci_amd64_binary/unpacked/usr/share/doc/postgresql-15/README.Debian.gz
at /usr/share/lintian/lib/Lintian/Check/Debian/Readme.pm line 109.
warning: cannot run debian/readme check on package
binary:postgresql-15_15~beta2-2+salsaci_amd64
skipping check of binary:postgresql-15_15~beta2-2+salsaci_amd64
W: postgresql-15-dbgsym: unknown-field Postgresql-Catversion
[...]
Christoph
Bug#1014162: lintian's run-time is too long on some packages
Package: lintian Version: 2.115.2 Severity: normal Lintian now needs about 3 minutes to check the postgresql-15 source package alone. I'm not really willing to wait that long interactively, so chances are I'll ignore Lintian in the future more than I'd actually like to :(. Christoph
Bug#1013873: lintian: "Cannot open" warnings on symlinks to files in other packages from same source
Control: severity -1 important Hi Andreas, Andreas Metzler wrote: > lintian has recently started throwing errors like this for when run on > exim4_..._amd64.changes (source + binary upload): > > -- > Warning in processable ../exim4-daemon-heavy_4.96-1_amd64.deb: Cannot open > /dev/shm/lintian-pool-b_2HrMSwnf/exim4/exim4-daemon-heavy_4.96-1_amd64_binary/unpacked/usr/share/doc/exim4-daemon-heavy/README.Debian.gz > at /usr/share/lintian/lib/Lintian/Check/Debian/Readme.pm line 109. > warning: cannot run debian/readme check on package > binary:exim4-daemon-heavy_4.96-1_amd64 > -- Interesting. Thanks for the bug report! > The respective file is a symlink to the file in exim4-base/: > (sid)ametzler@argenau:/tmp/EXIM4/exim-4.96$ ls -l > debian/exim4-daemon-heavy/usr/share/doc/exim4-daemon-heavy/README.Debian.gz > lrwxrwxrwx 1 ametzler ametzler 30 Jun 26 11:53 > debian/exim4-daemon-heavy/usr/share/doc/exim4-daemon-heavy/README.Debian.gz > -> ../exim4-base/README.Debian.gz Since ../exim4-base/README.Debian.gz is actually existing, I wonder if that "<:gzip" in 109 open($fd, '<:gzip', $item->unpacked_path) plays a role here. My current guess is that there is a "use PerlIO::gzip;" missing in lib/Lintian/Check/Debian/Readme.pm since it it seems required to make "<:gzip" work (wonder why it does only spew runtime warnings because of that and doesn't bail out at compile time already) and it is present in quite some other Lintian Perl modules: ~/lintian/lintian → git grep PerlIO::gzip lib/Lintian/Data/Debhelper/Addons.pm:use PerlIO::gzip; lib/Lintian/Data/Debhelper/Commands.pm:use PerlIO::gzip; lib/Lintian/Data/Fonts.pm:use PerlIO::gzip; lib/Lintian/Data/InitD/VirtualFacilities.pm:use PerlIO::gzip; lib/Lintian/Processable/Installable/Overrides.pm:use PerlIO::gzip; ~/lintian/lintian → Will check. And if I'm right with my guess, I'll likely will write a test first for this type of bug as there are quite some more such cases: ~/lintian/lintian → git grep -Fl '<:gzip' | xargs fgrep -L 'use PerlIO::gzip;' lib/Lintian/Check/Debian/Readme.pm lib/Lintian/Check/Documentation.pm lib/Lintian/Check/Documentation/Manual.pm lib/Lintian/Check/Documentation/Texinfo.pm lib/Lintian/Check/Languages/Fortran/Gfortran.pm lib/Lintian/Check/Languages/R.pm lib/Lintian/Data/Authority/DocBaseManual.pm lib/Lintian/Data/Authority/VimPolicy.pm ~/lintian/lintian → Raising severity to important because this issue has quite some impact if my guess above is correct. 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
Processed: Re: Bug#1013873: lintian: "Cannot open" warnings on symlinks to files in other packages from same source
Processing control commands: > severity -1 important Bug #1013873 [lintian] lintian: "Cannot open" warnings on symlinks to files in other packages from same source Severity set to 'important' from 'normal' -- 1013873: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013873 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Processing control commands: > tag -1 - moreinfo Bug #995492 [lintian] lintian: Broken --fails-on=none as default never got reverted Removed tag(s) moreinfo. -- 995492: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995492 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Control: tag -1 - moreinfo Hi Guillem, Guillem Jover wrote: > > Can you please elaborate what exactly is the bug? You refer to > > something being problematic without explaining what actually is > > problematic. > > lintian used to exit with a non-zero value when it emitted at least > one error tag. This was changed, for some reason, and then it stopped > doing that, instead requiring users to specify --fail-on=error. This > was supposedly reverted, but the patch that got applied that fixed > this at the time of submission did not apply at the time it got > committed due to refactoring, and it was ineffective. As such the > --help output now is misleading, mentioning that the default --fail-on > is "error" when it is not. Thanks for that summary, it helped a lot. I'll have a look. > I'd have to re-dig all this. I might just try to provide a patch, I > think should probably be a one-liner. A patch of course would be nice, but I won't mind if you don't provide one. 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#995492: lintian: Broken --fails-on=none as default never got reverted
Hi! On Tue, 2022-06-14 at 01:26:02 +0200, Axel Beckert wrote: > Guillem Jover wrote: > > So the problematic --fail-on default change never got actually reverted > > as the patch applied in commit 3758bfafd5dd742c327f2312dac8e3a71b1f036e > > omitted the relevant part that would make it work. :( > > Can you please elaborate what exactly is the bug? You refer to > something being problematic without explaining what actually is > problematic. > > You refer to 3758bfafd5dd742c327f2312dac8e3a71b1f036e and > https://bugs.debian.org/962158 which has been closed about 2 years and > ca. 35 Lintian releases ago. That thread in #962158 is quite long and > difficult to grasp. lintian used to exit with a non-zero value when it emitted at least one error tag. This was changed, for some reason, and then it stopped doing that, instead requiring users to specify --fail-on=error. This was supposedly reverted, but the patch that got applied that fixed this at the time of submission did not apply at the time it got committed due to refactoring, and it was ineffective. As such the --help output now is misleading, mentioning that the default --fail-on is "error" when it is not. The above caused the below problems. ↓ > > None of the previous arguments against the default change brought up > > in #962158 have stopped being relevant (also contrary to the commit > > message…). Worse, this sneaked in what has shipped now in a stable > > Debian release. :( So any errors found in CI systems and through other > > tooling has been silently ignored since then. :/ > > This doesn't really makes the issue easier to understand. I don't ask > for a patch, but at least for a list of defects what is wrong where > and probably why. > > So far I got that there is an issue with the exit codes having changed > to be somewhat less helpful for automatic usage. (When did it change > and how? Do you happen to know a commit id? What condition should in > your opinion cause which exit code?) I'd have to re-dig all this. I might just try to provide a patch, I think should probably be a one-liner. > > Only noticed now due to #994414, a great excuse to now keep the broken > > behavior I guess. > > So this bug report actually should no more be fixed?!? The point of that comment, was that because Felix was pushing for that behavior change even when no apparent good reasons were given, and then after the behavior was supposedly reverted (but in fact it was not), when that bug report about the man page also mismatching the current behavior was filed, instead of properly fixing the behavior, he used the opportunity to keep pushing for the IMO broken behavior. > > (Where the --help output still does not match…) > > So --help seems outdated. At which line or option exactly and what > should it say instead? IMO it should stay as it is and the behavior reverted. But if you also disagree, then it should reflect reality. Thanks, Guillem
Bug#1013873: lintian: "Cannot open" warnings on symlinks to files in other packages from same source
Package: lintian Version: 2.115.1 Severity: normal X-Debbugs-Cc: ex...@packages.debian.org Hello, lintian has recently started throwing errors like this for when run on exim4_..._amd64.changes (source + binary upload): -- Warning in processable ../exim4-daemon-heavy_4.96-1_amd64.deb: Cannot open /dev/shm/lintian-pool-b_2HrMSwnf/exim4/exim4-daemon-heavy_4.96-1_amd64_binary/unpacked/usr/share/doc/exim4-daemon-heavy/README.Debian.gz at /usr/share/lintian/lib/Lintian/Check/Debian/Readme.pm line 109. warning: cannot run debian/readme check on package binary:exim4-daemon-heavy_4.96-1_amd64 -- The respective file is a symlink to the file in exim4-base/: (sid)ametzler@argenau:/tmp/EXIM4/exim-4.96$ ls -l debian/exim4-daemon-heavy/usr/share/doc/exim4-daemon-heavy/README.Debian.gz lrwxrwxrwx 1 ametzler ametzler 30 Jun 26 11:53 debian/exim4-daemon-heavy/usr/share/doc/exim4-daemon-heavy/README.Debian.gz -> ../exim4-base/README.Debian.gz cu Andreas
Bug#1013331: lintian: Tag hints inside Lintian's own test suite should support wild cards to allow running it on non-amd64 hosts
onfig-all (binary): pkg-config-multi-arch-wrong-dir full text contains architecture specific dir aarch64-linux-gnu [usr/lib/pkgconfig/indep-include-arch-2.pc] # +pkgconfig-all (binary): pkg-config-multi-arch-wrong-dir full text contains architecture specific dir aarch64-linux-gnu [usr/lib/pkgconfig/indep-include-arch-1.pc] # # Failed test 'Lintian passes for files-pkgconfig' # at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343. # Looks like you failed 1 test of 1. ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/pkgconfig/files-pkgconfig/generic.t . Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests # TODO (This tests the Todo feature in the runner.) Test Summary Report --- ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/config-scripts/files-old-config-script/generic.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/generic.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/multi-arch/files-pkgconfig/generic.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/multi-arch/files-multiarch-foreign-files/generic.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/pkgconfig/files-pkgconfig/generic.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=1476, Tests=61721, 2889 wallclock secs (12.20 usr 7.65 sys + 6797.67 cusr 1088.14 csys = 7905.66 CPU) Result: FAIL But simply replacing all occurrences of "x86_64" with "*" does not work. It though would be a start if it would work. -- 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') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-6-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.38.50.20220615-4 ii bzip2 1.0.8-5 ii clzip [lzip-decompressor] 1.13-3 ii diffstat1.64-1 ii dpkg1.21.8 ii dpkg-dev1.21.8 ii file1:5.41-4 ii gettext 0.21-6 ii gpg 2.2.35-2 ii intltool-debian 0.35.0+20060710.5 ii iso-codes 4.10.0-1 ii libapt-pkg-perl 0.1.40+b1 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-1+b2 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b8 ii libclone-perl 0.45-1+b2 ii libconfig-tiny-perl 2.28-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.29-1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-1+b3 ii libdigest-sha-perl 6.02-1+b4 ii libdpkg-perl1.21.8 ii libemail-address-xs-perl1.04-1+b4 ii libencode-perl 3.17-1 ii libfile-basedir-perl0.09-1 ii libfile-find-rule-perl 0.34-1.1 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-2 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.023-1 ii libio-prompt-tiny-perl 0.003-2 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-someutils-perl 0.58-1 ii liblist-utilsby-perl
Bug#989381: marked as done (lintian: spelling-error-in-copyright is triggering on names)
Your message dated Mon, 20 Jun 2022 14:34:13 + with message-id and subject line Bug#989381: fixed in lintian 2.115.0 has caused the Debian Bug report #989381, regarding lintian: spelling-error-in-copyright is triggering on names to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 989381: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989381 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: lintian Version: 2.104.0 Severity: normal X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, Lintian is triggering spelling-error-in-copyright upon seeing my first name (Gard) in the copyright field of some packages (example: [1]). It suggests that I should be named Guard instead. A bug filed with my parents was closed with wontfix, so I'll try the second best thing. I do not know how one would go about exempting names from such spellchecks, but could one perhaps at least whitelist the known quantity that is the maintainer's name? The bug seems at least superficially similar to #922233. [1] https://lintian.debian.org/sources/python-cdsapi Best, Gard -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.35.2-2 ii bzip2 1.0.8-4 ii diffstat1.64-1 ii dpkg1.20.9 ii dpkg-dev1.20.9 ii file1:5.39-3 ii gettext 0.21-4 ii gpg 2.2.27-2 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.39 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b7 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.26-1 ii libcpanel-json-xs-perl 4.25-1+b1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdevel-size-perl 0.83-1+b2 ii libdpkg-perl1.20.9 ii libemail-address-xs-perl1.04-1+b3 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1.1 ii libhtml-html5-entities-perl 0.004-1.1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-moreutils-perl 0.430-2 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.004004-1 ii libmoox-aliases-perl0.001006-1.1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.118-1 ii libperlio-gzip-perl 0.19-1+b7 ii libproc-processtable-perl 0.59-2+b1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libtext-glob-perl 0.11-1 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.12-1+b1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-2 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.012001-2 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.08-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl0.82+repack-1+b1 ii lzip1.22-3 ii lzop1.04-2 ii man-db 2.9.4-2 ii patchutils 0.4.2-1 ii perl [libdigest-sha-perl] 5.32.1-4 ii t1utils 1.41-4 ii unzip 6.0-26 ii xz-utils5.2.5-2 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch pn libtext-template-perl -- no debconf information --- End Message --- --- Begin Message --- Source: lintian Source-Version: 2.115.0 Done: Axel Beckert We believe that the bu
Bug#1003272: marked as done (lintian: chokes on overrides with "(" but no ")")
Your message dated Mon, 20 Jun 2022 14:34:13 +
with message-id
and subject line Bug#1003272: fixed in lintian 2.115.0
has caused the Debian Bug report #1003272,
regarding lintian: chokes on overrides with "(" but no ")"
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1003272: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003272
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: lintian
Version: 2.114.0
Severity: normal
Documentation seems to imply. that overrides only use * [1] and ? [2]
as wildcards.
However, if I have the following override:
solarpowerlog: skip-systemd-native-flag-missing-pre-depends (does not satisfy
init-system-helpers*
lintian breaks with:
Unmatched ( in regex; marked by <-- HERE in m/( <-- HERE does not satisfy
init-system-helpers.*/ at
/usr/share/lintian/bin/../lib/Lintian/Processable/Overrides.pm line 228.
Not sure if thi is just an documentation issue (is there intentional regexp
support?) or unintended behaviour.
[1] from: file:///usr/share/doc/lintian/lintian.html#overrides
Many tags can occur more than once (e.g. if the same error is found in more
than one file). You can override a tag either completely by specifying its name
(first line in the examples) or only one occurrence of it by specifying the
additional info, too (second line in the examples). If you add an asterisk (*)
in the additional info, this will match arbitrary strings similar to the shell
wildcard. For example:
[2] inconsitent/different from [1], additionally
https://lintian.debian.org/tags/mismatched-override?version=2.104.325 says
that:
"You can use wildcards, such as * or ? in the context to make a match more
likely."
--
tobi
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'),
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.15.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 binutils2.37-10.1
ii bzip2 1.0.8-5
ii diffstat1.64-1
ii dpkg1.21.1
ii dpkg-dev1.21.1
ii file1:5.41-2
ii gettext 0.21-4
ii gpg 2.2.27-3
ii intltool-debian 0.35.0+20060710.5
ii libapt-pkg-perl 0.1.40
ii libarchive-zip-perl 1.68-1
ii libcapture-tiny-perl0.48-1
ii libclass-xsaccessor-perl1.19-3+b7
ii libclone-perl 0.45-1+b1
ii libconfig-tiny-perl 2.27-1
ii libconst-fast-perl 0.014-1.1
ii libcpanel-json-xs-perl 4.27-1
ii libdata-dpath-perl 0.58-1
ii libdata-validate-domain-perl0.10-1.1
ii libdata-validate-uri-perl 0.07-1
ii libdevel-size-perl 0.83-1+b2
pn libdigest-sha-perl
ii libdpkg-perl1.21.1
ii libemail-address-xs-perl1.04-1+b3
ii libfile-basedir-perl0.09-1
ii libfile-find-rule-perl 0.34-1
ii libfont-ttf-perl1.06-1.1
ii libhtml-html5-entities-perl 0.004-1.1
ii libio-interactive-perl 1.023-1
ii libio-prompt-tiny-perl 0.003-1
ii libipc-run3-perl0.048-2
ii libjson-maybexs-perl1.004003-1
ii liblist-compare-perl0.55-1
ii liblist-someutils-perl 0.58-1
ii liblist-utilsby-perl0.11-1
ii libmoo-perl 2.005004-3
ii libmoox-aliases-perl0.001006-1.1
ii libnamespace-clean-perl 0.27-1
ii libpath-tiny-perl 0.120-1
ii libperlio-gzip-perl 0.19-1+b7
ii libperlio-utf8-strict-perl 0.008-1+b1
ii libproc-processtable-perl 0.634-1
ii libsereal-decoder-perl 4.018+ds-1+b1
ii libsereal-encoder-perl 4.018+ds-1+b1
ii libsort-versions-perl 1.62-1
ii libsyntax-keyword-try-perl 0.26-1
ii libterm-readkey-perl2.38-1+b2
ii libtext-glob-perl 0.
Bug#1001655: marked as done (Avoid hardcoding depends on specific lzip implementations)
Your message dated Mon, 20 Jun 2022 14:34:13 +
with message-id
and subject line Bug#1001655: fixed in lintian 2.115.0
has caused the Debian Bug report #1001655,
regarding Avoid hardcoding depends on specific lzip implementations
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1001655: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001655
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: lintian
Version: 2.114.0
Severity: wishlist
Hi,
in #967083, someone requested that the lintian depends on lzip should be
changed into an alternative depends on 'lzip | clzip' with the
justification, that the submitter prefered clzip as his
lzip-implementation-of-choice (for memory footprint reasons).
I'm maintaining all lzip related packages in Debian and there's a set of
provides by all lzip compressors/decompressors packages since the jessie
release in place.
May I therefore ask to have the current 'lzip | clzip' depends to be
changed into either one of these:
if only decompression is used:
'lzip | lzip-decompressor'
if only compression is used:
'lzip | lzip-compressor'
if both copmression and decompression is used:
'lzip | lzip-alternative'
This will smoothly allow using any of the packages of the lzip family to
be used, most notably the one I prefer: plzip (fully parallel version)
Regards,
Daniel
--- End Message ---
--- Begin Message ---
Source: lintian
Source-Version: 2.115.0
Done: Axel Beckert
We believe that the bug you reported is fixed in the latest version of
lintian, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1001...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Axel Beckert (supplier of updated lintian package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 20 Jun 2022 13:23:02 +0200
Source: lintian
Architecture: source
Version: 2.115.0
Distribution: unstable
Urgency: medium
Maintainer: Debian Lintian Maintainers
Changed-By: Axel Beckert
Closes: 657390 932634 941656 963099 989381 995286 996740 999768 999810 1000234
1000977 1001655 1002828 1003131 1003272 1003353 1003456 1003668 1003817 1003913
1003941 1004231 1004239 1004240 1004660 1005046 1005184 1005762 1006390 1006859
1007140 1007257 1012090
Changes:
lintian (2.115.0) unstable; urgency=medium
.
The Lintian Resurrection Release.
.
* Summary of tag changes:
+ Added:
- alien-tag
- chown-with-dot
- conflicting-test-fields
- declare-python-versions-for-test
- drop-python-version-declaration
- invalid-override-restriction
- missing-prerequisite-for-pyproject-backend
- old-devhelp-standard
- stray-devhelp-documentation
- test-leaves-python-version-untested
- uses-poetry-cli
+ Removed:
- crossing-screens
- debhelper-compatibility-level-not-a-number
- debian-tests-control-and-control-autodep8
- exclusive-runtime-tests-field
- package-contains-devhelp-file-without-symlink
.
[ Axel Beckert ]
* Adopting Lintian. (Changes #1012289 from ITA to pure RFH.)
+ Remove Chris Lamb from Uploaders (see #1012289) and re-add myself.
* Workarounds until
https://github.com/Perl-Critic/Perl-Critic/issues/925 is fixed:
+ Replace all occurrences of "Copyright ©" with "Copyright (C)" again.
+ Remove unnecessary usage of UTF-8 from bin/lintian.
+ Replace UTF-8 characters in mostly Copyright comments.
+ Replace UTF-8 characters in code with \N{…}.
* Remove literal unicode character U+0334 COMBINING TILDE OVERLAY which
likely had been added accidentally. (Triggered by the symptoms of
https://github.com/Perl-Critic/Perl-Critic/issues/925, but permanent.)
* Update copyright years in debian/copyright.
* Run perltidy over lib, bin/lintian, private/refresh-perl-provides,
private/runtests and several files in t/scripts/.
* data/…/perl-provides updated by running "debian/rules
refresh-perl-provides".
* Add Felix Lechner to debian
Processed: Re: Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Processing control commands: > tag -1 + moreinfo Bug #995492 [lintian] lintian: Broken --fails-on=none as default never got reverted Added tag(s) moreinfo. > severity -1 important Bug #995492 [lintian] lintian: Broken --fails-on=none as default never got reverted Severity set to 'important' from 'serious' -- 995492: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995492 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Control: tag -1 + moreinfo Control: severity -1 important Hi Guillem, I'm trying to catch up with that chaos which is in lintian's current state. Guillem Jover wrote: > So the problematic --fail-on default change never got actually reverted > as the patch applied in commit 3758bfafd5dd742c327f2312dac8e3a71b1f036e > omitted the relevant part that would make it work. :( Can you please elaborate what exactly is the bug? You refer to something being problematic without explaining what actually is problematic. You refer to 3758bfafd5dd742c327f2312dac8e3a71b1f036e and https://bugs.debian.org/962158 which has been closed about 2 years and ca. 35 Lintian releases ago. That thread in #962158 is quite long and difficult to grasp. > None of the previous arguments against the default change brought up > in #962158 have stopped being relevant (also contrary to the commit > message…). Worse, this sneaked in what has shipped now in a stable > Debian release. :( So any errors found in CI systems and through other > tooling has been silently ignored since then. :/ This doesn't really makes the issue easier to understand. I don't ask for a patch, but at least for a list of defects what is wrong where and probably why. So far I got that there is an issue with the exit codes having changed to be somewhat less helpful for automatic usage. (When did it change and how? Do you happen to know a commit id? What condition should in your opinion cause which exit code?) > Only noticed now due to #994414, a great excuse to now keep the broken > behavior I guess. So this bug report actually should no more be fixed?!? > (Where the --help output still does not match…) So --help seems outdated. At which line or option exactly and what should it say instead? Downgrading to import for now as I can't really fix something which is totally unclear, both, the how and the why. P.S.: Sorry if you explained that in the past, but the whole situation in general and with this issue in specific is quite tangled, so that I'd really appreciate a summary to get an idea what this bug report exactly is about. 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
Processed: retitle 1003272 to lintian: chokes on overrides with "(" but no ")"
Processing commands for cont...@bugs.debian.org:
> # Back to the original titles for these unmerged bug reports
> retitle 1003272 lintian: chokes on overrides with "(" but no ")"
Bug #1003272 [lintian] lintian: Override processing defective for square
brackets, parentheses and curly brackets
Changed Bug title to 'lintian: chokes on overrides with "(" but no ")"' from
'lintian: Override processing defective for square brackets, parentheses and
curly brackets'.
> retitle 1003353 lintian: Cannot use brackets in suppression rules?
Bug #1003353 [lintian] lintian: Override processing defective for square
brackets and curly brackets
Changed Bug title to 'lintian: Cannot use brackets in suppression rules?' from
'lintian: Override processing defective for square brackets and curly brackets'.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
1003272: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003272
1003353: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003353
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
