Bug#970106: This bug was marked pending but is not mentioned in Git
Hi Chris, > Bug reopened I usually indicate pending bugs with a commit message, which marks the bug pending *and* generates a changelog message that closes the bug. With new releases provided nearly weekly, I found that an acceptable workflow (while we deal with large numbers of bugs) especially for this one, which was fixed in Git before being filed. Apparently, some people disagree. Perhaps you could also check your draft changelogs against pending bugs before a release, if you do not already do so. Thanks! Kind regards Felix Lechner
Bug#969541: lintian: globbing-patterns-out-of-order false positive
Hi Ximin, > W: wasi-libc source: globbing-patterns-out-of-order > libc-top-half/musl/arch/*/bits/* libc-top-half/musl/arch/mips64/* This is an interesting case for a better specification of the DEP-5 format. Lintian considers the latter pattern to be broader. I will have to think about that one for a little while. Kind regards Felix Lechner
Bug#970105: lintian-info -t stopped working
Hi Uwe, On Fri, Sep 11, 2020 at 12:10 PM Uwe Kleine-König wrote: > > lintian-info isn't working any more as before: The name was changed to lintian-explain-tags. [1] Please use that instead. As a bonus, you now get all tags when none are specified. Thanks! > Maybe lintian-info can be made a wrapper The name was the issue. It meant too little and too much. The new name is more specific, and better. Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian/-/commit/9b433ce10e2b8f786599c0b1918765af0bd84458
Bug#970006: unused-override is reported with new tag name
Hi Jelmer, On Fri, Sep 11, 2020 at 5:08 AM Jelmer Vernooij wrote: > > For example, see iio-sensor-proxy. Its debian/source/lintian-overrides has: > > iio-sensor-proxy: binary-without-manpage usr/bin/monitor-sensor > iio-sensor-proxy: binary-without-manpage usr/sbin/iio-sensor-proxy > iio-sensor-proxy: systemd-service-file-missing-documentation-key > lib/systemd/system/iio-sensor-proxy.service That is not quite what I am seeing. I believe these overrides are incorrectly listed as source overrides in d/source/lintian-overrides. [1] The tags are for installation packages, so their overrides in the source package remain unused (one unrelated tag was removed): % bin/lintian /mirror/debian/pool/main/i/iio-sensor-proxy/iio-sensor-proxy_3.0-1.dsc I: iio-sensor-proxy source: unused-override no-manual-page usr/bin/monitor-sensor I: iio-sensor-proxy source: unused-override no-manual-page usr/sbin/iio-sensor-proxy I: iio-sensor-proxy source: unused-override systemd-service-file-missing-documentation-key lib/systemd/system/iio-sensor-proxy.service P: iio-sensor-proxy source: renamed-tag binary-without-manpage => no-manual-page in line 2 P: iio-sensor-proxy source: renamed-tag binary-without-manpage => no-manual-page in line 3 As a courtesy, Lintian also reminds the user that the tag was renamed. For the installation package, on the other hand, Lintian reports (some unrelated tags were removed): % bin/lintian /mirror/debian/pool/main/i/iio-sensor-proxy/iio-sensor-proxy_3.0-1_amd64.deb W: iio-sensor-proxy: no-manual-page usr/bin/monitor-sensor W: iio-sensor-proxy: no-manual-page usr/sbin/iio-sensor-proxy I: iio-sensor-proxy: package-supports-alternative-init-but-no-init.d-script lib/systemd/system/iio-sensor-proxy.service I: iio-sensor-proxy: systemd-service-file-missing-documentation-key lib/systemd/system/iio-sensor-proxy.service I: iio-sensor-proxy: systemd-service-file-missing-install-key lib/systemd/system/iio-sensor-proxy.service As far as I can tell, Lintian reports what was intended. Can you please try moving the file in [1] to debian/iio-sensor-proxy.lintian-overrides? Kind regards Felix Lechner [1] https://sources.debian.org/src/iio-sensor-proxy/3.0-1/debian/source/lintian-overrides/
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#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#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#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, > 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#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#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#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#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#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#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#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#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#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#968611: lintian: No SIGCHLD handler set when running on multiple package groups
Package: lintian Severity: important Owner: Shengjing Zhu The IO::Async heisenbug was mitigated for single package groups but still occurs when multiple groups are run together. There are two ways to mitigate the issue: 1. Provide an implementation of Lintian::IO::Async::unpack_and_index_piped_tar that does not use IO::Async. 2. For separate processes for each package group. Thanks to Shengjing Zhu for catching this issue! Kind regards Felix Lechner
Bug#968416: lintian: Gives ridiculous warning about spelling in overrides file
Hi Robert, > Most of the spelling tags > will be reduced to 'info' severities next week. Please see https://salsa.debian.org/lintian/lintian/-/commit/93e50254ef683200a9433f69035813cf0509eef1 > We'll try to address the line number too Please see https://salsa.debian.org/lintian/lintian/-/commit/69565d4cb9e20542edfc705bd270eb52f9f3a15c > Aside from those observations, there is an underlying false positive. We are still working on the underlying false positive. Kind regards Felix Lechner
Bug#968416: lintian: Gives ridiculous warning about spelling in overrides file
Hi Robert, On Fri, Aug 14, 2020 at 4:36 PM Robert Luberda wrote: > > lintian started to show the following ridiculous warning about > spelling in a line that is supposed to explain why lintian is > wrong with its "typo in manual page" warning. First off, you are seeing too many warnings. Most of the spelling tags will be reduced to 'info' severities next week. Here is the full list: tags/s/spelling-error-in-binary.desc:Severity: info tags/s/spelling-error-in-changelog.desc:Severity: warning tags/s/spelling-error-in-copyright.desc:Severity: info tags/s/spelling-error-in-description.desc:Severity: warning tags/s/spelling-error-in-description-synopsis.desc:Severity: warning tags/s/spelling-error-in-doc-base-abstract-field.desc:Severity: warning tags/s/spelling-error-in-doc-base-title-field.desc:Severity: warning tags/s/spelling-error-in-news-debian.desc:Severity: warning tags/s/spelling-error-in-patch-description.desc:Severity: warning tags/s/spelling-error-in-readme-debian.desc:Severity: warning tags/s/spelling-error-in-rules-requires-root.desc:Severity: warning tags/s/spelling-in-override-comment.desc:Severity: warning We'll try to address the line number too, although many of our line references are approximate (as are those in the coding universe). I am not sure why you spent so much time. Your override file is only three lines long. [1] More than likely, your confusion was caused by the fact that the offending phrase also appeared in line 3, but that line is not an override comment. Aside from those observations, there is an underlying false positive. We may ultimately turn off the multi-word part of spell check for override comments, or perhaps require that spaces are used instead of word breaks. We are in touch with our chief spell checker to find the best solution for you. Thanks to Paul Wise for these suggestions! [1] https://sources.debian.org/src/super/3.30.1-1/debian/lintian-overrides/ > what's the point of checking spelling there? Like most of our tags, this one is based on user suggestions. Being a checking tool, Lintian tends to check more rather than less. It is always better to ignore our tags instead of getting frustrated. We are trying to make Lintian more accurate and helpful for everyone. We also do not know how common an issue is when a tag is implemented. In the future, we hope to derive a diagnostic power from comparing false positives (as indicated by overrides) to the overall prevalence in the archive. That will help us drop tags that are annoying rather than helpful, for Debian contributors as a whole. > And BTW. are you going > to check spelling of comments in source code files as well? I'm pretty > sure you can find a lot of spelling typos there... I am sorry but we do not plan to implement your suggestion. You may be correct that there are lots of typos in code comments but that task is too complicated for us. Patches are welcome. Kind regards Felix Lechner
Bug#968262: lintian: spare-manual-page misses .so targets
Hi Ross, On Wed, Aug 12, 2020 at 7:17 PM Ross Vandegrift wrote: > > Is that unusual or incorrect?'. I cannot answer that. From Lintian's perspective, there is no executable for the manual page, and that is how the tag works. The easiest thing would be to add an override. Alternatively, you could name the manual page after one of the utilities, but then you probably also have to change the contents to avoid 'wrong-name-for-manual-page'. You would probably end up listing the names of all utilities (although the one matching the manual page's file name is the only required). As a side note, I am not sure how helpful terminology-helpers.1 is. Why don't you just link to the main manual page terminology.1 and add a section about the helpers there? Other alternatives would be to split terminology-helper.1 into multiple files in hope that someone would get around to adding information. You could also delete terminology-helpers.1 and add overrides for each of the utilities, but that would be my least favorite option. Hope this was helpful. Kind regards Felix Lechner
Bug#968262: lintian: spare-manual-page misses .so targets
Hi Ross, On Tue, Aug 11, 2020 at 10:39 PM Ross Vandegrift wrote: > > I: terminology-data: spare-manual-page > usr/share/man/man1/terminology-helpers.1.gz The links are fine, but I could not find an executable named terminology-helpers in your installation packages. Do you ship one? Kind regards Felix Lechner
Bug#968071: lintian: Differentiate between "ar" static libraries and "ar" archives
Hi Olek, On Fri, Aug 7, 2020 at 6:03 PM Olek Wojnar wrote: > > Lintian currently emits an arch-dependent-file-in-usr-share I cannot find bazel in the archive. How can I trigger the tag, please? > lintian assumes that this is a static library. That is probably right. The relevant line is: https://salsa.debian.org/lintian/lintian/-/blob/master/checks/binaries.pm#L345 > https://salsa.debian.org/bazel-team/bazel-bootstrap/-/tree/olek-temp4/tools/build_defs/pkg/testdata The link shows source files but the tag is about installed files. Which *.deb are you using, please? > Please consider using the `file` command or something similar to distinguish > between the two types of "ar" files. I am not sure it is possible to distinguish them that way, but am happy to look at it once I can reproduce. The ar files in your source tree also come up as 'current ar archive'. Kind regards Felix Lechner
Bug#968041: lintian: fails with internal error
Hi, On Fri, Aug 7, 2020 at 8:06 AM Raphaël Hertzog wrote: > > I get the same error for lzop as well as for unzip. Thanks, lzop was added too: https://salsa.debian.org/lintian/lintian/-/commit/424208c0365c401a89577742e6db5f7aee715fc1 Kind regards Felix Lechner
Bug#968041: lintian: fails with internal error
Control: tags -1 + pending
Hi Sudip,
On Fri, Aug 7, 2020 at 2:51 AM Sudip Mukherjee
wrote:
>
> No such file or directory at /usr/share/perl5/IPC/Run3.pm line 417.
> Lintian::IPC::Run3::safe_qx("unzip", "-l",
> "/tmp/lintian-pool-tbdEtEj6Sb/pool/libi/libisnativec-java/libi"...) called at
Do you have the 'unzip' program installed? I think it is missing from
Lintian's prerequisites. Fixed here:
https://salsa.debian.org/lintian/lintian/-/commit/2fe37725b5816551b0850d2fe431c606bf5cefa2
In the commit, I forgot the hash before the bug number so the message
was not automatically forwarded here.
Please confirm if installing unzip fixes your problem. Thanks!
Kind regards
Felix Lechner
Bug#968011: lintian: Stop shipping modules in system path
Package: lintian Severity: normal Control: block -1 by 968000 Hi, Some modules were kept in Perl's system path because they are used by libconfig-model-dpkg-perl. A bug with some suggestions was filed in Bug#968000. The Perl packaging team is working hard to resolve the other bug, which blocks this one. The affected Lintian modules are presently shipped in two locations. This is a reminder to remove the duplicate files. The line 'lib/Lintian usr/share/perl5' should then be dropped from d/lintian.install. Aside from the other bug, more information may be available in commits 818b3aad and 0df1a8ed. Kind regards Felix Lechner
Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way
Hi Dominique, On Thu, Aug 6, 2020 at 8:10 AM Dominique Dumont wrote: > > Please wait until the next release of libconfig-model-dpkg-perl. No rush, please. We will keep shipping the modules until you close this bug. Thank you! Kind regards Felix Lechner
Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way
Hi gregor, On Thu, Aug 6, 2020 at 7:28 AM gregor herrmann wrote: > > having the > version in a file was the big advantage of using the lintian data. I figured. How about depending on debian-policy and using the information in its changelog? Kind regards Felix Lechner
Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way
Hi Dominique, On Thu, Aug 6, 2020 at 6:43 AM Dominique Dumont wrote: > > Does that sound reasonable ? First of all, thanks for your swift reply! I have no preference how the package gets the information. I suggested a solution only in order to appear helpful. Thanks for addressing it so promptly. Unless you advise otherwise, Lintian will stop shipping the modules in the system path in the next release. As a side note, it seems the changelog date could differ from the tag date, but that is a question for the policy editors. Kind regards Felix Lechner
Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way
Package: libconfig-model-dpkg-perl Severity: normal Hi, Your package is the only known consumer of Lintian's internal Perl modules. We would like to stop shipping our modules in the Perl system path. Here is another way to get the information you require. Your package loads a default Lintian profile [1] and uses the Lintian::Data mechanism to get the policy release dates from data/standard-version/release-dates [2]. It may be tempting to use a simpler parser, but please consider that the information actually originates somewhere else. [1] https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-perl/-/blob/master/lib/Config/Model/Dpkg/Control/Source/StandardVersion.pm#L19-23 [2] https://salsa.debian.org/lintian/lintian/-/blob/master/data/standards-version/release-dates Attached is a script that extracts the release dates from the policy changelog. It uses the network. The data will always be current. More information may be available in Bug#903220, which caused you to use Lintian in the first place. For some time, Lintian has had issues with outdated modules loading from the system path. Starting with the next release, Lintian will in addition ship its Perl modules in a private location. Please let us know when we can stop shipping our modules in the Perl system path. Thank you! Kind regards Felix Lechner get-policy-release-dates.xz Description: application/xz
Bug#966817: New dependency on lzip not documented in changelog
Hi Josh, On Sun, Aug 2, 2020 at 11:09 AM Josh Triplett wrote: > > lintian 2.86.0 introduces a new dependency on lzip, but does not > document that dependency in the changelog. Lzip is used in checks/files/compressed/lz.pm but was never available. More information about that check is in Bug#702545. What is the proper remedy for your bug, please? 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#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#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#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-contain
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#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#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#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#962601: manpage-section-mismatch doesn't take into account manpages with multiple binaries
Hi On Wed, Jul 8, 2020 at 7:41 PM Sergio Durigan Junior wrote: > > I honestly don't feel like spending > too much time investigating Perl's internals What does it have to do with Perl's internals, please? > What do you think? Would Text::Balanced help extract the quoted strings, and work from there? Kind regards Felix Lechner
Bug#964281: marked as pending in lintian
Hi Axel, On Wed, Jul 8, 2020 at 5:45 PM Axel Beckert wrote: > > Huh? I've never seen such a line. Do you use 'quilt header -e --dep3' ? Kind regards Felix Lechner
Bug#962601: manpage-section-mismatch doesn't take into account manpages with multiple binaries
Control: reopen -1 Hi Sergio, On Wed, Jun 10, 2020 at 9:57 AM Sergio Durigan Junior wrote: > > after calling Text::ParseWords::parse_line, we check to > see if the first package name has a comma as the last char. If it does, > then we assume that there will be at least one other package name > listed, and advance an index. When we reach a package name whose last > char is not a comma, we then assume that the next field is the manpage > section number. Something in that patch is not quite working. I previously added a safeguard for an undefined value warning, but that was not enough: https://salsa.debian.org/lintian/lintian/-/commit/d3c64d8ab40de6e38c96334e2515550df1957a4a In an archive-wide run, the modified patch still produced the warnings below. I show the complete list for the record, and not to intimidate anyone. It's no big deal. You may want to check out kde-dev-scripts, which generated a lot of warnings. Kind regards, Felix Lechner * * * Warning in group allegro5/2:5.2.6.0-2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group babeltrace2/2.0.3-2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group blender/2.82.a+dfsg-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group blender/2.83.1+dfsg-2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group checkit-tiff/0.2.3-2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group claws-mail/3.17.5-2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group comptext/1.0.1-4: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group comptty/1.0.1-4: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group dballe/8.6-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group delay/1.0-5: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group derivations/0.56.20180123.1-2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group gadmin-proftpd/1:0.4.2-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group git/1:2.27.0-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group git/1:2.27.0+next.20200625-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group git-repair/1.20200102-1: Use of uninitialized value $th_fields[1] in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group gmic/2.4.5-1.1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group guymager/0.8.12-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group kde-dev-scripts/4:18.08.0-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group libapache2-mod-qos/11.63-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group lavacli/1.0-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group lava/2020.06-2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group lirc/0.10.1-6.2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group lksctp-tools/1.0.18+dfsg-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group lxqt-config/0.14.1-4: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group manpages/5.07-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group manpages-ja/0.5.0.0.20180315+dfsg-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group manpages-zh/1.6.3.4-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group mariadb-10.3/1:10.3.23-1: Use of uninitialized value in s
Bug#769066: lintian: Consider processing files in disk order
Hi, > access files in disk order to increase performance What was the speedup in man-db and dpkg, please? Kind regards Felix Lechner
Bug#964381: lintian: Detecting bogus email address
Hi Hugh, On Mon, Jul 6, 2020 at 6:24 AM Hugh McMaster wrote: > > Should I ignore lintian, override the tag or change the problem email > addresses > to the upstream author's actual email address (also found all over the > changelog)? Adam confirmed via private email that changing the address is okay. An internal address appeared by mistake. Alternatively, you could wait until a new version of Data::Validate::Domain is uploaded. At that point, the TLD validation will probably be turned off (although it worked well in your case). The use of that feature is worth a discussion somewhere. Please feel free to close this bug report. Kind regards Felix Lechner
Bug#964111: dpkg-source: False positive 'points outside source root'
Hi Holger, On Tue, Jul 7, 2020 at 2:29 AM Holger Levsen wrote: > > sigh. so IMNSHO now lintian *and* dpkg are buggy. Or point me to policy > which prohibits files pointing to /dev/null. This worked for years. The restriction applies only to source packages and not to installation packages. Is it such a burden to create the file in d/rules, or elsewhere? It should be one line, at most. The logic is a little bit similar to device nodes, or other special files. Kind regards Felix Lechner
Bug#964111: dpkg-source: False positive 'points outside source root'
Hi Guillem,
On Fri, Jul 3, 2020 at 9:54 PM Guillem Jover wrote:
>
> As long as the autopkgtests show regressions for the involved packages
>From Lintian's perspective, this bug is now resolved. After some
changes on our side, Lintian builds in unstable (without a new upload
of dpkg). I would normally close the bug, but did not wish to
interfere with Holger's matter below.
>From our Salsa job #850167:
debian/test-out/eval/checks/files/encoding/testsuite-in-western-encoding/generic.t
. ok
debian/test-out/eval/checks/testsuite/national-encoding/generic.t
.. ok
debian/test-out/eval/checks/testsuite/testsuite-general/generic.t
.. ok
> there
> are still other regressions being dealt with…
The following information could be helpful to you: I initially thought
that Bug#964234 ("dpkg-source: Considers missing symlink targets
directory traversals") was the same, but I am no longer sure. More
significantly, our test suite no longer reproduces the other bug.
The three tests mentioned earlier all create links with missing
symlink targets in source packages, but do not FTBFS (or perhaps
succeed now for unrelated reasons).
ln -s nonexistent "$DIR/debian/tests/broken"
I attached one of the packages for you.
> not sure if this is the same bug or just a similar one:
> lrwxrwxrwx 1 user user 9 Jul 3 16:07 debian/munin.service -> /dev/null
As for Holger's package, Lintian also flags that condition. Source
packages can be unpacked anywhere. We likewise consider absolute
symlink targets unacceptable there.
W: munin source: absolute-symbolic-link-target-in-source
debian/munin.service -> /dev/null
Hope this helps!
Kind regards
Felix Lechner
testsuite-general_1.0.dsc
Description: Binary data
testsuite-general_1.0.tar.xz
Description: Binary data
Bug#964381: lintian: Detecting bogus email address
Hi Hugh, On Mon, Jul 6, 2020 at 6:24 AM Hugh McMaster wrote: > > lintian has detected two identical entries in yaz's debian/changelog > as bogus. Thank you for filing this report. The address is indeed bogus, although we tried to turn off TLD validation. That issue is being addressed separately. [1] % whois flurry.index No whois server is known for this kind of object [1] https://lists.debian.org/debian-perl/2020/07/msg7.html > The entries are adam@flurry.index. I wrote to another email address from your changelog that was used recently in the Debian BTS and pointed Adam to this bug. > I'm not sure how to address this. Unless Adam objects, I would replace the bogus address with the one recently used in Bug#955501. Kind regards Felix Lechner
Bug#964282: marked as pending in lintian
Hi Axel,
On Sun, Jul 5, 2020 at 6:57 AM Axel Beckert wrote:
>
> Why didn't the test suite catch that second case?
The tests do not exercise all execution paths. :(
In our new coding practices, we try to separate diagnostics and
issuance like this (please see the use of the array @empty), but there
is legacy code:
my @all = keys %{$self->processable->field};
my @empty = grep { $self->processable->field($_) =~ /^\s*$/ } @all;
$self->tag('empty-field', $_) for @empty;
> I actually stashed that fix in wml for now as the crash at least
> showed me that it was obviously an incomplete fix.
What is 'wml', please? Maybe I should use it too. :)
Kind regards
Felix Lechner
Bug#964281: marked as pending in lintian
Hi Axel, On Sun, Jul 5, 2020 at 6:45 AM Axel Beckert wrote: > > > This commit has a potential to disturb the release process. The two tests t/recipes/checks/files/encoding/utf8-header-fix-encoding-patch/ t/recipes/checks/files/encoding/national-header-fix-encoding-patch/ contain legacy encoding and would have triggered 'national-encoding' when Lintian is released. The Lintian maintainers, however, strive to keep Lintian itself Lintian-clean. The occurrence is traditionally prevented by either (1) creating the offending files on the fly or (2) by adding a programmatic exemption for the 'lintian' package. Here I did not do either. The latter leads to ridicule on IRC and was remedied in a general way with this commit, but is currently untested: https://salsa.debian.org/lintian/lintian/-/commit/4f4654ddfd2841f5440a83bc3f30b6091b10986c So before burdening fellow maintainers with unexpected release problems, I tested a full package build, and then ran Lintian on itself, in a testing chroot. I would have liked to use unstable but Lintian does not currently build there as a result of a bug in Dpkg. > Ah, this probably also explains why > https://lintian.debian.org/tags.html misses some of the new tags. I > searched for "breakout-link" in it for a reference to upstream several > times the past few days. Unfortunately, it does not. Over the past few months, the website has been updated only sporadically from my own hardware and database systems, which have more resources than the service provided by DSA. Some details are in Bug #779228. I am not sure sure what is causing the problems (and I am sure DSA would provide additional resources if I asked) but for many users the service is deficient in other ways. Most notably, it is difficult from a scheduling perspective to provide just-in-time analysis for new uploads. In any event, people only see those results after they upload. Ideally, they would see them before. To tackle that use case from a different angle, I worked with the Salsa CI team to modify the standard runner so Lintian tags are issued in Salsa CI. (That already happens on a regular basis, but the results are stored as JUnit xml and generally ignored.) We added a new standalone HTML output mode, which is described here [1]. A nice web page that resembles lintian.d.o will be shown to a majority of Salsa users a short time after they commit to their master branches. [1] https://lists.debian.org/debian-lint-maint/2020/07/msg00022.html The Lintian website will probably provide links to the relevant Gitlab pages in Salsa. We will also advise tracker.d.o of these new resources and URLs. To reimagine lintian.d.o., we may also collect those individual Lintian results for research and archival purposes. The Lintian website will probably become a research tool for the QA team with higher order functions that Lintian does not currently provide, such as full dependency graph analysis, which would be appreciated by the bootstrapping team. Some of ideas are mentioned here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896012#31 Thank you for your valuable contributions to Lintian, and sorry about any inconvenience as we try to make the software better for everyone. Kind regards Felix Lechner
Bug#964290: lintian: FP missing-build-dependency-for-dh-addon gir => gobject-introspection
Package: lintian Severity: normal Submitter: Paul Gevers X-Debbugs-CC: elb...@debian.org Hi Paul, It's a bug. I filed this report on your behalf. I will be on top of it after I resolve something time sensitive early this week. Thank you for your patience! Kind regards Felix Lechner * * * >From Paul: In my package liferea, I am getting this error: missing-build-dependency-for-dh-addon gir => gobject-introspection but I have in my control: gobject-introspection | dh-sequence-gir I added the alternative in 2019 because lintian suggested it. I am surprised it went from a recommendation to an error in one year.
Bug#964234: dpkg,firmware-nonfree: cannot unpack: dpkg-source: error: pathname 'firmware-nonfree-20190717/debian/config/libertas/sd8688_helper.bin' points outside source root
Hi Andreas, > dpkg-source: error: pathname > points outside source root Maybe the same as Bug#964111? Kind regards Felix Lechner
Bug#963939: lintian: breakout-link wrongly reported against jar files
Control: tags -1 - pending Hi Chris, On Fri, Jul 3, 2020 at 1:02 PM Chris Lamb wrote: > > Please go ahead. https://salsa.debian.org/lintian/lintian/-/commit/8016b7d681f5b1e5a1864ac7d88da4c29fc73af7 I'll try to remember to reopen if you release before this is resolved. Kind regards Felix Lechner
Bug#964215: libwolfssl-dev: #warning "For timing resistance / side-channel attack prevention consider using harden options"
Hi Thorsten, On Fri, Jul 3, 2020 at 3:26 PM Thorsten Glaser wrote: > > Whoa, I didn’t mean you had to upload, right today, just for that ☻ > but thanks anyway. wolfSSL is seeing an increase in popularity. By uploading, I hoped to avoid additional uncertainty about the compatibility mode. Kind regards & happy encrypting! Felix Lechner
Bug#963939: lintian: breakout-link wrongly reported against jar files
Hi Chris, > I don't think this warning applies to architecture independent jar files. After speaking with others about these links, I am not sure our existing fix is appropriate. I think it should be reverted until we hear from Emmanuel. Kind regards Felix Lechner
Bug#964215: libwolfssl-dev: #warning "For timing resistance / side-channel attack prevention consider using harden options"
Hi Thorsten, On Fri, Jul 3, 2020 at 12:14 PM Thorsten Glaser wrote: > > I did consult the Debian-packaged README, but it > had no such thing, The instructions for the OpenSSL layer are not Debian-specific, but I will add a note to the README.Debian to bridge the documentation gap. > and the code compiles without it. Sounds like the compatibility layer had everything you needed. I am glad to hear it. Which package is it, please? > Why, if this file is so important, is it not automatically included? I have asked myself that, as well. Maybe there is a technical reason, or maybe the authors would like people to use the native interface. Either way, the library works great once you get over the small hurdle! Please feel free to close this bug. Kind regards Felix Lechner
Bug#964215: libwolfssl-dev: #warning "For timing resistance / side-channel attack prevention consider using harden options"
Hi Thorsten, On Fri, Jul 3, 2020 at 11:21 AM Thorsten Glaser wrote: > > Just using the library (as OpenSSL drop-in for licence compliance > in Debian terms) produces the following warning: Did you '#include ' in each file before using the OpenSSL compatibility headers as described in the instructions? [1] I know the manual is not that clear, but it works for me every time. I can also help with porting, if needed. Kind regards Felix Lechner [1] https://www.wolfssl.com/docs/wolfssl-manual/ch13/
Bug#964111: dpkg-source: False positive 'points outside source root'
Hi, On Thu, Jul 2, 2020 at 10:11 PM Guillem Jover wrote: > > The affected pathnames contain symlink loops, which I'd consider to be > erroneous constructs, and I don't see why we'd want to allow these. In > this case this seem just like an incorrect error message. I've updated > this locally now to print a matching error message, and I'm thus > lowering the severity to match too. The links Dpkg now disallows were removed from the three Lintian tests, but our CI pipeline still fails. Why did you lower the severity instead of releasing a fix? If version 1.20.3 progresses to testing, Lintian loses its last functioning CI pipeline. (Our stable-bpo pipeline is optional with a reduced test set.) Kind regards Felix Lechner
Bug#963939: lintian: breakout-link wrongly reported against jar files
Hi Emmanuel, On Sun, Jun 28, 2020 at 3:06 PM Emmanuel Bourg wrote: > > This is due to links in /usr/lib/eclipse/plugins/ > pointing to jar files in /usr/share/java/. > I don't think this warning applies to architecture independent jar files. Why did you place the links, which appear to be architecture-independent, in /usr/lib and not in /usr/share? eclipse-debian-helper (1.3) unstable; urgency=medium * Add a symlink in /usr/lib/eclipse/plugins/ when installing a plugin -- Emmanuel Bourg Fri, 28 Sep 2018 00:21:02 +0200 Kind regards Felix Lechner
Bug#964073: lintian: Possible false positives for breakout-link for Lua modules
Hi Russ, On Wed, Jul 1, 2020 at 9:55 PM Russ Allbery wrote: > > I'm not active and don't want to second-guess how > you're handling things. Thank you for writing that. I have likewise been reluctant to comment on the good work of past maintainers. > But I guess I'll say here that I think the point > of a linter is externalized good taste. It's a codification of good > judgment calls about the way to construct a package. I actually exercise relatively little judgment, at least by Debian standards. On the contrary, I try to accommodate every bug filer, but it is hard. People have so many expectations and styles. And often, my solutions are not appreciated. > I should have, and probably the answer is that I didn't read it in any > detail. It's never too late. I am happy to change the check, or to drop it entirely, if you can figure out the original problem. It may involve tools with which I am unfamiliar. > That said, I think the way I would have interpreted that bug would have > been to warn about symlinks inside /usr/lib to outside of /usr/lib. That seems to be the consensus between Sergei, Chris and myself. It's also what the check does now. > looking at it now, I'm not sure what problem that would cause and > therefore what purpose would be served by warning about it. I am not sure, either. Perhaps a future bug report will tell. > In general, I wouldn't assume that all the old bugs are valid or > interesting. After some reflection, I found that the most defensible way to close feature requests is to implement them. On a personal note, thanks for your book reviews. I serve as a library commissioner in a town near you, and enjoyed reading them. Kind regards Felix Lechner
Bug#964073: lintian: Possible false positives for breakout-link for Lua modules
Hi Russ, On Wed, Jul 1, 2020 at 8:16 PM Russ Allbery wrote: > > I'm puzzled by why you would have changed Lintian in response to that bug, > given that the reported problem was only with Lintian and was fixed > sixteen years ago. I am just working through open bugs. Why did you not voice your opposition as a maintainer during the past seventeen years, or close the bug? Kind regards Felix Lechner
Bug#964073: lintian: Possible false positives for breakout-link for Lua modules
Hi Sergei, On Wed, Jul 1, 2020 at 1:33 AM Sergei Golovan wrote: > > Though, the link never goes outside /usr/lib/x86_64-linux-gnu, > so I would say that this warning is spurious. I am not sure who is right, but the warning is not spurious from the perspective of the original requestor. Bug#243158 cited a scenario very much like yours as the reason for why the dynamic linker was confused. Those links also never left /usr/lib. Like so many bugs in Debian, however, the feature was requested 17 years ago. At that point, Lua had already been around for ten years (having arrived in 1993). Do you know when Lua adopted the current shared object hierarchy and resolution method? Kind regards Felix Lechner
Bug#964111: dpkg-source: False positive 'points outside source root'
Control: retitle -1 dpkg-source: False positive 'points outside source root' Control: severity -1 serious Hi, The initial filing said the three packages contained link targets outside of the package root, but that is not so. This is not right: dpkg-source: error: pathname 'testsuite-general-1.0/debian/tests/self1' points outside source root One of the affected test packages is attached to this message. When issuing the false positive, dpkg-source also exits with status 25. Everything goes away when the patch is applied, but in the meantime this bug breaks the Lintian testsuite. Accordingly, I upgraded the severity to prevent migration until the bug is fixed. Kind regards Felix Lechner testsuite-general_1.0.dsc Description: Binary data testsuite-general_1.0.tar.xz Description: Binary data
Bug#964111: dpkg-source: Uninitialized value $canon_pathname
Package: dpkg-source
Severity: minor
Tags: patch
X-Debbugs-CC: debian-lint-ma...@lists.debian.org
Hi,
The new version of dpkg-source recently caused the failures of three
Lintian tests. All had link targets pointing outside the source root,
which caused the failures, but there was an additional warning:
Use of uninitialized value $canon_pathname in pattern match (m//)
at /usr/share/perl5/Dpkg/Source/Package.pm line 555.
Here are the tests:
checks/files/encoding/testsuite-in-western-encoding
checks/testsuite/national-encoding
checks/testsuite/testsuite-general
The patch below caused the warning to disappear. Thank you for your
hard work on Dpkg.
Kind regards
Felix Lechner
* * *
--- Package.pm2020-07-01 21:35:04.978251308 +
+++ /usr/share/perl5/Dpkg/Source/Package.pm2020-07-01
21:35:42.846687621 +
@@ -552,6 +552,7 @@
my $canon_newdir = realpath($newdirectory);
my $check_symlinks = sub {
my $canon_pathname = realpath($_);
+return unless length $canon_pathname;
return if $canon_pathname =~ m/^\Q$canon_newdir\E/;
error(g_("pathname '%s' points outside source root"), $_);
Bug#953629: Bug#953554: Please permit Debian revisions with 1.0 native packages [and 1 more messages]
[This is the policy bug.] Hi, On Mon, Jun 15, 2020 at 5:18 PM Sean Whitton wrote: > > the relevant sentence of Policy ... was intended to be > informative, not normative. Just a brief post scriptum: I had to disable a test in Lintian due to new restrictions on version strings in Dpkg. The commit message has more documentation: https://salsa.debian.org/lintian/lintian/-/commit/5f0333ebc6e3ba144717eca1ef0bddfd39413df0 Kind regards Felix Lechner
Bug#953554: Please permit Debian revisions with 1.0 native packages [and 1 more messages]
Hi, On Mon, Jun 15, 2020 at 5:18 PM Sean Whitton wrote: > > the relevant sentence of Policy ... was intended to be > informative, not normative. Just a brief post scriptum: I had to disable a test in Lintian due to new restrictions on version strings in Dpkg. The commit message has more documentation: https://salsa.debian.org/lintian/lintian/-/commit/5f0333ebc6e3ba144717eca1ef0bddfd39413df0 Kind regards Felix Lechner
Bug#963699: PostgreSQL: WolfSSL support
Hi Florian, On Tue, Jun 30, 2020 at 12:15 PM Florian Weimer wrote: > > >> The other issue (WolfSSL GPL violation due to linking against > >> GPL-incompatible applications via libpq) unfortunately remains. Can we figure out which packages in Debian are so affected? Could the use of the GPL for libraries really create a lot of issues? Even the FSF does not universally advocate using a lesser license for libraries. From Wikipedia's entry on the LGPL: > In February 1999, GNU Project leader Richard Stallman wrote the essay "Why > you shouldn't use the Lesser GPL for your next library" explaining that the > LGPL > had not been deprecated, but that one should not necessarily use the LGPL for > all libraries: > > "Which license is best for a given library is a matter of strategy ... Using > the > ordinary GPL for a library gives free software developers an advantage over > proprietary developers: a library that they can use, while proprietary > developers cannot use it" (quote partially reproduced) Kind regards Felix Lechner
Bug#963699: PostgreSQL: WolfSSL support
Hi, > we could ship a libpq5-nossl.deb Don't users of libpq5 generally rely on the SSL features being present there? Kind regards Felix Lechner
Bug#963699: PostgreSQL: WolfSSL support
Hi Florian On Tue, Jun 30, 2020 at 11:38 AM Florian Weimer wrote: > > The other issue (WolfSSL GPL violation due to linking against > GPL-incompatible applications via libpq) unfortunately remains. Could that be remedied with a special grant from wolfSSL exempting such uses, or would they have to switch to the LGPL? Kind regards Felix Lechner
Bug#963699: PostgreSQL: WolfSSL support
Hi Florian On Sat, Jun 27, 2020 at 6:22 AM Florian Weimer wrote: > > <https://github.com/wolfSSL/wolfssl/blob/master/LICENSING> says this: Kaleb from wolfSSL followed up today: > After going over with our management we see what the concerns are with > this file: https://github.com/wolfSSL/wolfssl/blob/master/LICENSING > > We'll update that to include the verb-age "or any later version". I'll also > work > with our website maintainer to get the verb-age on the website update. It > should always be v2 "or any later version" or in some cases > v3 "or any later version" but we want to be explicit! Kind regards Felix Lechner
Bug#963699: PostgreSQL: WolfSSL support
Hi, I think Christoph was right. For details, please see below. On Sat, Jun 27, 2020 at 6:22 AM Florian Weimer wrote: > > At this point, I have no idea what the actual intent is. In response to your concern, I filed a support request to clarify the wolfSSL license. Here is the relevant part of my correspondence with Kaleb Hines, whom I have met on multiple occasions: > 3. The file COPYING and the individual disclaimers in most files state > that your library is provided under the GPLv2 or later, while the file > LICENSING and your website omit the 'or later' language. This is a > subtle but important difference (the details of which I probably do > not fully appreciate). It may determine whether wolfSSL can link with > projects released under the GPLv3, such as 'readline' (used in the > command line utility 'psql'). Would you please clarify that your open > source license is the GPLv2+ (emphasis on plus) and includes the ''or > later' language? That was Kaleb's reply: > 3) This is actually clarified in the GPLv2 licensing itself: > https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html > > 9. The Free Software Foundation may publish revised and/or new > versions of the General Public License from time to time. Such new > versions will be similar in spirit to the present version, but may differ > in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the > Program specifies a version number of this License which applies > to it and "any later version", you have the option of following the > terms and conditions either of that version or of any later version > published by the Free Software Foundation. If the Program does > not specify a version number of this License, you may choose > any version ever published by the Free Software Foundation. > > Since wolfSSL specifies the distinguished version 2, this part of > section 9 of the GPLv2 license applies: > > If the Program specifies a version number of this License which > applies to it and "any later version", you have the option of > following the terms and conditions either of that version or of any > later version published by the Free Software Foundation. > > Hope that helps to clear up any questions, the verbage may > differ between our sources and the LICENSE and website > document however all give a distinguished version. You may > either follow the terms and conditions of v2 or of any later version > of the GPL license published by the Free Software Foundation > as part of the GPLv2 licensing. If this needs any further clarity we > would be more than happy to setup a call with our management > for you to go over any outstanding concerns! > > Warmest Regards, > > Kaleb Himes > > If you enjoy working with wolfSSL please leave us a star on our > github repository https://github.com/wolfSSL/wolfssl! > > Position: Software Engineer > Website: www.wolfssl.com > Hours: 09:00 - 17:00 MDT > Email: ka...@wolfssl.com > News: TLS 1.3 is now available in wolfSSL! If you have a moment, please leave a star in their Github repo. Kind regards Felix Lechner
Bug#963699: PostgreSQL: wolfSSL support
Hi Christoph, On Fri, Jun 26, 2020 at 2:51 PM Christoph Berg wrote: > > post it > as a WIP patch on the pgsql-hack...@postgresql.org list I just did it. > Do you think renaming the types in wolfSSL is feasible? Probably. > I don't even know what "ValidateDate" is Neither do I, but a #define HAVE bracket suggests it's a standard function. Unfortunately, the arguments to the PostgreSQL version look totally different. Maybe we can rename ours, or isolate. It's used less often. > > 1. DH parameters are not currently loaded from a database-internal PEM Fortunately, I don't think it's a seed. The code states: /* * Set DH parameters for generating ephemeral DH keys. The * DH parameters can take a long time to compute, so they must be * precomputed. * * Since few sites will bother to create a parameter file, we also * provide a fallback to the parameters provided by the OpenSSL * project. * * These values can be static (once loaded or computed) since the * OpenSSL library can efficiently generate random keys from the * information provided. */ > Do you mean the module shouldn't use the OpenSSL compat layer? I am not sure. It definitely cannot use the EVP portion, which provides standardized access to cryptographic primitives. Maybe the module should switch to the native interface. > > That is what the routine being mimicked does in wolfSSL. This code comment will help you figure out what I meant: /* This should exactly match OpenSSL's SSL_set_fd except for using my BIO */ Please have good vacation, and get some rest! Kind regards Felix Lechner
Bug#963699: Fwd: PostgreSQL: WolfSSL support
Hi, Is anyone here interested in helping to evaluate an experimental patch for wolfSSL support? Attached please find a WIP patch for wolfSSL support in postgresql-12. As a shortcut, you may find this merge request helpful: https://salsa.debian.org/postgresql/postgresql/-/merge_requests/4 I used Debian stable (buster) with backports enabled and preferred. The wolfssl.patch in d/patches builds and completes all tests, as long as libwolfssl-dev version 4.4.0+dfsg-2~bpo10+1 is installed and patched with the included libwolfssl-dev-rename-types.patch. You can do so as root with: cd /usr/include/wolfssl patch -p1 < libwolfssl-dev-rename-types.patch Patching the library was easier than resolving type conflicts for twenty-five files. An attempt was made but resulted in failing tests. The offending types are called 'ValidateDate' and 'Hash'. They do not seem to be part of the wolfSSL ABI. The patch operates with the following caveats: 1. DH parameters are not currently loaded from a database-internal PEM certificate. The function OBJ_find_sigid_algs is not available. The security implications should be discussed with a cryptographer. 2. The contrib module pgcrypto was not compiled with OpenSSL support and currently offers only native algorithms. wolfSSL's compatibility support for OpenSSL's EVP interface is incomplete and offers only a few algorithms. The module should work directly with wolfCrypt. 3. The error reporting in wolfSSL_set_fd seems to be different from OpenSSL. I could not locate SSLerr and decided to return BAD_FUNC_ARG. That is what the routine being mimicked does in wolfSSL. If you see an SSL connection error, it may be wise to simply remove these two statements in src/interfaces/libpq/fe-secure-openssl.c: ret = BAD_FUNC_ARG; Unsupported functions or features can probably be replaced with wolfSSL's or wolfCrypt's native interfaces. The company may be happy to assist. The patch includes modifications toward missing goals. Some parts modify code, for example in util/pgpcrypto, that is not actually called. Please note that the wolfSSL team prefers the styling of their brand to be capitalized as recorded in this sentence. Thank you! Kind regards Felix Lechner unchanged: --- a/configure.in +++ b/configure.in @@ -1211,7 +1211,7 @@ fi if test "$with_gssapi" = yes ; then if test "$PORTNAME" != "win32"; then -AC_SEARCH_LIBS(gss_init_sec_context, [gssapi_krb5 gss 'gssapi -lkrb5 -lcrypto'], [], +AC_SEARCH_LIBS(gss_init_sec_context, [gssapi_krb5 gss 'gssapi -lkrb5 -lwolfssl'], [], [AC_MSG_ERROR([could not find function 'gss_init_sec_context' required for GSSAPI])]) else LIBS="$LIBS -lgssapi32" @@ -1221,29 +1221,35 @@ fi if test "$with_openssl" = yes ; then dnl Order matters! if test "$PORTNAME" != "win32"; then - AC_CHECK_LIB(crypto, CRYPTO_new_ex_data, [], [AC_MSG_ERROR([library 'crypto' is required for OpenSSL])]) - AC_CHECK_LIB(ssl,SSL_new, [], [AC_MSG_ERROR([library 'ssl' is required for OpenSSL])]) + AC_CHECK_LIB(wolfssl, wolfSSL_new, [], [AC_MSG_ERROR([library 'wolfssl' is required for OpenSSL])]) else - AC_SEARCH_LIBS(CRYPTO_new_ex_data, [eay32 crypto], [], [AC_MSG_ERROR([library 'eay32' or 'crypto' is required for OpenSSL])]) - AC_SEARCH_LIBS(SSL_new, [ssleay32 ssl], [], [AC_MSG_ERROR([library 'ssleay32' or 'ssl' is required for OpenSSL])]) + AC_SEARCH_LIBS(wolfSSL_new, [wolfssl], [], [AC_MSG_ERROR([library 'wolfssl' is required for OpenSSL])]) fi - AC_CHECK_FUNCS([SSL_get_current_compression X509_get_signature_nid]) + # support for NIDs is incomplete; lack OBJ_find_sigid_algs + #AC_DEFINE(HAVE_X509_GET_SIGNATURE_NID, 1, [Define to 1 if you have X509_get_signature_nid()]) + # Functions introduced in OpenSSL 1.1.0. We used to check for # OPENSSL_VERSION_NUMBER, but that didn't work with 1.1.0, because LibreSSL # defines OPENSSL_VERSION_NUMBER to claim version 2.0.0, even though it # doesn't have these OpenSSL 1.1.0 functions. So check for individual # functions. - AC_CHECK_FUNCS([OPENSSL_init_ssl BIO_get_data BIO_meth_new ASN1_STRING_get0_data]) + AC_DEFINE(HAVE_BIO_GET_DATA, 1, [Define to 1 if you have BIO_get_data()]) + + # support for BIO_meth_new incomplete; lack BIO_meth_get_* + #AC_DEFINE(HAVE_BIO_METH_NEW, 1, [Define to 1 if you have BIO_meth_new()]) + AC_DEFINE(HAVE_ASN1_STRING_GET0_DATA, 1, [Define to 1 if you have ASN1_STRING_get0_data()]) # OpenSSL versions before 1.1.0 required setting callback functions, for # thread-safety. In 1.1.0, it's no longer required, and CRYPTO_lock() # function was removed. - AC_CHECK_FUNCS([CRYPTO_lock]) + # wolfSSL has CRYPTO_lock but does not need it; lacks CRYPTO_get_locking_callback + # AC_DEFINE(HAVE_CRYPTO_LOCK, 1, [Define to 1 if you have CRYPTO_lock()]) # SSL_clear_options is a macro in OpenSSL from 0.9.8 to 1.0.2, and # a funct
Bug#963699: PostgreSQL: WolfSSL support
Hi, > For postgresql-12, it fails at the configure stage Attached please find a WIP patch for wolfSSL support in postgresql-12. The build log was too large, even with compression, to include here. I used Debian stable (buster) with backports enabled and preferred. The wolfssl.patch in d/patches builds and completes all tests, as long as libwolfssl-dev version 4.4.0+dfsg-2~bpo10+1 is installed and patched with the included libwolfssl-dev-rename-types.patch. You can do so as root with: cd /usr/include/wolfssl patch -p1 < libwolfssl-dev-rename-types.patch Patching the library was easier than resolving type conflicts in about twenty-five files. An attempt was made but resulted in failing tests. The offending types are called 'ValidateDate' and 'Hash'. They do not seem to be part of the wolfSSL ABI. The patch operates with the following caveats: 1. DH parameters are not currently loaded from a database-internal PEM certificate. The function OBJ_find_sigid_algs is not available. The security implications should be discussed with a cryptographer. 2. The contrib module pgcrypto was not compiled with OpenSSL support and currently offers only native algorithms. wolfSSL's compatibility support for OpenSSL's EVP interface is incomplete and offers only a few algorithms. The module should work directly with wolfCrypt. 3. The error reporting in wolfSSL_set_fd seems to be different from OpenSSL. I could not locate SSLerr and decided to return BAD_FUNC_ARG. That is what the routine being mimicked does in wolfSSL. If you see an SSL connection error, it may be wise to simply remove these two statements in src/interfaces/libpq/fe-secure-openssl.c: ret = BAD_FUNC_ARG; Unsupported functions or features can probably be replaced with wolfSSL's or wolfCrypt's native interfaces. The company may be happy to assist. The patch includes modifications toward missing goals. Some parts modify code, for example in util/pgpcrypto, that is not actually called. Please note that the wolfSSL team prefers the styling of their brand to be capitalized as recorded in this sentence. Thank you! Kind regards Felix Lechner unchanged: --- a/configure.in +++ b/configure.in @@ -1211,7 +1211,7 @@ fi if test "$with_gssapi" = yes ; then if test "$PORTNAME" != "win32"; then -AC_SEARCH_LIBS(gss_init_sec_context, [gssapi_krb5 gss 'gssapi -lkrb5 -lcrypto'], [], +AC_SEARCH_LIBS(gss_init_sec_context, [gssapi_krb5 gss 'gssapi -lkrb5 -lwolfssl'], [], [AC_MSG_ERROR([could not find function 'gss_init_sec_context' required for GSSAPI])]) else LIBS="$LIBS -lgssapi32" @@ -1221,29 +1221,35 @@ fi if test "$with_openssl" = yes ; then dnl Order matters! if test "$PORTNAME" != "win32"; then - AC_CHECK_LIB(crypto, CRYPTO_new_ex_data, [], [AC_MSG_ERROR([library 'crypto' is required for OpenSSL])]) - AC_CHECK_LIB(ssl,SSL_new, [], [AC_MSG_ERROR([library 'ssl' is required for OpenSSL])]) + AC_CHECK_LIB(wolfssl, wolfSSL_new, [], [AC_MSG_ERROR([library 'wolfssl' is required for OpenSSL])]) else - AC_SEARCH_LIBS(CRYPTO_new_ex_data, [eay32 crypto], [], [AC_MSG_ERROR([library 'eay32' or 'crypto' is required for OpenSSL])]) - AC_SEARCH_LIBS(SSL_new, [ssleay32 ssl], [], [AC_MSG_ERROR([library 'ssleay32' or 'ssl' is required for OpenSSL])]) + AC_SEARCH_LIBS(wolfSSL_new, [wolfssl], [], [AC_MSG_ERROR([library 'wolfssl' is required for OpenSSL])]) fi - AC_CHECK_FUNCS([SSL_get_current_compression X509_get_signature_nid]) + # support for NIDs is incomplete; lack OBJ_find_sigid_algs + #AC_DEFINE(HAVE_X509_GET_SIGNATURE_NID, 1, [Define to 1 if you have X509_get_signature_nid()]) + # Functions introduced in OpenSSL 1.1.0. We used to check for # OPENSSL_VERSION_NUMBER, but that didn't work with 1.1.0, because LibreSSL # defines OPENSSL_VERSION_NUMBER to claim version 2.0.0, even though it # doesn't have these OpenSSL 1.1.0 functions. So check for individual # functions. - AC_CHECK_FUNCS([OPENSSL_init_ssl BIO_get_data BIO_meth_new ASN1_STRING_get0_data]) + AC_DEFINE(HAVE_BIO_GET_DATA, 1, [Define to 1 if you have BIO_get_data()]) + + # support for BIO_meth_new incomplete; lack BIO_meth_get_* + #AC_DEFINE(HAVE_BIO_METH_NEW, 1, [Define to 1 if you have BIO_meth_new()]) + AC_DEFINE(HAVE_ASN1_STRING_GET0_DATA, 1, [Define to 1 if you have ASN1_STRING_get0_data()]) # OpenSSL versions before 1.1.0 required setting callback functions, for # thread-safety. In 1.1.0, it's no longer required, and CRYPTO_lock() # function was removed. - AC_CHECK_FUNCS([CRYPTO_lock]) + # wolfSSL has CRYPTO_lock but does not need it; lacks CRYPTO_get_locking_callback + # AC_DEFINE(HAVE_CRYPTO_LOCK, 1, [Define to 1 if you have CRYPTO_lock()]) # SSL_clear_options is a macro in OpenSSL from 0.9.8 to 1.0.2, and # a function from 1.1.0 onwards so we cannot use AC_CHECK_FUNCS. AC_CACHE_CHECK([for SSL_clear
Bug#963698: lintian: 'stripped-library' error after dh_dwz
Hi Alberto, On Thu, Jun 25, 2020 at 7:15 AM Alberto Garcia wrote: > > E: libwebkit2gtk-4.0-37-dbgsym: stripped-library > usr/lib/debug/.dwz/x86_64-linux-gnu/libwebkit2gtk-4.0-37.debug The traditional position is that debug libraries should not be stripped: https://salsa.debian.org/lintian/lintian/-/blob/master/checks/binaries.pm#L468-471 but maybe 'dwz' consolidates the debug information in another ELF section. It's possible that Lintian's check is outdated. I am looking into it. Kind regards Felix Lechner
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
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#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#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#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#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#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 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 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 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#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#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#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#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#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#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
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#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#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#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#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#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#945934: false positive udev-rule-missing-subsystem
Hi Michael, On Sun, Dec 1, 2019 at 3:42 AM Michael Biebl wrote: > > Afaics, libmtp-common is affected by this as well. [That] maintainer decided > to override lintian. I noticed you eventually decided to override Lintian, as well. > Tbh, I'm not sure how to fix this without lintian becoming a udev rules > parsers which understands how those labels are resolved. Like you, I am not sure how to address that. Does systemd offer any validation capabilities? Alternatively, would it be okay to close this bug? We will soon have ways to monitor overrides in the archive (and yours are annotated with this bug number). N: False positive: SUBSYSTEM is tested at the beginning of the rules file. N: See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945934 O: udev: udev-rule-missing-subsystem lib/udev/rules.d/60-autosuspend-chromiumos.rules:100 vendor/product matching missing SUBSYSTEM specifier Kind regards Felix Lechner
Bug#962158: lintian: Swapped exit statuses and --fail-on default value require downstream adjustments
Hi On Thu, Jun 4, 2020 at 3:21 PM Chris Lamb wrote: > > I can relate to this feeling so let me do this for you. At the very > least, this change now won't hit bullseye before being resolved. I also agree with this bump in severity. Thanks! > This change means that any current caller which uses lintian as part > of its acceptance testing will now silently let broken things through As I explained on IRC this statement is probably untrue (and you did not have the courtesy to mention that objection here). From what I can tell, the FTP Master (who are arguably the one "acceptance tester" who really matters) parses the tags. [1] Please let me know if you know otherwise. [1] https://salsa.debian.org/ftp-team/dak/-/blob/master/daklib/lintian.py#L73-74 > If the default change made sense due to some technical rationale, this > effort might be worthwhile As I likewise explained on IRC, Lintian's return status was unreliable. Some program errors exited with status 1 and others with status 2, while detecting error tags always produced status 1. Lintian was also unable to use Perl's 'die'. The proper remedy was to always use status 1 for program errors. That step alone would require any automated user to examine their scripts. The 'fail-on' command-line option resolved a long standing problem with the implicit behavior your so cherish (#709932). Instead of adding more complex options, the current solution is simple, elegant, straighforward and explicit. And again, automated users already had to look at their scripts. It was the perfect timing to make both changes. Kind regards, Felix Lechner
Bug#953262: lintian.d.o: Provide archive-wide statistics on home page
Control: retitle -1 lintian.d.o: Provide archive-wide statistics on home page Hi s3v, > I would like to see stats of Lintian's tags get restored on the main web > page of the project. First of all, sorry our web service has been spotty. We hope it will become one of people's favorite interfaces to research issues in Debian packages. Your request predates my involvement but I would like to understand how to make our data more meaningful on an archive level. (The 'archive' is actually a fluid set of packages that is constantly synchronized via dakweb.) I can find meaning only by slicing the data in other dimensions, such as by architecture, or by providing normalized averages, such as tags per package or overrides per package, and so on. Below you will find an old snapshot from the Internet Archive's Wayback Machine. Which data was most useful to you, please, and why? Kind regards, Felix Lechner * * * Archives The following archives are processed by Lintian: Archive nameAttributeAttribute value debianArchitecturesi386 amd64 Distributions/Suitesunstable experimental Componentsmain contrib non-free Mirror timestampSun, 21 Apr 2019 20:30:22 + debian-debugArchitecturesi386 amd64 Distributions/Suitesunstable-debug experimental-debug Componentsmain contrib non-free Mirror timestampSun, 21 Apr 2019 20:30:22 + Statistics Last updated: Mon, 22 Apr 2019 00:33:21 + Maintainers: 2423 (+0) Package groups: 31284 (+5) Rescheduled groups: 3 (+0) Groups with processing errors: 3 (+0) Source packages: 29929 (+1) Binary packages: 39928 (-3) μdeb packages: 225 (+0) E Errors: 32305 (+4) W Warnings: 186976 (-6) I Info tags: 575740 (-196) P Pedantic tags: 175454 (-42) O Overridden tags: 181682 (-138) X Experimental tags: 124653 (+25) Lintian version: 2.12.0 (The numbers in parentheses describe the changes since the last Lintian report, published on Sun, 21 Apr 2019 00:28:21 +.)
