[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#943913: lintian: processing packages with many manpages is very slow



On 2019-11-01 10:42 +0100, Sven Joachim wrote:

> 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 <svenjoac@gmx.de> 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)
>>
>> real    0m50.609s
>> user    3m38.614s
>> sys    0m16.174s
>>
>> In a first attempt to get to the issue, I reverted commit 067ec6cb but
>> it took about the same:
>>
>> real    0m51.193s
>> user    3m39.174s
>> sys    0m15.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.

It seems to me we are likely experiencing
https://github.com/seccomp/libseccomp/issues/153.

Cheers,
       Sven


Reply to: