Bug#890606: -lpthread
Hi,
I cannot get to the same place with 'sbuild' on experimental. How did
you do it, please? Thank you!
Are you missing an '-lpthread' in the link command? A more
sophisticated solution may involve
find_package(Threads)
and
target_link_libraries( ... Threads::Threads)
or
target_link_libraries( ... ${CMAKE_THREAD_LIBS_INIT})
in one of the CMakeLists.txt files.
Best regards,
Felix
Bug#890606: updated patch
Bernhard, Please try the attached patch. Over here, it builds kopete 17.08.3-1 from unstable against the linphone libraries in experimental. I hope it allows Linphone to enter unstable. The patch also applies to kopete 18.04.2-1 from experimental (with fuzz), but still throws the error. If it is okay with you, I will leave that for another day. Please let me know how it goes. Thank you! Kind regards, Felix fix-mediastreamer-ftbfs.patch.xz Description: application/xz
Bug#884635: Linphone block
Hi, Before removing Linphone, please have a look at the kopete patch I posted yesterday. [1] Thank you! Kind regards, Felix Lechner [1] https://bugs.debian.org/890606#48
Bug#890606: Upstream review
Hi Pino, > Can you please open a new review request upstream [1]? You will need > to download kopete from git though, although it should not be an issue > (it is like building 18.04.x from experimental). > > [1] https://phabricator.kde.org/ Here it is: https://phabricator.kde.org/D15956. Thank you! Kind regards, Felix Lechner
Bug#890606: Patch for kopete 18.04.2-1 in experimental
Hi Bernhard, Here is a patch for kopete 18.04.2-1 in experimental. Thank you! Kind regards, Felix Lechner fix-mediastreamer-ftbfs.patch.xz Description: application/xz
Bug#890606: Patch for kopete 18.04.2-1 in experimental
> However the patched source does not build against the old versions > anymore. Can this be fixed? Otherwise we cannot do the transition with a > binNMU. Bernhard, Please try the attached patch. It builds here both with the old and the new libraries. I also sent it upstream. Thank you! Best regards, Felix fix-mediastreamer-ftbfs.patch.xz Description: application/xz
Bug#906466: Upload pending
Control: severity 906466 normal Hi, A pending upload is expected to resolve this bug report. To prevent auto removal, I am downgrading the severity to normal. Thank you! Felix Lechner
Bug#903670: RFS: pius/2.2.6-1 -- Tools to help before and after key-signing parties
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pius" Package name: pius Version : 2.2.6-1 Upstream Author : Phil Dibowitz URL : http://www.phildev.net/pius/ License : GPL-2 Section : utils It builds those binary packages: pius - Tools to help before and after key-signing parties To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pius Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pius/pius_2.2.6-1.dsc Changes since the last upload: * New upstream release (Closes: #873741) * Set Build-Depends: and Depends: to python3 and friends (Closes: #902328) * Removed X-Python-Version: * Set Depends: gnupg (>= 2) (Closes: #864431) * Switched to upstream manpages (submitted from Debian) * Set Vcs-Browser: https://salsa.debian.org/lechner-guest/pius * Set Vcs-Git: https://salsa.debian.org/lechner-guest/pius.git * Switched to secure URI in copyright * Set Priority: optional (from extra) * Set Build-Depends: debhelper (>= 11) * Set compat to 11 * Set Standards-Version: 4.1.5 Regards, Felix Lechner
Bug#903677: RFS: wolfssl/3.15.3+dfsg-1 [RC] [NEW] -- wolfSSL encryption library
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "wolfssl" Package name: wolfssl Version : 3.15.3+dfsg-1 Upstream Author : wolfSSL Inc. URL : https://www.wolfssl.com/products/wolfssl/ License : GPL-2+ and others Section : libs * This shared library release has a new major number, and will require a trip through the NEW queue. It builds those binary packages: libwolfssl18 - wolfSSL encryption library libwolfssl-dev - Development files for the wolfSSL encryption library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wolfssl Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wolfssl/wolfssl_3.15.3+dfsg-1.dsc Changes since the last upload: * New upstream release * Fixes "return of the hidden number problem" CVE-2018-12436 (Closes: #901627) * Major number is now 18 * Updated shared object symbols * Debug symbol migration complete; code deleted * Shipping examples for C library * Removed doxygen-generated files from source tarball * Removed non-existing 'm4/wolfssl_darwin_clang.m4' from copyright * Updated upstream home page in control * Switched to secure URI for copyright format * Fixed spelling in patch header * Set Standards-Version: 4.1.5 * Set compat to 11 * Set Build-Depends: debhelper (>= 11) Regards, Felix Lechner
Bug#886036: Improve changelog version parsing
Hi Chris, Thank you for following up. I have more patches. I am just not sure if the version parsing should really be duplicated in Lintian. Maybe there is a benefit to checks and balances, but at least some of the work might well go into 'dpkg/scripts/Dpkg/Version.pm', which we could then use in Lintian. What do you think, please? Thank you for your guidance! Best regards, Felix On Sun, Apr 15, 2018 at 1:21 AM, Chris Lamb wrote: > Chris Lamb wrote: > >> Can you update us on the status of this issue? Did we resolve it already >> or do you have more patches ready to roll soon? :) > > Gentle ping on this? I do remember you had some patches queued up, > I just hope we/I haven't neglected them somewhere... > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`-
Bug#892122: Bright red delete confirmations do not include all files actually deleted
Package: nautilus Version: 3.26.2-2 Severity: normal Hi, I experiences a fairly serious data loss on Debian testing with nautilus 3.26.2-2. After about two weeks of uptime on kerberized NFSv4 with fs-cache, a command to delete multiple files marked graphically in Nautilus included the subdirectory most recently visited. (I had just copied a file there.) Nautilus started being sluggish a few hours earlier, perhaps because it recursively stat'ed directories. While this report potentially indicates a more serious problem, I do not have enough information to pin it on nautilus. For now, I would only like to point out that the confirmation dialog included the files I intended to delete, but not the ones actually deleted---which would have been more helpful. Thank you! Best regards, Felix -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nautilus depends on: ii desktop-file-utils 0.23-2 ii gsettings-desktop-schemas 3.27.90-1 ii gvfs 1.34.1-2 ii libatk1.0-02.26.1-3 ii libc6 2.26-6 ii libcairo-gobject2 1.15.10-1 ii libcairo2 1.15.10-1 ii libexempi3 2.4.4-1 ii libexif12 0.6.21-4 ii libgail-3-03.22.28-1 ii libgdk-pixbuf2.0-0 2.36.11-1 ii libglib2.0-0 2.54.3-2 ii libglib2.0-data2.54.3-2 ii libgnome-autoar-0-00.2.3-1 ii libgnome-desktop-3-12 3.26.2-6 ii libgtk-3-0 3.22.28-1 ii libnautilus-extension1a3.26.2-2 ii libpango-1.0-0 1.40.14-1 ii libpangocairo-1.0-01.40.14-1 ii libselinux12.7-2+b1 ii libtracker-sparql-2.0-02.0.3-1 ii libx11-6 2:1.6.4-3 ii nautilus-data 3.26.2-2 ii shared-mime-info 1.9-2 Versions of packages nautilus recommends: ii gnome-sushi 3.24.0-3 ii gvfs-backends1.34.1-2 ii librsvg2-common 2.40.20-2 Versions of packages nautilus suggests: ii eog 3.26.2-3 ii evince [pdf-viewer] 3.26.0-3 ii nautilus-extension-brasero 3.12.2-4 ii nautilus-sendto 3.8.6-2 ii totem 3.26.0-3 ii tracker 2.0.3-1 ii vlc [mp3-decoder] 3.0.0-1 ii xdg-user-dirs 0.16-1 -- no debconf information
Bug#949066: lintian: testsuite failures on arm*
Hi Gianfranco, On Thu, Jan 16, 2020 at 8:26 AM Gianfranco Costamagna wrote: > > Hello, looks like tests regressed on arm64 and armhf Thanks for pointing this out. It is a result of splitting the build and test specifications. The best thing is probably to restrict the building of affected tests with the proper wildcard in 'Package-Architecture:' in build-spec/fill-values. I will add them in the near future. A list of the test packages that failed to build on arm* would be helpful. Kind regards Felix
Bug#949166: lintian: Faulty source-is-missing lexilla.so in SciTE
Hi Andreas, On Fri, Jan 17, 2020 at 9:27 AM Andreas Ronnquist wrote: > > The problematic source package available at > https://www.scintilla.org/scite430.tgz if you would like to look at it. I cannot find a ./debian folder in this tarball. It looks more like an upstream (orig) tarball rather than a source package (.dsc). Where can I find your packaging, please? > Trying to override I get another lintian error: > > E: scite: malformed-override Override of source-is-missing for package type > source (expecting binary) at line 6 Is the override included in your source package? If not, please attach it. > I am posting this bug, since I am not sure what is the proper way to > handle this Opening bugs is always a good idea. Debian can be complicated, and we are happy to help. Kind regards Felix Lechner
Bug#949166: lintian: Faulty source-is-missing lexilla.so in SciTE
Hi Andreas, On Fri, Jan 17, 2020 at 1:35 PM Andreas Ronnquist wrote: > > On Fri, 17 Jan 2020 12:10:07 -0800 > Felix Lechner wrote: > > If I use an override like this: > > > scite source: source-is-missing scintilla/bin/lexilla.so > > I get two Lintian errors: > > E: scite source: source-is-missing scintilla/bin/lexilla.so > E: scite: malformed-override Override of source-is-missing for package > type source (expecting binary) at line 6 The Lintian tag output takes some time to get used to. The first error relates to a 'scite*.dsc' while the second relates to a 'scite_*.deb'. It is a coincidence---confusing here---that both have the same name. Lintian overrides for source packages live in ./debian/source/lintian-overrides. The format with 'source' is not permitted for ./debian/scite.lintian-overrides, which is for the installation package (deb). > - but if I instead use it without the "source" field like this: > > > scite: source-is-missing scintilla/bin/lexilla.so My recommendation is to strip the package indicator altogether, i.e. just 'source-is-missing scintilla/bin/lexilla.so'. The file location will provide the other information. > I also get two lintian items (different ones, of course): > > E: scite source: source-is-missing scintilla/bin/lexilla.so > I: scite: unused-override source-is-missing scintilla/bin/lexilla.so Please try moving the override file to the ./debian/source/lintian-overrides. > Is it as simple as the only way to solve this is repackaging upstream > removing the unused .so? As I said earlier, the source for lexilla.so > _is_ there in the upstream source. Repacking is a good long-term solution. If upstream is happy to remove the offending file in a future release, I might override it, BUT the source must be present to avoid violating the DFSG. Please leave a comment line starting with # above the override. For a definitive answer on best practices on this point, please ask on #debian-mentors. Kind regards, Felix Lechner
Bug#948033: lintian: Fortran test fails on 'flang' mod files
Hi Alastair, On Fri, Jan 3, 2020 at 6:33 AM Alastair McKinstry wrote: > > /usr/share/lintian/checks/fortran.pm checks the 'mod' files for Fortran. To make space for flang, the gfortran check was moved to checks/fortran/gfortran.pm. > I'm adding support for the flang fortran compiler , which ships mod files > that are in a different format. > > flang mod files should be found in $LIBDIR/fortran/flang-$(version) The gfortran check now disregards paths containing /flang-\d+/. Gfortran modules do not appear to be similarly contained. For example, libopenmpi-dev ships both /usr/lib/x86_64-linux-gnu/openmpi/lib/mpi.mod /usr/lib/x86_64-linux-gnu/fortran/gfortran-mod-15/openmpi/mpi.mod They look identical but are not linked (and carry different permissions). Also, gfortran itself ships modules in yet another location, such as /usr/lib/gcc/x86_64-linux-gnu/8/finclude/openacc.mod The file magic for these modules is merely 'gzip', which means we have to use paths to distinguish them. If you have any say, it might make sense to group gfortran modules in fewer places. Grub and Libreoffice also ship .mod files. They are likewise excluded. > New lintian tests should be added We are happy to create a new check in checks/fortran/flang.pm for you when you are ready. Kind regards Felix Lechner
Bug#948033: Fwd: Bug#948033: lintian: Fortran test fails on 'flang' mod files
Copying bug on Alastair's response. -- Forwarded message - From: Alastair McKinstry Date: Thu, Jan 23, 2020 at 8:16 AM Subject: Re: Bug#948033: lintian: Fortran test fails on 'flang' mod files To: Felix Lechner On 23/01/2020 15:39, Felix Lechner wrote: > Hi Alastair, > > On Fri, Jan 3, 2020 at 6:33 AM Alastair McKinstry > wrote: >> /usr/share/lintian/checks/fortran.pm checks the 'mod' files for Fortran. > To make space for flang, the gfortran check was moved to > checks/fortran/gfortran.pm. Thanks. >> I'm adding support for the flang fortran compiler , which ships mod files >> that are in a different format. >> >> flang mod files should be found in $LIBDIR/fortran/flang-$(version) > The gfortran check now disregards paths containing /flang-\d+/. > > Gfortran modules do not appear to be similarly contained. For example, > libopenmpi-dev ships both > > /usr/lib/x86_64-linux-gnu/openmpi/lib/mpi.mod > /usr/lib/x86_64-linux-gnu/fortran/gfortran-mod-15/openmpi/mpi.mod I'm the maintainer of openmpi, and used it as a testbed -- the first path is the original (expected by many rdeps), the second is the preferred, but depends on a patch not yet in gfortran upstream. > They look identical but are not linked (and carry different > permissions). Also, gfortran itself ships modules in yet another > location, such as > > /usr/lib/gcc/x86_64-linux-gnu/8/finclude/openacc.mod > > The file magic for these modules is merely 'gzip', which means we have > to use paths to distinguish them. If you have any say, it might make > sense to group gfortran modules in fewer places. Yes. The draft Fortran policy / recommendations that I'm writing include explicitly that, and I'll be submitting patches to move mod files from $include to $libdir/fortran/gfortran-mod-15 (Fortran does not change its modversion regularly so I'm reluctant to put them in the gcc subdir, which is version-dependent) > Grub and Libreoffice also ship .mod files. They are likewise excluded. > >> New lintian tests should be added > We are happy to create a new check in checks/fortran/flang.pm for you > when you are ready. > > Kind regards > Felix Lechner Kind Regards Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#949398: marked as pending in lintian
Hi, On Thu, Jan 23, 2020 at 1:57 PM Niels Thykier wrote: > > Thanks for the quick response time and a fix. :) Please feel free to restart lintian.d.o. (I do not have access.) I think it's been down for months. Also, please note that I fixed much of the blacklist (per #946320) but cannot adjust it. Kind regards Felix
Bug#949398: marked as pending in lintian
Hi Chris, On Thu, Jan 23, 2020 at 2:20 PM Chris Lamb wrote: > > I plan to release Lintian tomorrow (ie. Friday 24th Jan) or > more accurately when the current version in unstable migrates to > testing. Please note that the next release will probably not migrate until #949066 is fixed. I am working on it with the dpkg maintainers. Kind regards Felix Lechner
Bug#898246: git-lab requires golang-github-xanzy-go-gitlab
Hi, On Sun, Dec 15, 2019 at 7:46 AM Dominique Dumont wrote: > > Felix, could you resume packaging this software ? Do you know anyone with upload privileges? :) Please feel free to upload the required prerequisite golang-github-xanzy-go-gitlab in #947304. My RFS had no takers for a month. I will package git-lab for you afterwards. Kind regards Felix
Bug#949066: lintian: testsuite failures on arm*
Hi Gianfranco, On Fri, Jan 24, 2020 at 8:39 AM Gianfranco Costamagna wrote: > > Felix gentle ping please? > (in Ubuntu I disabled that test BTW and the result package autopkgtestsuite > was green on all archs) The release took place solely to facilitate upgrading lintian.d.o, which has been down for months. Details are in #949398; your bug is mentioned there. I have been working with the dpkg maintainers on a solution, which will not happen anytime soon. The underlying problem is that dpkg-buildpackage issues a build error when there is simply nothing to do. Fixing that is complicated because source packages nowadays permit the building of undeclared artifacts. There is no longer a way to tell from a source package if a build should be attempted. Either way, I will triage your bug later today. Thank you for your patience and for your help in trying to make Lintian better for everyone. Kind regards Felix
Bug#935070: [lintian] Tags are too similar
Hi Thorsten, On Fri, Jan 24, 2020 at 6:50 AM Thorsten Glaser wrote: > > - latest-debian-changelog-entry-reuses-existing-version checks that > the version without the epoch is never reused, for the archive and > snapshots to be consistent (as the epoch is not used in filenames) > > - latest-debian-changelog-entry-without-new-version checks that the > upload does not have a smaller (or equal) version number to the > previous upload except in backports, to ensure that it’ll be newer > and nobody forgot a version increment before uploading As you point out, the former strips the epoch before comparing. It seemed to include the latter (and both tags had the same severity). > PS: Personally I’m not negatively affected by removal of the latter, > it was always annoying for local backports, but it might have >saved someone else from a brown paper bag upload… Did you see a d/changelog that triggered the latter but not the former? Kind regards Felix Lechner
Bug#935070: [lintian] Tags are too similar
Control: reopen -1 > > Did you see a d/changelog that triggered the latter but not the former? > > Yes:packagename (upstreamversion-1~wtf1) > followed by packagename (upstreamversion-1) > > (or even ~bpo10+1, when there was not the word “backport” in the > changelog text) Reopening for further examination.
Bug#898246: git-lab requires golang-github-xanzy-go-gitlab
Hi Julian, On Fri, Jan 24, 2020 at 3:39 AM Julian Gilbey wrote: > > The version of xanzy in debian/sid on salsa is very out of date - the > upstream version is now 0.22, but debian/sid is lagging on 0.15. State of package on Mentors (based on upstream's version 0.22) was pushed to the golang team repo. Kind regards Felix Lechner
Bug#1010703: haskell-hashable: FTBFS on i386: unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64'
Control: reassign -1 haskell-devscripts
Control: retitle -1 haskell-devscripts: Shell expansion breaks nested
quotes in GHC arguments
Control: affects -1 haskell-hashable
Hi,
> unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64'
I believe the quotes in haskell-hashable here: [1]
DEB_SETUP_GHC_CONFIGURE_ARGS = --hsc2hs-options="$(LFS_CFLAGS)"
--gcc-options="$(LFS_CFLAGS)" --ghc-options="$(GHC_LFSFLAGS)"
are lost when the environment variable is shell-expanded in
haskell-devscripts here: [2]
# DEB_SETUP_GHC_CONFIGURE_ARGS can contain multiple arguments
# with their own quoting so run through a shell expansion
my $ghc_configure_args = run_quiet(
qw{sh -c},
'echo -n '
. $DOUBLE_QUOTE
. ($ENV{DEB_SETUP_GHC_CONFIGURE_ARGS} // $EMPTY)
. $DOUBLE_QUOTE
);
Kind regards,
Felix Lechner
[1]
https://salsa.debian.org/haskell-team/DHG_packages/-/blob/master/p/haskell-hashable/debian/rules#L6
[2]
https://salsa.debian.org/haskell-team/haskell-devscripts/-/blob/master/lib/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm#L597-605
Bug#1010930: guix: May need CA certificates
Package: guix Severity: wishlist Hi, I used guix on a minimal Debian 11 to cross-install the Guix System and ran 'guix pull' before doing so. When I adapted the first file here [1] 'guix system init' failed due to missing certificates. The issue went away after I installed the standard certificate bundle via 'apt install ca-certificates'. On an unrelated side note, 'info guix' showed information in Spanish despite LC_ALL=en_US.UTF-8. That was from Debian's 'info', which I had installed with 'apt install info'. Thanks for bringing the great Guix package manager to Debian! I believe it is superior to Dpkg. Kind regards Felix Lechner [1] https://guix.gnu.org/manual/en/html_node/Using-the-Configuration-System.html
Bug#1009162: cabal-debian: Description in the Source section in d/control
Package: cabal-debian Severity: wishlist Hi, The Haskel tooling in Debian may be able to use the Description field in the Source paragraph of d/control without the X- prefix. For the relevant policy discussion, please see here. [1] Lintian allows the field already. [2] Kind regards Felix Lechner [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998165#81 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998115#28
Bug#994388: dpkg currently warning about merged-usr systems
Hi, On Fri, Apr 8, 2022 at 1:48 AM Wouter Verhelst wrote: > > The nuclear option here is obviously to take maintenance of dpkg away > from the dpkg maintainer unless and until he decides to follow the > rules. This song is for Guillem: https://www.youtube.com/watch?v=cnoX81TC6jk Kind regards, Felix Lechner
Bug#1009679: lintian: False positive for OCaml info files
Hi Rafael, On Thu, Apr 14, 2022 at 2:09 AM Rafael Laboissière wrote: > > See > https://salsa.debian.org/ocaml-team/dh-ocaml/-/commit/eae9dc26 What is the purpose of those files, please? Are they used in the oCaml Lintian check? Kind regards Felix Lechner
Bug#1009743: haskell-devscripts: recent changes cause haskell-hspec-discover to FTBFS
Control: fixed -1 0.16.11
Hi Scott,
I believe you saw a temporary malfunction. The sources for
haskell-hspec-discover_2.7.1 built locally with haskell-devscripts
0.16.11 in unstable. The tail of the log is below.
The disruption was caused by an effort to make the current build
system compatible with Debhelper's dh sequencer.
Thank you for your patience!
Kind regards,
Felix Lechner
* * *
[start of build log omitted]
dh_gencontrol -phspec-discover
dpkg-gencontrol: warning: package hspec-discover: substitution
variable ${haskell:ghc-version} unused, but is defined
dh_md5sums -phspec-discover
dh_builddeb -phspec-discover
dpkg-deb: building package 'hspec-discover' in
'../hspec-discover_2.7.1-1_amd64.deb'.
dpkg-genbuildinfo
dpkg-genchanges >../haskell-hspec-discover_2.7.1-1_amd64.changes
dpkg-genchanges: info: including full source code in upload
dpkg-source --after-build .
dpkg-buildpackage: info: full upload (original source is included)
Now running lintian haskell-hspec-discover_2.7.1-1_amd64.changes ...
W: hspec-discover: hardening-no-pie usr/bin/hspec-discover
W: haskell-hspec-discover source:
missing-license-paragraph-in-dep5-copyright debian/copyright mit (line
12)
W: haskell-hspec-discover source:
missing-license-text-in-dep5-copyright debian/copyright MIT (line 14)
W: hspec-discover: no-manual-page usr/bin/hspec-discover
W: haskell-hspec-discover source: no-nmu-in-changelog
W: haskell-hspec-discover source:
source-nmu-has-incorrect-version-number 2.7.1-1
I: hspec-discover: hardening-no-bindnow usr/bin/hspec-discover
I: hspec-discover: hardening-no-fortify-functions usr/bin/hspec-discover
I: haskell-hspec-discover source: older-debian-watch-file-standard 3
I: haskell-hspec-discover source: out-of-date-standards-version 4.1.4
(released 2018-04-05) (current is 4.6.0.1)
I: hspec-discover: unused-override binary-or-shlib-defines-rpath
X: haskell-hspec-discover source: debian-watch-does-not-check-gpg-signature
P: haskell-hspec-discover source: package-uses-old-debhelper-compat-version 10
P: hspec-discover: renamed-tag binary-or-shlib-defines-rpath =>
custom-library-search-path in line 1
X: haskell-hspec-discover source: upstream-metadata-file-is-missing
Finished running lintian.
Bug#999738: Sample research tag, untested
diff --git a/lib/Lintian/Check/Languages/Guile/DynamicLink.pm
b/lib/Lintian/Check/Languages/Guile/DynamicLink.pm
new file mode 100644
index 00..dcbd250139
--- /dev/null
+++ b/lib/Lintian/Check/Languages/Guile/DynamicLink.pm
@@ -0,0 +1,68 @@
+# languages/guile/dynamic-link -- lintian check script -*- perl -*-
+
+# Copyright © 2021 Felix Lechner
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, you can find it on the World Wide
+# Web at http://www.gnu.org/copyleft/gpl.html, or write to the Free
+# Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+# MA 02110-1301, USA.
+
+package Lintian::Check::Languages::Guile::DynamicLink;
+
+use v5.20;
+use warnings;
+use utf8;
+
+use Const::Fast;
+usa List::SomeUtils qw(uniq);
+
+use Moo;
+use namespace::clean;
+
+with 'Lintian::Check';
+
+const my $LEFT_SQUARE_BRACKET => q{[};
+const my $RIGHT_SQUARE_BRACKET => q{]};
+
+sub visit_installed_files {
+my ($self, $item) = @_;
+
+return
+ unless $item->name =~ m{ [.] scm $}x
+ || $item->interpreter eq 'guile';
+
+# slurping contents for now
+my $contents = $item->decoded_utf8;
+return
+ unless length $contents;
+
+my @libraries
+ = ($contents
+ =~ m{ [(] define \s+ \S+ \s+ [(] dynamic-link \s+ "([^"]+)"
[)] [)] }gx
+ );
+
+$self->hint('guile-dynamic-link', $_,
+$LEFT_SQUARE_BRACKET . $item->name . $RIGHT_SQUARE_BRACKET)
+ for uniq @libraries;
+
+return;
+}
+
+1;
+
+# Local Variables:
+# indent-tabs-mode: nil
+# cperl-indent-level: 4
+# End:
+# vim: syntax=perl sw=4 sts=4 sr et
diff --git a/tags/g/guile-dynamic-link.tag b/tags/g/guile-dynamic-link.tag
new file mode 100644
index 00..d1faa0b92d
--- /dev/null
+++ b/tags/g/guile-dynamic-link.tag
@@ -0,0 +1,7 @@
+Tag: guile-dynamic-link
+Severity: classification
+Check: languages/guile/dynamic-link
+Explanation: Guile tries to load this shared library via a Scheme
expression like
+ (define libglib (dynamic-link "libglib-2.0")).
+See-Also:
+ Bug#999738
Bug#1009975: O: libgsm -- Shared libraries for GSM speech compressor
Package: wnpp Severity: normal Hi, This package is low maintenance and now available for your adoption! Kind regards, Felix Lechner
Bug#1009978: O: gammastep -- Adjust display hue to outside lighting conditions
Package: wnpp Severity: normal Hi, This package is low maintenance and now available for your adoption! Kind regards, Felix Lechner
Bug#1009980: O: wxedid -- Graphical editor for monitor resolution and timing data (EDID)
Package: wnpp Severity: normal Hi, This package is low maintenance and now available for your adoption! You can use this software when repairing your monitor's EDID. [1] Kind regards, Felix Lechner [1] https://wiki.debian.org/RepairEDID
Bug#1009982: O: pius -- Tools to help before and after key-signing parties
Package: wnpp Severity: normal Hi, This package is low maintenance and now available for your adoption! Kind regards, Felix Lechner
Bug#1009983: O: mdadm -- Tool to administer Linux MD arrays (software RAID)
Package: wnpp Severity: normal Hi, This is an exciting opportunity to assume maintenance of an important package. It is now available for your adoption! Kind regards, Felix Lechner
Bug#1009988: O: postgresql-semver -- Semantic version number type for PostgreSQL
Package: wnpp Severity: normal Hi, This Postgres data type was used for the most recent Lintian website. Kind regards, Felix Lechner
Bug#1009883: dh_haskell_install_ghc_registration: does not support directories
Hi Scott, > It's not quite clear to me how a directory is supposed to be handled First off, thank you for your bug reports. I recently rewrote the Haskell tooling to allow the use of Debhelper's dh sequencer with all features. Unfortunately, I recently started using another OS and may not be able to iron out all the kinks in the new code. As for this bug, I was aware that I broke the directory feature but, like you, was also not sure right away about how to handle it properly. The directory feature for package registrations is described in the documentation. [1] Kind regards Felix Lechner [1] https://downloads.haskell.org/cabal/Cabal-3.0.0.0/doc/users-guide/installing-packages.html#cmdoption-setup-register-gen-pkg-config
Bug#1010025: ghc: Haddock fails with internal error when calculating transitive dependencies
Hi Scott, > Warning: The documentation for the following packages are not installed. No > links will be generated to these packages: dlist-0.8.0.8, hashable-1.3.0.0, > transformers-compat-0.6.5 Can you please try to see if the error goes away when those prerequisites are made available? I believe they are in: libghc-dlist-doc libghc-hashable-doc libghc-transformers-compat-doc Thanks! Kind regards Felix Lechner
Bug#1010025: ghc: Haddock fails with internal error when calculating transitive dependencies
Hi Scott, On Tue, Apr 26, 2022 at 7:23 AM Scott Talbert wrote: > > it's a core package and I'm new here I'm also not the right person to merge it, but I think Debian may be getting a new GHC version soon. Was the fix applied upstream? Kind regards Felix Lechner
Bug#1006573: haskell-devscripts: CDBS module incompatible with debhelper-compat (= 10)
Package: haskell-devscripts Severity: wishlist Hi, In my 'kickoff' sources, which use the CDBS module hlibrary.mk, the d/compat file must be present. When I delete d/compat and instead specify debhelper-compat (= 10) in Build-Depends, a d/compat file with the value '5' is created. That causes follow-on issues like the one at the bottom of this message. This bug is merely a wishlist item in case someone plans to fix hlibrary.mk. The issue goes away with the dh sequencer from dh-haskell, which may be a better option for other reasons, as well. Kind regards Felix Lechner * * * ➤ debclean Cleaning in directory /lcl/lechner/lintian/kickoff dpkg-buildpackage --rules-target clean -rfakeroot -us -uc -ui dpkg-buildpackage: info: source package kickoff dpkg-buildpackage: info: source version 0.1.0 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Felix Lechner debian/rules clean test -x debian/rules rm -f debian/stamp-makefile-build debian/stamp-makefile-install /usr/bin/make -C . CFLAGS="-g -O2 -ffile-prefix-map=/lcl/lechner/lintian/kickoff=. -fstack-protector-strong -Wformat -Werror=format-security" CXXFLAGS="-g -O2 -ffile-prefix-map=/lcl/lechner/lintian/kickoff=. -fstack-protector-strong -Wformat -Werror=format-security" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro" -k clean make[1]: Entering directory '/lcl/lechner/lintian/kickoff' cabal clean make[1]: Leaving directory '/lcl/lechner/lintian/kickoff' dh_clean dh_clean: warning: Please specify the debhelper compat level exactly once. dh_clean: warning: * debian/compat requests compat 5. dh_clean: warning: * debian/control requests compat 10 via "debhelper-compat (= 10)" dh_clean: warning: dh_clean: warning: Hint: If you just added a build-dependency on debhelper-compat, then please remember to remove debian/compat dh_clean: warning: dh_clean: error: debhelper compat level specified both in debian/compat and via build-dependency on debhelper-compat make: *** [/usr/share/cdbs/1/rules/debhelper.mk:211: clean] Error 255 dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2 debuild: fatal error at line 1182: dpkg-buildpackage --rules-target clean -rfakeroot -us -uc -ui failed
Bug#865640: dh-haskell: messes up substvars
Hi,
I am not sure this bug still exists with the rewrite of dh-haskell,
but please see below.
The dh sequencer now calls the same routines from Dh_Haskell.sh that
are also used by hlibrary.mk (both from haskell-devscripts), but under
both build systems I see the following messages for my source
'kickoff':
dpkg-gencontrol: warning: Depends field of package kickoff:
substitution variable ${haskell:Depends} used, but is not defined
dpkg-gencontrol: warning: Recommends field of package kickoff:
substitution variable ${haskell:Recommends} used, but is not defined
dpkg-gencontrol: warning: Suggests field of package kickoff:
substitution variable ${haskell:Suggests} used, but is not defined
dpkg-gencontrol: warning: Conflicts field of package kickoff:
substitution variable ${haskell:Conflicts} used, but is not defined
dpkg-gencontrol: warning: Provides field of package kickoff:
substitution variable ${haskell:Provides} used, but is not defined
There is also that one, but it may be less relevant:
dpkg-gencontrol: warning: package kickoff: substitution variable
${haskell:ghc-version} unused, but is defined
Kind regards
Felix Lechner
Bug#842549: haskell-devscripts: Dh_Haskell.sh should respect DH_VERBOSE settings
Hi, > Dh_Haskell.sh doesn't respect the DH_VERBOSE settings Dh_Haskell.sh cannot do that very well—at least not with respect to suppressing output—because callers of the shell functions rely on information in stdout for results. (The functions also reuse each other.) In a potential step forward, however, I wrote a Perl module that will soon sidestep Dh_Haskell.sh when builds are started from dh-haskell's dh sequencer. That Perl module will honor DH_VERBOSE. A merge request is in the works and will be submitted when testing is complete. Kind regards, Felix Lechner
Bug#1006464: Please use "mdadm monitoring " as default MAILFROM
Hi, On Fri, Feb 25, 2022 at 1:06 PM Marvin Renich wrote: > > create a default From address that is useful when root's mail is being > forwarded off the current system We just released 4.2-2 in order to address this issue in part. Hoping to improve the default MAILFROM value for all users we merely added the host name for now. That value was readily available in upstream's code. The patch has a better chance of being accepted upstream. The /etc/mailname mechanism is specific to Debian. A later release of mdadm in Debian may bring the MAILFROM value into compliance with Debian mail customs. I tried to test the change but my local mail server replaces all From addresses with meaningful values. (It was my fix for the reporter's issue.) Please let us know if this patch does not work as expected. Salsa is currently down. The patch is instead attached for your review. Kind regards Felix Lechner Description: Add host name to default MAILFROM The host on which the error occurred is mentioned in the subject and also in the message body, but some may find it useful in the From address, as well. Author: Felix Lechner Bug-Debian: https://bugs.debian.org/1006464 Forwarded: no --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- a/Monitor.c +++ b/Monitor.c @@ -440,8 +440,8 @@ static void alert(char *event, char *dev if (info->mailfrom) fprintf(mp, "From: %s\n", info->mailfrom); else -fprintf(mp, "From: %s monitoring \n", - Name); +fprintf(mp, "From: %s monitoring \n", + Name, hname); fprintf(mp, "To: %s\n", info->mailaddr); fprintf(mp, "Subject: %s event on %s:%s\n\n", event, dev, hname);
Bug#1006866: ITP: hackage-tracker -- Haskell package version tracker
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-hask...@lists.debian.org X-Debbugs-Cc: Joachim Breitner * Package name: hackage-tracker Version : 0.1.0 Upstream Author : Felix Lechner * URL : https://salsa.debian.org/haskell-team/hackage-tracker * License : AGPL-3.0-or-later Programming Lang: Haskell2010 Description : Haskell package version tracker Generates a file with information that can be used to update the Debian versions on Hackage for each package available there. Those versions appear in the Distribution field on Hackage. Furthermore produces an HTML page that compares the Haskell package versions available in Debian with those available on Hackage and elsewhere. The data is currently displayed at https://hackage-tracker.debian.net. This software falls under the Haskell team's umbrella and will be updated, managed and serviced going forward by members of the Haskell team.
Bug#998367: perlcritic: "Code not tidy' after perltidy
Hi, On Sun, Nov 7, 2021 at 11:37 PM intrigeri wrote: > > The bug lies in the interaction between these 2 tools. Yay, the problem was solved! [1] Will you please deploy the fix with a little bit of urgency? Lintian's pipeline has been malfunctioning for a little while. Thanks! Kind regards, Felix Lechner [1] https://github.com/Perl-Critic/Perl-Critic/issues/925#issuecomment-1048340859
Bug#1007140: please have a check for chown user.group
Hi, On Fri, Mar 11, 2022 at 1:18 PM Marc Haber wrote: > > [^[:alpha:]]chown[[:space:]][^[:space:]]+\.[^[:space:]] I cannot get that search to work properly on codesearch.d.n. Do you have a sample from the archive, please? Kind regards Felix Lechner
Bug#1007261: bullseye-pu: wolfssl/4.6.0-3_4.6.0+p1-1.debdiff
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hi, The wolfssl upstream released a fixed version [1] of their library (4.6.0) that we already have in stable. Upstream would now like to see the fixed version in stable, if possible. The six fixes are not large, but all of them address grave or serious CVEs. * PR 3676: CVE-2021-3336 * PR 3990: OCSP Match Issue * PR 4211: CVE-2021-38597 * PR 4629: CVE-2021-44718 * PR 4813: CVE-2022-25638 * PR 4831: CVE-2022-25640 They relate to wolfSSL's support for TLS 1.3, which they were the first to implement commercially. [2] More details, including URLs, are available below. According to upstream, the fixed version includes no new features. All six patches are already in version 5.2.0-2 in testing and unstable, as well as in 5.2.0-2~bpo11+1 in bullseye-backports. One Debian patch already addressed CVE-2021-3336. It had been cherry-picked and was dropped with the availability of this version. Given the issue with openssl/valgrind years ago, I asked upstream to maintain a "stable" branch with a four-eye review by another member of the cryptographic staff. As their Debian distributor, I prefer not to backport fixes from Git myself. As mentioned in the changelog, upstream also updated some certificates in the test suite. Following devref 5.5.1, a source debdiff was attached. Thank you for your guidance! Kind regards, Felix Lechner P.S. I used to work upstream. [1] look for +p1, https://github.com/wolfSSL/wolfssl/releases/tag/v4.6.0-stable [2] https://www.prweb.com/releases/wolfssl_announces_the_first_commercial_release_of_tls_1_3/prweb15672854.htm * * * Hi Felix, No risks. The code in the affected areas hasn’t changed and has been broken since our TLS v1.3 support was originally created. Tomorrow morning I’ll put together a package and sign it and have another engineer review and sign it also. * * * Hey Felix, In order to update the stable v4.6.0 on Debian I’ve back-ported the following high severity fixes to v4.6.0-stable: * PR 3676: CVE-2021-3336 * PR 3990: OCSP Match Issue * PR 4211: CVE-2021-38597 * PR 4629: CVE-2021-44718 * PR 4813: CVE-2022-25638 * PR 4831: CVE-2022-25640 I’ve posted a +p1 bundle and signature to the release page here: https://github.com/wolfSSL/wolfssl/releases/tag/v4.6.0-stable * wolfssl-4.6.0-stable+p1.tar.gz (SHA256: 3a112c1436bbd1afdb457d0a517312d03ab430c74b98f95a20a028d41440099e) * wolfssl-4.6.0-stable+p1.tar.gz.asc Note: The make check fails due to some expired certificates. If you think it is important I can update those expired certs in the bundle and re-sign re-post… * * * Hey Felix, FYI: Here is the script I’ve written up to create a new official patch. This is my take on patches that should be applied. #!/bin/bash # Get Release curl -L -o wolfssl-4.6.0-stable.tar.gz https://github.com/wolfSSL/wolfssl/archive/refs/tags/v4.6.0-stable.tar.gz tar xzvf wolfssl-4.6.0-stable.tar.gz cd wolfssl-4.6.0-stable # CVE-2021-3336 curl -L -o pr3676.diff https://github.com/wolfSSL/wolfssl/pull/3676.diff patch -p1 < pr3676.diff # OCSP Match Issue curl -L -o pr3990.diff https://github.com/wolfSSL/wolfssl/pull/3990.diff patch -p1 < pr3990.diff # CVE-2021-38597 curl -L -o pr4211.diff https://github.com/wolfSSL/wolfssl/pull/4211.diff patch -p1 < pr4211.diff # CVE-2021-44718 curl -L -o pr4629.diff https://github.com/wolfSSL/wolfssl/pull/4629.diff patch -p1 < pr4629.diff # CVE-2022-25638 curl -L -o pr4813.diff https://github.com/wolfSSL/wolfssl/pull/4813.diff patch -p1 < pr4813.diff # CVE-2022-25640 curl -L -o pr4831.diff https://github.com/wolfSSL/wolfssl/pull/4831.diff patch -p1 < pr4831.diff rm *.diff cd .. # Tar/GZ tar -czvf wolfssl-4.6.0-stable-patched.tar.gz wolfssl-4.6.0-stable # Sign gpg --armor --default-key 5CA29677 --detach-sign wolfssl-4.6.0-stable-patched.tar.gz shasum -a 256 wolfssl-4.6.0-stable-patched.tar.gz wolfssl_4.6.0-3.dsc_wolfssl_4.6.0+p1-1.dsc.debdiff.xz Description: application/xz
Bug#554006: lintian: Warn if package ships files in /etc/cron.* without depending on cron
Hi, On Mon, Mar 14, 2022 at 1:36 PM Josh Triplett wrote: > > I don't think lintian should warn about this, for two reasons: Are you saying the condition should indicate a visibility level lower than a warning, or that the tag should not be implemented at all? Thank you! Kind regards, Felix Lechner
Bug#1007717: Native source package format with non-native version
Hi Ian, On Tue, Mar 15, 2022 at 11:54 AM Ian Jackson wrote: > > I do remember this coming up > before, but I don't seem to be able to find a record of it now. Perhaps you were thinking about this discussion in a bug against Lintian? Ideally I would like dpkg-source to permit source format `3.0 (native)' packages to have a non-native version number. [1] Kind regards, Felix Lechner [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953554#30
Bug#1007717: Native source package format with non-native version
Hi, On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery wrote: > > We should define native and non-native > packages in terms of version numbers, and allow both native and non-native > packages to use single-tarball source package formats. I co-maintaintain several Debian-internal tools, and that description is backwards. "Native" sources are characterized by their lack of Debian patches. On that note, the term "native" is also not great. The words "patched" and "unpatched" describe the relationship between sources in the archive and their respective upstreams more accurately. As for version strings, we need no additional restrictions. The use of patches is declared in source format 3.0. Some folks even use Debian revisions for unpatched sources. [1] Most significantly, Lintian's parser is unable to deduce "nativeness" from the version number. The native status is a required input! [2] Please do not "define" a source's patch status via the version string. It's what got us here in the first place. Debian version numbers are complicated enough already. Thank you! Kind regards, Felix Lechner [1] for example, https://tracker.debian.org/pkg/python3-defaults [2] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Changelog/Version.pm#L79-80
Bug#1007261: bullseye-pu: wolfssl/4.6.0-3_4.6.0+p1-1.debdiff updated
Hi, The attached debdiff contains an updated d/changelog (plus, an excerpt below): (1) The target release now says 'bullseye'. (2) Pursuant to a request from the security team, the annotation CVE-2021-37155 was added to PR 3990. Is this ready to upload? Thanks! Kind regards, Felix Lechner * * * wolfssl (4.6.0+p1-1) bullseye; urgency=medium * Stable update to address the following vulnerabilities. All fixes were backported by upstream: - PR 3676: CVE-2021-3336 - PR 3990: CVE-2021-37155 (OCSP Match Issue) - PR 4211: CVE-2021-38597 - PR 4629: CVE-2021-44718 - PR 4813: CVE-2022-25638 - PR 4831: CVE-2022-25640 * Drop 58f9b6ec01f0caf89e9e4d37a8816b310005aaf1.patch, which was previously cherry-picked from upstream. * Upstream updated some certificates in the test suite. -- Felix Lechner Mon, 14 Mar 2022 15:45:37 -0700 wolfssl_4.6.0-3.dsc_wolfssl_4.6.0+p1-1.dsc.debdiff.xz Description: application/xz
Bug#1007261: bullseye-pu: wolfssl/4.6.0-3_4.6.0+p1-1.debdiff updated
Hi, On Thu, Mar 17, 2022 at 10:56 AM Adam D. Barratt wrote: > > That's a non-standard version for a stable update. What version do > upstream regard this as? 4.6.0+p1 > (The conventional version string would be 4.6.0-3+deb11u1.) That would not match the upstream version and would lead to the wrong orig tarball, wouldn't it? > You don't really need to mention who performed the backport here, FWIW. I mentioned it in part to explain the new version string. Kind regards, Felix Lechner
Bug#1007717: Native source package format with non-native version
Hi, On Thu, Mar 17, 2022 at 11:57 AM Russ Allbery wrote: > > source package format While everyone is receptive to new labels, I prefer "upload format" or "archive format". Either one helps us to distinguish the intermediate product from any workflow objects a maintainer may have. > single tarball as a source package format It is also not necessary to "define" unpatched sources in the archive by how many tarballs they have, or any tarballs at all. In fact, I wrote a manifest utility that could one day replace tarball signatures with per-file hashes. The latter remain useful even when sources are repackaged, because manifests can be cryptographically daisy-chained in a "chain of custody." Of course, they would be more often used for patched upload formats. Kind regards Felix Lechner
Bug#1007261: bullseye-pu: wolfssl/4.6.0-3_4.6.0+p1-1.debdiff updated
Hi, On Thu, Mar 17, 2022 at 11:49 AM Adam D. Barratt wrote: > > In that case, it would be slightly more conventional to use "4.6.0+p1- > 0+deb11u1" Thank you for that advice! I will use 4.6.0+p1-0+deb11u1 instead. > Well, you control the naming of the orig tarball, so you'd just make it > match the package. Without wishing to appear argumentative, I did not seem smart to have two different tarballs in the archive under the same wolfssl_4.6.0.orig.tar.gz name. > Please feel free to upload. Thanks for that too, and for your hard work on the stable releases! Kind regards, Felix Lechner
Bug#1007922: false positive spelling: substract and subtract is both correct
Hi Thomas, > substract and subtract are both correct Where did you see that word? > "Now nonstandard and rare" Yeah, I'm with Russ. I found "sub-S-tract" in the 1913 Webster's Dictionary but no longer in Webster's Second from 1960. (Finally, those dusty volumes found some use.) I have never heard, or seen, that form of "sub-tract," but let's give others a chance to chime in. Kind regards, Felix Lechner
Bug#962448: mailing-list-obsolete-in-debian-infrastructure: Please ignore the Debian Java Maintainers address
Hi Chris, On Mon, Jun 8, 2020 at 7:24 AM Chris Lamb wrote: > > (Felix, please consider reverting your change to 12cd485d until we > have consensus here.) Forgive me, but I do not follow your logic. We do not fix experimental tags? How are they supposed to get better? I would agree to a reversal only if the tag becomes a classification. Kind regards Felix Lechner
Bug#962158: lintian: New very problematic --fail-on default value
Hi Chris, On Tue, Jun 9, 2020 at 11:15 PM Chris Lamb wrote: > > Felix, can you help out? I am not in a position to contribute to this > discussion itself. Well, I wish I could. Guillem makes many alarmist statements, but fails to explain why the change is an undue burden. I also do not know how to engage productively with visceral and absolute responses such as: > Err… > it does not make any sense whatsoever > does not match reality > it does not even make sense within a Debian-centric view > I'll have to very much disagree > you have still not explained what this default change really accomplishes > besides inducing tons of work and breakage > No, they did not. It's amazing how much time and energy Guillem expended on this issue here, on IRC, and in #962157 while dpkg has more open bugs than Lintian. As you know from my past behavior with 'md5sums -z' or the odd contributor on Salsa, I am not opposed to compromise when it brings peace. In the present case, such a compromise could be a value 'none' to disable the default Guillem likes (and which I would like to remove). At the same time, the change was widely released two weeks ago. Simon Quigley from Ubuntu announced it on debian-devel on May 25 [1], while I advertised the change repeatedly on IRC and added a note to DevNews. Some users may have already adapted their systems. [1] https://lists.debian.org/debian-devel/2020/05/msg00239.html Now the best course of action, I think, is to downgrade the severity again to Guillem's original setting of 'important'. That will allow the change to remain in testing. It is, after all, what the testing distribution is for. It would also give me more time to understand the possibly unreasonable burden on Lintian users across Debian and the derivative ecosystem. Simon may receive feedback from Ubuntu, a significant derivative. If there are real problems, I am happy to discuss a solution that reverts the default to Lintian's old setting. Kind regards Felix Lechner
Bug#904885: lintian.d.o: En dashes in tag descriptions are output incorrectly
Hi Andrey, > lintian-info outputs "â" instead of en dash Fixed for the website in this commit: https://salsa.debian.org/lintian/taxiv/-/commit/927c23e0c2f28769321a34583b8339f35e1edc4d but not yet fixed for 'lintian-info'. We currently do not track bugs for the reporting code separately (although the code is now separate from Lintian). This bug will be closed when 'lintian-info' is fixed. Please note that the tag mentioned here will soon be replaced by a general policy tag called 'missing-field'. The references that caused the bug have been transferred to the new tag. The correct display can soon be verified there. Kind regards Felix Lechner
Bug#962671: lintian: Identify test cases without declared diagnostic value
Package: lintian Severity: wishlist Hi, Test cases that do not expect any tags or declare any Test-Against: tags have no declared diagnostic value and should be adjusted or removed. An internal harness test should identify such cases. Kind regards Felix Lechner
Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages
Hi, As a Lintian maintainer, I would like to express support for Ian's effort to remove restrictions on Debian version strings. Unlike Ian, however, I also believe all packages should be converted to format 3.0. A package's 'nativeness' is then declared explicitly, and does not have to be inferred from the version string. Lintian still does the latter for installation packages (aka 'binary' packages) because the expected changelog locations differ (and tags are issued accordingly). In my view, nativeness should only matter for source packages. The provenance of an installation package should not matter. I wrote this message because the Lintian bug that is blocked by this one will be triaged in another way. Lintian supports Ian's effort to the extent that it simplifies the parsing of version strings. Kind regards Felix Lechner
Bug#953554: Please permit Debian revisions with 1.0 native packages
Control: retitle -1 lintian: Restore format-specific changelog tags as warnings Control: forcemerge -1 944155 Hi Ian, On Wed, Mar 11, 2020 at 5:37 AM Ian Jackson wrote: > > I hope that whatever occurs more widely, this particular message can > be downgraded appropriately so that by default it is an warning rather > than an error. That's all I'm asking for in this bug. > > Can we perhaps go back to >hyphen-in-native-debian-changelog-version It never felt so wrong to merge two bugs, but they are now the same. I supported your request in the cloned policy bug #953629 and got you another +1. For now, I will reduce the tag's severity to a warning like you asked. Lintian is not a good vehicle for policy changes, and you were unaware when filing that policy stood in the way. Please contact us again when the policy changes (or if you require additional support in the matter). I cannot wait to implement your request. Kind regards Felix Lechner
Bug#852196: lintian: check of license-problem-convert-utf-code is too strict
Control: retitle -1 lintian: check of license-problem-convert-utf-code is too strict Hi, Message #18 went to #900598 and this bug, but the retitle operation should not have applied here. Reverting. Kind regards, Felix Lechner
Bug#953554: Please permit Debian revisions with 1.0 native packages
Hi Guillem, On Thu, Jun 11, 2020 at 11:14 PM Guillem Jover wrote: > > Given the timing of this reaction, I think it would not be > unreasonable to consider it originating out of spite? Actually, I did not think of you. I hoped to show Ian that I am not "part of a campaign to abolish one of [his] workflows." The record in this bug shows that my support for his position predates your current efforts against me. Kind regards Felix Lechner
Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages
Hi, On Fri, Jun 12, 2020 at 3:30 AM Ian Jackson wrote: > > As for `3.0 (native)', it has one serious disadvantage: dpkg-source > has been programmed to reject version numbers with a Debian revision. > If that restriction were relaxed, `3.0 (native)' would be a strictly > superior drop-in replacement for 1.0-native and I doubt anyone would > have any objection to phasingt 1.0-native out completely. What a winning trade! The restriction should be lifted right away. Kind regards Felix Lechner
Bug#945869: lintian: false positive for debian-rules-not-executable
Control: retitle -1 lintian: Ignore umask when recording file permissions in patched source tree Hi Andreas, On Sat, Nov 30, 2019 at 2:36 AM Andreas Metzler wrote: > > 0002. And surprisingly it does matter ;-) This is #796257 in Dpkg. Unfortunately, it has not been addressed in nearly five years. A resolution there seems far off given the conflicting opinion in message #22 of that bug. Lintian's output is inconsistent between users. Possible ways to triage are: 1. Reset umask before calling dpkg-source. It would never affect other users as mentioned in message #22 of #796257, because Lintian's directory is temporary. 2. Read the tar indices and reconstruct the patched sources. That seems difficult and error prone. The program to build the test packages may also have to reset its process umask to . Kind regards, Felix Lechner
Bug#909267: library-not-linked-against-libc: downgrade from error
Control: forcemerge 896012 909267 Hi Russ, > I wonder if we would get all of the utility out of the tag if instead it > looked for shared libraries with no NEEDED metadata. I think it's only > catching libraries that aren't linked with anything else, so maybe just > check for that explicitly? That is a super creative suggestion! However, nothing may be wrong with those libraries. We seem to ship quite a few [1]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896012#38 > My recollection is that Simon is correct and we added this tag to try to > find shared libraries that weren't linked to any of their dependencies. I don't believe Lintian can do something like that. As described in the merged bug [2], I think we need a portfolio-wide dependency tracker. [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896012#31 This tag will be removed in the near future. Kind regards Felix Lechner
Bug#953629: Bug#953554: Please permit Debian revisions with 1.0 native packages [and 1 more messages]
Hi Sean, On Mon, Jun 15, 2020 at 5:18 PM Sean Whitton wrote: > > As > discussion is ongoing in the context of Lintian, that seems premature, > however. The Lintian discussion was merged into a bug Guillem had filed to further enshrine the division between native and non-native packages Bug#944155 was about reminding maintainers to use a hyphen, or not. Based on your note, however, Lintian will stop warning about such version mismatches. Perhaps it will gradually pave the way for a constructive policy debate. Thanks! > So I think we can close the clone of this bug against Policy for now. Totally agree, for now. Kind regards Felix Lechner
Bug#950052: please warn for files installed into /
Hi Chris, On Sat, Jun 20, 2020 at 7:15 AM Chris Lamb wrote: > > the > severity level is too high. I agree. The severity was reduced to pedantic. As for the actual occurrence of the tag in Lintian, we have three options: 1. Install an override. This is my favorite. The tag was not triggered by the test suite in the source but is a genuine occurrence in our shipped product. The path segment repeats because our checks mirror Debian's ecosystem and infrastructure, including Lintian. In my mind, the is tag is real and should be overridden. 2. Alternatively, we could move the checks to d/lintian-overrides. The name is equally acceptable and would side-step the tag, but the path names become longer. That makes them less convenient. The change affects the tests, too. This is my second favorite option. 3. Programmatically exclude Lintian. Many of our self-exemptions will soon disappear. Lintian's test cases, which a are a major cause for the exemptions, will be excluded from source checks by a different mechanism. The tag at hand, however, is an installation matter and indicates a different kind of issue. Adding more exemptions for Lintian may also trigger image problems for us. I have been ridiculed for exempting Lintian from its own tags, which the correspondent perceived as equally overbearing on his own package. Kind regards, Felix Lechner
Bug#950052: please warn for files installed into /
Hi Chris, On Mon, Jun 22, 2020 at 12:45 AM Chris Lamb wrote: > > Up to you. In commit 1b9e1048, I went with option #2. Kind regards Felix Lechner
Bug#950052: please warn for files installed into /
Hi Chris, On Mon, Jun 22, 2020 at 7:57 AM Chris Lamb wrote: > > P: lintian: repeated-path-segment usr usr/share/lintian/checks/usr/lib.pm Also solved by renaming, in commit 68b72cd0. Kind regards Felix Lechner
Bug#950052: please warn for files installed into /
Hi Mattia, On Mon, Jun 22, 2020 at 8:58 AM Mattia Rizzolo wrote: > > I don't think I have much voice here, but tbh I feel like this is totally > artificially adding > restraints that have no real reason to exist. That sweeping statement does not cover either (1) the accidental installation errors that can occur when people use cp(1) instead of install(1) to copy files, or (2) the degradation of style and placement logic that happens with repetitive paths. > It's alright to think that at times this might be hiding a packaging error, > but honestly most of > those case are usually self-evident and IME very rarely are a real problem. Please remember I am closing bugs for requested features. I do not argue much because I find it unproductive. Instead, I implement everything that is remotely reasonable. I, too, have found repetitive paths annoying in the past, and have seen installation errors in which a destination folder was accidentally duplicated. Let's reserve judgment until we see how the check performs in the wild. In the end, you may well be right. But we don't know that yet. Kind regards Felix Lechner
Bug#950052: please warn for files installed into /
Hi Mattia, On Mon, Jun 22, 2020 at 9:40 AM Mattia Rizzolo wrote: > > However, please do try to judge the proposals Actually, I implement them so you and the community can judge. Kind regards Felix Lechner
Bug#963519: lintian: false positive: latex2rtf: source-is-missing latex2rtf
Hi Chris, On Mon, Jun 22, 2020 at 2:33 PM Chris Lawrence wrote: > > The latex2rtf binary is built by a Makefile, without a source file > specifically called latex2rtf.c > > it's a false positive That's not possible (or there is a misunderstanding). The tag source-is-missing operates on source packages. It does not seek sources for executables shipped in installation packages. Did you perhaps include the executable in your source package? As an aside, I can not duplicate your report with the version in unstable: % ./frontend/lintian /mirror/debian/pool/main/l/latex2rtf/*.dsc /mirror/debian/pool/main/l/latex2rtf/latex2rtf_2.3.16-1+b1_amd64.deb W: latex2rtf: national-encoding usr/share/latex2rtf/cfg/direct.cfg W: latex2rtf: national-encoding usr/share/latex2rtf/cfg/icelandic.cfg W: latex2rtf source: package-uses-deprecated-debhelper-compat-version 9 I: latex2rtf: hardening-no-bindnow usr/bin/latex2rtf I: latex2rtf: spelling-error-in-copyright Coypright Copyright I: latex2rtf source: testsuite-autopkgtest-missing I: latex2rtf source: unused-license-paragraph-in-dep5-copyright bsd-3 (paragraph at line 46) P: latex2rtf source: insecure-copyright-format-uri http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ P: latex2rtf source: rules-requires-root-missing P: latex2rtf source: trailing-whitespace debian/changelog (line 246) Kind regards Felix Lechner
Bug#1008130: lintian: support/use multi-threads (currently single threaded and slow)
Hi Samuel, On Tue, Mar 22, 2022 at 3:15 PM Samuel Henrique wrote: > > I believe there could be noticeable performance gains from using all > the threads available. I share your hope and have implemented two attempts to parallelize the ~300 or so checks. My first attempt used IO::Async but failed. That module is probably the best one currently available, but it replaces the SIGCHLD handler. Lintian uses dozens of other modules that call external programs via other means. Unfortunately, those do not interact well with IO::Async, which causes the parallel execution to freeze or otherwise experience strange bugs. A particularly serious problem for Lintian was the interaction with Path::Tiny. [1] You may be able to find some details by searching the Git log for "Heisenbug" (capital H, please). My current implementation uses MCE [2] which works okay, but does not yet yield the performance gains you and I are hoping for. That is why the experimental branch has not been merged. As far as I can tell, the degradation relates to the serializations Perl performs between parent and child processes. It is possible to "close" on the in-memory file indexes as part of the fork() but it's not enough to explain the difference. (The indexes are large and also being transitioned to disk for unrelated reasons.) Memory usage is higher, as well. I may have to implement better profiling before we make significant progress. That is because at least half the time is spent generating the file indexes, which require a different parallelization strategy than the checks. One long-term plan could be to have a data interchange format between the parent and the child processes. It would also allow checks to be written in other programming languages, such as Haskell, but I would seek further community input before proceeding with anything like that. [1] https://github.com/dagolden/Path-Tiny/issues/224 [2] https://metacpan.org/pod/MCE > Although I don't know how feasible that is with > lintian+perl. Perl performs surprisingly well for an interpreted language, but I am not sure true "threading" works well. In Lintian, we use multiple processes, if at all. That is how I interpreted your use of the word "threads". > Note that I didn't go all the way to debugging lintian to confirm it's > single-threaded You are right. For the purposes of your analysis, Lintian uses a single process. Thank you for your valuable suggestions! Kind regards, Felix Lechner
Bug#964770: lintian: lintian will get stuck on arm64
Hi Kentaro, On Sun, Jul 12, 2020 at 5:12 PM Kentaro Hayashi wrote: > > Here is the reproducible code. The failure does not reproduce on the Debian arm64 porterbox amdahl. In the code above, I removed the 'print $future' statement and replaced $loop->await with 'say $future->get'. The result is '4', presumably the number of processors on amdahl. I also forwarded your bug to the IRC channel #io-async. Someone there tested your initial filing in the docker container, as you described, on a Raspberry Pi4 and then the code you submitted later. Both ran fine. Do you have more information about your error? If you need help debugging your Perl setup, I can recommend the channel #perl-help. The good folks there would be able to shed light on it. Kind regards Felix Lechner
Bug#965327: Lower severity of bash-completion-with-hashbang
Hi Vincent, On Sun, Jul 19, 2020 at 9:03 AM Vincent Bernat wrote: > > bash-completion-with-hashbang got bump from > minor to certain, after commit 70eaca50411. I think that's a misunderstanding. We changed the scale back to the simple EWI system after having classed tags by levels from the BTS for some time. Due to Certainty: certain, this tag was always issued as a warning. [1] [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935706#40 That being said, the tag was introduced just three weeks earlier (in commit 6fbc952b) and may carry a severity higher than intended. (A warning does not sound like minor, does it?) I will think about the level. > the shebang is harmless and I won't > patch or other upstream about a harmless shebang. As explained in this MR [2], we consider the hashbang an error. The snippets are not meant to be executed. The upstream for 'bash-completion' also does not use them. [2] https://salsa.debian.org/lintian/lintian/-/merge_requests/292 > Also, this helps > editors turning on the right "mode" to edit the file. This is an unrelated function that you may be able to resolve by using [3] or [4]. [3] https://www.gnu.org/software/emacs/manual/html_node/emacs/Choosing-Modes.html [4] http://vimdoc.sourceforge.net/htmldoc/syntax.html You can see examples for both, at the top and the bottom of the file respectively, here: https://salsa.debian.org/lintian/lintian/-/blob/master/checks/continuous-integration/salsa.pm Kind regards Felix Lechner
Bug#965335: Lintian: missing complaining of Lintian
Hi Mechthilde, On Sun, Jul 19, 2020 at 11:33 AM Mechtilde Stehmann wrote: > > lintian didn't complain if Maintainers adress miss a ">" at the end n > debian /control We use the Perl module Email::Address::XS to parse the contact information in package control files. Overall, we found the module reliable (especially with respect to UTF-8, which can cause a lot of problems). You are right that it does not complain about the missing closing bracket when the information is otherwise parsed correctly. I briefly looked at the relevant RFC but did not arrive at a conclusion. For now, I added a test case for that situation: https://salsa.debian.org/lintian/lintian/-/commit/8ea3d161006d3325d81d6205b15186637a2a63a9 Please share any documentation about valid and invalid email addresses, if you have it. Thanks! Kind regards Felix Lechner
Bug#700970: lintian: check for incorrectly formatted lists in DEP-5 copyright files
Hi Jakub, I am not sure what Policy §5.6.13 said in 2013, but from my perspective such formatting is not an error (unless the entire text is indented by more than a single space). For the examples you attached, especially, it is actually desirable that the bullet points are rendered verbatim as described in policy: > Those starting with two or more spaces. These will be displayed > verbatim. I would like to close this bug. Please object if you disagree. Thanks! Kind regards Felix Lechner
Bug#966072: lintian: Cannot pipe() - Too many open files
Hi Andreas, On Wed, Jul 22, 2020 at 8:15 AM Andreas Beckmann wrote: > > Cannot pipe() - Too many open files at > /usr/share/perl5/IO/Async/Internals/ChildManager.pm line 122. > ... > internal error: cannot run documentation/manual check on package > binary:nvidia-cuda-dev/10.1.243-8/amd64 > warning: skipping check of binary:nvidia-cuda-dev/10.1.243-8/amd64 The bug was probably introduced by https://salsa.debian.org/lintian/lintian/-/commit/2009f51a34c78d3e8fa73ece4a6aaa7d57e1751d > while working on src:nvidia-cuda-toolkit But I cannot reproduce the behavior locally. (See working tag output below.) Are you using a resource-constrained system? Also, I have a non-standard setup locally in /etc/security/limits.d: # *hardnofile65536 *softnofile65536 Kind regards Felix Lechner * * * % ./frontend/lintian /mirror/debian/pool/non-free/n/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.1.243-7.dsc /mirror/debian/pool/non-free/n/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.1.243-7_amd64.deb W: nvidia-cuda-toolkit: no-manual-page usr/bin/bin2c W: nvidia-cuda-toolkit: no-manual-page usr/bin/cudafe++ W: nvidia-cuda-toolkit: no-manual-page usr/bin/fatbinary W: nvidia-cuda-toolkit: no-manual-page ... use --no-tag-display-limit to see all (or pipe to a file/program) I: nvidia-cuda-toolkit source: dh-exec-subst-unknown-variable debian/nsight-systems.install env:NSIGHT_SYSTEMS_HOST_DIR I: nvidia-cuda-toolkit source: dh-exec-subst-unknown-variable debian/nsight-systems.install env:NSIGHT_SYSTEMS_TARGET_DIR O: nvidia-cuda-toolkit: embedded-library usr/bin/gpu-library-advisor: zlib O: nvidia-cuda-toolkit source: source-is-missing amd64/bin/bin2c O: nvidia-cuda-toolkit source: source-is-missing amd64/bin/cuda-gdb O: nvidia-cuda-toolkit source: source-is-missing amd64/bin/cuda-gdbserver O: nvidia-cuda-toolkit source: source-is-missing ... use --no-tag-display-limit to see all (or pipe to a file/program) N: Monolithic installation tree shim for clang++ --cuda-path=/usr/lib/cuda O: nvidia-cuda-toolkit: breakout-link usr/lib/cuda/nvvm/libdevice -> usr/lib/nvidia-cuda-toolkit/libdevice N: Some of NVIDIA's binaries expect files at certain relative paths. O: nvidia-cuda-toolkit: breakout-link usr/lib/nvidia-cuda-toolkit/bin/nvcc.profile -> etc/nvcc.profile O: nvidia-cuda-toolkit: hardening-no-pie usr/bin/bin2c O: nvidia-cuda-toolkit: hardening-no-pie usr/bin/cuda-memcheck O: nvidia-cuda-toolkit: hardening-no-pie usr/bin/cudafe++ O: nvidia-cuda-toolkit: hardening-no-pie ... use --no-tag-display-limit to see all (or pipe to a file/program) O: nvidia-cuda-toolkit: hardening-no-relro usr/bin/bin2c O: nvidia-cuda-toolkit: hardening-no-relro usr/bin/cuda-memcheck O: nvidia-cuda-toolkit: hardening-no-relro usr/bin/cudafe++ O: nvidia-cuda-toolkit: hardening-no-relro ... use --no-tag-display-limit to see all (or pipe to a file/program) N: patching is done manually after unpacking the .run files O: nvidia-cuda-toolkit source: patch-file-present-but-not-mentioned-in-series cuda-gdb.patch N: patching is done manually after unpacking the .run files O: nvidia-cuda-toolkit source: patch-file-present-but-not-mentioned-in-series gdb-python3.7.patch N: patching is done manually after unpacking the .run files O: nvidia-cuda-toolkit source: patch-file-present-but-not-mentioned-in-series man-hyphenation.patch N: patching is done manually after unpacking the .run files O: nvidia-cuda-toolkit source: patch-file-present-but-not-mentioned-in-series ... use --no-tag-display-limit to see all (or pipe to a file/program) O: nvidia-cuda-toolkit: binary-has-unneeded-section usr/bin/bin2c .comment O: nvidia-cuda-toolkit: binary-has-unneeded-section usr/bin/cudafe++ .comment O: nvidia-cuda-toolkit: binary-has-unneeded-section usr/bin/cuobjdump .comment O: nvidia-cuda-toolkit: binary-has-unneeded-section ... use --no-tag-display-limit to see all (or pipe to a file/program) N: The NVIDIA license does not allow any form of modification. O: nvidia-cuda-toolkit: hardening-no-bindnow usr/bin/bin2c N: The NVIDIA license does not allow any form of modification. O: nvidia-cuda-toolkit: hardening-no-bindnow usr/bin/cuda-memcheck N: The NVIDIA license does not allow any form of modification. O: nvidia-cuda-toolkit: hardening-no-bindnow usr/bin/cudafe++ N: The NVIDIA license does not allow any form of modification. O: nvidia-cuda-toolkit: hardening-no-bindnow ... use --no-tag-display-limit to see all (or pipe to a file/program) O: nvidia-cuda-toolkit: hardening-no-fortify-functions usr/bin/bin2c O: nvidia-cuda-toolkit: hardening-no-fortify-functions usr/bin/cuda-memcheck O: nvidia-cuda-toolkit: hardening-no-fortify-functions usr/bin/cudafe++ O: nvidia-cuda-toolkit: hardening-no-fortify-functions ... use --no-tag-display-limit to see all (or pipe to a file/program) O: nvidia-cuda-toolkit: package-contains-empty-directory usr/lib/cuda/bin/ O: nvidia-cuda-toolkit: package-co
Bug#966072: lintian: Cannot pipe() - Too many open files
Hi Andreas,
On Wed, Jul 22, 2020 at 2:03 PM Andreas Beckmann wrote:
>
> Everything is on defaults, i.e. ulimit -n returns 1024
Our current best guess is that you are running out because IO::Async
allocates two file descriptors for each new process. The check
documentation/manual always spawned an unlimited number of processes
and reaped them later, That is probably why it became a problem now
with your package, which contains about 2K files. I have not counted
the manual pages in your package.
We will try to address the issue by limiting the number of processes
spawned in that check. The plan is to use something like:
(fmap_void { $loop->run_process(...) } concurrent => 8, foreach =>
[ ... ])->retain
Credit for that idea goes to tom_m from IRC#io-async.
> (and the just uploaded -8, too)
I do not see it on my mirror yet, but I am pretty sure it will run here too.
Kind regards
Felix Lechner
Bug#966122: Hangs when run under mc(1)
Hi Andrey, On Thu, Jul 23, 2020 at 4:03 AM Andrey Rahmatullin wrote: > > lintian 2.85.0 hang when run on any .deb from under mc. This issue is related to the mixing of IO::Async with other methods of forking processes. IO::Async replaces the SIGCHLD handler (and relies on it staying that way). When those calls are interleaved with calls to system(), strange things can happen. We have known about that for some time, but for the most part it worked great against all odds until the Heisenbug mentioned in commit cb45b444 brought the matter back into focus. Triage is under way and may entail dropping IO::Async from Lintian. We know this bug is urgent. The fix is coming soon. Kind regards Felix Lechner
Bug#966368: lintian gets stuck when run by sbuild within rebuildd
Hi Raphael, On Mon, Jul 27, 2020 at 11:45 AM Raphael Hertzog wrote: > > I saw #964770 but it > didn't seem exactly the same issue. That bug is also unconfirmed—iincluding by the IO::Async developers. Kind regards Felix Lechner
Bug#968758: lintian: Explore Emacs integration (lintian-mode)
Package: lintian Severity: normal Owner: Sean Whitton Hi, Sean uses Lintian in eshell. It would be great if we could provide a lintian mode in Emacs. Similar to the old info system, it could provide clickable links for tag definitions, and perhaps even the reference citations. Thanks to Sean Whitton for the idea! Kind regards Felix Lechner
Bug#950516: file: Does not detect python3.8 byte-compiled files
Control: retitle -1 file: does not detect python3.8 byte-compiled files Hi Christoph, Given the passage of time, it is okay if Lintian detects Python3 files only in unstable. Unfortunately, the file(1) program in unstable does not detect files byte-compiled by the Python3 version in unstable, which is 3.8. (file 1:5.38-5 detects only 3.7.) Would you please provide a version that does? Thanks! Retitling this bug accordingly. The fix blocks the removal of Python2 from Lintian. Thanks! Kind regards Felix Lechner
Bug#968926: jupp: block reformatting malfunctions sometimes
Package: jupp
Severity: normal
Hi,
In version 3.1.38-1 on stable, block reformatting sometimes changes
the content when the first character in the second line is either an
asterisk or a slash. Here is how to produce it:
1. Save the first attachment.
2. Invoke 'cat test.txt' in a GNOME terminal window
3. Highlight the two lines with the mouse and copy to clipboard.
4. Invoke 'jmacs'
5. Paste into the editor with the right button of the mouse.
6. The editor breaks the first line into two.
7. Move cursor to the first position in the second line ('and')
8. Hit backspace once to join 'long' and 'and' on the first line.
9. Invoke Alt-Q
The editor then shows the contents in the second attachment 'jumbled.txt'.
The same thing happens when the slash is altered into an asterisk
before the two words are combined. Perhaps it is a feature related to
bullet points, but I did not expect the results.
Thanks for providing a nifty little editor with UTF-8 support!
Kind regards
Felix Lechner
One way to see this bug is to edit furio usly until a li ne gets super long and
the
/usr/local/bin
One way to see this bug is to edit furio usly until a li ne gets super
/longand the usr/local/bin
Bug#968972: volpack: Manual pages are formatted incorrectly
Package: libvolpack1-dev Severity: normal X-Debbugs-CC: Stuart Prescott Hi, Many of the manual pages in your package appear to be formatted incorrectly. In a recent Lintian run across the archive, they generated many errors like this: Warning in group volpack/1.0b3-8: Non-zero status 3 from man --warnings -E UTF-8 -l -Tutf8 -Z /tmp/lintian-pool-aeCkRt5q0G/v/volpack/libvolpack1-dev_1.0b3-8_amd64_binary/unpack ed/usr/share/man/man3/BruteForce.3.gz: man: ignoring unknown preprocessor `C' man: ignoring unknown preprocessor `o' man: ignoring unknown preprocessor `y' man: ignoring unknown preprocessor `i' man: ignoring unknown preprocessor `h' man: can't execute grap: No such file or directory refer:0BU:70: fatal error: output error man: command exited with status 127: /usr/lib/man-db/zsoelim | /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 | pic -S | refer | grap | tbl | g roff -mandoc -Z -wmac -Tutf8 A full log with all errors is attached to this message. The errors seem to be caused by the copyright notice: \" Copyright (c) 1994 The Board of Trustees of The Leland Stanford '\" Junior University. All rights reserved. '\" '\" Permission to use, copy, modify and distribute this software and its '\" documentation for any purpose is hereby granted without fee, provided '\" that the above copyright notice and this permission notice appear in '\" all copies of this software and that you do not sell the software. '\" Commercial licensing is available by contacting the author. '\" '\" THE SOFTWARE IS PROVIDED "AS IS" AND WITHOUT WARRANTY OF ANY KIND, '\" EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY '\" WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. '\" '\" Author: '\"Phil Lacroute '\"Computer Systems Laboratory '\"Electrical Engineering Dept. '\"Stanford University '\" '\" $Date: 1994/12/31 19:49:53 $ '\" $Revision: 1.1 $ '\" '\" Macros '\" .FS -- function start '\" is return type of function '\" name and arguments follow on next line Perhaps the '\" should be .\" ? This transformation via sed seems to fix it: sed "s@'@.@" You can use the same command as Lintian to check the result: man --warnings -E UTF-8 -l -Tutf8 [-Z if compressed] [filename] Thanks to Stuart Prescott for figuring it all out! Kind regards Felix Lechner volpack-errors.log.xz Description: application/xz
Bug#969468: lintian 2.92.0 is broken inside a lxd container:
Hi Julian, Iñaki Malerba from the Salsa CI team was so kind to point me to the following code right after I hit the send button on my previous message: https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/salsa-ci.yml#L208 Perhaps it is helpful to you. Kind regards Felix Lechner
Bug#969468: lintian: Can't opendir(/dev/.lxd-mounts): Permission denied
Hi Julian, Iñaki Malerba also pointed out the following code: https://salsa.debian.org/salsa-ci-team/autopkgtest-lxc/-/blob/master/.gitlab-ci.yml#L13 Perhaps you find it useful. Kind regards Felix Lechner
Bug#892423: groff: Lintian crashes host for some Asian-language manual pages
Hi, In archive-wide Lintian runs, this issue occurred in the following binary packages. apt_2.1.10_amd64.deb dos2unix_7.4.1-1_amd64.deb manpages-zh_1.6.3.4-1_all.deb mplayer_1.3.0-8+b9_amd64.deb wesnoth-1.14-core_1.14.13-1_amd64.deb A sample command is: man --warnings -E UTF-8 -l -Tutf8 -Z mplayer/usr/share/man/zh_CN/man1/mplayer.1.gz but the screen width must be 80 or smaller to reproduce. Jakub Wilk suggested the minimal code below to reproduce the issue. When the troff subprocess is not killed in a timely manner (within six to ten hours), it will consume all of the host machine's I/O buffers and cause a kernel panic. It was observed several times over the past two weeks. Lintian triaged the issue by setting the value to 120 in this commit, but the change should probably be reverted when this bug is fixed: https://salsa.debian.org/lintian/lintian/-/commit/5be6bd66a9f52872615ef32d234b6d616fd5fa49 The credit for tracking down the issue to groff and suggesting a fix belongs to Jakub Wilk. Thanks! Kind regards Felix Lechner * * * $ mkdir -p usr/share/man/ja/man5 $ printf '\343\201\210\343\201\260\343\200\201.lcs.mit.edu_debian_dists_unstable_contrib_binary\\-i386_Release \n' > usr/share/man/ja/man5/test.5 $ MANWIDTH=80 man --warnings -E UTF-8 -l -Tutf8 -Z usr/share/man/ja/man5/test.5 > /dev/null troff: :1: warning [p 1, 0.0i]: cannot adjust line [hangs indefinitely]
Bug#969636: bashtop: Please require python3-psutil or soften error message
Package: bashtop Severity: wishlist Hi, Thanks for packaging an attractive new tool for Debian! I ran bashtop recently (from backports) and received this error message: % bashtop Error: Missing python3 psutil module! The program works fine, but the relatively strong error message seems inconsistent with the maintainer's decision to merely recommend python3-psutil. Please require the missing module or soften the message. Thanks for your hard work on Debian! Kind regards Felix Lechner
Bug#969637: xmonad: Show key bindings in default background
Package: xmonad Severity: wishlist Hi, For novice users, it might be helpful to show the key bindings more prominently. A nice guide on the Haskell website [1] could serve as a background for new installations. (Out of the box xmonad shows a stale workspace, which is confusing.) I installed the guide as a background with: feh --bg-max --image-bg white ~/.wallpapers/Xmbindings.png Thanks for this great window manager. What a discovery! Kind regards Felix Lechner [1] https://wiki.haskell.org/wikiupload/b/b8/Xmbindings.png
Bug#969719: lintian: Unable to override team/pkg-perl/testsuite/no-team-tests
Hi Xavier, > I'm unable to override team/pkg-perl/testsuite/no-team-tests The first issue is caused by the slash. The inconsistency revealed by the second is a bug in the parser. I have a proposed fix. Will you please send your package so I can test it? Thanks! Kind regards Felix Lechner
Bug#969719: lintian: Unable to override team/pkg-perl/testsuite/no-team-tests
Hi Xavier, On Mon, Sep 7, 2020 at 8:33 AM Felix Lechner wrote: > > source: team/pkg-perl/testsuite/no-team-tests autopkgtest Those lines are malformed. Please use the attached file instead. A commit with the Lintian fix will appear here shortly. Kind regards Felix Lechner lintian-overrides Description: Binary data
Bug#969719: lintian: Unable to override team/pkg-perl/testsuite/no-team-tests
Hi Xavier, On Mon, Sep 7, 2020 at 10:09 AM Felix Lechner wrote: > > Those lines are malformed. Actually, it seems the modified parser should tolerate those lines. Unfortunately, the parsing of overrides is fraught with ambiguities. For details, please see #699628. I am trying to restore the previous behavior. Kind regards Felix Lechner
Bug#969769: ability to filter on severity when listing all tags
Hi Jelmer, > At the moment, classification tags are excluded manually I'll think of a good way to address your issue, but wanted to cue you in that classification tags are on the way out. Lintian is being split into two parts (internally). One provides scanning (similar to lab results in medicine) and the other provides the evaluation (like a doctor's diagnosis). Classification tags are scanning results and have nothing to do with the diagnosis. Direct access to Lintian's scanning results, which will be provided in ever greater numbers, should be very useful to many automated tools in the Debian ecosystem, such as Lucas's Trends, and perhaps even to the Janitor. An example for this new direction is the tag trimmed-field. Kind regards Felix Lechner
Bug#969762: warn about invalid field names in debian/upstream/metadata
Hi Jelmer, > lintian-brush can use this as a signal to fix typos in field names I'll try to track down a list of valid names and will happily implement it. In a pinch, you could even do it yourself. The tag upstream-metadata-field-present [1], which as a classification tag is not shown for packages on the website but is available in UDD, gives you the verbatim field names found. Like me, you just need a list of valid names to determine those that are bogus. They are already only one SQL query away! It is what happens when Lintian provides its scanning results to the world, as discussed in your other Bug#969769. Kind regards Felix Lechner [1] https://lintian.debian.org/tags/upstream-metadata-field-present.html
Bug#963524: dpkg: source-only *.changes files lack two mandatory fields
Package: dpkg Severity: normal X-Debbugs-CC: debian-lint-ma...@lists.debian.org Hi Guillem, Starting with an upcoming release, Lintian will check for the presence of required and recommended fields in various packaging control files. Our methods are probably not perfect, but it was brought to my attention that 'dpkg-buildpackage -S' produces *.changes files without 'Binary' and 'Description' fields. Policy 5.5 states that both fields are mandatory. [1] [1] https://www.debian.org/doc/debian-policy/ch-controlfields.html#debian-changes-files-changes You may be able to find details about an example (by building Lintian) at the link below. https://salsa.debian.org/lintian/lintian/-/commit/54a3c2437eadb0684f6762a81a82163f36562d3e#note_176583 Please note that I filed this bug with normal severity, even though as a policy violation, it should be serious. I did so because I believe the policy is at least partially in error (with respect to the 'Binary' field). This issue may be loosely related to your pending Bug#956321 but is clearly a different issue. Thank you for your hard work on dpkg and friends. Kind regards Felix Lechner
Bug#963524: dpkg: source-only *.changes files lack two mandatory fields
Hi Chris, On Tue, Jun 23, 2020 at 3:58 PM Chris Lamb wrote: > > to me this is a simple oversight in the Debian Policy That's exactly what I wrote in the initial filing. Kind regards Felix
Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies
Hi, > the OpenSSL ./. GPL problem (if one sees it as a problem) is larger There may be an alternative for some cases mentioned here. The wolfSSL encryption library is a FIPS-certified, commercial product with a fully usable, although incomplete, OpenSSL compatibility layer. The developers are very friendly toward open-source. One of them uses Ubuntu. Licensed under the GPL (or alternatively proprietary terms), wolfSSL avoids the linking problems OpenSSL has been trying to shed for years. wolfSSL is popular in embedded systems. If you bought an appliance or a car in the past ten years, you are probably using it already. In the enterprise space, MariaDB ships with an older, captive version. For a long time, MySQL relied on it (then called cyaSSL). I do not know if PostgreSQL can use it. Here is a list of projects that have been officially ported. [1] Daniel Stenberg, the creator of cURL, works there. I see the developers from time to time and receive free support. The library has been in Debian for five years. Kind regards Felix Lechner [1] https://www.wolfssl.com/community/
Bug#963519: lintian: false positive: latex2rtf: source-is-missing latex2rtf
Hi Chris, On Wed, Jun 24, 2020 at 3:26 PM Chris Lawrence wrote: > > I just reassigned the bug to my package and am preparing to upload a > fix. Sorry for troubling you! Please do not worry. We are happy to help! I am thinking about renaming the tag to 'generated-content'. Would that be a little bit better? Kind regards Felix
