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
Re: 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
Re: 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
Programmatic exemptions for lintian are obsolete
Hi, Traditionally, we exempted Lintian from its own checks when the test suite triggered a tag. With this commit, it should no longer be necessary: https://salsa.debian.org/lintian/lintian/-/commit/4f4654ddfd2841f5440a83bc3f30b6091b10986c The commit automatically exempts Lintian's test suite. All other tags are probably real. Please do not exempt Lintian programmatically any more. It leads to ridicule and an image problem on IRC. Please use visit_patched from Lintian::Check instead. It's new, but I think it works. The new setup was tested with a full build and self-examination by Lintian in a testing chroot, which produced no tags. 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.
New HTML output mode for Gitlab CI
Hi, Here is quick heads up that Lintian has a new output mode for standalone HTML pages. The mode will be used with Gitlab Pages to offer graphical Lintian results in the majority of Gitlab CI instances. The functionality may reduce user reliance on lintian.d.o. In Lintian, the new mode is invoked with '--exp-output format=html'. After piping, please use your favorite browser with a 'file:' URL to look at the results. A new Lintian release would be nice for continued work in deployed instances, but due to Bug#964111 I am not sure Lintian will currently build. Perhaps it's better to hold off for now. I already made several adjustments to our test suite and am not sure which, if any, additional steps should be taken to accommodate Dpkg. Please have a good weekend (it's a big holiday, for some)! 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#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
Re: 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
What is an invalid package? (Was: Checking vs. building packages)
Hi Russ,, On Wed, Jul 1, 2020 at 8:25 PM Russ Allbery wrote: > > dpkg has been picking up basic sanity checks for obvious packaging bugs Thank you for using such decisive language. My message was exactly about that. Please allow me to restate the original question: Is the absence of fields in d/test/control such an "obvious packaging bug"? > I don't > think it makes sense to rely on linting to reject invalid packages. Or, to borrow your alternative wording, is a package with missing fields in d/tests/control really an "invalid package"? Your choice of words was so fitting, I adopted them as the subject header. What is an "invalid package", please? In Lintian, we certainly have a graduated view. Similarly, I am not sure that symlink loops in source code are serious enough for dpkg-source to refuse unpacking (please the open Bug#964111 for details). Must faulty upstream sources, which regularly contain odd artifacts, now be repackaged? In a basic inconsistency, dpkg-buildpackage still creates such packages. I hope we agree that there is a gray area. I am merely asking for clarification. By comparison, I was stunned when the Dpkg Maintainers refused to ensure that all *.changes files are UTF-8 encoded, arguably a more basic and more direct requirement. The last time I checked (which was prior to the most recent release) dpkg-genchanges simply copied legacy encodings from d/changelog to *.changes. I was told that Dpkg tries to change as little as possible. At the same time, Policy 5.1 states that "All control files must be encoded in UTF-8." Is that requirement not more binding on Dpkg than the presence of fields in d/tests/control? In view of the rigor imposed on d/tests/control, should Dpkg produce *.changes files---one of its own products---in legacy encoding? > Linting is optional True, but Lintian is much better equipped to provide context, references and other packages so affected. Plus, we maintain nice explanations that are often superior to dpkg's one-liners, which can be hard to spot in typical build logs. Also, Lintian can run, at least theoretically, on packages created by any tool, although I am not sure there are alternatives to Dpkg. 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
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-maint@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"), $_);
Checking vs. building packages; Lintian's relationship with Dpkg and Debhelper
Hi, Lintian's task of checking packages is often affected by the tools building them. There is an interaction between Dpkg, Debhelper, and Lintian that can at times be complex. I would like to initiate a discussion among the Lintian maintainers about the proper boundaries for each tool. The best outcome would be a simple and logical rule to divide tasks between our tools. For example, it could be helpful if Dpkg and Debhelper prevent only the creation of packages that cannot be built or unpackaged safely. This message was prompted by recent changes in Dpkg which, if you haven't noticed, encroach a little bit on Lintian's traditional area of expertise. Because Dpkg now fails to build some of Lintian's test packages, the tags can no longer be tested and will be removed from Lintian. As an example, I will pick the way Dpkg started to examine autopkgtest files. On the surface, it seems like I may be responsible for it. The Dpkg changelog states: * dpkg-source: Check that debian/tests/control has the required fields. Prompted by Felix Lechner . Like so many things Guillem writes, that is a mischaracterization. I asked him on IRC whether Dpkg examines those files, and he promptly implemented the check in Dpkg even though, after some consideration, I asked him not to. That conversation is also why I have not yet filed a wishlist bug to revert the change in Dpkg. To the extent they relate to autopktest, our current Gitlab CI failures in unstable are emblematic of the efforts to duplicate Lintian tasks in Dpkg. The issue for us is testability, as I will remove those tags from Lintian. I think everyone would be much better served if Dpkg simply limited itself to building packages. Some checking is certainly appropriate for Dpkg, to facilitate safe handling, but I do not presently understand why faulty definitions in an autopkgtest suite should make a package unbuildable. Here are the relevant log messages from Salsa CI: Cannot parse line Non-zero status 25 from dpkg-source: at /builds/lintian/lintian/lib/Test/Lintian/Run.pm line 398. [The output from dpkg-source is stored in a log file.] Please let me know your thoughts. 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#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
Re: failed all build of lintian 2.81.0
Hi Chris, Found it. Two files were being excluded by dpkg-source. Details in commit f6f7cca4. Tested in sbuild. Kind regards Felix
Re: failed all build of lintian 2.81.0
Chris, On Tue, Jun 23, 2020 at 3:58 PM Chris Lamb wrote: > > I have no insight on how to fix this build failure, sorry. I cannot reproduce the build failures from x86-conova-01 in a fresh chroot with i386 unstable, but fixed an unrelated issue in commit b4b66459. I would upload that. Unfortunately, I do see another build failure for the test package shared-libs/shared-libs-non-pic-i386, which takes the wrong branch in its Makefile here: ifeq ($(shell dpkg-architecture --is i386),0) The command returns 0 when run manually inside the i386 chroot. I have no idea what is going on. The test has not been touched in ages. As a side note, I may try to switch the Salsa runners to i386 so we might see similar errors earlier in the release cycle. Kind regards Felix Lechner
Re: failed all build of lintian 2.81.0
Hi Chris On Tue, Jun 23, 2020 at 3:58 PM Chris Lamb wrote: > > I have no insight on how to fix this build failure. Okay, I will look into it. > "orig" seems like a particularly poor choice of term I believe the usage predates my arrival. Kind regards Felix Lechner
Re: failed all build of lintian 2.81.0
Hi Chris, Here is a pointer to the lines copying the files. There are two identical segments like this in t/templates/upload-make-builder/Makefile.in: if [ -d $(origdata)/. ] ; then \ cp -rp $(origdata)/. $(packagedir) ; \ fi I haven't touched those lines in a year or two, but does that dot in the -d test expression look odd to you? It's also important that $(ROOT_DIR) is set right, but we have never had problems with it before. ROOT_DIR:=$(shell dirname $(realpath $(lastword $(MAKEFILE_LIST Here is the invocation: % more t/templates/upload-make-builder/fill-values.d/upload-make-builder.values Upload-Type: [% $host_architecture %] Build-Product: [% $source %]_[% $no_epoch %]_[% $upload_type %].changes Build-Command: make --trace -f [% $source_path %]/Makefile DEFAULT_DH_COMPAT=[% $dh_compat_level %] Default-Build-Depends: debhelper-compat (= [% $dh_compat_level %]) Since the tests are new and were written together, something may be wrong with them specifically. Unfortunately, I do not know, even though I just looked at them again. Kind regards Felix Lechner
Re: failed all build of lintian 2.81.0
Hi Chris, Please allow me to add that the meaning of orig in the test suite is not the same as in the rest of Debian. They are the files outside the ./debian directory, and should be part of all packages, including native. Kind regards Felix Lechner
Re: failed all build of lintian 2.81.0
Hi Chris, On Tue, Jun 23, 2020 at 4:45 AM Chris Lamb wrote: > > I don't quite understand this Neither do I. > (The build > and testsuite works locally here.) Here too. The Makefile for the upload-native skeleton is different from source-native, but this looks like the problem described in commit 17b1afee. The first thing I would try is to convert both tests to upload-non-native. That ought to include the orig file for sure. Kind regards Felix Lechner
Bug#963524: dpkg: source-only *.changes files lack two mandatory fields
Package: dpkg Severity: normal X-Debbugs-CC: debian-lint-maint@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#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
Reassigning multiple bugs for shell script analysis from Lintian
Hi, Over the years, Lintian accumulated many requests for features better addressed by a shell script analyzer. If there are no objections, I plan to assign them a copy each to morbig and shellcheck. Many of the bugs are blocked by Bug#629247, so that's a good place to start. Lintian will only keep the master bug. It is entitled: "Please use a decent shell script parser." We look forward to enhancing our user experience with your programs. Please let us know your thoughts and make sure to copy Paul Wise. Thanks! 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#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#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
[Git][lintian/lintian][master] 2 commits: Read test diff as bytes for immediate printing.
Felix Lechner pushed to branch master at lintian / lintian
Commits:
95897129 by Felix Lechner at 2020-06-05T07:38:49-07:00
Read test diff as bytes for immediate printing.
May otherwise cause wide character errors, particularly on Ansgars
test cases for colorful maintainer addresses, which will become test
cases in the near future:
Wide character in print at t/bin/runtests line 483.
It would be silly to parse the diff as UTF-8 and convert it right back
for printing.
Gbp-Dch: ignore
- - - - -
ad4c446e by Felix Lechner at 2020-06-05T07:44:40-07:00
Add two test cases from Ansgars colorful test package. (See:
#962277)
Below is the original *.dsc that gave rise to both cases. Perhaps
Salsa will show the escape sequences?
The Maintainer address contains ANSI escape sequences for many colors,
plus blinking.
The Uploaders address includes a UTF-8 RIGHT-TO-LEFT OVERRIDE.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 3.0 (native)
Source: colorful
Binary: colorful
Architecture: all
Version: 1
Maintainer: Colorful
[31mc[32mo[33ml[34mo[35mr[36mf[37mu[96ml[0m@43-1.org
Uploaders: Ansgar ansgar@43-1.org
Standards-Version: 4.5.0
Build-Depends: debhelper-compat (= 13)
Package-List:
colorful deb misc optional arch=all
Checksums-Sha1:
43d4b3c075021d4b289affe136fcd212fb9f5da6 1412 colorful_1.tar.xz
Checksums-Sha256:
ca5bad845ba84bab1d84f8e9b4792f7a92cbe1be3cf8b010389bde82f63c10b5 1412
colorful_1.tar.xz
Files:
7fa97791d08c7ae2764e75ee1e86824a 1412 colorful_1.tar.xz
-BEGIN PGP SIGNATURE-
iQJTBAEBCgA9FiEEDJOr3FWozOtfziCXgqh1rnceDD4FAl7aCoQfHGFuc2dhci5i
dXJjaGFyZHRAdHUtZHJlc2Rlbi5kZQAKCRCCqHWudx4MPhMQD/9jPgtHHQRFApjI
3aZT6fYQbXu223+C6cjkSEIy2xKjaxm0DxqfZamSyhkjNBSql9V21o5bzh5jiB0T
L3XVfAIRS5MLkUR2EsPYHKsBYpCVU5qESdBl2xN+WDvSAp95rydOBZo7u12N1YUo
HzJqG3anpYg/73Vy8z1IV9iuZHYnFlh7OhDMd64H/bHeOtuNfKquOQ3dFd25JEFj
b8m5wOjbLfPZSq7hX2btSqd+jjk8wAjUL4Cnh5yyOilVV4zk5cvCqpvF+rlmVtxr
JhIlSiqYKSAQfePg00JLZTAMtuECy/bR8cq3Zm/9iiOE81F3mXFVWfP+bmhVUbkG
OC1kZwYFxsgadX3uJlDPVC9DEn3xnWvFQdTM18GDfxhncapavi/dap+EybInGVAQ
g+EwmCCR1VDzAN5xzgUyGSNwpylv1uTQ/YUJT+0yL3H8L5nwWmqTW4tlOsQ/GRQI
hHx52JqjRKH52Krn2Q05dggi2jcTt3wRO7ClaW80q1wrFo1mutZa6TnJ3RAdAg4x
QAHQA/KQjuYApKYQzYL4b/jfttVbq3LSeV3bAQu5jU8aqA6AYTotKe1NIjg8bQ9+
Vg3KIfpiFXVGwRwkxKevq36rJ4T0bunvDUWJUSn+vprkmClN8XmpbijaqO1o0uu5
6OBj9C5IFp2fpdVPrfDSZvpBWwrW/g==
=2ls4
-END PGP SIGNATURE-
- - - - -
7 changed files:
- t/bin/runtests
- + t/tags/checks/fields/maintainer/colorful/build-spec/fill-values
- + t/tags/checks/fields/maintainer/colorful/eval/desc
- + t/tags/checks/fields/maintainer/colorful/eval/tags
- +
t/tags/checks/fields/maintainer/right-to-left-override/build-spec/fill-values
- + t/tags/checks/fields/maintainer/right-to-left-override/eval/desc
- + t/tags/checks/fields/maintainer/right-to-left-override/eval/tags
Changes:
=
t/bin/runtests
=
@@ -479,7 +479,7 @@ if (-t STDOUT && !$unattended) {
next
unless -r $diffpath;
-my $diff = path($diffpath)->slurp_utf8;
+my $diff = path($diffpath)->slurp;
print $diff;
} elsif ($testcase->{match_strategy} eq 'literal') {
=
t/tags/checks/fields/maintainer/colorful/build-spec/fill-values
=
@@ -0,0 +1,4 @@
+Skeleton: upload-native
+Testname: colorful
+Author: Colorful
<"[31mc[32mo[33ml[34mo[35mr[36mf[37mu[96ml[0m"@43-1.org>
+Description: Colorful maintainer from Ansgar's 'colorful' test package (false
positive)
=
t/tags/checks/fields/maintainer/colorful/eval/desc
=
@@ -0,0 +1,3 @@
+Testname: colorful
+Check: fields/maintainer
+Reference: Bug#962277
=
t/tags/checks/fields/maintainer/colorful/eval/tags
=
@@ -0,0 +1,2 @@
+colorful (source): maintainer Colorful
<"[31mc[32mo[33ml[34mo[35mr[36mf[37mu[96ml[0m"@43-1.org>
+colorful (binary): maintainer Colorful
<"[31mc[32mo[33ml[34mo[35mr[36mf[37mu[96ml[0m"@43-1.org>
=
t/tags/checks/fields/maintainer/right-to-left-override/build-spec/fill-values
=
@@ -0,0 +1,4 @@
+Skeleton: upload-native
+Testname: right-to-left-override
+Author: Ansgar <"ansgar"@43-1.org>
+Description: Maintainer with UTF-8 RIGHT-TO-LEFT OVERRIDE from Ansgar's
'colorful' test package (false positive)
=
t/tags/checks/fields/maintainer/right-to-left-override/eval/desc
=
@@ -0,0 +1,3 @@
+Testname: right-to-left-override
+Check: fields/maintainer
+Reference: Bug#962277
=
t/tags/checks/fields/maintainer/right-to-left-overri
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 +.)
Bug#850520: lintian: PT_GNU_STACK change triggers ~500 new errors
Hi Matthias,
> so you still need to update that list manually ...
I can revert commit 4c722ae9, which applied the tag to all
architectures instead of a select list (diff below). Is there a source
for the list, or a plan to implement additional architectures?
Kind regards
Felix Lechner
* * *
commit 4c722ae90d4c09542ee33aa549745879ea11465c
Author: Jakub Wilk
Date: Fri Oct 21 20:48:54 2016 +0200
checks/shared-libs: Check for PT_GNU_STACK on all architectures
The list of architectures that supported PT_GNU_STACK was woefully out
of date. Hopefully this feature is supported everywhere these days.
diff --git a/checks/shared-libs.pm b/checks/shared-libs.pm
index 93dfbed28..8122aa50c 100644
--- a/checks/shared-libs.pm
+++ b/checks/shared-libs.pm
@@ -36,19 +36,6 @@ use Lintian::Util qw(fail strip);
# one of the following names.
my $HWCAP_DIRS = Lintian::Data->new('shared-libs/hwcap-dirs');
-# The following architectures should always have a STACK setting in shared
-# libraries to disable executable stack. Other architectures don't always add
-# this section and therefore can't be checked.
-my %stack_arches = map { $_ => 1 }qw(
- alpha
- amd64
- i386
- m68k
- powerpc
- s390
- sparc
-);
-
# List of symbols file meta-fields.
my %symbols_meta_fields = map { $_ => 1 }qw(
Build-Depends-Package
@@ -162,15 +149,11 @@ sub run {
tag 'shlib-with-bad-permissions', $cur_file, $perms;
}
-# executable stack. We can only warn about a missing
-# section on some architectures. Only warn if there's an
-# Architecture field; if that's missing, we'll already be
-# complaining elsewhere.
+# executable stack.
if (not defined $objdump->{$cur_file}{'PH'}{STACK}) {
if (defined $info->field('architecture')) {
my $arch = $info->field('architecture');
-tag 'shlib-without-PT_GNU_STACK-section', $cur_file
- if $stack_arches{$arch};
+tag 'shlib-without-PT_GNU_STACK-section', $cur_file;
}
} elsif ($objdump->{$cur_file}{'PH'}{STACK}{flags} ne 'rw-'){
tag 'shlib-with-executable-stack', $cur_file;
diff --git a/debian/changelog b/debian/changelog
index 7b8e8411e..541ad1e73 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -19,6 +19,7 @@ lintian (2.5.49) UNRELEASED; urgency=medium
+ [JW] Don't complain about missing SONAME for position-independent
executables. Thanks to Reuben Thomas for the bug report.
(Closes: #731987)
++ [JW] Check for PT_GNU_STACK existence on all architectures.
* checks/source-copyright.pm:
+ [RA, JW] Fix handling punctuation characters in license expressions
in machine-readable copyright files. (Closes: #841356)
Bug#896012: lintian: Remove tag library-not-linked-against-libc
P.S: A recent archive-wide run showed 334 overrides and occurrences. The override ratio does not support a removal, but the total number of occurrences may. Could it be true that we are shipping defective shared libraries? I don't think so. Also, the tag carries the Severity 'error'. Kind regards Felix Lechner * * * detagtive=> SELECT count(taxiv.hint.id) AS hints, count(taxiv.override.id) AS overrides FROM taxiv.hint INNER JOIN taxiv.run ON taxiv.run.id = taxiv.hint.run_id INNER JOIN ftp.source ON ftp.source.id = taxiv.run.ftp_source_id INNER JOIN ftp.source_name ON ftp.source_name.id = ftp.source.source_name_id INNER JOIN lintian.tag ON lintian.tag.id = taxiv.hint.lintian_tag_id INNER JOIN lintian.tag_name ON lintian.tag_name.id = lintian.tag.tag_name_id LEFT JOIN taxiv.override ON taxiv.override.hint_id = taxiv.hint.id WHERE taxiv.run.lintian_version_id = 3 AND lintian.tag_name.literal = 'library-not-linked-against-libc' hints | overrides ---+--- | 334 (1 row)
Bug#896012: lintian: Remove tag library-not-linked-against-libc
Control: retitle -1 lintian: Remove tag library-not-linked-against-libc Hi, > So probably we need an update for our QA tools to do a better detection of > dynamically linked binaries. Lintian cannot detect this tag reliably. It should probably be removed. Like many other dependency-type problems in Debian, the analysis of library prerequisites requires a tool with an archive-wide perspective. The Lintian team may eventually be able to provide something on lintian.d.o, but the stand-alone program 'lintian' cannot do it. In the case of fwupd, Lintian sees the following, immediate library requirements: % readelf -WltdVs dir/usr/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_uefi_recovery.so ... 0x0001 (NEEDED) Shared library: [libfwupd.so.2] 0x0001 (NEEDED) Shared library: [libfwupdplugin.so.1] 0x0001 (NEEDED) Shared library: [libgobject-2.0.so.0] 0x0001 (NEEDED) Shared library: [libglib-2.0.so.0] ... while ldd resolves the whole tree: % ldd dir/usr/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_uefi_recovery.so linux-vdso.so.1 (0x7ffd7ebca000) libfwupd.so.2 => /lib/x86_64-linux-gnu/libfwupd.so.2 (0x7fea01bce000) libfwupdplugin.so.1 => not found libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x7fea01b79000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x7fea01a5a000) libgio-2.0.so.0 => /lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x7fea0189c000) libsoup-2.4.so.1 => /lib/x86_64-linux-gnu/libsoup-2.4.so.1 (0x7fea0180c000) libjson-glib-1.0.so.0 => /lib/x86_64-linux-gnu/libjson-glib-1.0.so.0 (0x7fea017e) * libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fea0161f000) libffi.so.6 => /lib/x86_64-linux-gnu/libffi.so.6 (0x7fea01615000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fea015f4000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7fea0158) libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x7fea0157a000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fea0135a000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fea01355000) libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x7fea012f6000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x7fea010ce000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7fea010b4000) libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7fea01067000) libxml2.so.2 => /lib/x86_64-linux-gnu/libxml2.so.2 (0x7fea00ebc000) libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7fea00d9a000) libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 (0x7fea00d87000) /lib64/ld-linux-x86-64.so.2 (0x7fea01c1d000) libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x7fea00d32000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fea00d28000) libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x7fea00c46000) libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x7fea00c12000) libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7fea00c0c000) libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7fea00bfd000) libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x7fea00bf6000) libicui18n.so.63 => /lib/x86_64-linux-gnu/libicui18n.so.63 (0x7fea0091b000) libicuuc.so.63 => /lib/x86_64-linux-gnu/libicuuc.so.63 (0x7fea0074a000) libicudata.so.63 => /lib/x86_64-linux-gnu/libicudata.so.63 (0x7fe9fed5a000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fe9fed32000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fe9febaf000) libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x7fe9feb9) libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (0x7fe9fea0c000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fe9fea01000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fe9fe87d000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fe9fe863000) As one can see, the dynamic linker makes libc.so.6 available indirectly, but that analysis is possible only on a running system. Another approach would be to scan all shared libraries in the archive and construct the dependency tree. Both are outside Lintian's purview. The bootstrapping folks occasionally approach the Lintian team with requests for similar analysis. Their solution will also require a portfolio-type approach, and a new tool. Let's call it 'detaxification' for now. It resolves dependencies. > lintian generates false positives for library-not-linked-against-libc after > gcc-7 7.3.0-16 Perhaps the previous title of the bug report is valuable for posterity. Kind regards Felix Lechner
Bug#672284: lintian: False positive: no-debian-copyright when packages supply debian/$pkgname.copyright
Hi, > having > copyright files that vary with binary package doesn't make sense to me. I struggled with that as well while rewriting the copyright check. Lintian will soon ignore per-package copyrights in ./debian. It will also produce errors. Lintian may further print errors when copyright files in installation packages are not true copies of the d/copyright file in their source. > One nice thing that having separate copyright files per binary package > would let you do is be unambiguous that a particular binary package with > an OpenSSL dependency contains only BSD-licensed code even if the source > package has other GPL-licensed code, so that you know for certain there's > no clash with the OpenSSL license. Leaving the relicensing of OpenSSL aside (plus, alternatives like wolfSSL exist) I do not think that this fine point, while well articulated, warrants the technical complexity or the legal risks. Kind regards Felix Lechner
Bug#895597: lintian: recommend runuser(1) for recursive file changes
Hi dkg, > From the tag description (extended in bug #889489), it's not clear to me > *how* to use runuser for the requested fix and *why* using runuser > actually fixes the problem described in the tag > I can't comment on this directly, but the tag was also extended in > #895370 which might explain a little more. You filed both of the bugs referenced here but even though they are closed, something was still unclear. I rewrote the tag description and renamed the tag. Perhaps you have a moment to take brief look. Thanks! https://salsa.debian.org/lintian/lintian/-/blob/master/tags/r/recursive-privilege-change.desc Kind regards Felix Lechner
Bug#926409: lintian: autopkgtest takes very long to finish
Hi Chris, On Fri, Apr 5, 2019 at 4:33 AM Iain Lane wrote: > > We do similar in some pkg-gnome packages, for example glib2.0 ships a > -tests package that contains "installed tests" which are compiled as > part of the package build and then executed during the autopkgtests. Should we ship all built test packages as part of our releases? I can't think of a better way to close this bug. Kind regards Felix Lechner
Bug#953428: Using /usr/bin/env to invoke maintainer scripts
Dear Policy Team, > Does Debian Policy prohibit the use of /usr/bin/env? Lintian flags the interpreter /usr/bin/env in maintainer scripts. Unfortunately, that appears inconsistent with the recommendations for scripts in Debian. Policy section 6.1 states that "Programs called from maintainer scripts should not normally have a path prepended to them." It says further that "any ... program that one would expect to be in the PATH, should ... be invoked without an absolute pathname." Finally, it expands on the point with "These considerations really apply to all shell scripts." Lintian does not flag /usr/bin/env in regular, i.e. non-maintainer scripts. Why is the use of the system PATH desirable in the body of a maintainer script, but not when locating the interpreter, please (the shebang). Shouldn't we encourage the use of /usr/bin/env? Or does the calling infrastructure disregard the path? Please respond to the bug. I do not subscribe to your mailing list. Thank you! Kind regards Felix Lechner
Bug#961800: lintian: profile support in config file broken
Hi gregor, On Fri, May 29, 2020 at 5:06 AM gregor herrmann wrote: > > The order seems to have been the other way round before. On top of the official fix, I also reordered that process some more: https://salsa.debian.org/lintian/lintian/-/commit/5e5c69adce0f2aaef7d0604fa7827c1337394a30 Sorry about the inconvenience. Kind regards Felix Lechner
Bug#922544: lintian: Mass tag rename to unify naming convention
Hi, On Tue, Feb 19, 2019 at 2:30 PM Chris Lamb wrote: > > > As I mentioned initially, I don't think the patch is ready as is, it > > even has syntax errors The suggestions from this bug report will be adopted in the near future. Kind regards Felix Lechner
Bug#534938: lintian: Pending rename for some shared library tags
Control: tags -1 - wontfix Hi, > Probably only one prefix (shlib or shared-lib) should be used. I agree with this sentiment. This will be implemented in the near future. The new prefix will be shared-lib. > I'm not sure that it's worth the disruption The tag rename facility will make this process somewhat easier on maintainers. Also, overrides are available in a Postgres database. Any impact can be assessed beforehand. The number of affected overrides will be documented. Kind regards Felix Lechner
Lintian exit status
Hi, Please see this new note about Lintian in the upcoming Misc Developer News [1]: Lintian exit status Starting with Lintian version 2.77.0, the handling of exit codes is reversed. Lintian now exits with a status of 1 for program errors and with 2 for other conditions. The new command-line option --fail-on determines those conditions. Please keep in mind that --fail-on warning does not imply --fail-on error. Please specify both if you require both. You can use a comma-separated list or use the option multiple times. Also, there is no default setting anymore. Policy violations no longer produce a non-zero exit status unless the option --fail-on error is used. Thanks for using Lintian when working on your packages! Kind regards Felix Lechner [1] https://wiki.debian.org/DeveloperNews
Bug#709932: Upcoming changes to Lintian's exit status; new --fail-on option
Hi, > [Lintian] Currently ... exits with "1" if policy violations ... are detected. This behavior will soon be reversed. Lintian will exit with status 1 on program errors (thus enabling the use of 'die') and with status 2 on policy violations. > It would be nice if lintian had an option to exit with a status != 0 > only if there are internal errors. You will soon have some control via the upcoming '--fail-on' command-line option. More information may be available here: https://salsa.debian.org/lintian/lintian/-/merge_requests/311 Please also look out for a more widely disseminated announcement of these changes, probably on debian-devel. Kind regards Felix Lechner
Lintian's Gitlab CI pipeline stages
Hi Chris, I noticed that you previously tried to combine the two CI pipeline stages, but then reverted. The timeout is now three hours. Would you mind if I combine them again? My reasons are: 1. When test packages fail to build, other pipelines may still complete. 2. When a pipeline needs to build few or no test packages, it completes faster. 3. The resolution of debhelper-compat (= 13) from stable-backports only needs to be fixed in one place. Your guidance would be appreciated. Kind regards Felix Lechner
Bug#947258: lintian: manpage-without-executable is too strict (false positives for subcommand man pages)
Hi Daniel, On Mon, Dec 23, 2019 at 10:06 AM Daniel Kahn Gillmor wrote: > > If there is a way that notmuch, git, and other subcommand-style tools > should be annotating their manpages to avoid triggering this lintian > report, please update lintian's tag description to point to how to do > this. So far, I learned that 'man' interprets two commands by default as a sub-command [1] but I do not know how to tell from a man page that it is for a sub-command like 'git add' instead of a command called git-add. I do not believe there is an annotation for it, although there probably should be. Unless someone has a better idea, I think we have parse the output generated by 'groff -man -Tascii'. Similar to man's strategy [1] a man page would be deemed to relate to a sub-command when the first two words in the synopsis, connected by a hyphen, are the same as the file name. Kind regards Felix Lechner [1] https://stackoverflow.com/a/32750157
Bug#960485: Modified regex to strip comments in d/rules
Hi, > We believe that the bug you reported is fixed. The tag still showed when a test case was added for this bug report: https://salsa.debian.org/lintian/lintian/-/commit/5b09fbfde06638ca6b5415c01e372beaa459fdd9 The regex may not have stripped comments as intended. It was modified with: https://salsa.debian.org/lintian/lintian/-/commit/95feead477824f9b7b3d35e22cdc19f23259027b Kind regards Felix Lechner
Bug#960807: Bug#950455: Don't emit override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS with debhelper 13
Hi Chris, On Sat, May 16, 2020 at 4:03 PM Chris Lamb wrote: > > > > Making it "just" a library method is not that straightforward either > > > as the code in debhelper.pm also finds and reports on conflicting/ > > > broken numbers, etc. I have a branch that separates scanning from diagnostics. It solves this dilemma. Please look out for a 'lab scan' facility in the near future. The terminology corresponds to the interaction between a doctor and a blood lab. Lintian checks function like a doctor that issues a diagnosis based on lab results. The low-level scan results will become much more abundant and provide all kinds of data to consumers like Lintian Brush. They will replace classification tags. Kind regards Felix Lechner
Use of Lintian role account on lindsay.debian.org
Hi Mattia, This was moved to the list, since your comment did not relate to #960154. > (PS, lechner: ... it's not quite > nice to any other team member in the future, even if the umask seems to > allow all team members to edit those files; I recommend you take on the > habit to deploy that stuff entirely under the role account.) Please have a look at the README on lindsay.d.o: > The cronjob is stored in /srv/lintian.debian.org/config/cron. Changes > should be made in that file. The changed file can then be installed > with: > > sudo -u lintian crontab /srv/lintian.debian.org/config/crontab > > Only this installation of the cron tab should be done as the role user > lintian. You can use 'sudo -u lintian -s' to get a shell for the user, > but use it with discretion. > > Most changes should be made as your regular Debian user. The directory > has the sticky bit set. PLEASE SET YOUR UMASK TO 002. Otherwise, your > fellow developers will run into permission problems. Kind regards Felix Lechner
Salsa CI failures
Hi, Today I made a series of commits trying to restore the Gitlab CI pipeline for stable. I now think they should probably be reversed, as explained below. Has anyone figured out what caused the failures? My commits attempted to use the resolver used on experimental buildds, aspcud, but in retrospective I do not think it was a good idea. Concerns about an alternative resolver aside, I just don't think that we had a problem with not pinning buster-backports before. Any comments would be appreciated. Kind regards Felix Lechner
Re: New changelog commits in release cycle
Hi Chris, On Wed, Apr 29, 2020 at 2:18 PM Chris Lamb wrote: > > Happy to be convinced otherwise though. Like you, I am not fond of it. Besides, gbp-dch looks at tags (which are right) so you should be fine. Kind regards Felix Lechner
Re: New changelog commits in release cycle
Hi Chris, You are welcome to break history for this, if it makes sense. I have not rebased any branches since your release. Kind regards, Felix Lechner On Wed, Apr 29, 2020 at 1:33 PM Chris Lamb wrote: > > Hi Felix, > > > > do you have some specific issue? > > > > I don't. I just hoped to avoid friction in the future if there had > > been any. Thanks for letting me know! > > I just went to look at the Lintian repository. So, I did not notice > any issue at the time of the release but it appears like I could not > push the release commits and tag. > > I've merged them back into master, including my release tag of the > time. > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org chris-lamb.co.uk >`- >
Re: New changelog commits in release cycle
Hi Chris, On Tue, Apr 28, 2020 at 4:02 PM Chris Lamb wrote: > > do you have some specific issue? I don't. I just hoped to avoid friction in the future if there had been any. Thanks for letting me know! Kind regards Felix Lechner
New changelog commits in release cycle
Hi Chris, Due to Salsa downtime earlier today, some commits of mine may have interfered with your release. (I think it happened to another contributor, as well.) Did that bother you, or did it create any kind of problem for you? Kind regards Felix Lechner
Bug#959037: lintian: FPOS? for executable-in-usr-lib
Hi Mattia, On Tue, Apr 28, 2020 at 4:27 AM Mattia Rizzolo wrote: > > Package: lintian > Version: 2.68.0 > X-Debbugs-Cc: debian-b...@lists.debian.org > > Hi, > > I'm CCing d-boot@ for confirmation, since I'm not sure if maybe I'm > doing something wrong. > > Today I notices these tags: > > P: eatmydata-udeb udeb: executable-in-usr-lib > usr/lib/finish-install.d/13eatmydata-udeb > N: I expanded that odd tag description with some text from the original bug report. I also adjusted the references. Perhaps the remark regarding /usr/libexec is helpful: The package ships an executable file in /usr/lib. Please move the file to /usr/libexec. Debian adopted the Filesystem Hierarchy Specification (FHS) version 3.0 starting with our policy revision 4.1.5. The FHS 3.0 describes /usr/libexec. Please use that location for executables. The relevant commit is here: https://salsa.debian.org/lintian/lintian/-/commit/0e3c63e69f5f154034d958b1456bee4cea841c63 Unfortunately, I cannot comment on the substantive question regarding udebs. Kind regards Felix Lechner
Bug#958845: false positive wildcard-matches-nothing-in-dep5-copyright
Hi, On Sat, Apr 25, 2020 at 2:15 PM Chris Lamb wrote: > > this appears to be nondeterminstic on my local machine. Here too. It's wild! I believe it is related to Perl's UTF-8 features. They were recently turned on in Lintian. Strings can be 'upgraded' anytime. According to preliminary experiments it causes mismatches here: https://salsa.debian.org/lintian/lintian/-/blob/master/checks/debian/copyright.pm#L783 The check is on my list to be rewritten. Now it is more urgent. Thanks for reporting this bug! Kind regards Felix Lechner
Bug#958932: lintian: debhelper compat level 13 is no longer experimental
Hi, On Sun, Apr 26, 2020 at 3:54 PM Chris Lamb wrote: > > I do not follow how > making this minor change would affect the rest of Lintian in the > dramatic way you describe. Following a conversation on IRC with mapreri last week I made the changes below. They caused build failures in almost all test artifacts on stable. The debian-compat (= 13) facility is not available. Are you saying we could simply make the second change but not the first? I am fine with that. Please know, however, that mapreri asked for both. Debhelper compat level 13 is now recommended. 09:19 < mapreri> P: django-housekeeping source: package-uses-experimental-debhelper-compat-version 13 09:20 < mapreri> lechner: ↑ debhelper now recommends 13, please update lintian :) Kind regards Felix Lechner * * * Author: Felix Lechner Date: Mon Apr 20 11:33:53 2020 -0700 Bump recommended debhelper compat-level to 13; move experimental to 14. diff --git a/data/debhelper/compat-level b/data/debhelper/compat-level index 2bb3b786d..a1bce7ee4 100644 --- a/data/debhelper/compat-level +++ b/data/debhelper/compat-level @@ -1,8 +1,8 @@ # warn if no versioned depend below this level pedantic=10 # warn (pedantic) if does not depend on this debhelper level -recommended=12 +recommended=13 # warn if below this level deprecated=10 # warn if equal or above -experimental=13 +experimental=14
Bug#958932: lintian: debhelper compat level 13 is no longer experimental
Hi Sven, On Sun, Apr 26, 2020 at 12:54 PM Sven Joachim wrote: > > you might want to wait for its migration before uploading a lintian fix. I have been told that compat level 13 has been available for a while (and presumably in testing), but we do lack the modern and recommended facility debhelper-compat vs. d/compat in stable (and probably also in testing). For some reason, it is not shipped until version 13 is released. Without debhelper-compat (= 13) on stable, all our tests fail to build. They cease to function. We are discussing the matter with the debhelper and dpkg maintainers. The resolution of this bug may have to wait until debhelper version 13 is backported to stable. Kind regards Felix Lechner
Bug#958666: New lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team
Hi, On Fri, Apr 24, 2020 at 10:24 AM Chris Lamb wrote: > > in order to spare this boilerplate within the Med team. Wouldn't it be better to lower the severity for scripts shipped by upstream (vs the maintainer)? Kind regards Felix Lechner
Re: New lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team
Hi Andreas, On Fri, Apr 24, 2020 at 5:57 AM Andreas Tille wrote: > > I've written lots of mails to upstreams just to learn > that I'm mostly ignored. You are facing the dilemma of #907727, except a change would also negatively impact your users. Lintian may in the future automatically reduce the visibility of some tags (aka severity) when a maintainer can do nothing about them. Does that sound like an attractive proposition? Kind regards Felix Lechner
Updates to Lintian's reporting framework
Hi, Lintian is making changes to its reporting framework. You can see a beta at https://lintian.debian.org. It is (or will be) a web app driven by SQL. In another change, we run a separate tag sieve across the archive (to fill the database). Those two products are not part of Lintian. I saw your website http://lintian.debathena.org/. At some point you would lose that functionality. Do you plan to maintain the site going forward? Also, please write if you know any additional consumers of Lintian's reporting framework. Thank you! Kind regards, Felix Lechner on behalf of the Lintian maintainers
Rewriting our git history for non-UTF-8 filenames?
Hi Chris, List is copied. Bastian Blank think we should perhaps merge two commits that both generate 500 errors in Salsa, and rewrite history: https://salsa.debian.org/lintian/lintian/-/commit/37d5255fdbe9e45dfa92d5b05d7efae73fa7a8fd https://salsa.debian.org/lintian/lintian/-/commit/bc81771b388cbf53cf7ecb0e530108212d891565 Do you have a position? Relevant IRC exchange with pros and cons is below. Kind regards Felix Lechner * * * 08:48 < lechner> waldi: i removed the non-UTF-8 filename from lintian, but that blob also causes a 500 error. perhaps the detail helps to understand the issue further. https://salsa.debian.org/lintian/lintian/-/commit/37d5255fdbe9e45dfa92d5b05d7efae73fa7a8fd 08:49 -!- ema [~ema@51.15.179.138] has quit [Remote host closed the connection] 08:49 < waldi> lechner: well. did you force-push to eradicate it from history? 08:49 -!- ema [~ema@51.15.179.138] has joined #alioth 08:50 < mapreri> err why 08:50 < mapreri> that's a gitlab bug, there is no need to mess with published history 08:52 < lechner> waldi: i did not, but am not opposed to it if it makes your life easier. 08:52 < lechner> although I also agree with mapreri 08:53 < mapreri> please do not break other's clones just for that 08:56 < waldi> "doctor, doctor, it hurts when i do this" 08:56 < waldi> i the end, i don't care. you need to live with error messages 08:58 < waldi> (and i have to ignore it) 09:08 < lechner> we made one release, and it may also mess up some commit references in messages and bug reports, but that's probably fewer than five. i'll check with lamby and get back to you.
Bug#683940: lintian.d.o: Specially mark FTP auto-reject tags
Hi, On lintian.d.o, FTP Master auto-reject tags could be marked more prominently. (A related idea would be for tracker.d.o to show a visual alert.) Maybe it would reduce the burden on the FTP team to keep the community informed [1] Kind regards Felix Lechner [1] https://lists.debian.org/debian-devel-announce/2009/10/msg4.html
Bug#935292: lintian: reporing-harness get stuck when lintian deadlocks
Control: retitle -1 lintian: encrypted zip files stall processing
Hi,
On Wed, Aug 21, 2019 at 4:27 AM Niels Thykier wrote:
>
> Below is the log from where
> lintian was manually killed by me on a stuck package
We have a new tag sieve that examines the archive. It is separate from
Lintian, and will be moved to a team location soon:
https://salsa.debian.org/lechner/taxiv
The tag sieve currently gets stuck on two packages that ship encrypted
zip files that require passwords. Archive::Zip apparently waits for
user input, although there is no prompt. The affected packages are:
androguard
fcrackzip
The following commands appear in the process table. Lintian will
resume processing when they are killed, but the condition should not
appear:
unzip -t
/tmp/lintian-pool-isMSeQshki/pool/a/androguard/androguard_3.3.5-2_all_binary/unpacked/usr/share/doc/androguard/examples/malware/4e2201cde26141715255d2421f0bcfb1.zip
unzip -t
/tmp/lintian-pool-x_RwncOeP5/pool/f/fcrackzip/fcrackzip_1.0-10_amd64_binary/unpacked/usr/share/doc/fcrackzip/examples/noradi.zip
This patch seemed plausible but did not work:
index 2142c92da..2322f4962 100644
--- a/lib/Lintian/Index/Java.pm
+++ b/lib/Lintian/Index/Java.pm
@@ -164,6 +164,10 @@ sub parse_jar {
next
if $member->isDirectory;
+# prompts for password otherwise
+next
+ if $member->isEncrypted;
+
# store for later processing
$manifest = $member
if $name =~ m@^META-INF/MANIFEST.MF$@oi;
The presence of an encrypted zip member should probably also trigger a tag.
Kind regards
Felix Lechner
Bug#958113: lintian crash on empty orig.tar
Hi Baptiste, On Sat, Apr 18, 2020 at 9:09 AM Baptiste BEAUPLAT wrote: > > lintian crashes That should not happen! > Can't call method "parent_dir" on an undefined value at > /usr/share/perl5/Lintian/Index.pm line 278. There are additional conditions in Lintian that could cause follow-on failures. Will you please provide that package, even if it isn't in the archive? Kind regards Felix Lechner
dak's FTP auto-reject profile
Hi, I submitted this merge request on behalf of Lintian: https://salsa.debian.org/ftp-team/dak/-/merge_requests/198 Kind regards Felix Lechner
Bug#956233: lintian: Perl bug triaged
Hi, On Wed, Apr 8, 2020 at 10:30 AM Dmitry Shachnev wrote: > > Can't open > '/tmp/lintian-pool-z2LddsoVG9/pool/s/sphinx/sphinx_2.4.3-2+salsaci_source/unpacked/tests/roots/test-images/testimäge.png' > with mode '<:raw': 'No such file or directory' at > /usr/share/lintian/checks/cruft.pm line 992 The Perl bug that causes the runtime failures in both bugs was triaged with this commit: https://salsa.debian.org/lintian/lintian/-/commit/412b592077efdde9609f3fce98493909daa77172 It should make resolution less urgent, although both bugs will be addressed very soon. Sorry about the inconvenience. Kind regards Felix Lechner
Bug#956723: lintian: add check for invalid UTF8 filenames in source
Hi Ivo, On Tue, Apr 14, 2020 at 10:33 AM Ivo De Decker wrote: > > I assumed that those packages would be > rejected by the archive, but clearly that's not the case. Is it okay if source packages with non-UTF-8 file names show merely a warning? The archive should probably tolerate them. Kind regards Felix Lechner
Bug#956723: lintian: add check for invalid UTF8 filenames in source
Control: severity -1 important Hi Ivo, On Tue, Apr 14, 2020 at 10:12 AM Ivo De Decker wrote: > > This was inspired by bug #956233 The solution for that bug will address this one, as well. The supysonic case is already mentioned there (perhaps that's what you meant by inspiration): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956233#17 Kind regards Felix Lechner
Bug#956613: lintian: inconsistent-appstream-metadata-license is confused when appstream metadata file is generated
Hi dkg, On Mon, Apr 13, 2020 at 9:45 AM Daniel Kahn Gillmor wrote: > > W: balsa source: inconsistent-appstream-metadata-license > balsa.appdata.xml (cc0-1.0 != gpl-2+) I do not see that tag when running lintian's development version against balsa from unstable: $ frontend/lintian -EvIL +classification /mirror/debian/pool/main/b/balsa/balsa_2.5.9-4.dsc N: Using profile debian/main. N: Starting on group balsa/2.5.9-4 N: Unpacking packages in group balsa/2.5.9-4 N: Finished processing group balsa/2.5.9-4 N: N: Processing source package balsa N: (version 2.5.9-4, arch source) ... C: balsa source: debhelper-compat-level 12 C: balsa source: debhelper-compat-virtual-relation 12 C: balsa source: debian-build-system dh C: balsa source: debian-watch-file-standard 4 C: balsa source: package-is-team-maintained pkg-gnome-maintain...@lists.alioth.debian.org 3 C: balsa source: patch-system quilt C: balsa source: rules-does-not-require-root C: balsa source: source-format 3.0 (quilt) C: balsa source: standards-version 4.5.0 C: balsa source: vcs git C: balsa source: vcs-uri https://salsa.debian.org/gnome-team/balsa.git > Rather, i think lintian should avoid warning about license information > in a file that is not part of the source package. Lintian should not complain, for a source package, about files not shipped within it. Was the file perhaps included accidentally? Kind regards Felix Lechner
Bug#956233: lintian: Internal error opening files since 2.63.0
Control: retitle -1 lintian: UTF-8 filenames cause internal errors Hi Dmitry, On Wed, Apr 8, 2020 at 10:30 AM Dmitry Shachnev wrote: > > Can't open > '/tmp/lintian-pool-z2LddsoVG9/pool/s/sphinx/sphinx_2.4.3-2+salsaci_source/unpacked/tests/roots/test-images/testimäge.png' > with mode '<:raw': 'No such file or directory' at > /usr/share/lintian/checks/cruft.pm line 992 This error is about UTF-8 filenames. We have a solution in Lintian, but it does not work reliably due to a Perl bug. In my opinion, the bug is serious enough to patch all versions of Perl shipped in Debian, as explained below. In lieu of what would have been an upcoming email to debian-perl, they are hereby copied. In a nutshell, file tests such as '-f' do not work reliably with strings that were internally "upgraded" by Perl (i.e. utf8::upgrade). More details about this dangerous bug are available here [1] and [2]. Other system calls such as 'stat' and 'open' are likewise affected. This bug shows the problem with 'open'. It is amazing that the bug has been open for so long. It is literally the well-known "Unicode bug", but for file names. Apparently there is no common solution for all Perl platforms. (The use of UTF-8 filenames also appears to be uncommon outside Linux, or is implemented differently, i.e. MacOS.) In my view, many Perl scripts in Debian, including those for installation and security purposes, depend on file tests working reliably. Perhaps our Perl interpreters should be patched with a Debian-specific fix. Related questions about file name mangling or matching in modules, such as Path::Tiny and File::Find::Rule, may have to be explored or mitigated before this bug can be considered completely closed. The credit for identifying the bug in Lintian (and saving my sanity) goes to Grinnz on #debian-perl. Kind regards, Felix Lechner [1] https://github.com/Perl/perl5/issues/10550 [2] https://github.com/Perl/perl5/issues/9674
Bug#945544: lintian: Field too long doesn't report anything on the website
Hi Sylvestre, On Tue, Nov 26, 2019 at 10:36 AM Sylvestre Ledru wrote: > > https://lintian.debian.org/tags/field-too-long.html is empty while it should > return > some results (oca-core, parl-desktop-world, some rust stuff) Our website is still not working properly. Below please find a database excerpt that shows the recent activity for your tag. Right now, we only have it for main from unstable. Automatic debug packages are also not yet included. I hope this information is helpful to you. Sorry about the delay. Kind regards Felix Lechner * * * sqlite> select file.name, tag.hint from tag inner join file on file.id = tag.file_id where tag.name = 'field-too-long'; consul_1.7.1+dfsg1-2_amd64.deb|Built-Using (5092 chars > 5000) docker.io_19.03.6+dfsg1-2_amd64.deb|Built-Using (5014 chars > 5000) firefox-esr_68.6.0esr-1.dsc|Checksums-Sha1 (8728 chars > 5000) firefox-esr_68.6.0esr-1.dsc|Files (7976 chars > 5000) gcc-10_10-20200211-1.dsc|Build-Depends (10687 chars > 5000) gcc-10_10-20200324-1.dsc|Build-Depends (10691 chars > 5000) gcc-10_10-20200402-1.dsc|Build-Depends (10691 chars > 5000) gcc-10-cross_5.dsc|Binary (9282 chars > 5000) gcc-10-cross-mipsen_2+c1.dsc|Binary (15867 chars > 5000) gcc-10-cross-ports_3.dsc|Binary (9660 chars > 5000) gcc-10-cross-ports_4.dsc|Binary (9660 chars > 5000) gcc-8_8.3.0-2.dsc|Build-Depends (9812 chars > 5000) gcc-8_8.4.0-1.dsc|Build-Depends (9575 chars > 5000) gcc-8_8.4.0-2.dsc|Build-Depends (9575 chars > 5000) gcc-8_8.4.0-3.dsc|Build-Depends (9607 chars > 5000) gcc-9_9.2.1-21.dsc|Build-Depends (10484 chars > 5000) gcc-9_9.2.1-24.dsc|Build-Depends (10484 chars > 5000) gcc-9_9.2.1-25.dsc|Build-Depends (10484 chars > 5000) gcc-9_9.2.1-29.dsc|Build-Depends (10497 chars > 5000) gcc-9_9.3.0-3.dsc|Build-Depends (10501 chars > 5000) gcc-9_9.3.0-6.dsc|Build-Depends (10497 chars > 5000) gcc-9_9.3.0-7.dsc|Build-Depends (10497 chars > 5000) gcc-9_9.3.0-8.dsc|Build-Depends (10497 chars > 5000) gcc-9_9.3.0-9.dsc|Build-Depends (10497 chars > 5000) gcc-9-cross_18.dsc|Binary (9418 chars > 5000) gcc-9-cross_21.dsc|Binary (7157 chars > 5000) gcc-9-cross-mipsen_3+c1.dsc|Binary (15516 chars > 5000) gcc-9-cross-mipsen_4+c2.dsc|Binary (11527 chars > 5000) gcc-9-cross-mipsen_4+c2.dsc|Build-Depends (5411 chars > 5000) gcc-9-cross-ports_15.dsc|Binary (9801 chars > 5000) gcc-9-cross-ports_17.dsc|Binary (7355 chars > 5000) gcc-9-cross-ports_18.dsc|Binary (7355 chars > 5000) gcc-snapshot_20191110-1.dsc|Build-Depends (10756 chars > 5000) gcc-snapshot_20191130-1.dsc|Build-Depends (10756 chars > 5000) gcc-snapshot_20200124-1.dsc|Build-Depends (10628 chars > 5000) gcc-snapshot_20200401-1.dsc|Build-Depends (10663 chars > 5000) gstreamer1.0-libav_1.16.2-2_amd64.deb|Gstreamer-Elements (8155 chars > 5000) kubernetes_1.7.7+dfsg-3.dsc|Build-Depends (5085 chars > 5000) libdpdk-dev_19.11-4_amd64.deb|Depends (5238 chars > 5000) libmono-cil-dev_6.8.0.105+dfsg-2_all.deb|Depends (7485 chars > 5000) librust-winapi-dev_0.3.8-2_amd64.deb|Provides (65642 chars > 5000) linux_4.19.98-1.dsc|Binary (42108 chars > 5000) linux_4.19.98-1.dsc|Build-Depends-Arch (6323 chars > 5000) linux_5.4.19-1.dsc|Binary (43272 chars > 5000) linux_5.4.19-1.dsc|Build-Depends-Arch (6155 chars > 5000) linux_5.5.13-2.dsc|Binary (42827 chars > 5000) linux_5.5.13-2.dsc|Build-Depends-Arch (6155 chars > 5000) med-bio_3.5.1_all.deb|Recommends (5222 chars > 5000) mono_6.8.0.105+dfsg-2.dsc|Binary (5384 chars > 5000) mono-devel_6.8.0.105+dfsg-2_all.deb|Breaks (9778 chars > 5000) mono-devel_6.8.0.105+dfsg-2_all.deb|Replaces (9890 chars > 5000) node-gulp_4.0.2-6.dsc|Checksums-Sha1 (5670 chars > 5000) node-gulp_4.0.2-6.dsc|Files (5150 chars > 5000) nomad_0.10.2+dfsg1-10.dsc|Build-Depends (5456 chars > 5000) nomad_0.10.4+dfsg1-1.dsc|Build-Depends (5507 chars > 5000) nomad_0.10.4+dfsg1-3_amd64.deb|Built-Using (7135 chars > 5000) nomad_0.10.4+dfsg1-3.dsc|Build-Depends (5507 chars > 5000) oca-core_11.0.20180730-1_all.deb|Provides (7505 chars > 5000) parl-desktop-world_1.9.23_all.deb|Depends (6846 chars > 5000)
Bug#955538: lintian: unused-file-paragraph-in-dep5-copyright on orig file with /./ in filenames
Hi Roland, On Thu, Apr 2, 2020 at 2:06 AM Roland Rosenfeld wrote: > > It would be great, if you could fix lintian to ignore the /./ in the > path for dep5-copyright file matching. Please use the attached copyright file. A detailed explanation will appear below shortly from the commit to follow. Lintian now produces this output: $ frontend/lintian --no-tag-display-limit ../bugs/privoxy/privoxy_3.0.28-2.dsc W: privoxy source: orig-tarball-missing-upstream-signature privoxy_3.0.28.orig.tar.gz P: privoxy source: uses-debhelper-compat-file N: 2 tags overridden (2 warnings) Due to extraordinary insights gained from the analysis for this bug, a full path list with all files both shipped and covered by d/copyright in privoxy 3.0.28-stable, prior to this fix, is included below. Please disregard the remainder of this message. Kind regards Felix Lechner * * * Shipped: ./AUTHORS Shipped: ./ChangeLog Shipped: ./GNUmakefile.in Shipped: ./INSTALL Shipped: ./LICENSE Shipped: ./Makefile Shipped: ./README Shipped: ./TODO Shipped: ./acconfig.h Shipped: ./actionlist.h Shipped: ./actions.c Shipped: ./actions.h Shipped: ./cgi.c Shipped: ./cgi.h Shipped: ./cgiedit.c Shipped: ./cgiedit.h Shipped: ./cgisimple.c Shipped: ./cgisimple.h Shipped: ./client-tags.c Shipped: ./client-tags.h Shipped: ./config Shipped: ./config.guess Shipped: ./config.sub Shipped: ./configure.in Shipped: ./cygwin.h Shipped: ./deanimate.c Shipped: ./deanimate.h Shipped: ./default.action.master Shipped: ./default.filter Shipped: ./doc/gpl.html Shipped: ./doc/pcrs.3 Shipped: ./doc/source/authors.sgml Shipped: ./doc/source/buildsource.sgml Shipped: ./doc/source/changelog.sgml Shipped: ./doc/source/config.sgml Shipped: ./doc/source/contacting.sgml Shipped: ./doc/source/copyright.sgml Shipped: ./doc/source/developer-manual.sgml Shipped: ./doc/source/faq.sgml Shipped: ./doc/source/history.sgml Shipped: ./doc/source/install.sgml Shipped: ./doc/source/ldp.dsl.in Shipped: ./doc/source/license.sgml Shipped: ./doc/source/newfeatures.sgml Shipped: ./doc/source/p-authors.sgml Shipped: ./doc/source/p-config.sgml Shipped: ./doc/source/privoxy-man-page.sgml Shipped: ./doc/source/privoxy.sgml Shipped: ./doc/source/readme.sgml Shipped: ./doc/source/seealso.sgml Shipped: ./doc/source/supported.sgml Shipped: ./doc/source/user-manual.sgml Shipped: ./doc/source/webserver/index.sgml Shipped: ./doc/webserver/README.txt Shipped: ./doc/webserver/announce.txt Shipped: ./doc/webserver/developer-manual/coding.html Shipped: ./doc/webserver/developer-manual/documentation.html Shipped: ./doc/webserver/developer-manual/git.html Shipped: ./doc/webserver/developer-manual/index.html Shipped: ./doc/webserver/developer-manual/introduction.html Shipped: ./doc/webserver/developer-manual/newrelease.html Shipped: ./doc/webserver/developer-manual/testing.html Shipped: ./doc/webserver/developer-manual/webserver-update.html Shipped: ./doc/webserver/error-favicon.ico Shipped: ./doc/webserver/faq/configuration.html Shipped: ./doc/webserver/faq/contact.html Shipped: ./doc/webserver/faq/copyright.html Shipped: ./doc/webserver/faq/general.html Shipped: ./doc/webserver/faq/index.html Shipped: ./doc/webserver/faq/installation.html Shipped: ./doc/webserver/faq/misc.html Shipped: ./doc/webserver/faq/trouble.html Shipped: ./doc/webserver/favicon.ico Shipped: ./doc/webserver/images/files-in-use.jpg Shipped: ./doc/webserver/images/proxy_setup.jpg Shipped: ./doc/webserver/index.html Shipped: ./doc/webserver/man-page/privoxy-man-page.html Shipped: ./doc/webserver/p_doc.css Shipped: ./doc/webserver/p_feedback.css Shipped: ./doc/webserver/privoxy-index.html Shipped: ./doc/webserver/privoxy.css Shipped: ./doc/webserver/robots.txt Shipped: ./doc/webserver/sponsors/index.html Shipped: ./doc/webserver/team/01stefanw.jpg Shipped: ./doc/webserver/team/01stefanw_t.jpg Shipped: ./doc/webserver/team/02jon.jpg Shipped: ./doc/webserver/team/02jon_t.jpg Shipped: ./doc/webserver/team/03andreas.jpg Shipped: ./doc/webserver/team/03andreas_t.jpg Shipped: ./doc/webserver/team/04rodney.jpg Shipped: ./doc/webserver/team/04rodney_t.jpg Shipped: ./doc/webserver/team/05david.jpg Shipped: ./doc/webserver/team/05david_t.jpg Shipped: ./doc/webserver/team/05member.jpg Shipped: ./doc/webserver/team/05member_t.jpg Shipped: ./doc/webserver/team/06member.jpg Shipped: ./doc/webserver/team/06member_t.jpg Shipped: ./doc/webserver/team/07member.jpg Shipped: ./doc/webserver/team/07member_t.jpg Shipped: ./doc/webserver/team/08member.jpg Shipped: ./doc/webserver/team/08member_t.jpg Shipped: ./doc/webserver/team/20member.jpg Shipp
Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
Hi, On Mon, Mar 30, 2020 at 6:07 PM Jiri Palecek wrote: > > Yeah and it's (slightly?) wrong in using of the negative assertions. I thought I also changed some when importing xdeb. Which are wrong, please? > Maybe another time. Let's take care of it now! Kind regards Felix Lechner
Bug#920575: copyright-without-copyright-notice assumes upstream has copyright notices
Hi Josh, On Sat, Jan 26, 2019 at 10:03 PM Josh Triplett wrote: > > (This lintian issue currently leads me to have a build wrapper script > generating debian/copyright, rather than just having a static > debian/copyright file checked in.) The lack of a copyright notice seems to be package specific (and not related to a particular workflow). Would it be more helpful to suppress the tag with an override? Kind regards Felix Lechner
Bug#675163: Probably a separate package
Hi Gergely, > I'm thinking about something along the lines of apt-listchanges (or > apt-listbugs, but I haven't used this last one in ages), which can > either mail the results to the user (which wouldn't make much sense in > this case, in my opinion), or display the results, and prompt the user > whether to abort the installation, or continue. Like apt-listchanges and apt-listbugs, such a hook probably belongs into a separate package. As a side note, I see Lintian mostly as a development tool. The messages may not be helpful to users, but I would fully support this effort! Kind regards Felix Lechner
Bug#955386:
Hi Aurelien, I believe that this was solved with: https://salsa.debian.org/lintian/lintian/-/commit/a1dbe23dc95c8bf9b71d59894b97d9cd03b5ecc2 Kind regards Felix Lechner
Bug#935292: Lintian no longer deadlocks
Control: retitle -1 lintian.d.o: reporting-harness gets stuck Hi, > Below is the log from where > lintian was manually killed by me on a stuck package Lintian no longer deadlocks on any of the packages mentioned in this bug report. The logs are attached. Re-titling this bug. Golang-1.12 was replaced by golang-1.14 since the relevant report was made. Kind regards Felix Lechner grpc.log.xz Description: application/xz guake.log.xz Description: application/xz grass.log.xz Description: application/xz golang-1.14.log.xz Description: application/xz golang-github-mcuadros-go-gin-prometheus.log.xz Description: application/xz libbpp-seq-omics.log.xz Description: application/xz intel-cmt-cat.log.xz Description: application/xz libbpp-qt.log.xz Description: application/xz intel-processor-trace.log.xz Description: application/xz libseqlib.log.xz Description: application/xz linux-signed-i386.log.xz Description: application/xz libconfig-model-itself-perl.log.xz Description: application/xz mgcv.log.xz Description: application/xz mandos.log.xz Description: application/xz
Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
Hi Jiri, On Mon, Mar 30, 2020 at 5:54 AM Jiri Palecek wrote: > > That's good; however, I'd like to know why is that tag even needed > in lintian, and if removing that altogether wouldn't be the best course > of action. Especially given that lintian already has a tag for the very > same check, but with some multilib issues solved and more: Thanks for being persistent. It made my work a lot easier. I totally agree with you. I will remove the xdeb check in the near future. I will only keep the test, which is slightly different from t/tags/checks/binaries/binaries-from-other-arch. It actually builds a cross-binary, even if the arch-dependent build prerequisite is not in d/control (so our Gitlab CI is not burdened all the time). > https://salsa.debian.org/lintian/lintian/-/blob/40a028318ae647034ac35f900c119f922ca1b638/data/binaries/arch-regex That table was apparently imported from xdeb at some point. Kind regards Felix Lechner
Bug#947763: "aCount" is not a spelling error of "account"
Hi Christoph, On Mon, Dec 30, 2019 at 2:51 AM Christoph Berg wrote: > > "aCount" is hardly a spelling error for "account". It's not even > present in the source, but only in the "strings /usr/bin/cqrlog" > output. Since the string is not present in your source, your bug was probably filed against the wrong package. Lazarus, one of your prerequisites, exports a variety of variable names as object strings, including 'aCount'. It would be nice to know the reason. Here are a few more using non-standard spelling: I: lazarus-ide-gtk2-2.0: spelling-error-in-binary usr/lib/lazarus/2.0.6/lazarus-gtk2 Exluded Excluded I: lazarus-ide-gtk2-2.0: spelling-error-in-binary usr/lib/lazarus/2.0.6/lazarus-gtk2 Montly Monthly I: lazarus-ide-gtk2-2.0: spelling-error-in-binary usr/lib/lazarus/2.0.6/lazarus-gtk2 Syncronized Synchronized I: lazarus-ide-gtk2-2.0: spelling-error-in-binary usr/lib/lazarus/2.0.6/lazarus-gtk2 aCount account I: lazarus-ide-gtk2-2.0: spelling-error-in-binary usr/lib/lazarus/2.0.6/lazarus-gtk2 availlable available I: lazarus-ide-gtk2-2.0: spelling-error-in-binary usr/lib/lazarus/2.0.6/lazarus-gtk2 memeber member I: lazarus-ide-gtk2-2.0: spelling-error-in-binary usr/lib/lazarus/2.0.6/lazarus-gtk2 occured occurred I: lazarus-ide-gtk2-2.0: spelling-error-in-binary usr/lib/lazarus/2.0.6/lazarus-gtk2 respository repository I am unfamiliar with Lazarus or Free Pascal and copied the lazarus maintainer on this message. I am inclined to assign this bug to lazarus. Please let's wait for their response. > I suggest excluding CamelCased words from the spelling check. I have not seen a lot of GUI items in camel case (which would cause more legitimate strings like it to appear in binaries) and do not perceive 'aCount' as a false positive. An override would be a simple solution, depending on the outcome of the inquiry above. As a side note, your package suffers from additional spelling issues, as noted below. Like the present case, many of them do not originate in your source. Kind regards Felix Lechner, WU8K * * * $ frontend/lintian --no-tag-display-limit /mirror/debian/pool/main/c/cqrlog/cqrlog_2.4.0-3_amd64.deb W: cqrlog: hardening-no-pie usr/bin/cqrlog I: cqrlog: hardening-no-bindnow usr/bin/cqrlog I: cqrlog: hardening-no-fortify-functions usr/bin/cqrlog I: cqrlog: spelling-error-in-binary usr/bin/cqrlog Childs Children I: cqrlog: spelling-error-in-binary usr/bin/cqrlog Disconected Disconnected I: cqrlog: spelling-error-in-binary usr/bin/cqrlog Memebers Members I: cqrlog: spelling-error-in-binary usr/bin/cqrlog aCount account I: cqrlog: spelling-error-in-binary usr/bin/cqrlog availlable available I: cqrlog: spelling-error-in-binary usr/bin/cqrlog databse database I: cqrlog: spelling-error-in-binary usr/bin/cqrlog lenght length I: cqrlog: spelling-error-in-binary usr/bin/cqrlog occured occurred I: cqrlog: spelling-error-in-binary usr/bin/cqrlog uploded uploaded
Bug#779224: Experimental branch runs checks in parallel
Control: retitle -1 lintian: run checks in parallel Control: severity -1 normal Hi, > * Do checks in subprocesses, so memory will be reclaimed There is an experimental branch that runs checks in parallel. For reasons unknown, It is slower by a factor of two or more. Reasons may include unwanted serialization (although most data structures were "closed upon") or a repeated reading of the remaining collections files. Most data is now in memory, but some files remain. There are 161 checks. The strategy "fork, do memory intensive stuff, exit" is the best and maybe only way to recapture memory in Perl. Running checks in parallel would automatically release memory used in each check. Re-titling the bug accordingly. Kind regards Felix Lechner
