Hi Andreas,
On Thu, Oct 31, 2019 at 8:47 PM Andreas Beckmann <a...@debian.org> wrote:
>
> In case you have some hints for "speeding up" bisecting
> lintian, you could add them to some readme.
Right now I am totally in the dark. I have almost no experience with
stretch-bpo and have to think about it.
> # ---
> debian/test-out/tags/checks/debian/debconf/debconf-config-not-executable/tags.specified.calibrated
> # +++
> debian/test-out/tags/checks/debian/debconf/debconf-config-not-executable/tags.actual.parsed
> # -debconf-config-not-executable (binary): control-file-has-bad-permissions
> config 0644 != 0755
The associated check 'control-files.pm' is brief and simple. It seems
to indicate that the data from collections/bin-pkg-control is either
created or communicated incorrectly. The operation is somewhat distant
from the changes in the offending commits, which relate to scheduling
such tasks.
> The first bad commit could be any of:
> 53002feb5b944681a17109b704fdcb10f1032c84
> ba56dcca2932913945346ebf56e428801970e3e1
> 5b3f9904ee4f2aa128c65f7b407be14827f06c9c
> fb7c61656fd6a5ba5f4449a005a3d8884b4be886
> 713e9ac5e159d7011239e78a025747a80cdaf54b
> 8e4e87e93958ee75a707be0e97de3af6dcf8e859
> a6d28ec18b0968728aab07490a04384ea78f0a25
As you pointed out the commits are part of a larger reorganization.
With minor exceptions, I merely shuffled code around to clean up. I
don't remember introducing any new features. The use of Moo was
probably the most important change.
For the commit range you mentioned, I will point out that all of them
failed in Gitlab (unstable) due to the presence of debhelper 12.7:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943376
but there is little chance the bug in that version of debhelper
affects stretch-bpo.
Just because it happened recently, please also allow me to point out
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943724
Lintian did an FTBFS on stable when libclass-xsaccessor-perl (a
recommended package) is installed, although with a different error.
> Does the new Lintian::Processable::Pool have new insufficiently
> versioned external dependencies? Or does it require newer perl?
I have to think some more, but as indicated the changes related
primarily to proper class association, streamlining of conditional
logic and and cutting of unused of code. While I had used Moo before,
the commits introduced it to Lintian's key infrastructure of
scheduling packages.
I did not intentionally use features of newer Perls, but it's possible
that it plays a role.
Kind regards,
Felix Lechner
