Bug#1057881: Please drop Felix from Uploaders
Package: nullmailer Severity: wishlist Hi David, Please remove my name from the list of Uploaders at your convenience. I switched to OpenSMTPd and am not a good contributor anymore. Thanks! Kind regards Felix
Bug#1057340: Please drop Felix from Uploaders
Package: wolfssl Severity: wishlist X-Debbugs-CC: Bastian Germann Hi Bastian, Please replace my name with yours in the Uploaders field when you get a chance. I do not have time to help maintain wolfSSL at the moment since my wife had a baby. Thanks! Kind regards Felix
Bug#1040002: Drop Felix from Uploaders
Package: nullmailer Severity: wishlist Hi David, I have not used nullmailer in a little while, and I do not plan to work on the package in the near future. Please remove my email address from the Uploaders field at your leisure. Thanks! Kind regards Felix P.S. The proposed change alone did not seem to justify an upload.
Bug#1023697: wolfSSL 5.5.4 uploaded
Hi, > there is considerable interest in using WolfSSL I uploaded version 5.5.4-1, which was released last week, to the archive. Kind regards Felix Lechner
Bug#1023697: Keep out of testing
Hi, On Fri, Nov 25, 2022 at 4:27 AM Bastian Germann wrote: > > It would be great to address the CVEs with patches on 4.6.0+p1-0+deb11u1. A proposed update for the 11.6 point release of bullseye, which is scheduled for next weekend, was filed with the release team. [1] They were also contacted for guidance via IRC. Kind regards Felix Lechner [1] https://bugs.debian.org/1025789 cc: Security Team
Bug#1025789: bullseye-pu: wolfssl/4.6.0+p1-0+deb11u1_4.6.0+p1-0+deb11u2.debdiff
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-CC: sirkilam...@msn.com Hi, The wolfssl upstream released three patches for the version in Debian stable specifically in order to address the following three vulnerabilities present in bullseye: - CVE-2022-42961, scored by NVD as "5.3 medium" [1] - CVE-2022-39173, scored by NVD as "7.5 high" [2] - CVE-2022-42905, scored by NVD as "9.1 critical" [3] All three vulnerabilities are being tracked by DSA. [4] They were already fixed in unstable. There is no separate bug for the stable package. Given the increased popularity of the package [5] and the severity of the vulnerabilities, it seemed prudent to offer users of Debian stable an update. This bug was filed with a view toward the upcoming point release 11.6 for bullseye, which is scheduled for December 17. The freeze starts this weekend. The proposed upload has not seen a lot of testing. Following devref 5.5.1 [7] a source debdiff was attached. Please let me know if the version number is right and if you need any more information, or whether I may upload the package. Thanks! Kind regards, Felix Lechner [1] https://nvd.nist.gov/vuln/detail/CVE-2022-42961 [2] https://nvd.nist.gov/vuln/detail/CVE-2022-39173 [3] https://nvd.nist.gov/vuln/detail/CVE-2022-42905 [4] https://security-tracker.debian.org/tracker/source-package/wolfssl [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023697#28 [6] https://lists.debian.org/debian-release/2022/11/msg00251.html [7] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions wolfssl_4.6.0+p1-0+deb11u1.dsc_wolfssl_4.6.0+p1-0+deb11u2.dsc.debdiff.xz Description: Binary data
Bug#1023697: Keep out of testing
Hi, On Tue, Nov 8, 2022 at 12:00 PM Moritz Muehlenhoff wrote: > > open security issues I also just uploaded a backport for bullseye. Kind regards, Felix Lechner
Bug#1023835: wolfssl: FTBFS because of amd64-only symbols in symbols file
Hi, On Thu, Nov 10, 2022 at 4:06 PM Bastian Germann wrote: > > Please keep the three symbols out of the symbols file or make them optional. Thanks. We are aware of the issue. Unfortunately, your suggestion will likely cause a build failure on amd64. How do you make the symbols "optional" please? Thanks! Kind regards, Felix Lechner
Bug#1023697: Version 5.5.3-1 is in the NEW queue
Hi, FWIW, version 5.5.3-1 was accepted into the NEW queue. Kind regards Felix Lechner
Bug#1023697: Keep out of testing
Hi, On Tue, Nov 8, 2022 at 12:00 PM Moritz Muehlenhoff wrote: > > wolfssl has no active maintainer, plenty of open security issues and we > already > have too many TLS libraries in our releases. Keep it out of testing. I'm going > to file bugs against the handful of reverse deps. Sorry, I have been out ill, but please do what you think is right. Kind regards Felix
Bug#1021021: Upload planned
Hi, I plan to upload version 5.5.1 in the near future. Kind regards Felix Lechner
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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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 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#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#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#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#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#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#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#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#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#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#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#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#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#1006348: lintian: Tag improbable-bug-number-in-closes condition considers 7-digit bug numbers improbable
Hi, On Wed, Feb 23, 2022 at 3:57 PM Ben Finney wrote: > > const my $OUT_OF_REACH_BUG_NUMBER => 1_500_000; Due to a new override format, which remained pending due to my extremely critical commitment elsewhere, the change remains unreleased. I hope to get to Bug#1003272 tomorrow or on Friday, with a release soon after that. Kind regards Felix Lechner
Bug#1005326: no-code-sections triggered on non-ELF files
Hi, On Fri, Feb 11, 2022 at 12:09 PM Marc Dequènes wrote: > > Could you consider improving the check? Yes, I'd like to. > readelf fails with "readelf: Error: Not an ELF file - it has the wrong > magic bytes at the start" I confirmed that Lintian's invocation produces that error for usr/lib/dxvk/wine64-development/d3d10.dll.a in dxvk, but how can we tell such archives apart from those that are legitimately broken? Kind regards Felix Lechner
Bug#1005200: lintian: prefer-uscan-symlink should to single maintainer packages at most
Control: forcemerge 1001458 -1 Hi, On Tue, Feb 8, 2022 at 1:33 PM Scott Kitterman wrote: > > It's not clear why this would be better This tag was implemented at the suggestion of a very reputable fellow contributor, but I am also not sure I understand the benefit. We may drop the tag again. I took the liberty to merge this bug with the bug advocating the removal. Kind regards Felix Lechner
Bug#1005049: lintian: incorrect leading comma in "sub oxford_enumeration"
Control: tags -1 + pending Hi, On Sat, Feb 5, 2022 at 4:39 PM Chris Lamb wrote: > > The code in question is as follows: The code for the serial comma is relatively well-tested. It is also used on the website. On the website, you can see that a citation is being swallowed ("social contract item 2"). [1] An empty string is presented instead. A look at the tag declaration confirms that an additional citation is present but not being shown. [2] The bug is (or was) probably located elsewhere. More significantly, I can no longer reproduce the bug with the development version in Git, per the output below. May I please close this bug? Thank you! Kind regards Felix Lechner [1] https://lintian.debian.org/tags/patch-not-forwarded-upstream [2] https://salsa.debian.org/lintian/lintian/-/blob/master/tags/p/patch-not-forwarded-upstream.tag#L12 * * * ➤ bin/lintian --info --tags patch-not-forwarded-upstream debian/test-out/packages/checks/debian/patches/dep3/empty-forwarded-no-bug/ empty-forwarded-no-bug_1.0-1.dsc N: I: empty-forwarded-no-bug source: patch-not-forwarded-upstream [debian/patches/silent.patch] N: N: According to the DEP-3 headers, this patch has not been forwarded upstream. N: N: Please forward the patch and try to have it included in upstream's version control system. If the patch is not suitable for N: that, please mention not-needed in the Forwarded field of the patch header. N: N: Please refer to social contract item 2, Coordination with upstream developers (Section 3.1.4) in the Debian Developer's N: Reference, Changes to the upstream sources (Section 4.3) in the Debian Policy Manual, and Bug#755153 for details. N: N: Visibility: info N: Show-Always: no N: Check: debian/patches/dep3 N: Renamed from: send-patch N:
Bug#1001625: python3-script-but-no-python3-dep unoverridable
Hi, On Mon, Jan 24, 2022 at 4:03 AM Marc Haber wrote: > > Starting which lintian version are Deb822 overrides allowed? The Deb822 override format has not been released. It will be very soon, however. The implementation of file pointers—which appear inside square brackets on terminals and as live links on our website—has made the old override format cumbersome for many users. > Does all > Debian infrastructure run appropriately recent versions of lintian so > that a package can safely migrate to Deb822 overrides? I cannot speak for users of Lintian, but they are generally provided with timely backports. Kind regards Felix Lechner
Bug#996740: Consider having very-long-line-length-in-source-file ignore autotools files
Hi, On Sun, Oct 17, 2021 at 4:40 PM Russ Allbery wrote: > > That looks like exactly the right way to handle this. The results for your screen are now live on our website. [1] They are a showcase example for how exemptions should be granted in Lintian. Thank you so much for suggesting them! Kind regards, Felix Lechner [1] https://lintian.debian.org/screens/autotools/long-lines
Bug#1003456: Excessive memory use with large binaries
Hi, So far, the most convenient way to reproduce this bug is the following command. It exercises only a single, very simple check. [1] bin/lintian -C linda --debug --no-override --no-tag-display-limit ../picolibc-arm-none-eabi_1.7.4-1_all.deb Kind regards, Felix Lechner [1] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Linda.pm#L32-39
Bug#1001677: Comments regarding pytest-order_1.0.0-1_amd64.changes
Hi Julian, On Sun, Jan 16, 2022 at 7:01 AM Julian Gilbey wrote: > > So perhaps another clause or two, something along the lines of the > following, would be good? Your suggestion was implemented in: https://salsa.debian.org/lintian/lintian/-/commit/d228765ce4db8057fd0c9780b2312c0e26914434 Thank you for making Lintian better for everyone! Kind regards Felix Lechner
Bug#1003817: lintian: fpos for update-debian-copyright
Hi, On Sun, Jan 16, 2022 at 12:30 AM Mattia Rizzolo wrote: > > I guess it's taking the 2021 from the second paragraph? The code assumes there is only one Debian paragraph [1] and issues the tag for any with an outdated copyright. The current year (2022) in just one of them should suffice to silence the tag altogether. I cannot reproduce the behavior with hexchat_2.16.0-3.dsc (although there are probably others) because it lacks the second paragraph. [2] Are you uploading your new version to the archive? It would help me fix the bug. Thanks! Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Debian/Copyright/Dep5.pm#L644 [2] https://sources.debian.org/src/hexchat/2.16.0-3/debian/copyright/
Bug#1001677: Comments regarding pytest-order_1.0.0-1_amd64.changes
Hi, On Sun, Jan 16, 2022 at 2:27 AM Julian Gilbey wrote: > > *If* the consensus is that py3versions -r is wrong, then we should > probably have a lintian check for it: py3versions -r (and variants > such as -rv and -vr) without a corresponding X-Python3-Version field > should give a lintian warning, and py3versions -s with an > X-Python3-Version field should do so likewise. For reference, here is Lintian's current code examining the use of 'py3versions' in tests. [1] Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Testsuite.pm#L289-309
Bug#1003751: In NEW queue
The sources were uploaded and are now in the NEW queue.
Bug#1003813: libghc-lzma-dev: static C library missing as a prerequisite
Package: libghc-lzma-dev Severity: normal Hi, I am new to Debian's ecosystem for Haskell, so please forgive me if this filing is perhaps not entirely justified. When building my new package 'kickoff' [1] using sbuild in a fresh 'unstable' chroot, I received the build error below. It looks to me like the linker could not find the static LZMA library. I believe the library is available in the installable 'liblzma-dev'. (Your package [2] only pulls in the shared version via liblzma5.) Are consuming sources supposed to depend on the C library separately? The full build log was attached to this message. Thank you for your guidance! Kind regards Felix Lechner [1] https://bugs.debian.org/1003751 [2] https://packages.debian.org/sid/libghc-lzma-dev * * * /usr/bin/ld.gold: error: cannot find -llzma /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/lzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz/libHSlzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz.a(lzma_wrapper.o):function hs_lzma_init_decoder: error: undefined reference to 'lzma_stream_decoder' /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/lzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz/libHSlzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz.a(lzma_wrapper.o):function hs_lzma_init_decoder: error: undefined reference to 'lzma_auto_decoder' /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/lzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz/libHSlzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz.a(lzma_wrapper.o):function hs_lzma_init_encoder: error: undefined reference to 'lzma_easy_encoder' /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/lzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz/libHSlzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz.a(lzma_wrapper.o):function hs_lzma_run: error: undefined reference to 'lzma_code' /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/lzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz/libHSlzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz.a(lzma_wrapper.o):function hs_lzma_done: error: undefined reference to 'lzma_end' collect2: error: ld returned 1 exit status `x86_64-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1) make: *** [/usr/share/cdbs/1/class/hlibrary.mk:147: build-ghc-stamp] Error 1 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 kickoff_0.1.0_amd64-2022-01-16T04:50:08Z.build.xz Description: application/xz
Bug#1003751: ITP: kickoff -- Generalized job scheduler (with runners) for the Debian archive
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-lint-ma...@lists.debian.org * Package name: kickoff Version : 0.1.0 Upstream Author : Felix Lechner * URL : https://salsa.debian.org/lintian/kickoff * License : GPL-3.0-or-later Programming Lang: Haskell2010 Description : Generalized job scheduler (with runners) for the Debian archive This package provides a generalized job scheduler. It supports fully configurable processing actions on local copies of the Debian archive. The programs herein generate the contents of the Lintian website. This software falls under Lintian's umbrella and will be updated, managed and serviced by the Lintian maintainers.
Bug#1002614: no longer report source-is-missing for binary file in source
Hi, On Sat, Dec 25, 2021 at 7:00 AM Shengjing Zhu wrote: > > I got rejected by ftp-master Is there a record of the rejection? Which of these excluded files [1] did the Archive Team find in your sources? Thanks! Kind regards Felix Lechner [1] https://salsa.debian.org/zhsj/kata-containers/-/blob/debian/experimental/debian/copyright#L4-63
Bug#1003582: ITP: detagtive -- Lintian web application
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-lint-ma...@lists.debian.org * Package name: detagtive Version : 0.1.0.0 Upstream Author : Felix Lechner * URL : https://salsa.debian.org/lintian/detagtive * License : AGPL-3.0-or-later Programming Lang: Haskell2010 Description : Lintian web application This package is for the Haskell rewrite of the Lintian website. The code will be transferred gradually as the site is migrated. Also ships an executable to generate the special file 'qa-list.txt', on which several important Debian services rely (tracker.d.o among them). This software falls under Lintian's umbrella and will be updated, managed and serviced by the Lintian maintainers.
Bug#1003456: Excessive memory use with large binaries
Hi, On Mon, Jan 10, 2022 at 5:45 AM Ben Hutchings wrote: > > lintian allocated about 23 GiB Thanks for reporting this! That is one of several mysterious results of what happened when I simplified the code. It's possibly due to excessive regex usage, although Perl usually catches that. Another possibility is an accidental recursion in Lintian's copy of your package's file index. Either way, I will shortly add helpful profiling information that you will be able to examine on our website. On the positive side, I broke Lintian's 23 original checks into 353 pieces (and counting). It makes issues much easier to monitor and isolate. Kind regards Felix Lechner
Bug#1002936: lintian: False positive missing-pkg-php-tools-addon when using dh-sequence-phpcomposer
Hi Robin, On Sat, Jan 1, 2022 at 7:39 AM Robin Gustafsson wrote: > > Using it Which package are you working on, please? It's probably one of the 56 sources that trigger the tag: https://lintian.debian.org/tags/missing-pkg-php-tools-addon We cannot investigate your report without that information. Thank you! Kind regards Felix Lechner
Bug#1003340: qa.debian.org: Please agree with salsa on the lintian version to use
Hi, On Sun, Jan 9, 2022 at 8:51 AM Samuel Thibault wrote: > > But what is "latest version"? The latest version is the most recent commit on the 'master' branch in our public repository. [1] We found it is the fastest way to bring bug fixes to the community. Bug fixes can often be verified on our website within days. [2] Our use of the SemVer patch digit [3] is explained on each tag page. [4] You can also have a look at this message. [5] The name of the 'master' branch is subject to change. We already use the more neutral 'history' in most of our other repos. [6][7][8] Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian [2] https://lintian.debian.org/ [3] https://semver.org/ [4] for example, https://lintian.debian.org/tags/bad-whatis-entry [5] https://lists.debian.org/debian-lint-maint/2021/09/msg00148.html [6] https://salsa.debian.org/lintian/detagtive [7] https://salsa.debian.org/lintian/kickoff [8] https://salsa.debian.org/lintian/emacs-lintian
Bug#1003340: qa.debian.org: Please agree with salsa on the lintian version to use
Hi, On Sun, Jan 9, 2022 at 7:36 AM Samuel Thibault wrote: > > we cannot > write lintian overrides files that avoid red flags on both platforms. Lintian's latest version will always be authoritative. In addition, please note that the format for override files is changing. [1] Please remember, however, that Lintian is not your boss. Credit for that critical insight goes to D. Bremner—thank you! On a side note, Salsa has more serious issues when running Lintian jobs. [2][3][4] Thank you for using Lintian! Kind regards Felix Lechner [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003272#10 [2] https://bugs.debian.org/973313 [3] https://salsa.debian.org/salsa/support/-/issues/277 [4] https://salsa.debian.org/lintian/lintian/-/merge_requests/367#note_281411
Bug#1003272: lintian: chokes on overrides with "(" but no ")"
Hi, On Fri, Jan 7, 2022 at 10:18 AM Tobias Frost wrote: > > FWIIW, escaping with a backslash, e.g "\(" *did* work for me earlier today... Okay, thanks! I just knew backslashes do not work for square brackets, which are perhaps more common right now. There, the awkward notation [[] is required until I implement the new override format. Kind regards Felix Lechner
Bug#1003272: lintian: chokes on overrides with "(" but no ")"
Hi, On Fri, Jan 7, 2022 at 2:57 AM Tobias Frost wrote: > > Unmatched ( in regex; marked by <-- HERE in m/( <-- HERE That is a consequence of switching to Text::Glob for overrides. I would suggest '[(]' and '[)]' as probable fixes (backslashes do not work) but more changes are coming to override files. We recently introduced 'pointed hints' which allow live links on our website to sources.d.o and soon others. In terminal output, they are shown as tag annotation [file pointer] but that format is not great for overrides. We will likely allow globbing on the file pointer, regular expressions on the annotation and require literal matches for the tag name. To keep those fields separate, we may switch to a Deb822 format for override files, but hope to provide automated tools for migration and management similar to those we already use internally to interactively recalibrate Lintian's test suite. Kind regards Felix Lechner
Bug#1003271: lintian: skip-systemd-native-flag-missing-pre-depends still relevant?
Hi, On Fri, Jan 7, 2022 at 2:51 AM Tobias Frost wrote: > > the description of the tag has a bug: I just made these changes: https://salsa.debian.org/lintian/lintian/-/commit/f5107b60f4c7bbb9762dd375e3513cf54b3bac0d >From the commit message: The tag combines two checks in one. First, it requires that a Pre-Depends on was declared and, second, that the version is sufficient. The reporting party pointed out that the version requirement is satisfied in oldstable, so the version requirement was dropped from both the code and from the description. The overall check that a Pre-Depends was declared, however, may still be sensible to keep. On the website 73 sources currently provoke the tag, but we cannot if the declaration is missing or just does not satisfy the minimum version requirement. Let's see how the tag performs after this change. Thanks to Tobias Frost for bringing the matter to our attention! Kind regards Felix Lechner
Bug#1002461: Pending with DSA
Hi, > it would be even better if lintian provided up-to-date data. Tracker.d.o relies on a traditional batch file called qa-list.txt. [1] In the past, I had to generate it via UDD [2] because the Lintian database (on puny, non-DSA hardware) had too little memory to run the self-JOIN. Updating UDD became harder when Lintian started to update its database dynamically, for example to illustrate bug fixes. Like tracker.d.o, UDD uses a batch system for imports, while the Lintian website does everything on demand. [3] It is not possible to feed partial updates to UDD. I finally found a benevolent donor for Lintian's database and can now run the query, but lintian.d.o lacks the installation prerequisites. Unfortunately, DSA has been too busy to work on it, and just told me so last week. It might help if you could lean on them to please process RT#8721. At a minimum, we need ghc and cabal-install. Thanks! Kind regards Felix Lechner [1] https://lintian.debian.org/static/qa-list.txt [2] https://udd-mirror.debian.net/ [3] https://lintian.debian.org/query
Bug#1003074: libwolfssl30: wc_HashInit(h, WC_HASH_TYPE_SHA512) overflows
Hi Tim, On Mon, Jan 3, 2022 at 9:09 AM Tim Rühsen wrote: > > Valgrind reports a buffer overflow. The good folks at wolfSSL cannot reproduce the error. Do you '#include ' before the others? Either way, will you please also attach your configuration to this report? Thanks! Kind regards, Felix Lechner
Bug#1002824: lintian/python3-gitlab: Please feel free to reopen
Hi Alex, Please feel free to reopen this bug if your wishlist items for Lintian need more work. Thanks! Kind regards Felix Lechner
Bug#1001655: Avoid hardcoding depends on specific lzip implementations
Hi Daniel, On Tue, Dec 28, 2021 at 7:09 PM Daniel Baumann wrote: > > you can now safely depend on ... "plzip | lzip-decompressor" Great, thanks! Will that work for backports, too? Kind regards Felix Lechner
Bug#1002503: false reports skip-systemd-native-flag-missing-pre-depends
Control: reopen -1 Control: retitle -1 lintian: Clarify all tags about missing Pre-Depends Hi Marc, On Thu, Dec 23, 2021 at 3:57 AM Marc Haber wrote: > > No, a false bug report. Sorry. Confusing tag descriptions are also bugs in Lintian! We strive to please all. Note for later: This is about Depends vs Pre-Depends. Kind regards Felix Lechner
Bug#1002503: false reports skip-systemd-native-flag-missing-pre-depends
Hi Marc, On Thu, Dec 23, 2021 at 3:57 AM Marc Haber wrote: > > Depends: [...] init-system-helpers (>= 1.54~) The tag is asking for Pre-Depends though, isn't it? [1][2] > ippl_1.4.14-12.2_amd64.deb I do not see a declaration for Pre-Depends in your control file. [3] Is Lintian too strict? Kind regards Felix Lechner [1] https://lintian.debian.org/tags/skip-systemd-native-flag-missing-pre-depends [2] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Systemd/Native/Prerequisites.pm#L49 [3] https://tracker.debian.org/media/packages/i/ippl/control-1.4.14-12.2
Bug#1002466: emacs-lintian: Renamed the source package
Hi, Pursuant to a suggestion from the Emacs maintainers (thank you!) the source package was renamed to emacs-lintian and resubmitted to the FTP Masters. The path on Salsa also changed: https://salsa.debian.org/lintian/emacs-lintian Kind regards Felix Lechner
Bug#1002466: ITP: elpa-lintian -- Examine Lintian packaging hints in Emacs
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-emac...@lists.debian.org * Package name: elpa-lintian Version : 0.1 Upstream Author : Felix Lechner * URL : https://salsa.debian.org/lintian/elpa-lintian * License : GPL-3+ Programming Lang: Lisp Description : Examine Lintian packaging hints in Emacs This package provides a command to run Lintian in Emacs. The purpose is to provide extra functionality when examining the resulting packaging hints. A preliminary version may be found in the Lintian source tree. [1] Going forward, I hope to maintain the software jointly as a member of the Lintian Maintainers Team. [1] https://salsa.debian.org/lintian/lintian/-/blob/master/integration/emacs/lintian.el
Bug#968758: Emacs integration for Lintian
Hi, With that commit [1] Lintian now offers rudimentary Emacs integration. [2] In the future, pointed hints may allow the user to travel directly to the file indicated in the packaging hint. Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian/-/commit/addd6064625a6996b76afa0bd81cdb02eacd8ce9 [2] https://salsa.debian.org/lintian/lintian/-/blob/master/integration/emacs/lintian.el
Bug#1002296: dh-haskell: Version 0.5 is now in NEW
Control: tags -1 + pending Hi, Version 0.5 of dh-haskell was uploaded to the NEW queue. [1] Kind regards Felix Lechner [1] https://ftp-master.debian.org/new/dh-haskell_0.5.html
Bug#1002296: ITP: dh-haskell -- Debhelper build system for cabal-based Haskell packages
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-hask...@lists.debian.org * Package name: dh-haskell Version : 0.5 Upstream Author : Felix Lechner * URL : https://salsa.debian.org/lechner/dh-haskell * License : GPL-3+ Programming Lang: Perl Description : Debhelper build system for cabal-based Haskell packages Version 0.4 was dropped from unstable on 2018-11-04 at the author's request in #912000. While the software seemed not useful then, the dh sequencer is now the dominant build system. [1] This version is a simple, but complete rewrite based on /usr/share/cdbs/1/class/hlibrary.mk. It was tested with a Haskell executable that is not in the archive, but not yet with any libraries or documentation. Further adaptation may be required. Going forward, I would like to maintain the software, potentially jointly, as a prospective member of the Haskell Group! [1] https://trends.debian.net/#build-systems
Bug#1001655: Avoid hardcoding depends on specific lzip implementations
Hi Daniel, On Mon, Dec 13, 2021 at 2:00 PM Daniel Baumann wrote: > > all of them, except lzd, do implement --test. Looking at your documentation [1] does that mean Lintian can only offer the alternatives except lzd? Or, is there another way to assess the actual nature or integrity of a file named like *.lz? Thanks! Kind regards Felix Lechner [1] https://sources.debian.org/src/lzip/1.22-4/debian/lzip.README.Debian/
Bug#1001625: python3-script-but-no-python3-dep unoverridable
Hi Marc, On Mon, Dec 13, 2021 at 4:33 AM Marc Haber wrote: > > I wondering whether the missing leading backslash in the path is > correct. You probably meant a regular slash, and not a backslash. Lintian has used such relative-looking path names since before it found me. The only exception I know of is the hint annotation, which is usually taken verbatim from your code. It can include leading slashes (for conffiles, for example, which are absolute). The path you asked about is part of a pointed hint. It includes file information that will soon be a live link on our website. [1] Those paths are taken straight from Lintian's in-memory copy of the file index. [2] [1] https://bugs.debian.org/743226 [2] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Index.pm#L393-396 > debian/sudo-ldap.lintian-overrides:sudo-ldap: > python3-script-but-no-python3-dep /usr/bin/python3 > [usr/share/apport/package-hooks/*] Our Git version already moved past your 2.114.0 with respect to override treatments. We now allow globbing patterns [3] using Text::Glob. [4] Unfortunately, the square bracket I recently selected for file pointers is cumbersome to escape. The backslash \[ does not work, while [[] (from bash) and the question mark ? both work. You could leave out the ending ] or use the even more awkward-looking []]. None of that is great for users. Overrides are currently in flux. Maybe overrides should be in a more capable format, such as Deb822. In your case, that would probably look something like: Tag: python3-script-but-no-python3-dep Note: /usr/bin/python3 Pointer: usr/share/apport/package-hooks/* Perhaps I should also add a tool for users to generate or modify overrides interactively. I have used something similar for years in Lintian's test suite to recalibrate tests for sweeping changes. Kind regards Felix Lechner [3] https://salsa.debian.org/lintian/lintian/-/commit/139009d5a54225ebff4509ec37b979cb898c17fe [4] https://metacpan.org/pod/Text::Glob
Bug#1001651: lintian: changelog-file-missing-explicit-entry: false positives with successive stable uploads
Control: forcemerge 941656 -1 Control: severity 941656 important Hi, On Mon, Dec 13, 2021 at 11:00 AM Cyril Brulebois wrote: > > W: debian-installer source: changelog-file-missing-explicit-entry > 20210731+deb11u1 -> 20210731 (missing) -> 20210731+deb11u2 Your case from stable was already mentioned in the other bug. [1] Merging. A better course of action might have been to retitle the bug to describe the failure better. I did that now. I also upgraded the priority to your requested level of 'important'. On a side note, version parsing is one of the more complex subjects in Debian. Thanks! Kind regards Felix Lechner [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941656#20
Bug#1001655: Avoid hardcoding depends on specific lzip implementations
Hi Daniel, On Mon, Dec 13, 2021 at 11:36 AM Daniel Baumann wrote: > >if only decompression is used: >'lzip | lzip-decompressor' We only use the '--test' functionality. [1] Is that implemented by all alternatives? Also, do we still need to determine the proper name of the executable, as introduced in this commit? [2] Thanks! Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Files/Compressed/Lz.pm#L61 [2] https://salsa.debian.org/lintian/lintian/-/commit/bc64d63c4ecd293687524086b6966e30e9c48ae0
Bug#1001575: lintian: duplicate-globbing-patterns notice says "(lines $lines)"
Control: tags -1 + pending Hi, On Sun, Dec 12, 2021 at 5:09 AM Julian Gilbey wrote: > > Presumably the $lines variable should have been expanded? Thanks! We already caught it in an unreleased commit. [1] Unfortunately, we cannot adopt the relevant Perl::Critic policy just yet, due to unresolved issues elsewhere. Thanks for helping to make Lintian better! Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian/-/commit/87825cb0c24368a4b627b70b7b3c9feecca2157f
Bug#1001463: java-policy: Please retitle to "Java Policy for Debian"
Package: java-policy Hi, Lintian cites your manual as supporting documentation for several tags. [1][2][3][4][5][6][7][8] Such references help users when grasping the conditions that provoke Lintian's recommendations. In our view, your policy [9] should be named "Java Policy for Debian." Will you please retitle it? Thanks! Kind regards Felix Lechner [1] https://lintian.debian.org/tags/bad-jar-name [2] https://lintian.debian.org/tags/build-depends-on-an-obsolete-java-package [3] https://lintian.debian.org/tags/jar-not-in-usr-share [4] https://lintian.debian.org/tags/jar-contains-source [5] https://lintian.debian.org/tags/javalib-but-no-public-jars [6] https://lintian.debian.org/tags/missing-dep-on-jarwrapper [7] https://lintian.debian.org/tags/executable-jar-without-main-class [8] https://lintian.debian.org/tags/package-installs-java-bytecode [9] https://www.debian.org/doc/packaging-manuals/java-policy/
Bug#1001458: lintian: tag prefer-uscan-symlink has bad name and may be wrong
Hi, On Fri, Dec 10, 2021 at 6:28 AM Yadd wrote: > > Multiple-Upstream-Tarballs package (from uscan(1) sorry ;-)) Thanks for the explanation! I'll return the favor: In Lintian, we call them "sources with multiple orig components". On a related note, we generally do not use "packages" to refer to sources (our website is a notable exception). We usually eschew the barebones moniker altogether. In Lintian, installable packages are exactly that, and sources are sources. As an aside, I have been accused of reinventing terminology, but it's really helped Lintian to keep apart things that otherwise sound too similar. In my defense, I developed a low tolerance for confusion when trying to navigate, on a visit, Atlanta's 71 streets named "Peachtree". [1] Just as Debian is recognized for its great packages, peaches are a famous product of Georgia! Kind regards Felix Lechner [1] https://en.wikipedia.org/wiki/Peachtree_Street#Nomenclature
Bug#1001458: lintian: tag prefer-uscan-symlink has bad name and may be wrong
Hi, On Fri, Dec 10, 2021 at 5:51 AM Yadd wrote: > > That's why I think this tag shoud be removed. I think I concur—but what's a MUT, please? Kind regards Felix Lechner
Bug#1001399: lintian: adjust backports-upload-has-incorrect-version-number for ubuntu
Hi, On Thu, Dec 9, 2021 at 8:37 AM Mattia Rizzolo wrote: > > I believe we shouldn't concern > ourselves too much with UNRELEASED (what's the current behaviour here > anyway?) For the majority of tags, the release is not considered but having less concern for UNRELEASED would negatively affect the quality of hints issued on Salsa. [1] I expect that to be the primary Lintian platform for contributors in the future. Kind regards Felix Lechner [1] sample, https://lechner.pages.debian.net/-/mdadm/-/jobs/2004554/artifacts/debian/output/lintian.html
Bug#1001399: lintian: adjust backports-upload-has-incorrect-version-number for ubuntu
Hi, On Thu, Dec 9, 2021 at 7:24 AM Mattia Rizzolo wrote: > > However, in Ubuntu we just started up again the process, and the new > policy says to append ~bpo$UBU_VERSION.1, with $UBU_VERSION 20.04, > 18.04, 20.10, etc. Right now, Lintian's profiles just enable or disable tags. I am not opposed to expanding their capabilities, but is it the right approach? Should the version string for a Ubuntu package also be acceptable even if Lintian ran on Debian? Can Lintian tell the target OS without looking at the version string? Maybe the changelog (except that would not work for UNRELEASED)? Thanks! Kind regards Felix Lechner
Bug#1001247: vim-doc: Please publish Vim packaging policy on the Web
Package: vim-doc Severity: wishlist Hi, Lintian provides references to the Vim packaging in tag descriptions. [1] We determine the appropriate sections by scanning your HTML index file. [2] Vim is somewhat special because your policy is not published. (Doc-base isn't either.) All we can do, therefore, is provide URI into a user's file system. Unfortunately, your URL structure is significantly different between the versions in stable and unstable. (For example, x73.html vs x65.html; please see below for details.) The Lintian maintainers are therefore uncertain which version to provide. The easiest way would be for you to publish your packaging policy on the Web. Several other teams do so. [3] You may be eligible for the same assistance that we were offered from the official New Maintainer's guide. [4][5] For Lintian, we ended up publishing the manual ourselves, but we have a website. [6] Alternatively, I could replace the Vim policy reference in the tag shown above [1] with a more permanent link. I believe that no other tags refer to your policy. Thank you! Kind regards Felix Lechner [1] https://lintian.debian.org/tags/vim-addon-within-vim-runtime-path [2] https://salsa.debian.org/lintian/lintian/-/blob/master/data/authority/vim-policy [3] https://salsa.debian.org/lintian/lintian/-/tree/master/data/authority [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998701#15 [5] https://www.debian.org/doc/manuals/maint-guide/index.en.html [6] https://lintian.debian.org/ * * * If is an underscore, that line specifies the title and URL for the whole manual. bullseye: _::Debian Packaging Policy for Vim::file:///usr/share/doc/vim/vim-policy.html/index.html 1::Vim Addon Packaging in a Nutshell::file:///usr/share/doc/vim/vim-policy.html/index.html#nutshell 2::Vim Packaging::file:///usr/share/doc/vim/vim-policy.html/x73.html 3::Packaging of Vim Addons::file:///usr/share/doc/vim/vim-policy.html/x113.html 3.1::Addon Structure::file:///usr/share/doc/vim/vim-policy.html/x113.html#addon-structure 3.2::Addon Packages::file:///usr/share/doc/vim/vim-policy.html/x113.html#addon-packages 3.3::Registry Entries::file:///usr/share/doc/vim/vim-policy.html/x113.html#registry-entry 4::Tools::file:///usr/share/doc/vim/vim-policy.html/x221.html A::Vim Registry Entry Examples::file:///usr/share/doc/vim/vim-policy.html/a245.html sid: _::Debian Packaging Policy for Vim::file:///usr/share/doc/vim/vim-policy.html/index.html 1::Vim Addon Packaging in a Nutshell::file:///usr/share/doc/vim/vim-policy.html/index.html#nutshell 2::Vim Packaging::file:///usr/share/doc/vim/vim-policy.html/x65.html 3::Packaging of Vim Addons::file:///usr/share/doc/vim/vim-policy.html/x126.html 3.1::Addon Structure::file:///usr/share/doc/vim/vim-policy.html/x126.html#addon-structure 3.2::Addon Packages::file:///usr/share/doc/vim/vim-policy.html/x126.html#addon-packages 4::Tools::file:///usr/share/doc/vim/vim-policy.html/x166.html
Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements
Hi, On Mon, Dec 6, 2021 at 12:44 PM gregor herrmann wrote: > > It's already in NEW (and the other requested package as well). Thank you for your prompt assistance! Lintian provides backports to stable (and some users run it in even more adventurous ways). Is it acceptable for the Lintian maintainers to upload backports of the new packages, or would the Perl team rather handle them via bug reports? I would prefer if the Perl team handled backports as well, but it would be an extra burden. Please just let me know one way or the other. Thanks! Kind regards Felix Lechner
Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements
Hi, On Mon, Dec 6, 2021 at 10:48 AM gregor herrmann wrote: > > I have no good idea how to handle it right now. Thank you for having a look! For Lintian, the functionality of Sub::StrictDecl is probably enough. I requested it separately (and you already assumed ownership). [1] Thank you! Kind regards, Felix Lechner [1] https://bugs.debian.org/1001175
Bug#998701: correct lintian documentation site
Hi, On Sun, Nov 21, 2021 at 1:00 AM Osamu Aoki wrote: > > Felix, what is your plan? The Lintian manual is now published online. The URL is https://lintian.debian.org/manua/index.html. [1] We also provided a navigation entry on our website as well as a redirect to the index page. Thank you! Hope that helps! Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/detagtive/-/issues/13
Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements
Hi, On Sun, Dec 5, 2021 at 12:08 PM gregor herrmann wrote: > > (Just as a note, and that means I won't upload this tonight :)) Thank you for looking into it! Kind regards, Felix Lechner
Bug#1001173: Moo: Should use Depends for libclass-xsaccessor-perl (instead of Recoomends)
Hi, On Sun, Dec 5, 2021 at 10:10 AM intrigeri wrote: > > Would you mind asking upstream about this? I corresponded with Moo's maintainer and others on IRC. Moo does not have any hard prerequisites on XS modules so it can be used in places without a compiler. The upstream decision is essentially for use cases that do not apply here: fatpacking or building from source without a compiler. The consensus seemed to be that it was reasonable to have Class::XSAccessor listed as a hard prerequisite when packaging for Debian. Thanks! Kind regards, Felix Lechner
Bug#1001178: RFP: liblib-relative-perl -- In Perl scripts, Add paths relative to the current file to @INC
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-p...@lists.debian.org * Package name: liblib-relative-perl Version : 1.000 Upstream Author : Dan Book * URL : https://metacpan.org/pod/lib::relative * License : Artistic-2.0 Programming Lang: Perl Description : In Perl scripts, Add paths relative to the current file to @INC Adding a path to @INC to load modules from a local directory may seem simple, but has a few common pitfalls to be aware of: Directly adding a relative path to @INC means that any later code that changes the current working directory will change where modules are loaded from. This applies to the . path that used to be in @INC by default until perl 5.26.0, or a relative path added in code like use lib 'path/to/lib', and may be a vulnerability if such a location is not supposed to be writable. Additionally, the commonly used FindBin module relies on interpreter state and the path to the original script invoked by the perl interpreter, sometimes requiring workarounds in uncommon cases like generated or embedded code. This module proposes a more straightforward method: take a path relative to the current file, absolutize it, and add it to @INC. The more straightforward name librelative-perl was already taken. [1] Perhaps the name proposed here is better for consistency, even though it looks awkward. Lintian presently uses a series of tedious work-arounds to get the same functionality. [2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17] Thanks! Kind regards, Felix Lechner [1] https://tracker.debian.org/pkg/librelative-perl [2] https://salsa.debian.org/lintian/lintian/-/blob/master/bin/lintian#L30-38 [3] https://salsa.debian.org/lintian/lintian/-/blob/master/bin/lintian-annotate-hints#L30-38 [4] https://salsa.debian.org/lintian/lintian/-/blob/master/bin/lintian-explain-tags#L30-38 [5] https://salsa.debian.org/lintian/lintian/-/blob/master/bin/spellintian#L28-37 [6] https://salsa.debian.org/lintian/lintian/-/blob/master/private/generate-tag-summary#L9-18 [7] https://salsa.debian.org/lintian/lintian/-/blob/master/private/hintadjust#L31-40 [8] https://salsa.debian.org/lintian/lintian/-/blob/master/private/hintdiff#L31-40 [9] https://salsa.debian.org/lintian/lintian/-/blob/master/private/hintextract#L31-39 [10] https://salsa.debian.org/lintian/lintian/-/blob/master/private/hintsort#L31-40 [11] https://salsa.debian.org/lintian/lintian/-/blob/master/private/latest-policy-version#L31-40 [12] https://salsa.debian.org/lintian/lintian/-/blob/master/private/refresh-data#L27-35 [13] https://salsa.debian.org/lintian/lintian/-/blob/master/private/refresh-locale-codes#L26-35 [14] https://salsa.debian.org/lintian/lintian/-/blob/master/private/refresh-manual-refs#L32-41 [15] https://salsa.debian.org/lintian/lintian/-/blob/master/private/runtests#L36-44 [16] https://salsa.debian.org/lintian/lintian/-/blob/master/private/tag-stats#L17-26 [17] https://salsa.debian.org/lintian/lintian/-/blob/master/private/generate-profiles#L10-18
Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-p...@lists.debian.org * Package name: perlimports Version : 0.27 Upstream Author : Olaf Alders * URL : https://metacpan.org/pod/App::perlimports * License : Artistic Programming Lang: Perl Description : Automate maintenance of Perl import statements This distribution provides the perlimports command line interface (CLI), which automates the cleanup and maintenance of Perl use and require statements. Loosely inspired by goimports, this tool aims to be part of your linting and tidying workflow, in much the same way you might use perltidy or perlcritic. For a detailed discussion of the problems this tool attempts to solve, see this "Conference in the Cloud" talk from June 2021: Where did that Symbol Come From? [1] Lintian would like to use the functionality to protect against missing imports in rarely used code paths during parallel execution. [2] Thanks! Kind regards, Felix Lechner [1] https://www.youtube.com/watch?v=fKqxdTbGxYY [2] https://lists.debian.org/debian-perl/2021/11/msg00011.html
Bug#1001175: RFP: libsub-strictdecl-perl -- Detect undeclared subroutines in Perl compilation
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-p...@lists.debian.org * Package name: libsub-strictdecl-perl Version : 0.005 Upstream Author : Andrew Main (Zefram) * URL : https://metacpan.org/pod/Sub::StrictDecl * License : Artistic Programming Lang: Perl Description : Detect undeclared subroutines in Perl compilation This module provides optional checking of subroutine existence at compile time. This checking detects mistyped subroutine names and subroutines that the programmer forgot to import. Traditionally Perl does not detect these errors until runtime, so it is easy for errors to lurk in rarely-executed or untested code. Lintian would like to use the functionality to protect against missing imports in rarely used code paths during parallel execution. [1] Thanks! Kind regards, Felix Lechner [1] https://lists.debian.org/debian-perl/2021/11/msg00011.html
Bug#1001173: Moo: Should use Depends for libclass-xsaccessor-perl (instead of Recoomends)
Package: libmoo-perl Hi, Moo performs faster when Class::XSAccessor is available [1] but libmoo-perl only Recommends it. More important, Moo's behavior changes when Class::XSAccessor is installed. [1] For consistency as well as performance, Moo should probably Depend on libclass-xsaccessor-perl. While a new, hard prerequisite may cause some programs using Moo to fail unexpectedly, they would at least do so consistently. It would eliminate a transient class of bugs that depends on whether Class::XSAccessor is present on a reporter's system—something that can be hard to pin down when the installable is only recommended. Lintian was affected in several ways. [2][3][4][5][6] Sorry to report the suggestion with a two-year delay. Thank you! Kind regards Felix Lechner [1] https://metacpan.org/pod/Moo#MOO-AND-CLASS::XSACCESSOR [2] https://salsa.debian.org/lintian/lintian/commit/b951f0d4d83fa76286d1f4bd5836cf256038f31c [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943724#30 [4] https://salsa.debian.org/lintian/lintian/commit/f4c5659353198014d56810bec72225dda1dd21c8 [5] https://salsa.debian.org/lintian/lintian/commit/29a4d4dc6967f959f7c167a8b09e35c3610a3812 [6] https://salsa.debian.org/lintian/lintian/commit/15ae1403b8f455d4672990492cdb7a14929e40dc
Bug#1001164: HTML::TokeParser::Simple: Should perhaps depend on libwww-perl?
Package: libhtml-tokeparser-simple-perl Hi, The documentation indicates that the convenience constructor for a 'url' relies on LWP::Simple [1] but the installable package does not declare libwww-perl as a prerequisite. [2] Should it? The prerequisite HTML::Parser does not declare libwww-perl in 'Depends' either, although it 'Enhances' it. [3] The Lintian maintainers use the described functionality to update data files prior to release [4] but the feature is not tested in autopkgtest. For now, we simply declared libwww-perl as a prerequisite for Lintian. Thanks! Kind regards Felix Lechner [1] https://metacpan.org/pod/HTML::TokeParser::Simple#new($source_type,-$source) [2] https://packages.debian.org/unstable/libhtml-tokeparser-simple-perl [3] https://packages.debian.org/sid/libhtml-parser-perl [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885438#20
Bug#1000977: lintian: bogus elf-error in debug symbols
Hi, On Wed, Dec 1, 2021 at 6:03 PM Andreas Beckmann wrote: > > That seems to happen with any debug symbols package ... Do you have an opinion on the related #1000449 in binutils, please? Thanks! I set 'affects: lintian' on that bug, but am not sure why it does not show up locally. Kind regards Felix Lechner
Bug#1000631: misreports mismatched-override update-debian-copyright
Hi Marc, On Thu, Nov 25, 2021 at 10:57 PM Marc Haber wrote: > > - How am I supposed to override a warning for two lines of copyright > with differnet years? First off, I think this tag is malfunctioning. It should pick the most recent copyright year of any file in ./debian (and not operate on any 'Files' stanza or on individual files). I believe that is the solution to your other Bug#1000629. > in a yet unpublished branch of the aide package > (https://salsa.debian.org/debian/aide), Would you please attach your unpublished d/copyright and d/changelog files to this bug? I'll make them part of our test suite and resolve the issue there. Thanks! Kind regards Felix Lechner