Bug#943724: lintian: internal error in Lintian::files::empty_package::_set_is_dummy
Hi everyone, On Wed, Oct 30, 2019 at 2:55 PM Thorsten Glaser wrote: > > indeed, ... [my] script uses -o APT::Install-Recommends=true Starting with the next release, your build experience will match ours. Lintian now depends on libclass-xsaccessor-perl. Thank you for your goodwill. Kind regards, Felix Lechner
Processed: Re: Please check for update-rc.d "start" and "stop" argument usage
Processing control commands: > tags -1 - moreinfo Bug #717595 [lintian] lintian: Please check for update-rc.d "start" and "stop" argument usage Bug #733156 [lintian] lintian: Please check for update-rc.d "start" and "stop" argument usage Removed tag(s) moreinfo. Removed tag(s) moreinfo. -- 717595: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717595 733156: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733156 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#717595: Please check for update-rc.d "start" and "stop" argument usage
Control: tags -1 - moreinfo Since this problem is still an issue with packages in the archive (like x11-common), it would be nice to have lintian warn about the issues. On Tue, 17 Dec 2013 10:10:58 +0100 Bastien ROUCARIES wrote: > I am willing to implement this test but could you please provide a description A reasonable description was already provided in the mail: The update-rc.d "start" and "stop" arguments are obsoleted and replaced by the "defaults" argument. It is no longer possible to specify start and stop runlevel and sequence numbers; these must be provided by the LSB header of every init script. If start and/or stop arguments are provided, these now act as if "defaults" had been used instead, and the extra runlevel and sequence information is discarded, and a warning will be issued. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#943910: lintian: FTBFS in stretch-bpo: Cannot parse line Argument "1/8" isn't numeric in numeric eq (==) at /build/lintian-2.31.0/lib/Lintian/Processable/Pool.pm line 348.
Hi Andreas,
On Fri, Nov 1, 2019 at 2:47 PM Andreas Beckmann wrote:
>
> ./lib/Lintian/Processable/Pool.pm:347:return scalar %{$self->groups} == 0;
I introduced the expression in commit fb7c6165. (The other line did
not break stretch.) Sorry about the massive inconvenience I caused
you.
Kind regards
Felix Lechner
Bug#943910: lintian: FTBFS in stretch-bpo: Cannot parse line Argument "1/8" isn't numeric in numeric eq (==) at /build/lintian-2.31.0/lib/Lintian/Processable/Pool.pm line 348.
Hi Andreas,
On Fri, Nov 1, 2019 at 2:47 PM Andreas Beckmann wrote:
>
> ./lib/Lintian/DepMap.pm:162:unless ($parents || scalar
> %{$self->{'nodes'}{$node}{'parents'}}) {
> ./lib/Lintian/Processable/Pool.pm:347:return scalar %{$self->groups} == 0;
Wow, I saw the second one and almost inserted 'keys' because it is
easier to read. Please file an MR with Lintian, if you have time. Your
authorship and hard detective work should be recognized. Thanks so
much!
Kind regards,
Felix Lechner
Bug#943910: lintian: FTBFS in stretch-bpo: Cannot parse line Argument "1/8" isn't numeric in numeric eq (==) at /build/lintian-2.31.0/lib/Lintian/Processable/Pool.pm line 348.
On 01/11/2019 06.17, Felix Lechner wrote:
> I did not intentionally use features of newer Perls, but it's possible
> that it plays a role.
Found it:
https://perldoc.perl.org/perl5260delta.html#scalar(%25hash)-return-signature-changed
stretch$ perl -e '%a = (1,2,3); print scalar %a, " -- ", scalar keys %a, "\n";'
2/8 -- 2
buster$ perl -e '%a = (1,2,3); print scalar %a, " -- ", scalar keys %a, "\n";'
2 -- 2
Some documentation of the old behavior:
https://www.perlmonks.org/?node=perldata
"If you evaluate a hash in a scalar context, it returns a value that is true if
and only if the hash contains any key/value pairs. (If there are any key/value
pairs, the value returned is a string consisting of the number of used buckets
and the number of allocated buckets, separated by a slash. ..."
A backwards compatible solution should be the use of "scalar keys %hash"
(which also occurs about a dozen times in the code).
I only found two obvious occurrences of "scalar %hash" in current git master:
./lib/Lintian/DepMap.pm:162:unless ($parents || scalar
%{$self->{'nodes'}{$node}{'parents'}}) {
./lib/Lintian/Processable/Pool.pm:347:return scalar %{$self->groups} == 0;
Andreas
PS: backporting coreutils 8.30 to stretch locally was a trivial no-change
rebuild
PPS: I'll now try a 2.32.0 stretch backport with the above "keys" fix and
locally backported coreutils
(I had to build lintianwith nocheck due to several tests failing due to
coreutils
not being 8.30 at build time (and maybe other errors))
Processed: Bug#933304 marked as pending in lintian
Processing control commands: > tag -1 pending Bug #933304 [lintian] lintian: suggest switching from debian/compat to debhelper-compat Added tag(s) pending. -- 933304: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933304 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#943957: lintian: missing-systemd-service-for-init.d-script should be a warning, not just pedantic
package: lintian severity: wishlist version: 2.32.0 x-debbugs-cc: 941...@bugs.debian.org, r...@debian.org, ans...@43-1.org On Fri, Nov 01, 2019 at 11:20:59AM -0700, Russ Allbery wrote: > > I think there is already a lintian warning: > > > > https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html > Oh! I should have checked rather than assuming. It would ideally be nice > to make it a warning rather than a pedantic tag before we add it to > Policy, but meh, and the count of tags isn't all that high. I'm pretty sure this is trival and just a matter of asking via a wishlist bug, thus doing so here. See #941198 for more context. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Processed: Bug#943947 marked as pending in lintian
Processing control commands: > tag -1 pending Bug #943947 [lintian] lintian: outdated build-profile list - noguile is registered, isn't it? Added tag(s) pending. -- 943947: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943947 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#943947: Bug#943905: gnutls28 FTCBFS during guile bindings
Hi Andreas,
On Fri, Nov 01, 2019 at 01:42:24PM +0100, Andreas Metzler wrote:
> This was not the fine point I had been was trying to ask about, though. ;-)
> - I was wondering why you suggested using a gnutls specific
> profile ("pkg.gnutls28.noguile") while the BuildProfileSpec lists
> "noguile" as registered profile name.
I'm sorry. The sole reason was me not remembering that we registered it
already. I didn't check the docs and just assumed that it wasn't
registered. As it is, I second #943947 and of course do prefer "noguile"
over "pkg.something.noguile"!
Helmut
Bug#943947: lintian: outdated build-profile list - noguile is registered, isn't it?
Package: lintian Version: 2.32.0 Severity: normal Hello, I have just gotten this warning: - E: gnutls28 source: invalid-profile-name-in-build-profiles-field noguile guile-g nutls N: N:The restriction formula in Build-Profiles field includes an unknown N:build profile. The only allowed build profiles are "cross", "nobiarch", N:"nocheck", "nodoc", "nogolang", "nojava", "noperl", "nopython", N:"noudeb", "stage1", "stage2" and "pkg..". N: N:Refer to N:https://wiki.debian.org/BuildProfileSpec#Registered_profile_names for N:details. - The quoted wiki page lists "noguile" as registered profile. cu Andreas
Bug#943913: lintian: processing packages with many manpages is very slow
Bringing man-db and libseccomp maintainers into the loop. On 2019-10-31 23:01 -0700, Felix Lechner wrote: > On Thu, Oct 31, 2019 at 11:33 AM Sven Joachim wrote: >> >> Running lintian on packages with many manpages is painfully slow. > > I can confirm that it takes a long time: > > $ time frontend/lintian ../manpages-dev_5.03-1_all.deb > I: manpages-dev: > cannot-check-whether-usr-share-doc-symlink-points-to-foreign-package > I: manpages-dev: spelling-error-in-manpage > usr/share/man/man3/fgetws.3.gz "permit to" "permit one to" > I: manpages-dev: spelling-error-in-manpage > usr/share/man/man3/gethostbyname.3.gz "permits to" "permits one to" > I: manpages-dev: spelling-error-in-manpage > usr/share/man/man3/inet_net_pton.3.gz pres press > I: manpages-dev: spelling-error-in-manpage ... use > --no-tag-display-limit to see all (or pipe to a file/program) > W: manpages-dev: manpage-has-errors-from-man > usr/share/man/man2/ioctl_list.2.gz 730: warning [p 8, 2.7i]: cannot > adjust line > W: manpages-dev: manpage-has-errors-from-man > usr/share/man/man2/syscall.2.gz 200: warning [p 2, 5.5i]: cannot > adjust line > N: 3 tags overridden (3 info) > > real0m50.609s > user3m38.614s > sys0m16.174s > > In a first attempt to get to the issue, I reverted commit 067ec6cb but > it took about the same: > > real0m51.193s > user3m39.174s > sys0m15.833s > > Do you have older measurements to which we can compare this performance? In a buster chroot lintian (version 2.15.0) is about seven times faster on the same manpages-dev package, however in sid downgrading lintian or man-db to their buster versions did not help. To track down the problem, I upgraded packages piecemeal from buster to sid in a chroot, and the massive lintian slowdown happened after upgrading libseccomp2 from 2.3.3-4 to 2.4.1-2. Hopefully the man-db and libseccomp maintainers can help here. Cheers, Sven
Bug#943913: lintian: processing packages with many manpages is very slow
Hi Sven, On Thu, Oct 31, 2019 at 11:33 AM Sven Joachim wrote: > > Running lintian on packages with many manpages is painfully slow. I can confirm that it takes a long time: $ time frontend/lintian ../manpages-dev_5.03-1_all.deb I: manpages-dev: cannot-check-whether-usr-share-doc-symlink-points-to-foreign-package I: manpages-dev: spelling-error-in-manpage usr/share/man/man3/fgetws.3.gz "permit to" "permit one to" I: manpages-dev: spelling-error-in-manpage usr/share/man/man3/gethostbyname.3.gz "permits to" "permits one to" I: manpages-dev: spelling-error-in-manpage usr/share/man/man3/inet_net_pton.3.gz pres press I: manpages-dev: spelling-error-in-manpage ... use --no-tag-display-limit to see all (or pipe to a file/program) W: manpages-dev: manpage-has-errors-from-man usr/share/man/man2/ioctl_list.2.gz 730: warning [p 8, 2.7i]: cannot adjust line W: manpages-dev: manpage-has-errors-from-man usr/share/man/man2/syscall.2.gz 200: warning [p 2, 5.5i]: cannot adjust line N: 3 tags overridden (3 info) real0m50.609s user3m38.614s sys0m16.174s In a first attempt to get to the issue, I reverted commit 067ec6cb but it took about the same: real0m51.193s user3m39.174s sys0m15.833s Do you have older measurements to which we can compare this performance? Kind regards, Felix Lechner
