Bug#886036: Improve changelog version parsing
Hi Chris, Thank you for following up. I have more patches. I am just not sure if the version parsing should really be duplicated in Lintian. Maybe there is a benefit to checks and balances, but at least some of the work might well go into 'dpkg/scripts/Dpkg/Version.pm', which we could then use in Lintian. What do you think, please? Thank you for your guidance! Best regards, Felix On Sun, Apr 15, 2018 at 1:21 AM, Chris Lamb wrote: > Chris Lamb wrote: > >> Can you update us on the status of this issue? Did we resolve it already >> or do you have more patches ready to roll soon? :) > > Gentle ping on this? I do remember you had some patches queued up, > I just hope we/I haven't neglected them somewhere... > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`-
Bug#886036: Salsa merge request
The patches were consolidated in this merge request (https://salsa.debian.org/lintian/lintian/merge_requests/14).
Bug#904707: fakeroot chown fails on kerberized NFSv4
Package: lintian Version: 2.5.94 Hi, When the Lintian test suite runs on a kerberized NFSv4 volume, 't/tests/files-wrong-owner' fails with this error message: tests::files-wrong-owner: chown: changing ownership of 'debian/files-wrong-owner/usr/lib/filenames/wrong-owner-100:0': Invalid argument tests::files-wrong-owner: make[1]: *** [debian/rules:13: override_dh_fixperms] Error 1 The full log is attached. I can replicate the behavior by cloning Lintian from salsa and running './debian/rules runtests onlyrun=files-wrong-owner'. I isolated the error in the shell script below (also attached). In a strange twist, the script produces no error for some low uids here, including 0 and 1, but fails consistently for uids that don't exist. (The uid 100 exists but fails.) Please try a different uid if you do not get the error right away. #!/bin/sh set -x tmpdir="$(mktemp -d --tmpdir=.)" tmpfile="$(mktemp --tmpdir=$tmpdir)" fakeroot -- chown 17171:0 $tmpfile # offending command rm $tmpfile rmdir $tmpdir I do not see a workaround in Lintian, so the bug should probably be reassigned to 'nfs-utils'. The bugs over there did not strike me immediately as related. (I have other bugs open and would be happy to help.) Here are my mount and export details: /etc/exports (on server): /srv/nfs *(rw,sync,no_subtree_check,no_root_squash,sec=krb5i:krb5p,fsid=0) /srv/nfs/acct *(rw,sync,no_subtree_check,no_root_squash,sec=krb5i:krb5p,mountpoint) /etc/fstab (on client): server:/acct /acct nfs4 rw,sec=krb5i,fsc 0 0 Perhaps it is relevant that 'root' on the client is allowed to use the machine credentials: /etc/idmapd (on server): [Translation] Method = nsswitch GSS-Methods = static,nsswitch [Static] host/client.domain@domain.tld = root [Mapping] Nobody-User = nobody Nobody-Group = nogroup Also, (client) Linux client.domain.tld 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64 GNU/Linux (server) Linux server.domain.tld 4.16.0-2-amd64 #1 SMP Debian 4.16.16-2 (2018-06-22) x86_64 GNU/Linux and finally, -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.31.1-1 ii bzip2 1.0.6-8.1 ii diffstat 1.61-1+b1 ii dpkg 1.19.0.5+b1 ii file 1:5.33-3 ii gettext0.19.8.1-6+b1 ii intltool-debian0.35.0+20060710.4 ii libapt-pkg-perl0.1.34 ii libarchive-zip-perl1.60-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.39-1 ii libdigest-sha-perl 6.02-1 ii libdpkg-perl 1.19.0.5 ii libemail-valid-perl1.202-1 ii libfile-basedir-perl 0.08-1 ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b3 ii libparse-debianchangelog-perl 1.2.0-12 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.74-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.72+repack-1 ii man-db 2.8.3-2 ii patchutils 0.3.4-2 ii perl [libdigest-sha-perl] 5.26.2-6 ii t1utils1.41-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b4 Versions of packages lintian suggests: ii binutils-multiarch 2.31.1-1 ii dpkg-dev 1.19.0.5 ii libhtml-parser-perl3.72-3+b2 ii libtext-template-perl 1.53-1 -- no debconf information Thank you! lintian-nfs-fakeroot-error.log.gz Description: application/gzip nfsv4-fakeroot-chown-test.sh.gz Description: application/gzip
Bug#904707: fakeroot chown fails on kerberized NFSv4
Control: reassign 904707 nfs-utils 1:1.3.4-2.2 > I think your next step might be to try and create a minimal testcase > outside of Lintian. If you can, then it should not be assigned here > (naturally). It's already isolated---maybe you did not see the script. Reassigned. Thank you!
Re: Lintian test suite proposal
Hi Niels, Thank you for your thoughtful comments. Your input weighs heavily in Debian QA. I will address your points one by one, but will mostly disregard your comments regarding style. Some of it may be my lack of experience. Perhaps it is my walk of life. I probably dislike the passive language that is so common in technical documents. Either way, I am not tied to any wording. Let's begin: > As I read it, there are two orthogonal but interesting ideas. > > 1. The tags.d layout > > 2. The Abbreviated-Tags proposal pigging backed on top of tags.d. The two ideas are not as unrelated as they seem. Both (1) and (2) dissociate the tag names from the test context. Keeping that information together as we currently do is not only redundant but also makes it hard to refactor and reorganize our tests. Given your positive reaction to 'Abbreviated-Tags' I won't dwell on its advantages, but it is the less powerful idea of the two. Sure, it's nice you don't have to mention the test name in 'tags' any more, but you still have to deal with nuisance tags from unrelated checks. Many times, they are a pointless obstacle: Who cares about a watch file, for example, when you are testing lintian's reaction to changelog entries? I think ultimately the option 'Abbreviated-Tags' only makes it easier to rename tests. It does not help with unit testing the lintian checks, which is the core proposal. The tags directory proposal suppresses tag noise from other checks. I also makes it easy to reuse tag files in various test contexts as long as you are testing the same basic features. Another great advantage, and a major motivation, is the easier reordering of git commits containing newly proposed Lintian tags. If any test validates more than one check you are working on, you can spend a lot of time with 'git rebase -i' and 'git add -i' trying to swap the commit order. With tags.d it is almost guaranteed to be conflict-free. You may want to add a third point. My proposal also abolishes the tag order. As a side note, I actually expected greater opposition to the bundling of all tags in one check as a testable entity, as opposed to viewing single tags as the proper entity under test. The idea for tags.d arose when I read the following portions of the README (emphasis marked with >>> and <<<): / Please keep each test case focused. One of the problems that / developed with the old test suite is that each test was serving many / separate purposes and testing large swaths of Lintian, which made it / difficult to know what could be changed and what would destroy some / other useful test. >>> Test cases should only test a set of closely / related tags and new tests should be added for new issues that aren't / part of that closely-related set. <<< / Test cases should be as Lintian-clean as possible except for the tags / that they're testing for. The template is intended to help with this. / It generates a Lintian-clean basic package for you to start with. You / should override only the minimal required to trigger your test, and / try to fix any unrelated problems. >>> Sometimes this won't be possible / and the only way to trigger a tag is to also trigger another tag, and / that's fine, but it shouldn't be the normal case. <<< > As I read it, these proposals should be feasible implement separately > (i.e. Abbreviated-Tags could be retrofitted into the existing framework > without adding tags.d). This is mostly relevant if one of the proposals > turn out to be controversial and the other is not - in that case, we can > move forward with the uncontroversial one. Good point. I originally implemented them separately but found the combination more powerful. Please note that either way the use of directory tags is optional. People can still use the regular 'tags' file. > Personally, I feel I understand Abbreviated-Tags good enough that I can > say I would support it and I would recommend it was made the default for > new tests (modulo a few minor remarks). > On the tags.d layout, I can mostly see where you would like to go but > it is not clear to me when the test runner will accept vs. fail a test. The test runner fails if a check being tested did not issue all tags specified, or if the check issued tags that weren't specified. That behavior is similar to what happens now, except everything happens on a per-check basis. > > New tags.d layout > > - > > General remarks about the text (assuming it is for t/tests/README): > > * I think we should avoid the "New" / "Old" in this document if it is >an addition to t/tests/README. The problem with using "new" for >everything is that in a year it will no longer be new and at some >point it could even be superseded by a different format/layout as we >improve ourselves. Let's cooperate on wording if you are available to give advice, please. > * The text sometimes stops being a README document and starts being >sales-pitch and then jumps back to bei
Bug#886036: Improve changelog version parsing
Hi Chris,
There were two separate errors. Versions with "0" in any component
were not evaluated correctly. (The Perl string "0" is logically false
even though it has non-zero length.) A second problem was that
versions with "+bzr" triggered false positives for
'debian-changelog-version-requires-debian-revision'. That was solved
by restricting binary NMUs (which probably should not appear in source
changelogs anyway) to one or more digits. Both errors were fixed in
this merge request. Thank you!
https://salsa.debian.org/lintian/lintian/merge_requests/20
Best regards,
Felix> found 886036 2.5.97
> thanks
>
> Hi Felix,
>
> > * checks/source-changelog.{desc.pm}:
> >+ [FL] Rework, centralise and improve version parsing.
> > (Closes: #886036)
>
> I'm seeing some false-positives here:
>
> https://lintian.debian.org/tags/malformed-debian-changelog-version.html
>
> Could you take a look?
>
>
> Regards,
>
> --
> ,''`.
> : :' : Chris Lamb
> `. `'` la...@debian.org / chris-lamb.co.uk
>`-
Bug#906957: More tests
Thadeu, thank you for reporting, and sorry about the error. Best regards, Felix Chris, Would you like me to add Thadeu's test to my merge request? I would like to add one for the +bzr vs binNMU, as well. Thank you! Best regards, Felix
Bug#911355: False negative for 'multi-arch-same-package-has-arch-specific-overrides'
Package: lintian Version: 2.5.109 Severity: minor Tags: patch Hi, The Lintian test suite identified a potential false negative for the tag 'multi-arch-same-package-has-arch-specific-overrides' when the value of the Architecture: field in 'debian/control' does not match the extension of the lintian-override file. Both fields could be architecture wildcards. A positive finding should take place when the latter is a subset of the former. Attached please find a patch fixing the issue. To reproduce, please manually change both package architectures in the test 'fields-multi-arch-same-package-has-arch-specific-overrides' to Architecture: any (in the file 'debian/debian/control.in'). The tag 'multi-arch-same-package-has-arch-specific-overrides' should disappear. To assist the developers, I will also file a merge request on salsa with a commit message that references the assigned bug number. Thank you! Best regards, Felix fix-false-negative.patch.xz Description: application/xz
Bug#913099: Possible triage
Thank you for identifying the offending commit. The error you are
seeing could be caused by the second assignment in:
our $ARCHITECTURE = safe_qx(qw(dpkg-architecture -qDEB_HOST_ARCH));
...
$data->{architecture} = $ARCHITECTURE;
which happened in this commit:
https://salsa.debian.org/lintian/lintian/commit/8d1f6a0a6c3617b168f36cd1389b5ae2b3470d1e#c126e8eff5e7366571c744785275b8864017724f_1068_1067
What is the output of 'dpkg-architecture -qDEB_HOST_ARCH', please, on
the machines the failed architectures were building on? If the value
is 'amd64', you may be able to triage with:
$data->{architecture} = 'any'; (Please don't try 'all', as in the
commit; it won't work.)
Thank you!
Kind regards,
Felix Lechner
Bug#912292: Fixed in master?
Hi, On Lintian master (which includes the pending commit) and with default-jdk 2:1.11-70 and javahelper 0.71 installed, I get tests::java-class-format: diff -u t/tests/java-class-format/tags /lcl/lechner/lintian/git/debian/test-out/tests/java-class-format/tags.java-class-format --- t/tests/java-class-format/tags2018-11-05 05:43:01.455447409 -0800 +++ /lcl/lechner/lintian/git/debian/test-out/tests/java-class-format/tags.java-class-format 2018-11-07 07:32:39.427605662 -0800 @@ -1,2 +1,2 @@ -W: libtest-java: incompatible-java-bytecode-format Java12 version (Class format: 56) W: libtest-java: unknown-java-class-version usr/share/java/testa-1.0.jar (org/debian/lintian/TestA.class -> 42) +W: libtest-java: unknown-java-class-version usr/share/java/testb-1.0.jar (org/debian/lintian/TestB.class -> 56) fail tests::java-class-format: output differs! If the existing tags are correct, what would a good version requirement look like for Extra-Build-Depends: in 'desc', please? Thank you! Kind regards, Felix Lechner
Bug#913099: Thank you
Hi, Thank you for sending the patch. We adopted all your changes except for the architecture restriction on 'files-multiarch-foreign-files'. (The issue may not be related to #886163.) Instead, the previous behavior should be restored with this commit: https://salsa.debian.org/lintian/lintian/commit/1b886506df601e2235a7ba0b9ab80e5ee0e8889d#756caf68255acd27da6501c989bfd38778f890e0_5_5 Thank you! Kind regards, Felix Lechner
Bug#913930: lintian: Potentially false-positive public-upstream-key-unusable upstream/signing-key.asc
Hi Pierre-Elliott, Looks like the call to 'gpg --list-packets' failed, but I cannot reproduce the issue. Your report mentioned lintian 2.5.112~bpo9+1 and stable, while the build log was for lintian 2.5.112 on experimental. With which release are you working, please? Thank you! Kind regards, Felix Lechner
Bug#913930: Confirmed for sbuild only
tags 913930 - moreinfo + confirmed found 913930 lintian/2.5.112 thanks Hi, I can reproduce the issue only when using sbuild. I am looking into the possibility that a dependency is missing inside sbuild. Meanwhile, I marked the bug as confirmed. Thank you!
Renaming some Lintian test suites
Hi everyone, I spent some time with Lintian's test suite and would like to propose a few changes: 1. Rename the suite 'tests' to 'uploads' (which is what is being tested). 2. Rename the suite 'scripts' to 'code' (which is what is being tested). 3. Require an explicit 'Suite:' statement in each test description. My overall goal is to curate the test set more aggressively. Tests will be associated more closely with checks by: A. Allowing tests to be arranged in folders other than t/$suite/$testname. (For many tests, that could be t/$check/$testname.) B. As an option, disregarding tags emitted by unrelated checks. (Patch set complete but not submitted.) C. Manually sorting tests by identifying the check they are exercising (or splitting them when appropriate) and enabling the new option described under B. This plan will bring unit testing to Lintian checks. It will also make it easier to write and maintain tests: There will be no more nuisance tags from unrelated checks. When writing new checks you will no longer have to add some of the new tags to existing tests. Converted tests will more or less automatically fulfill the README's plea that "Test cases should be as Lintian-clean as possible except for the tags that they're testing." Perhaps best of all, the fields Test-For: and Test-Against: will be obsolete. They will be inferred automatically from the checks being tested. I will submit merge requests in the next few weeks. This email is only about enabling step A. Please let me know if you have any thoughts. Tx! Kind regards, Felix Lechner
Re: Renaming some Lintian test suites
On Mon, Nov 19, 2018 at 11:45 PM Chris Lamb wrote: > Would that mean we wouldn't have to do the somewhat-ugly > "$checkname-$tagname"? :) > An *extremely* common use case for me at least is to run all checks > for a particular tag. You can still run all *tests* for a particular tag by prefixing "tag:" (and thus without worrying about any of the ugliness you mentioned). The function will be retained. There is, however, a new function to run all tests for a particular *check*. Over time, you may find that more useful. It would naturally make you want to split checks into smaller units. Either way, you can continue to work exactly the way you have. Tx!
Re: Renaming some Lintian test suites
[I am also on the list] > That's neat. Does this tie-in at all with the t/scripts/ > implemented-tags.t "tag coverage" test? My email was only about test selection, i.e. which tests in t/* are being run (the "onlyrun" option to t/runtests). I am not sure that intersects with t/scripts/implemented-tags.t, which I think tests that all tags mentioned in checks/*.desc are also emitted in the corresponding checks/*.pm. > Speaking of which, I guess we should also be tracking our line-by- > line test coverage too? Are you referring to Perl coverage? I have struggled with it but hope to implement it going forward. My new runner retains the functionality, although the present code seems to be slow and unsuitable for parallel processing. I did not previously work much with such a low level of testing. Its utility may be eclipsed by my other plans which would allow, for example, to disable at release time any Lintian check that does not provide at least one test for each tag it emits. Tx!
Re: Renaming some Lintian test suites
On Tue, Nov 20, 2018 at 9:06 AM Chris Lamb wrote: > > Felix Lechner wrote: > > > other plans which would allow, for example, to disable at release time > > any Lintian check that does not provide at least one test for each tag > > it emits. > > What is the use-case for disabling checks like this? Following your blog post [1], which motivated my interest in Lintian, I would like to encourage more developers to submit checks, but they must bundle them with working tests. (That is why my mission is to make testing easier.) Consistent with Lintian's own mission, it seems appropriate to insist that no untested code runs inside it, and while there may be better ways to enforce that, it would automatically ensure that all checks being shipped were tested. Tx! [1] https://chris-lamb.co.uk/posts/how-write-your-first-lintian-check
Some stats from the test suite
Hi, I ran some statistics on the test suite. While not fully accurate, they still show some helpful details. As far as the test suite is concerned, the following 23 tags appear to be completely untested. (I realize the archive provides great validation too.) If you see one of them often, please add a test case: changelog-file: changelog-distribution-does-not-match-changes-file changes-file: changed-by-invalid-for-derivative, checksum-count-mismatch-in-changes-file control-file: rules-requires-root-implicitly, should-specify-rules-requires-root cruft: debian-files-list-in-source, package-uses-deprecated-source-override-location deb-format: tar-errors-from-control debhelper: debhelper-compatibility-level-not-a-number fields: invalid-field-for-derivative, invalid-version-number-for-derivative, priority-extra-is-replaced-by-priority-optional files: package-contains-eslint-config-file, package-contains-npm-ignore-file, package-contains-python-hypothesis-example, udeb-contains-documentation-file menu-format: menu-item-contains-unknown-tag, menu-item-needs-dwww, old-format-menu-file, whitespace-after-continuation-character menus: executable-in-usr-share-docbase, executable-menu-file po-debconf: invalid-potfiles-in Also, some checks emit large numbers of tags and should probably be split into smaller pieces, if possible: 200 files 158 fields 91 scripts 84 cruft 48 changelog-file 45 debhelper 45 menu-format 41 menus 40 shared-libs 39 control-file 39 init.d 38 debconf 38 source-copyright 37 binaries 34 copyright-file 33 rules 29 description 25 changes-file 22 manpages 19 patch-systems 18 systemd 18 testsuite 18 watch-file 15 python 14 apache2 14 java 14 po-debconf The data files are attached for anyone interested in further research. Sorry about any errors. Thank you for reading! Kind regards, Felix Lechner checkstats.csv.gz Description: application/gzip tagstats.csv.gz Description: application/gzip teststats.csv.gz Description: application/gzip
Bug#914271: lintian: Rationale behind hyphen-in-upstream-part-of-debian-changelog-version
Well, I also agree with Josch's well-articulated argument. A merge request to remove the tag is pending (!72). Thank you for bringing this to our attention!
Bug#914271: lintian: Rationale behind hyphen-in-upstream-part-of-debian-changelog-version
> This suggests that you know tools that behave wrongly. Unfortunately, I cannot help. I remember having issues when experimenting with less common version numbers, but that may not have been with dashes. My hope was to build a fence around policy to save a maintainer from potential headaches (which I saw as a precaution more than a cure). Since then, many packages have been so tagged, and none of you have any problems. Turns out no fence was needed. Thank you for following up!
Bug#856128:
Hi, The upstream author of CUPS-PDF recently agreed to publish package signatures for future releases. While I share the sentiment of the reporting party, the specific point regarding CUPS-PDF may be moot. Thank you! Kind regards, Felix Lechner
Bug#915778: lintian.debian.org: broken git repo link in page footers
Hi Niko, I saw it too, but thought that was fixed here: https://salsa.debian.org/lintian/lintian/commit/a716002c5bff418de665aae942ea953e1bfcc715#58d4498662ce139c2b39fc509fdb6fad0cb70ee4_68_68 which is used here: https://salsa.debian.org/lintian/lintian/blob/master/reporting/templates/foot.tmpl Maybe the actual website has not been updated? Kind regards, Felix On Thu, Dec 6, 2018 at 10:09 AM Niko Tyni wrote: > Package: lintian > Severity: minor > > The footer of web pages at https://lintian.debian.org/ has a broken link > to the git repo: > > The source code to Lintian is available under the GNU GPL version 2, > or (at your option) any later version. It can be downloaded from > https://anonscm.debian.org/git/lintian/lintian.git. > > This should presumably be https://salsa.debian.org/lintian/lintian.git > nowadays. > > (BTW it would be nice to have the source to the web site available > so I could have just made an MR or something. Filing a bug against the > lintian package seems a bit weird for this.) > > > Thanks for your work on lintian, it's invaluable to the whole project. > -- > Niko Tyni nt...@debian.org > >
Format of test specifications
Hi, The format for test specifications in 'desc' mixes template fill data (Package-Architecture:) with test options (Output-Format:) and constraints (Test-Architectures:). I would like to split it into three files. * Please note that all test specifications throughout 't/' would be split. * There are no tests currently that use all three sections. As a example, therefore, the default configuration in 't/defaults/desc' would look something like this: desc/template-fill: Author: Debian Lintian Maintainers Section: devel Distribution: unstable Type: native Source-Format: 1.0 Package-Architecture: all Prev-Date: Mon, 01 Jan 1990 00:00:00 +0100 desc/test-options: Skeleton: default Post-Template-Command: post_template Runner: generic.t Builder: builder Sequence: 6000 Profile: debian Options: -I -E Output-Format: EWI Sort: yes Todo: no desc/constraints: Test-Architectures: any I considered and discarded the idea to continue to use one file in a format with multiple sections. When degrees of freedom are allowed (by altering the template input) the information ends up in different places: The template data belongs to a single built package, while constraints apply to a group of tests around the specification. File modification times also matter; changing 'Test-Architectures', should not trigger the rebuilding of packages. If there are no objections, I will probably file merge requests in a few weeks. Please let me know what you think! Kind regards, Felix
Layout of test data
Hi, Based on advice from #perl-help, I would like to move some test data out of 't/'. The latter directory should probably be reserved for Perl tests (*.t) that are ready to run, such as t/scripts [to be renamed t/code] t/harness [internal harness tests not yet merged] The custom test specifications, templates, skeletons, whitelist, defaults and helpers would be moved to 'test/'. The purpose is to separate the preparation of tests from running them. Generated tests would remain in 'debian/test-out/'. If there are no objections, I will probably file merge requests in a few weeks. Please let me know what you think! Kind regards, Felix
Re: Format of test specifications
Chris, On Fri, Dec 7, 2018 at 1:24 PM Chris Lamb wrote: > > Could you elaborate more why? You do mention that changing 'Test- > Architectures' (for example) should not trigger the rebuilding of > packages but is that really a big concern? I mean, I throw away > everything before running any test and it's not excessively slow to do > so. > First of all, it is not urgent. My hope is that the test suite will eventually permutate through several degrees of freedom. The goal is to get as many *test cases* out of the test specifications as possible. That idea was formed in reaction to commit ccb387b4. There, a problem arose when a test specification was filled with 'Package-Architecture: any' while the harness provided 'amd64' (due to a particular implementation of Test-Architectures). The check should have worked either way. Next, please consider that the current defaults for test cases are package format '1.0 (native)' with 'Package-Architecture: all'. That is not representative of the archive at all. As you know from my merge requests, I went on to parametrize many templates. I never submitted branches changing the default package architecture to 'any', because they seemed like half-way solutions. The right way is to permutate for each degree of freedom through all possible values. When one test specification is turned into many test cases, some data changes and some does not. The template fill data and the test options can vary from one test case to another, while the constraints do not. In fact, the constraints are currently stored up one directory. The distinction between fill data and test options, on the other hand, is helpful to avoid confusion. Among other things, it will safely allow the field Package-Architecture to be renamed back to Architecture (hoping to address your request here: https://salsa.debian.org/lintian/lintian/merge_requests/46#note_46510). As for rebuilding, perhaps I am more time sensitive. I run the full suite dozens of times a day and would like to bring it down from six minutes over here to about one (if my experiments hold up). When adding permutations for package architecture and package format alone (and there are additional degrees of freedom), the 670~ test specifications turn into 6000 test cases, or more. Rebuilding is not a problem with a single test specification or with hand edits, but rather when such processes are automated. That being said, I am not set one way or another. Please let's revisit this proposal when my 'variations' branch is ready for your consideration.
Bug#916087: lintian: "exec failed: Text file busy" when running tests by tag
This is confirmed. I saw it earlier and thought it was fixed. Will be back shortly.
Bug#916087: lintian: "exec failed: Text file busy" when running tests by tag
Chris, > I think your recent commits have introduced a regression in the test > harness: I am stumped. If you urgently require the tag functionality (I know you use it often), please reverse !88 and !82, in that order. I do have a better fix on the way, however, and would appreciate a day to make sure it is error-free.
Bug#916087: lintian: "exec failed: Text file busy" when running tests by tag
Chris,
On Sun, Dec 9, 2018 at 1:57 PM Chris Lamb wrote:
> I think your recent commits have introduced a regression in the test
> harness:
They sure did. (Although they worked fine in my new runner.)
> exec failed: Text file busy at
> /home/lamby/git/debian/lintian/lintian/lib/Lintian/Command.pm line 274.
>at /home/lamby/git/debian/lintian/lintian/lib/Lintian/Command.pm line 274.
>at t/runtests line 482.
Using plain qx{}, this message turns into "Can't exec
"/lcl/lechner/lintian/git/debian/test-out/tests/scripts-maintainer-general/post_template":
Text file busy at t/runtests line 482."
After substantial investigation (and consultation with #perl-help), I
believe the close function in
`lib/Test/Lintian/Templates.pm::fill_template did not close the
generated file 'post_template'.
https://salsa.debian.org/lintian/lintian/blob/master/lib/Test/Lintian/Templates.pm#L273
When run immediately afterward, the command 'lsof' shows the file
post_template (and other files generated in that function) as open
even after the call to close(). The process ID matched that of the
thread, so no other thread kept it open. ($$ is the number before
COMMAND.)
$ debian/rules runtests onlyrun=tag:uses-dpkg-database-directly
running tests
mkdir -p "/lcl/lechner/lintian/git/debian/test-out"
t/runtests -k t "/lcl/lechner/lintian/git/debian/test-out"
tag:uses-dpkg-database-directly
ENV[PATH]=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Running 3 tests.
error tests::scripts-maintainer-general: 8061: COMMAND
PIDUSER FD TYPE DEVICE SIZE/OFFNODE NAME
Test\x20worker\x20-\x20p 8061 lechner8w REG 253,0 122
1050553
/lcl/lechner/lintian/git/debian/test-out/tests/scripts-maintainer-general/post_template
error tests::legacy-maintainer-scripts: 8063: COMMAND
PIDUSER FD TYPE DEVICE SIZE/OFFNODE NAME
Test\x20worker\x20-\x20p 8063 lechner8w REG 253,0 122
1050557
/lcl/lechner/lintian/git/debian/test-out/tests/legacy-maintainer-scripts/post_template
pass tests::files-uses-dpkg-database-directly
Failed tests (2)
tests::scripts-maintainer-general
tests::legacy-maintainer-scripts
make: *** [debian/rules:51: runtests] Error 1
A solution was proposed as merge request !89. It reuses skeletons as
suite-based defaults. The watch file is now provided from there. For
more information, please see the commit messages.
The active template idea was scrapped. The current scheme is probably better.
> ie. Only when running tests by tag name, even if it's the same test.
While I also observed this, I was unable to tie the "tag" selector to
the error. I even backported a new test selection mechanism; the error
remained. With a solution pending, the relationship was not
investigated further.
Kind regards,
Felix
Bug#916207: lintian: debian-watch-does-not-check-gpg-signature certainty considered annoying
Hi Scott, Many people find the tag cumbersome, and some people think it should go away. At the same time, upstream sources are more trustworthy when verified; and that is in the project's overall interest. Could your concern be resolved by better naming? I process the tag name (it has already been renamed once [1]) as "debian-watch-does-not-check-A-gpg-signature." Without a signature that is an objective fact. On Tue, Dec 11, 2018 at 5:18 AM Scott Kitterman wrote: > As designed, debian-watch-does-not-check-gpg-signature does not check if > upstream provides a GPG signature to make checking it possible. When I process the name as "debian-watch-does-not-check-THE-gpg-signature"---which is maybe the way you are reading it---it means the same as 'debian-watch-could-verify-download' but the tag does not behave like it. My suggestion would be to rename the tag to 'built-from-unverified-sources' or similar. What do you think? > when if there's no upstream signature, it's not at all a problem > the maintainer can fix. "Certainty: possible" seems much more reasonable to > me. The tag would continue to be of Certainty: certain. Kind regards, Felix [1] https://salsa.debian.org/lintian/lintian/commit/0cbebd4ba0b2a067383616e18981eeb9de5d7df2
Bug#916444: lintian: FTBFS on master ("pod2man: unable to format lib/Test/State.pm")
I think it was this commit: https://salsa.debian.org/lintian/lintian/commit/ea1357ead68e8f2a5b1ce8deb5e98178eb27b812 Please see this MR for a resolution: https://salsa.debian.org/lintian/lintian/merge_requests/100
Bug#917097: lintian: Build fails with "Can't locate Test/Lintian/Harness.pm in @INC"
Please see merge request !107.
Bug#917752: lintian: FTBFS: tests failed
Chris,
On Sat, Dec 29, 2018 at 3:23 PM Chris Lamb wrote:
>
> > > +I: changes-upstream-signature-not-missing source:
> public-upstream-key-unusable upstream/signing-key.asc cannot be processed
>
> Felix, not sure your MR/branch handles this one?
>
This looks like #913930. I have only seen it in sbuild, but not otherwise.
> > > -W: debhelper-compat-experimental source:
> package-needs-versioned-debhelper-build-depends 12
>
> I assume it addresses this one in an ongoing/sustainable manner.
>
This tag should no longer be issued. My builder automatically supplies the
correct dependency via:
desc: Dh-Compat-Level: 12
Default-Build-Depends: debhelper (>= {$dh_compat_level}~)
Because I run the test suite often, I am surprised I did not see it until
now. The tag will be removed with this merge request:
https://salsa.debian.org/lintian/lintian/merge_requests/112
> > -W: manpages-general: manpage-has-errors-from-man
> usr/share/man/man1/test.1p.gz 14: warning: macro `dep' not defined
> (possibly missing space after `de')
>
> I don't recall seeing one for these.
>
Like you, I have not seen this one. This test was not changed recently;
neither was the associated check 'manpages.pm'.
Bug#917752: lintian: FTBFS: tests failed
On Sun, Dec 30, 2018 at 3:06 PM Chris Lamb wrote: > > > > +I: changes-upstream-signature-not-missing source: > > > public-upstream-key-unusable upstream/signing-key.asc cannot be > > > processed > > > > This looks like #913930. I have only seen it in sbuild, but not otherwise. > > Interesting. Well, given that it is causing FTBFS I am raising the > severity of that and marking as a blocker. I am looking into this with some urgency. > > > -W: manpages-general: manpage-has-errors-from-man > > > usr/share/man/man1/test.1p.gz 14: warning: macro `dep' not defined > […] > > Like you, I have not seen this one. This test was not changed recently; > > neither was the associated check 'manpages.pm'. > > Mm, this appears to be caused by the recent groff 1.22.4-1 upload to > unstable. Cloning, etc. I think you are right. I upgraded 'groff-base' this morning and then starting seeing the error.
Bug#917752: lintian: FTBFS: tests failed
On Sun, Dec 30, 2018 at 3:06 PM Chris Lamb wrote: > > > > -W: manpages-general: manpage-has-errors-from-man > > > usr/share/man/man1/test.1p.gz 14: warning: macro `dep' not defined > […] > > Like you, I have not seen this one. This test was not changed recently; > > neither was the associated check 'manpages.pm'. > > Mm, this appears to be caused by the recent groff 1.22.4-1 upload to > unstable. Cloning, etc. Please see this merge request for a solution: https://salsa.debian.org/lintian/lintian/merge_requests/113
Bug#917844: Fixed
Hi, I did not see the separate report at first and commented on #917752. For a fix, please see: https://salsa.debian.org/lintian/lintian/merge_requests/113 Felix Lechner
Bug#913930: Confirmed for sbuild only
Hi Harlan! On Thu, Dec 27, 2018 at 9:09 PM Harlan Lieberman-Berg wrote: > > Just as one more datapoint for you, I see the same thing with > certbot-dns-ovh with lintian 2.5.118 and sbuild 0.77.1-2. Thank you for writing! Your package builds much faster than lxc. The problem was fixed in https://salsa.debian.org/lintian/lintian/merge_requests/114 Kind regards Felix Lechner
Bug#917752: lintian: FTBFS: tests failed
This bug is fixed. It can be marked as pending when the merge requests for the two blocking bugs are accepted.
Re: Lots of zombie processes on lindsay/lintian.debian.org
Perhaps this relates to problems I have been having recently with multi-threading/spawning in Perl. The test runner uses multiple processes and required modifications such as commit dca6831a and the resolution to bug #916087 to work properly (or maybe, as it turns out, not so properly).
Meaning of 'suite' in the Lintian test suites
Hi,
Unless anyone uses the 'suite' paradigm to run tests for *.changes,
*.dsc and *.deb separately, I would like to change the meaning of
'suite' to correspond to the following categories:
code-quality: Currently known as 'scripts'.
lintian-output: All the tests presently in 'changes', 'debs', 'source'
and 'tests'.
harness: A series of forthcoming internal tests.
As an underlying reason, I would like to group most tests by Lintian
check. (There are some exceptions, such as generic-dh-make-2008; other
tests, like runtests-todo, will find a better home in suite 'harness.)
The current layout forces too many tests into the suite 'tests' (which
is also awkwardly named) and makes a meaningful reorganization
impossible. I envision a flexible layout in which test directories are
defined by the presence of a test specification ('desc').
The lost functionality may reappear in the future as an 'onlyrun'
filter for Lintian input files with a particular format. That would
treat the suites 'tests' and 'changes' similarly, as they operate on
the same type of file.
Best regards,
Felix Lechner
Bug#918817: lintian: Returns with exit code of 0 (zero) on failed tests
Please see https://salsa.debian.org/lintian/lintian/merge_requests/121 although I cannot explain the exit code '2' right now.
Bug#919096: lintian: autopkgtest regression in 2.5.121
Please see: https://salsa.debian.org/lintian/lintian/merge_requests/126
Bug#919531: lintian: "Could not determine what you meant by: tag:foo"
Please see this MR for a fix: https://salsa.debian.org/lintian/lintian/merge_requests/129
Bug#920691: lintian gets stuck collecting info after failed objdump-info
I think this is related to Perl update 5.28.1-3. Shortly afterward, I had the problem raised in #916087, which also showed up with IO::Async. Files did not close properly. It seemed processes were spawned differently. Copies of open file descriptors survived in spawned processes, and I was unable to close files open for writing. Perhaps the note helps someone.
Bug#920691: lintian gets stuck collecting info after failed objdump-info
Maybe the pending Perl commit 672eb451 will help? Details in #916313.
Bug#921112: Convert Lintian's internal warnings into W: tags
Package: lintian Some tests check directory transversal issues. Those arise when control fields contain relative paths. The tests look for Lintian warnings. They look like this: warning: tainted [...] package '...', skipping The warnings are emitted by lib/Lintian/ProcessablePool.pm. While they are not printed by any Lintian 'check', they should at least look like 'W:' tags. That way they can be processed further by programs scanning Lintian's output. The affected tests are: t/tags/debs/control-field-traversal-4 t/tags/source/control-field-traversal-1 t/tags/source/control-field-traversal-3
Bug#920691: lintian gets stuck collecting info after failed objdump-info
On Mon, Feb 4, 2019 at 5:03 AM Raphael Hertzog wrote: > Thanks for the notice, I tried with that version of Perl but the problem I > reported is still present. So it seems unrelated. Here is a merge request that seems to fix the issue by reverting: https://salsa.debian.org/lintian/lintian/merge_requests/139 I am only making it available in case downgrading is not an option. The merge request should not be accepted. Still looking for the actual bug.
Bug#920691: lintian gets stuck collecting info after failed objdump-info
On Mon, Feb 4, 2019 at 5:03 AM Raphael Hertzog wrote: > Thanks for the notice, I tried with that version of Perl but the problem I > reported is still present. So it seems unrelated. This MR fixes the hang here: https://salsa.debian.org/lintian/lintian/merge_requests/140
Bug#922737: lintian rarely hangs
Hi Helmut, I have also had this problem since December and hoped no one would notice. Personally, I think it is related to Perl 5.28.1-3, but I am not sure. We also recently added a parallel collection that may have a race condition. I will look at it in the coming days. Thank you for your diligence in reporting this. Kind regards, Felix Lechner On Tue, Feb 19, 2019 at 9:15 PM Helmut Grohne wrote: > > Package: lintian > Version: 2.6.0 > Severity: important > User: helm...@debian.org > Usertags: rebootstrap > > I use lintian to detect wrongly cross built packages. In this setup, > lintian is run by sbuild inside the (unstable) schroot after the build. > I pass "-T > binary-from-other-architecture,triplet-dir-and-architecture-mismatch" to > lintian and it all works fine ... most of the time. > > In roughly 1/2000 builds, lintian hangs. Now the bad part is that I have > little details on what is going on here. > > * A process list shows just "lintian" without any command line flags. > * lintian has a zombie chiled called "[rm]". > * lintian has the following file descriptors: >+ 0 is /dev/null inherited from the sbuild invocation >+ 1 and 2 are the same writable pipe (presumably to sbuild) >+ 3 is /dev/null (inside the schroot) for writing >+ 4 and 5 are the read and write ends of a pipe >+ 6 is /usr/share/perl5/Net/DNS/Resolver/Base.pm inside the schroot > * It already happend with 2.6.0 and continues to happen with 2.7.0. > * Attaching the hanging lintian with strace only yields >restart_syscall. > > Given the 1/2000 builds nature, it takes a while (days) to reproduce. > I'll leave one such hanging process around for a while in case you have > ideas on how to debug this. > > Helmut >
Bug#922737: lintian rarely hangs
On Tue, Feb 19, 2019 at 9:15 PM Helmut Grohne wrote: > > In roughly 1/2000 builds, lintian hangs. I submitted a merge request in hope it will solve your issue: https://salsa.debian.org/lintian/lintian/merge_requests/154
Bug#903399: Fix makes tag untestable
The fix for this bug makes the tag 'old-python-version-field'
untestable. When the version for old-python equals ancient-python,
there is no way to reach the second block:
if (versions_lte($v, $ancient)) {
tag 'ancient-python-version-field', $field, $v;
} elsif (versions_lte($v, $old)) {
tag 'old-python-version-field', $field, $v;
The tags cannot be combined. They have different severities. I can
fake a test that swaps an actual 'ancient' tag for an 'old' tag, but
it would be a last resort. The test suite has almost full tag
coverage. Can we please find another solution, so that this tag is
testable, too?
Bug#903399: Fix makes tag untestable
On Thu, Feb 21, 2019 at 11:51 AM Chris Lamb wrote: > > Not sure how we can get around this. Have you implemented similar > things for other tags...? So far I have not faked a test, but sed will do a great job. Could the Python minor number differ between the tags?
Bug#903399: Fix makes tag untestable
On Thu, Feb 21, 2019 at 11:51 AM Chris Lamb wrote: > Not sure how we can get around this. Have you implemented similar > things for other tags...? The best alternative would be for the test to read the the value from data/python/versions when constructing the test package. That way the test fails when the value is changed. We can then remove the sed script. Perhaps the sed script could even check before running if the versions are the same. Then the whole thing would be on autopilot.
Updating runtime dependencies on lindsay.d.o
Hi, Following a suggestion from Niels and others, I filed this MR to update the runtime dependencies on lindsay.d.o: https://salsa.debian.org/lechner-guest/debian.org/merge_requests/1 Kind regards Felix
Bug#920763: lintian: orig-tarball-missing-upstream-signature interacts poorly with mode=git,pgpmode=gittag
Hi Daniel, On Wed, Feb 27, 2019 at 12:03 PM Daniel Kahn Gillmor wrote: > > I guess if we wanted some version of lintian to be able to check on the > git tag, we need to have some sort of export (git shallow > something-or-other?) that could be included in debian/ to recreate a git > repo that would be sufficient to verify the contents of the files and > confirm the git signature. I wrote a Debian tool to create a shipping manifest with file-based hashes. Would it help to include that at the time of packaging? If the manifest is signed, we could do away with tarball signatures. Felix
Bug#923696: lintian: Bad examples in Lintian::Tutorial::TestSuite
Hi Xavier, On Sun, Mar 3, 2019 at 2:27 PM Xavier Guimard wrote: > > To launch part of the tests, Lintian::Tutorial::Testsuite proposes to > use either: > > $ debian/rules runtests onlyrun=tag:$tag > $ t/bin/runtests --dump-logs -k t debian/test-out tag:$tag > > None of these examples work (all test launched or error). Looking at > source code, I ran with success: > > $ t/bin/runtests --unattended --work-dir=debian/test-out --onlyrun > tag:$tag t > > Same for other examples ($check,...) > Thanks for reporting this. I saw your note on #debian-qa, but you were gone when I got there. I will work on the documentation very soon. In most cases, you should be able to drop the work-dir and and the test base 't', like so t/bin/runtests --onlyrun=tag:$tag -k will run all selected tests even if the code quality scripts or the internal harness tests have failed. --unattended will never prompt for user input, for example to offer to re-calibrate tests when new tags appeared or some disappeared.
Bug#920763: lintian: orig-tarball-missing-upstream-signature interacts poorly with mode=git,pgpmode=gittag
Hi Daniel, On Fri, Mar 1, 2019 at 4:12 AM Daniel Kahn Gillmor wrote: > > > I think what you're describing takes aim a different problem, so i don't > think it addresses the underlying concern here. I believe it solves your problem, just not the way you expect. As you point out, the current approach of validating different upstream signature formats is the point of this bug. You list two, but as you note there could be more: > At issue in #920763 is our attempt to capture verified *upstream* > cryptographic signatures. There are (at least) two common practices for > such signatures by upstreams across the free software ecosystem: > > a) detached signatures over tarballs > b) signed git tags With source format 3.0 (git) that logic even found a way into the packaging system. Let's flip it around for a moment: Why not validate upstream signatures when the package is built? My shipping manifest offers an "origin statement" to include git or tarball signatures (even multiple) that tie the original source (in any format) to the list of file hashes. Signed by a Debian maintainer, the manifest provides a trust path. To pick up on Chris's comment, the validation happens when our tools can be reasonably expected to have network access (or the maintainer has a git repo nearby). > aiui, your tool is > designed to something operated by the debian developer/maintainer. > That cannot be an obstacle. You just suggested it earlier in this thread: I guess if we wanted some version of lintian to be able to check on the > git tag, we need to have some sort of export (git shallow > something-or-other?) that could be included in debian/ to recreate a git > repo that would be sufficient to verify the contents of the files and > confirm the git signature. > Yours were the very words that made me believe I could help. :) A signed manifest is less complex, more universal, and would likely take up less space. As an aside, maintainer involvement is always required when repacking for DFSG-compliance. A manifest with an origin statement would handle that case with ease. > Today, we have pretty decent tooling to handle (a). we even distribute> upstream tarball signatures directly when we have them: > (e.g. https://mirrors.edge.kernel.org/debian/pool/main/k/knot/knot_2.6.8.orig.tar.xz > can be verified against the upstream signer's key by fetching > https://mirrors.edge.kernel.org/debian/pool/main/k/knot/knot_2.6.8.orig.tar.xz.asc ) > > So for (a), we're effectively assembling an archive of all of the > upstream signatures that we know about, which could be used later for > verifying provenance of the source code used. > > What we don't have is tooling to handle or aggregate such a verifiable > archive for those upstream signatures that fall under (b). Do you think > the tool you're describing would help with that? I believe my tool covers a) and b) as well as any other past, current, or future authentication method for upstream sources. As a side note, the signed manifest could even be the sole item uploaded for a new version if it also includes a list of URLs where the sources may be found. Right now, I call it the Light Upload Format. Kind regards, Felix
Bug#926334: lintian: Does the SafeSEH check make sense for Mono/.NET DLLs?
Control: tags 926334 moreinfo On Wed, Apr 3, 2019 at 9:30 AM Hilko Bengen wrote: > > In this > context, looking for the x86-specific SafeSEH feature does not make much > sense, does it? I do not know enough about Mono to say whether your DLLs are vulnerable to manipulation of the Structured Exception Handler. Why don't you just override the tag if you are sure?
Bug#926409: lintian: autopkgtest takes very long to finish
On Thu, Apr 4, 2019 at 10:42 AM Chris Lamb wrote: > > * I'm not sure *how* we can speed up the tests. I mean, they all >essentially involve building Debian packages with all the usual >debhelper calls, etc. Speeding *this* up is somewhat out-of-scope >of this Lintian wishlist issue, alas. > > However, perhaps Felix has some input here as he has been doing a lot > of work on the test suite recently? About 95% of the time is spent building packages, even though they almost never change. The tests would run much faster if we shipped pre-built packages. One way to accomplish that would be to package the tests separately.
Bug#926409: lintian: autopkgtest takes very long to finish
On Thu, Apr 4, 2019 at 11:24 AM Balint Reczey wrote: > > One criterion that came to my mind is filtering by severity, including > errors for sure, but not pedantic ones. The pedantic setting may become the default for tests, but very little time is spent running Lintian. Things may speed up a little if we run only the checks being tested (using the '-C' option), but that won't make much of a difference in the overall run time of the tests, which is primarily spent building packages.
Bug#926409: lintian: autopkgtest takes very long to finish
On Thu, Apr 4, 2019 at 12:19 PM Chris Lamb wrote: > > Felix Lechner wrote: > > > About 95% of the time is spent building packages, even though they > > almost never change. The tests would run much faster if we shipped > > pre-built packages. > > Another way to accomplish this could be that we could cache/store them > across autopkgtest runs? IIRC (at least) Gitlab supports caching stuff > like this. > Upon reflection, each test should be packaged separately. That way I no longer have to worry about using chroot to build tests with potentially conflicting build dependencies.
Bug#926823: executable-not-elf-or-script should consider PE binaries
On Wed, Apr 10, 2019 at 2:33 PM Michael Biebl wrote: > > systemd ships EFI binaries which are PE executables. > > usr/lib/systemd/boot/efi/linuxia32.efi.stub [amd64, i386] > usr/lib/systemd/boot/efi/linuxx64.efi.stub [amd64, i386] > usr/lib/systemd/boot/efi/systemd-bootia32.efi [amd64, i386] > usr/lib/systemd/boot/efi/systemd-bootx64.efi [amd64, i386] > > I wonder whether executable-not-elf-or-script should be made aware of PE > executables and not warn about them. Does systemd-boot require the executable bits to be set on these files?
Bug#926823: executable-not-elf-or-script should consider PE binaries
On Wed, Apr 10, 2019 at 4:16 PM Michael Biebl wrote: > > Those bits are set by ld respectively objcopy when the binaries are > generated. Are you implying that ld/objcopy should not do that? No, you may well need it. It's just that the lintian tag is not triggered when the bit is off.
Bug#929430: marked as pending in lintian
My apologies for the remarks about Ubuntu. I introduced this error with commit 546c0d36. With some luck, it will be fixed with this merge request: https://salsa.debian.org/lintian/lintian/merge_requests/203
Bug#930487: lintian: speed up test suite CI
On Thu, Jun 13, 2019 at 8:51 AM Dmitry Bogatov wrote: > > It would be great to ... avoid rebuiling package at every job run. I would be nice to see how other projects deal with this issue. There is some support for uploading the test packages separately. [1] For Lintian, however, I would prefer to upload the test packages separately to Debian's regular build infrastructure. The test packages can and do have conflicting build dependencies and architectures. These conflicts are not addressed currently, and may require separate chroot build environments. It would be difficult to implement even in a single bulk package. Debian's infrastructure, on the other hand, is designed to build the packages. At the same time, separate uploads would place an undue burden on the archive's namespace and on the NEW queue. There would also be delays for new tags, as Lintian may at some point require that tags are tested. All test packages would have to be in the archive before the lintian source is uploaded. Right now, my favorite solution would be for the archive to offer dependent namespaces for source packages (such as lintian/...). Such internal packages could be uploaded separately and would not have to go through the NEW queue. Outside packages could not depend on them, but they would be installed if their source package requires them. This idea will likely generate much opposition. Let me just say that I am not sure my suggestion is worth the effort, or useful for anyone else. Kind regards, Felix [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926409#42
Bug#930487: lintian: speed up test suite CI
On Mon, Jun 17, 2019 at 4:03 PM Chris Lamb wrote: > > Chris Lamb wrote: > > The naïve solution here might be to save & restore debian/test-out > between runs. I do not think that will work for very long, although there is a better chance if we separate the expected tags from the artifact directory. (The expected tags change relatively often a new checks are implemented or old ones are tweaked.) > > There's currently no magical command in the > fancy test runner of yours that will rebuild any missing or otherwise > changed test packages is there…? We used filesystem timestamps for a while, but the standard resolution (1 sec) was not granular enough. AFAIR, we now generate everything every time. We instead split the generation of test packages from the test runs, although they currently just run consecutively. We could probably skip the generation of test packages if they are already present and nothing in t/ has changed. > In other > words, are we barking up the wrong tree here and what we need to do is > use different GitLab CI stage altogether and pass "artifacts" around > instead? > > https://docs.gitlab.com/ee/ci/caching/index.html#cache-vs-artifacts Artifacts may work, but uploading them separately without a dependency scheme seems to invite other problems. Also, your local build architecture and environment—which may figure into the artifacts you upload—may not match what the the runner needs. (I am thinking about stable or ubuntu-devel.)
Bug#930679: Please add overridable tag for not using dh sequencer
On Tue, Jun 18, 2019 at 8:00 AM Chris Lamb wrote: > > tags 930679 + moreinfo > thanks > > Sam Hartman wrote: > > > It would be even better to detect some of the adequate justifications > > automatically like Haskell packages. I think Sam meant that some circumstances should always prevent the issuance of the tag, so developers are not burdened with the override. Apparently, Haskell packages do not use dh but cabal. [1] [1] https://wiki.debian.org/Haskell/CollabMaint/GettingStarted#Debianize_the_Sources
Bug#930487: lintian: speed up test suite CI
Hi Dmitry, On Thu, Jul 4, 2019 at 10:41 AM Dmitry Bogatov wrote: > > It feels that build system for test suite is overconstrained now > (rebuilds more then necessary), and I consider to make some experiments > with Shake[1]. Should the experiments succeed, will they be accepted? The large majority of test packages is built using 'dpkg-buildpackage'. Do you plan to rewrite it? I looked into using golang for the test suite but, for the things we are doing, Perl is quite fast. It's also mature and available everywhere. How does Shake compare? Kind regards, Felix
Bug#930487: lintian: speed up test suite CI
Hi Chris, On Thu, Jul 4, 2019 at 12:31 PM Chris Lamb wrote: > > I'm very much in favour of us exhausting all caching opportunies, both > on our CI system and locally, Would it help to separate the build product for each test package, which will presumably be cached, from the test output (tags.actual, tagdiff and friends)? Kind regards Felix
Bug#924449: lintian: Periodic "out of disk space" errors from lindsay.d.o
Hi François, On Fri, Jul 5, 2019 at 2:03 AM Francois Gouget wrote: > > I'm also running into "out of disk space" errors caused by Lintian. > These happen when I check a 240 MB package Would you please provide a link to this package? Kind regards Felix
Bug#929729: lintian: \n in filenames cause "md5sum: ...: No such file or directory"
Hi Chris,
On Sat, Jul 6, 2019 at 7:21 PM Chris Lamb wrote:
>
> The following "fixes" it:
>
> diff --git a/collection/md5sums b/collection/md5sums
> index 970eb0656..e8006ab10 100755
> --- a/collection/md5sums
> +++ b/collection/md5sums
> @@ -53,7 +53,8 @@ sub collect {
>
> foreach my $file ($info->sorted_index) {
> next unless $file->is_file;
> +$file =~ s,\\n,\n,g;
> printf {$opts{pipe_in}} "%s\0", $file;
> }
>
> close($opts{pipe_in});
> diff --git a/lib/Lintian/Path.pm b/lib/Lintian/Path.pm
> index 108a18ede..fb8048ed5 100644
> --- a/lib/Lintian/Path.pm
> +++ b/lib/Lintian/Path.pm
> @@ -643,6 +643,7 @@ sub open {
> $layer //= '';
> my $opener = sub {
> use autodie qw(open);
> +$_[0] =~ s,\\n,\n,g;
> open(my $fd, "<${layer}", $_[0]);
> return $fd;
> };
>
> … but this is clearly hacking around the problem and is likely
> incomplete. Storing the newline literally in the internal structure
> breaks other things that I can't immediately see/fix.
I agree. I rewrote the collections using IO::Async (coming once buster
is out) and can look at the newline issue over the next few days, if
you are okay with that.
Kind regards,
Felix
Bug#930487: lintian: speed up test suite CI
Hi Dmitry, On Sat, Jul 6, 2019 at 11:27 PM Dmitry Bogatov wrote: > > > I think the most common use-case is that I make some change — possibly > > extremely minor — in, say, checks/foo.pm and I want to re-run the > > testsuite to check that I've fixed whatever false-positive or edge-case > > in a tag that I am in the process of implementing. We should optimise > > for kind of pattern. What do you think? In that scenario, I usually restrict the run with "--onlyrun=check:manpages" (after editing checks/manpages.pm). You can also use the selectors 'test:' or 'tag:'. > Ideally, I want test suite automatically detect: > > * test directory edited, test.deb needs to be rebuilt > + I do not want re-run perl-critic and perltidy checks aganist files, >that were not changed I have not found a way to implement that. An incremental builder I wrote based on file modification times (in lib/Test/StagedFileProducer.pm) cannot tell the difference between two files that were built within one second of another. That is the granularity of Linux filesystems. The templating mechanism relies on many intermediate build products. There should be a way to rebuild a test case if any of the inputs have changed, but I haven't found it. Patches are welcome. > In short, I want test suite to be dependable build system from source > files and test files into tarball of test logs. (~950 files or so) I think it's more or less dependable. Our issue is speed. You can find logs for each test case in ./debian/test-out/.../log. > Right now it feels like build system written in Make -- undercontrained > in one cases (you can easily get stalled results), overconstrained in > another cases (you build more then necessary -- perlcritic tests, for > example). I think the test suite builds exactly what is necessary. It just takes a long time. :) Perlcritic (or more often perltidy) is something we impose on ourselves. There are maddening moments, particularly when the software corrects itself, but on balance I am in favor. > To get feeling what is perfect (in sense of dependencies correctness) > build system, take a look at `tup'[1]. Read the tutorial, it is worthy > reading. How does 'tup' deal with the timestamp granularity? Is that solved with a 'directed acyclic graph (DAG)'? > That is why I talk about Shake -- it is more complicated, compared to > tup, but it supports dynamic (monadic) rules, so previous example with > `foo.tar' is basic example of Shake. Perl is a generalized programming language (and Debian runs on it). Everyone can contribute. I think the best path forward is to try caching, as Chris suggested. If that does not work, we should consider building the test packages separately. Thank you for your interest in the Lintian test suite. The long build times bother many people. I would very much like to reduce them.
Bug#931632: lintian: Testsuite hangs in/around "debian/test-out/tags/checks/version-substvars/legacy-etcfiles"
Hi Chris, On Mon, Jul 8, 2019 at 8:10 AM Chris Lamb wrote: > > Nothing immediately jumps out but I have attached it in case you see > something. At first glance, that build looks fine. Are you sure parallel building is off? If you are in a hurry, you could replace PAR_ARGS with '-j 1' after these two lines in d/rules: @echo building test packages t/bin/build-test-packages \ to find the offending test (and log). It seems dpkg-buildpackage or friends have changed, or they return different error codes.
Bug#931632: lintian: Testsuite hangs in/around "debian/test-out/tags/checks/version-substvars/legacy-etcfiles"
Hi Chris, On Mon, Jul 8, 2019 at 7:06 AM Chris Lamb wrote: > > Any ideas? Just off the cuff: Do you see anything interesting in ./debian/test-out/tags/checks/version-substvars/legacy-etcfiles/log? > This is blocking me from doing an "interesting" upload > hence setting severity to important and X-Debbugs-CCing you directly. You are always welcome to copy me directly.
Bug#929729: lintian: \n in filenames cause "md5sum: ...: No such file or directory"
On Sun, Jul 7, 2019 at 7:33 AM Chris Lamb wrote: > After a cursory review of filename handling in Lintian's index files I can think of three possible solutions: 1. Use String::Escape in both directions to make sure the transformation is reversible. (It currently isn't.) 2. Use Base64 to encode file names in the index. 3. Use an embedded DB such as SQLite in collections. I am happy to contribute patches if we can agree on a way forward. > Sure thing. (I wonder whether we should also check for (at least) \t > and possibly even *invalid* unicode characters; those are a great way > to make programs blow up.) Since filenames are arbitrary byte sequences that serve as valid identifiers in the file system, I am not sure it makes sense to impose UTF-8 validation in Lintian.
Bug#929729: lintian: \n in filenames cause "md5sum: ...: No such file or directory"
Hi Chris, On Mon, Jul 8, 2019 at 12:42 PM Chris Lamb wrote: > > Do we need any of these techniques? Can we decree that the index files > are escaped or unescaped (I'd be +1 on the latter, mind) The index files seem to be inspired by the 't' option in tar. My sense is that we need more encoding rather than less to preserve the meaning of whitespace, and especially newlines, in those files. I do not think we can leave the filenames unescaped, if that is what you are suggesting. > and then > adjust all the consumer/producers of that data to reflect that? The > current situation as I understand it is that some assume the former, > some the latter. I believe there is only one of each. Please let me know if you found others. This is the producer: https://salsa.debian.org/lintian/lintian/blob/master/collection/unpacked#L96-100 and this is the consumer: https://salsa.debian.org/lintian/lintian/blob/master/lib/Lintian/Collect/Package.pm#L518 which uses the subroutine 'dequote_name' from here: https://salsa.debian.org/lintian/lintian/blob/master/lib/Lintian/Util.pm#L775-795
Bug#929729: lintian: \n in filenames cause "md5sum: ...: No such file or directory"
Hi Russ, On Mon, Jul 8, 2019 at 12:50 PM Russ Allbery wrote: > > Policy 10.10: Thank you for the pointer to policy. > The name of the files installed by binary packages in the system PATH > (namely /bin, /sbin, /usr/bin, /usr/sbin and /usr/games) must be > encoded in ASCII. That policy appears to be enforced by checks/files.pm. It reads like the description for the tag 'file-name-in-PATH-is-not-ASCII'. > The name of the files and directories installed by binary packages > outside the system PATH must be encoded in UTF-8 and should be > restricted to ASCII when it is possible to do so. And that reads like the tag 'file-name-is-not-valid-UTF-8'. Kind regards Felix
Bug#929729: lintian: \n in filenames cause "md5sum: ...: No such file or directory"
On Mon, Jul 8, 2019 at 2:35 PM Russ Allbery wrote: > > I see that what you're > trying to do is get the data deep enough into Lintian so that you can > issue appropriate tags, and the problem is with the data representation in > advance of tag processing, for which this isn't super-relevant. The policy reference was very helpful. Thank you.
Bug#931632: lintian: Testsuite hangs in/around "debian/test-out/tags/checks/version-substvars/legacy-etcfiles"
On Mon, Jul 8, 2019 at 7:06 AM Chris Lamb wrote: > > I can't seem to get the build > process to complete in the testsuite: I am unable to reproduce this error using schroot and 'DEB_BUILD_OPTIONS=parallel=1 debuild'. Looking at your log, however, I did see this: Runner died for debian/test-out/tags/checks/binaries/binaries-general: cd debian/test-out/tags/checks/binaries/binaries-general; make --trace DEFAULT_DH_COMPAT=12 failed at t/bin/build-test-packages line 375. at t/bin/build-test-packages line 318. Will you please post debian/test-out/tags/checks/binaries/binaries-general/log? Kind regards Felix
Bug#931632: lintian: Testsuite hangs in/around "debian/test-out/tags/checks/version-substvars/legacy-etcfiles"
Hi Chris, On Mon, Jul 8, 2019 at 6:46 PM Chris Lamb wrote: > > (dh_dwz related...) The build is controlled by a Makefile. To debug, please change into ./debian/test-out/tags/checks/binaries/binaries-general and issue 'make'. Kind regards, Felix
Bug#931632: lintian: Testsuite hangs in/around "debian/test-out/tags/checks/version-substvars/legacy-etcfiles"
Also, can this bug be reassigned or closed?
Bug#931632: lintian: Testsuite hangs in/around "debian/test-out/tags/checks/version-substvars/legacy-etcfiles"
Please take a look at the following commit. It solved a similar issue in two other tests. Perhaps you find it helpful. https://salsa.debian.org/lintian/lintian/commit/d1d7acdb7ee124b6f59def18e5cfae9cd7e3592d On Tue, Jul 9, 2019 at 12:59 PM Chris Lamb wrote: > Hi Felix, > > > Also, can this bug be reassigned or closed? > > I'm a bit lost. Reassigned? Or closed? Did you mean to send this to > this particular bug? > > I mean, I am still in the process of debugging this (actual) issue as > per your instructions here: > > https://bugs.debian.org/931632#40 > > (Update soon...) > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org 🍥 chris-lamb.co.uk >`- >
Bug#931632: lintian: Testsuite hangs in/around "debian/test-out/tags/checks/version-substvars/legacy-etcfiles"
Also, should this bug be retitled?
Bug#931846: lintian: False positive debian-watch-file-should-mangle-version
Hi Mark, On Thu, Jul 11, 2019 at 3:09 AM Mark Hindley wrote: > > I think lintian should differentiate between 'debian' in the upstream version > (before the hyphen) and the packaging version (after the hyphen). Thank you for reporting the issue. This MR should fix it: https://salsa.debian.org/lintian/lintian/merge_requests/211 Kind regards Felix
Dealing with Lintian tags untestable using standard Debian packaging tools
Hi, Ideally, the Lintian test suite would test all tags. I would actually like to require it. We are doing quite well. 16 tags are currently untested out of 1,394. You can see a list below. Unfortunately some tags are hard to test. Debian's standard tools will not create packages that trigger them. Instead, they produce error messages such as: dpkg-source: error: source package format '3.0 (unknown-format)' is invalid or dpkg-source: error: syntax error in control-file-duplicate-field-1/debian/control at line 11: duplicate field Depends found. I would like to remove these tags. They currently are: unknown-source-format syntax-error-in-control-file syntax-error-in-debian-tests-control debian-tests-control-is-not-a-regular-file missing-runtime-tests-field These five tags are part of the old suite 'source', which uses low-level programs such as 'ar', 'cat', 'sed', or 'awk' to trigger them. I would like all tests for source packages to use standard tools such as 'dpkg-source'. (9 out of 27 already do, and many others are done.) That will make the five tags above untestable. I would like to delete them. Lintian may still raise exceptions. I would also like to remove the tag 'malformed-debian-changelog-version'. It has never been testable using 'dpkg-buildpackage'. Lintian will produce another type of error. Please share your thoughts! Kind regards, Felix Lechner * * * # Untested tag: bin-sbin-mismatch # Untested tag: changed-by-invalid-for-derivative # Untested tag: debian-files-list-in-source # Untested tag: directory-in-etc-sv-directory-without-executable-run-script # Untested tag: invalid-field-for-derivative # Untested tag: invalid-version-number-for-derivative # Untested tag: malformed-debian-changelog-version # Untested tag: old-python-version-field # Untested tag: package-supports-alternative-init-but-no-init.d-script # Untested tag: package-uses-deprecated-source-override-location # Untested tag: patch-system # Untested tag: script-uses-unversioned-python-in-shebang # Untested tag: tar-errors-from-control # Untested tag: vcs # Untested tag: vcs-uri
Detection of native packages
Hi, Detecting native binary packages [1] does not work nearly as well as for source packages [2]. In the Lintian test suite, we see discrepancies in the same *.changes files [3]. For that reason, I will soon propose to move all tags that depend on the detection from 'binary' to 'source'. In practice, that means moving many tags from the check 'changelog-file' to 'source-changelog'. (The check 'fields' may be split up.) The reclassification of tags as source vs. binary will cause ripple effects, such as the adjustment of expected tags in the test suite and potentially the greater ecosystem via overrides. The detection of native binary packages [1] will be removed. When both source and binary packages are present, Lintian may in the future check that changelogs in binary packages are identical to the source. Thank you to pabs for that idea. Please share your thoughts. Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian/blob/master/lib/Lintian/Collect/Binary.pm#L89-119 [2] https://salsa.debian.org/lintian/lintian/blob/master/lib/Lintian/Collect/Source.pm#L146-189 [3] An example are the legacy-maintainer-scripts family of tests; they use a native template but an erroneous, non-native looking version. The historical changelog versions, starting at '6.1' are parsed as non-native, causing faulty Lintian results.
Bug#930487: lintian: use GitLab caching of test packages to speed up test suite CI
Hi Chris, On Sat, Jul 20, 2019 at 1:33 PM Chris Lamb wrote: > > I've been hacking on this on a Salsa-local fork of Lintian that splits > the generation of the test packages and the testing itself, crucially > caching the result of the former if the tests and some other key files > have not changed. How do you tell when files have changed? I would like to use an MD5 manifest of all files generated after templating. That will also catch changes in defaults and templates---even missing files. Eventually, the expected tags (or output, if applicable) should be excluded from that manifest, as should those portions of each 'desc' file that apply only to lintian invocation (i.e. Profile, Output-Format) or runner behavior (i.e. Match-Strategy, Test-Architectures). This will require a splitting of all 'desc' files in the test directories. Also, the specifications for test packages should then be moved into dedicated directories in each test, named '$test/test-object' or similar. Kind regards, Felix
Bug#930487: lintian: use GitLab caching of test packages to speed up test suite CI
On Sat, Jul 20, 2019 at 2:02 PM Felix Lechner wrote: > > This will require a splitting of all 'desc' files > in the test directories. Actually, since the values from 'desc' are incorporated in the completed templates, all 'desc' files can be excluded from the manifest as well. No splitting is necessary. Kind regards, Felix
Bug#930487: lintian: use GitLab caching of test packages to speed up test suite CI
Hi, On Sun, Jul 21, 2019 at 6:28 AM Chris Lamb wrote: > > Felix Lechner wrote: > > $ find t/ debian/ -type f | sort | xargs sha1sum | sha1sum | cut -d' ' -f1 That's the same approach I suggested, except I would save the result of find t/ debian/ -type f | sort | xargs sha1sum and do so on a per-test basis. Then t/bin/runtest can rebuild the test packages adaptively. Please remember, contributors currently cannot run tests with '--onlyrun=check:XXX' when they add or change a tag, except after the time-consuming 'rm -rf debian/test-out; t/bin/build-test-packages'. (It was much faster until I separated the building of test packages.) The adaptive rebuilding would be super helpful even without caching on Salsa. > .. throwing the entire set of build packages away in the case of cache > miss. I did not suggest by-package caching on Salsa. I would write the test packages in to a different directory tree in d/test-out and only cache that. For example, I would write the filled templates to d/test-out/src. Only this tree needs to be hashed. During building, I would then write the test packages to d/test-out/built. Only that tree needs to be cached. > Anyway, without the Salsa caching working, all of this is moot. > One small step for a man; one big step for mankind. :)
Bug#930487: lintian: use GitLab caching of test packages to speed up test suite CI
Hi On Sun, Jul 21, 2019 at 6:28 AM Chris Lamb wrote: > > I am very much disposed towards simple and braindead obvious in things > like this, especially when they hit 90% of the use-case. And then we > can get back to other stuff... I realized we are talking about related but different things. Please look out for a merge request on the topics that go beyond the scope of this bug.
Re: Dealing with Lintian tags untestable using standard Debian packaging tools
Hi Chris, On Thu, Jul 18, 2019 at 12:00 PM Chris Lamb wrote: > > > missing-runtime-tests-field > > I'm surprised we can't check this one though; it is referring to the > autopkgtest control file, not the debian/control file, and thus > shouldn't cause dpkg-source to croak. Sorry I did not get back to you before filing !225 [1], which removed this tag. I had been unsuccessful in testing it [2], and did not see it emitted for any packages on lindsay. Please let's add this tag again if anyone can trigger it using standard tools. I was somewhat more casual when removing 'syntax-error-in-debian-tests-control'. While I was unable to trigger the tag with common syntax violations [4], it is actually emitted in two packages [5] for which all of d/tests/control is completely commented out. [6] [7] For those two packages, Lintian will now croak. To avoid that, I will soon file a merge request to reinstate the tag. My favorite solution, however, would be to test for the fully commented, i.e empty, condition in 'dpkg-source'. Perhaps we could also rename the tag. Kind regards, Felix [1] https://salsa.debian.org/lintian/lintian/merge_requests/225 [2] https://salsa.debian.org/lintian/lintian/commit/ff6a5fef762146027dfa295f73503476fe76535f (error message from dpkg-source included) [3] https://lintian.debian.org/tags/missing-runtime-tests-field.html [4] https://salsa.debian.org/lintian/lintian/commit/4f019cb2c1d754cdcb1c601f34b85d5015b2d90d (error message from dpkg-source included) [5] https://lintian.debian.org/tags/syntax-error-in-debian-tests-control.html [6] https://sources.debian.org/src/freeipa/4.7.2-3/debian/tests/control/ [7] https://sources.debian.org/src/kiten/4:17.08.3-1/debian/tests/control/
Bug#933134: lintian: depends on libparse-debianchangelog-perl that has no upstream maintainer
Hi intrigeri, On Fri, Jul 26, 2019 at 1:45 PM wrote: > > lintian depends, or build-depends, on libparse-debianchangelog-perl, > which has had no upstream maintainer since 2011. After you filed this bug I migrated Lintian away from that library. With some luck, it will be in master soon---and well before the bullseye freeze. > see https://bugs.debian.org/933128, where we can discuss our options. Our solution does not presently use Dpkg::Changelog::Debian. If it continues to work well, I will post a reference to it on your main bug. Kind regards Felix Lechner
Bug#933134: lintian: depends on libparse-debianchangelog-perl that has no upstream maintainer
Hi Chris, . On Tue, Jul 30, 2019 at 5:46 AM Chris Lamb wrote: > > is in a local branch or > perhaps did this change get lost somewhere? You don't have it yet. It works, but I am contemplating better parsing, possibly using Parser::MGC, and changes to the API. Coming in the next few days. Kind regards, Felix
Bug#930487: lintian: use GitLab caching of test packages to speed up test suite CI
Hi Chris, On Sat, Jul 20, 2019 at 1:33 PM Chris Lamb wrote: > > I've been hacking on this on a Salsa-local fork of Lintian that splits > the generation of the test packages and the testing itself, crucially > caching the result of the former if the tests and some other key files > have not changed. Will it also force an update of the test packages when the build chain has changed? It may expose Lintian bugs like #932339. Kind regards, Felix
Bug#933134: lintian: depends on libparse-debianchangelog-perl that has no upstream maintainer
Hi intrigeri, On Tue, Jul 30, 2019 at 6:16 AM intrigeri wrote: > > I have WIP locally that also migrates Lintian away from > Parse::DebianChangelog. I did not finish it yet but if it helps, > I could push my current branch somewhere. I knew Lintian would be high on your list and got to work immediately: https://salsa.debian.org/lintian/lintian/merge_requests/234 I plan more improvements and will share them when appropriate. We could also cooperate on making a new library available to others. Kind regards, Felix Lechner
Bug#933134: lintian: depends on libparse-debianchangelog-perl that has no upstream maintainer
Hi, On Wed, Jul 31, 2019 at 8:29 AM intrigeri wrote: > >I've pushed my current WIP to >https://salsa.debian.org/intrigeri/lintian/tree/bug933134. >I'm not sure if/when I'll be able to resume work on it, >so please don't block on me. Thank you. I will start with your code when we decide to go with Dpkg::Changelog::Debian. > - Your MR introduces yet another debian/changelog parser. > > Given the trouble we had with keeping Parse::DebianChangelog somewhat > working and up-to-date so far, I would argue that relying on existing, > well-maintained Dpkg::* code, is a safer approach on the long term. Having converted the Lintian test suite from a custom approach to TAP::Parser, I share your sentiment about using established, and tested, third-party packages. I am more tolerant, however, when duplicating efforts related to Debian---such as analyzing the changelog. Lintian is supposed to be an independent critic, and there is a value to, well, being independent. The changelog parser is also a relatively small piece of code. A more significant issue is that Dpkg::Changelog::Debian may not offer the kind of data structures I hope to offer to writers of Lintian checks. At least, I felt that way when implementing centralized version parsing as part of the $info data structure for source packages (MR in preparation) pursuant to this message: https://lists.debian.org/debian-lint-maint/2019/07/msg00141.html and based on this code: https://salsa.debian.org/lintian/lintian/blob/master/checks/source-changelog.pm#L28-84 If it helps us with a decision, I could submit that MR first. Or, Chris could accept my merge request !234 for now. We could look at alternatives later. That would immediately resolve #933134, which prevents the removal of libparse-debianchangelog-perl. (From your bug filing, it sounded like a priority for the Perl team.) Lintian would be off no worse than before: We have an old parser that does not use Dpkg::Changelog::Debian. :) This last course of action is my favorite. I have so many changes in the pipeline, it would be far easier for me to adapt Lintian to Dpkg::Changelog::Debian later than to rebase my branches. I promise to undertake the integration work, if necessary. Would that be agreeable to you? > But it requires more initial work because the API differs slightly, > and more importantly, the Dpkg::Changelog::Debian parser is stricter, > so we lose some granularity wrt. error reporting (some syntax errors > Lintian would previously catch itself later on are now reported as > syntax errors, as soon as we parse the changelog file). I am not worried about the amount of work, but about its outcome: As you acknowledge, Dpkg::Changelog::Debian's lack of granularity may make it harder to implement distinct tags. That results less detailed advice on how to improve packages, and is less customer-friendly. Kind regards, Felix
Bug#933134: lintian: depends on libparse-debianchangelog-perl that has no upstream maintainer
Hi intrigeri, On Wed, Jul 31, 2019 at 8:29 AM intrigeri wrote: > >I've pushed my current WIP to >https://salsa.debian.org/intrigeri/lintian/tree/bug933134. Your branch is now in my repo at https://salsa.debian.org/lechner-guest/lintian/tree/bug933134. >I'm not sure if/when I'll be able to resume work on it, >so please don't block on me. Please delete your copy when you do not need it anymore. Kind regards, Felix
Bug#873520: Check for bad distribution in d/changelog only when changes file is signed
Hi, > However, ... this would mean that every time you built a package > locally as part of regular development it would emit this tag. Would it be acceptable to generate the tag for bad distribution in d/changelog only when the *.changes file is signed (if it is present)? That should bypass interim packages produced locally but catch those intended for upload. Kind regards, Felix
Bug#933925: Misspelling in Lintian UDD table
Package: lintian Severity: minor This bug probably belongs elsewhere, but I could not find a better place. In the Lintian table in the UDD, the 'tag_type' for overridden tags is misspelled as 'overriden'. udd=> select package, tag_type, tag, information from public.lintian where tag='spelling-error-in-readme-debian' and tag_type='overriden' and information not like '%(duplicate word)%'; package | tag_type | tag | information --+---+-+-- liblorene-dev| overriden | spelling-error-in-readme-debian | Langage Language liblorene-dev| overriden | spelling-error-in-readme-debian | Langage Language lorene-codes-src | overriden | spelling-error-in-readme-debian | Langage Language (3 rows)
Bug#926823: executable-not-elf-or-script should consider PE binaries
Hi, On Thu, May 2, 2019 at 9:27 AM Chris Lamb wrote: > > This begs the question; why cannot the systemd packaging remove the > executable bits from these files? On my testing system post-buster, the executable bits are still set: $ ls -ald /usr/lib/systemd/boot/efi/* -rwxr-xr-x 1 root root 59730 Jul 18 10:38 /usr/lib/systemd/boot/efi/linuxx64.efi.stub -rwxr-xr-x 1 root root 91765 Jul 18 10:38 /usr/lib/systemd/boot/efi/systemd-bootx64.efi May I please assign this bug to package systemd? Kind regards, Felix Lechner
Bug#926823: executable-not-elf-or-script should consider PE binaries
Control: reassign -1 systemd Control: severity -1 wishlist Hi, On Mon, Aug 5, 2019 at 5:48 AM Chris Lamb wrote: > > Can you clarify whom you are directing this query to? (I am unable to > answer it.) It was a matter of politeness, I suppose. Kind regards, Felix
