Hi Niko, As mentioned on IRC, much thanks for this e-mail. On 22-04-18 14:53, Niko Tyni wrote: > my upload of Perl 5.26.2 to unstable has apparently caused some headache I wouldn't call them headaches :). Just part of the expected learning curve. > for the ci.debian.net autopkgtest checks of 'testing', which I understand > is the setup that's intended to drive the upcoming integration of > autopkgtest and britney. Indeed. I expect to be able to announce the integration to d-d-a in the next couple of weeks. > While there were some other failures that I think have since been > identified as bugs in the corresponding packages, the main failure mode > in my understanding is/was autopkgtest failures in 'command3' of the > autopkgtest-pkg-perl framework. (Paul, please correct me if there are > other unexplained failures too!) I'll need to check, but that may very well be. For me most failures I have seen fell in the bucket of "more packages from unstable needed than enabled by autopkgtest". > It looks to me like the ci.debian.net 'testing' failures are > running with perl 5.26.2 from unstable but libcommon-sense-perl / > libclass-xsaccessor-perl from testing. These are not installable > together, so apt silently gives up on installing the recommendations > without actually bailing out. The checks then rightly fail because not > all recommendations are installed. > > So afaics part of the issue is that when the 'needs-recommends' test > restriction cannot be fulfilled, autopkgtest doesn't notice and report > an error, but rather carries on and runs the test regardless. This (not bailing out) sounds like a bug in autopkgtest to me. I'll file one soon, based on your message. Although, if you want to file it yourself, please do so. > Another part is that the 'testing' checks need to take more packages > from unstable than just the one that's trying to migrate, and selecting > those packages doesn't seem to work yet in all cases? Indeed. Until autopkgtest 5.3 (there is a bug present in that version), it would retry and allow packages from both unstable and testing. But even without the bug it wouldn't always find a solution. I am going to try and use (an additionally) another apt resolver for that fallback in the hope it finds a solution that apt couldn't find. > I'm not at all > acquaintanced with how this is supposed to work, but it looks like for > instance https://ci.debian.net/packages/libj/libjson-xs-perl/ has since > learned that libcommon-sense-perl needs to be grabbed from unstable. > (This is much easier to detect as it's a direct dependency in this case, > not a recommendation.) Well, libjson-xs-perl was tested with autopkgtest 5.2 and that didn't have the fallback bug. > This all obviously mirrors the way britney needs hints for migrating > packages together; are those tied somehow? I'm sure this is a more > generic issue not specific to perl... Ideally, britney would grow a (simplified) full recursive installability check before or in the autopkgtest policy and wouldn't test the packages until they are installable. However, currently it runs its full recursive installability tests after the normal policy checks and thus the results are not available at the moment it determines which autopkgtest to run. I have discussed this with nthykier (of the Release Team), but we concluded that we don't want to mix creating this (at this moment) with the autopkgtest integration into britney. > Hope this is at least slightly useful. Thanks for your work on getting > more use out of the autopkgtest checks, much appreciated! Again, thanks for taking the time to investigate and to write it down. Much appreciated. Paul
Attachment:
signature.asc
Description: OpenPGP digital signature