Bug#1051338: lintian: Downgrade wrong-path-for-interpreter from error to pedantic, merged-usr is mandatory now
Control: tags -1 patch Control: severity -1 important Control: retitle -1 Lintian raises wrong-path-for-interpreter for valid aliased paths On Wed, 6 Sep 2023 12:36:50 +0200 Julian Andres Klode wrote: > Package: lintian > Severity: normal > > Merged-usr has been mandatory since bookworm, so use of /usr/bin/sh > and such can no longer constitute an error, it's just for pedantic > people who want to stay behind the times and annoy everyone. These tags flag more things than just /bin vs /usr/bin, so rather than downgrading I think it's better to adjust the check to accept both /usr and legacy paths. I have opened a MR on Salsa to do just that: https://salsa.debian.org/lintian/lintian/-/merge_requests/478 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#859659: lintian: version-substvar-for-external-package raised for dbgsym packages from same source
On Wed, 2017-04-05 at 16:21 +, Niels Thykier wrote:
> On Wed, 5 Apr 2017 17:15:20 +0100 Luca Boccassi
> wrote:
> > Package: lintian
> > Version: 2.5.50.1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > TL;DR: Lintian reports the version-substvar-for-external-package
> > error when the
> > "external package" in question is actually a dbgsym package
> > generated by the
> > same source package.
> >
> > I maintain a source package, dpdk [1], which builds a great many
> > libraries.
> > Consequently, in stretch, a lot of dbgsym packages are generated.
> >
> > As a shortcut, a colleague wanted to add an empty metapackage,
> > libdpdk-dbgsym,
> > which depends on all the generated -dbgsym packages. Unfortunately
> > Lintian
> > raises the (unoverridable) error mentioned above due to a line
> > similar to this:
> >
> > Package: libfoo
> > ...
> >
> > Package: libbar
> > ...
> >
> > Package: foobar-dbg-meta
> > Depends: libfoo-dbgsym (= ${binary:Version}), libbar-dbgsym (=
> > ${binary:Version})
> >
> > Given all the dbgsym packages have predictable names, and are
> > created from
> > packages listed in debian/control (ie: libfoo will be in
> > d/control), could
> > Lintian perhaps recognize this and avoid raising this error?
> >
> > Thank you!
> >
> > Kind regards,
> > Luca Boccassi
> >
> > [1] https://tracker.debian.org/pkg/dpdk
> >
> > [...]
>
> Hi Luca,
>
> Unfortunately, you would just trade one issue for another (at least
> in
> Debian). The dbgsym packages is going to a separate archive and the
> original packages are therefore not permitted to depend on them (the
> debug archive is optional, dependencies being satisfiable is not).
>
> That said, I can appreciate this might make sense for third-party
> packages.
>
> Thanks,
> ~Niels
Hi Niels,
I understand, makes sense.
In our specific case at work, as you correctly guessed, we don't have a
separate archive (build and repository management system is Suse's OBS)
so it does work. Of course being an external use case from Debian I
can't ask for it to be supported, so please feel free to close the bug
if you wish.
Thanks!
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Bug#859659: lintian: version-substvar-for-external-package raised for dbgsym packages from same source
Package: lintian
Version: 2.5.50.1
Severity: normal
Dear Maintainer,
TL;DR: Lintian reports the version-substvar-for-external-package error when the
"external package" in question is actually a dbgsym package generated by the
same source package.
I maintain a source package, dpdk [1], which builds a great many libraries.
Consequently, in stretch, a lot of dbgsym packages are generated.
As a shortcut, a colleague wanted to add an empty metapackage, libdpdk-dbgsym,
which depends on all the generated -dbgsym packages. Unfortunately Lintian
raises the (unoverridable) error mentioned above due to a line similar to this:
Package: libfoo
...
Package: libbar
...
Package: foobar-dbg-meta
Depends: libfoo-dbgsym (= ${binary:Version}), libbar-dbgsym (=
${binary:Version})
Given all the dbgsym packages have predictable names, and are created from
packages listed in debian/control (ie: libfoo will be in d/control), could
Lintian perhaps recognize this and avoid raising this error?
Thank you!
Kind regards,
Luca Boccassi
[1] https://tracker.debian.org/pkg/dpdk
-- System Information:
Debian Release: 9.0
APT prefers testing-proposed-updates
APT policy: (500, 'testing-proposed-updates'), (500,
'testing-debug'), (500, 'testing'), (103, 'unstable'), (102,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages lintian depends on:
ii binutils 2.28-2
ii bzip2 1.0.6-8.1
ii diffstat 1.61-1+b1
ii file 1:5.29-3
ii gettext 0.19.8.1-2
ii intltool-debian 0.35.0+20060710.4
ii libapt-pkg-perl 0.1.32
ii libarchive-zip-perl 1.59-1
ii libclass-accessor-perl0.34-1
ii libclone-perl 0.38-2+b1
ii libdpkg-perl 1.18.23
ii libemail-valid-perl 1.202-1
ii libfile-basedir-perl 0.07-1
ii libipc-run-perl 0.94-1
ii liblist-moreutils-perl0.416-1+b1
ii libparse-debianchangelog-perl 1.2.0-12
ii libperl5.24 [libdigest-sha-perl] 5.24.1-2
ii libtext-levenshtein-perl 0.13-1
ii libtimedate-perl 2.3000-2
ii liburi-perl 1.71-1
ii libyaml-libyaml-perl 0.63-2
ii man-db2.7.6.1-2
ii patchutils0.3.4-2
ii perl 5.24.1-2
ii t1utils 1.39-2
ii xz-utils 5.2.2-1.2+b1
Versions of packages lintian recommends:
ii dpkg 1.18.23
ii libperlio-gzip-perl 0.19-1+b2
ii perl 5.24.1-2
ii perl-modules-5.24 [libautodie-perl] 5.24.1-2
Versions of packages lintian suggests:
ii binutils-multiarch 2.28-2
ii dpkg-dev 1.18.23
ii libhtml-parser-perl3.72-3
ii libtext-template-perl 1.46-1
-- no debconf information
Bug#743599: lintian: false positive python-script-but-no-python-dep when using #!/usr/bin/python2
Control: tags -1 patch On Fri, 04 Apr 2014 03:31:05 +0200 Per Andersson wrote: > Package: lintian > Version: 2.5.22.1 > Severity: normal > > Dear Maintainer, > > Including a script with shebang #!/usr/bin/python2 in a Debian package > results in lintian reporting the error python-script-but-no-python-dep. > > I believe this to be incorrect since python-minimal ships > /usr/bin/python2 as a symlink to python2.7, as per upstream PEP0394 [1]. > > > [1] http://legacy.python.org/dev/peps/pep-0394/ Dear Maintainer(s), A new script was recently added to the Linux kernel in version 4.3: https://github.com/torvalds/linux/commit/4b715d24f4f14731c7b553cbb8604fe865cb8d3c This script uses /usr/bin/python2 as shebang as indicated by pep0394, since it depends strictly on Python 2. This Lintian bug is causing it to be flagged as an error in our internal build of the kernel, so it got on our radar. The attached patch fixes the problem by having /usr/bin/python2 treated as /usr/bin/python. Would this be an acceptable solution to the problem? If not, what would you recommend? Thank you! Kind regards, Luca Boccassi Brocade Communications Systems From c9a9e433c7734737712f1fc1067bdf6966938ec1 Mon Sep 17 00:00:00 2001 From: Luca Boccassi Date: Fri, 8 Jan 2016 20:12:09 + Subject: [PATCH] Do not match /usr/bin/python2 to python2:any A python2 package does not exist, so dh_python correctly does not generate a dependency. Using /usr/bin/python2 as shebang is required as explained in pep-0394: http://legacy.python.org/dev/peps/pep-0394/ --- data/scripts/versioned-interpreters | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/data/scripts/versioned-interpreters b/data/scripts/versioned-interpreters index fff44c2..48b8cc5 100644 --- a/data/scripts/versioned-interpreters +++ b/data/scripts/versioned-interpreters @@ -75,7 +75,7 @@ lua => /usr/bin, lua([\d.]+), lua$1, 40 50 5.1 5.2 octave => /usr/bin, octave([\d.]+), octave$1, 3.0 3.2 php => /usr/bin, php(\d+), php$1-cli, 5, @NO_DEFAULT_DEPS@ pike=> /usr/bin, pike([\d.]+), pike$1 | pike$1-core, 7.6 7.8, @NO_DEFAULT_DEPS@ -python => /usr/bin, python([\d.]+), python$1:any | python$1-minimal:any, 2.7, @SKIP_UNVERSIONED@ +python => /usr/bin, python(2\..+|[3-9.]+), python$1:any | python$1-minimal:any, 2.7, @SKIP_UNVERSIONED@ ruby=> /usr/bin, ruby([\d.]+), ruby$1, 1.8 1.9, @SKIP_UNVERSIONED@ runghc => /usr/bin, runghc(\d+), ghc$1, 6, ghc scsh=> /usr/bin, scsh-([\d.]+), scsh-$1, 0.6 -- 2.1.4 signature.asc Description: This is a digitally signed message part
