Control: tag -1 pending On Wed, Oct 23, 2019 at 10:41:24PM -0700, Steve Langasek wrote: > Source: perl > Version: 5.30.0-7 > User: [email protected] > Usertags: origin-ubuntu focal > > Dear maintainers, > > The perl autopkgtest passes in unstable, but consistently fails in testing > and will continue to do so: > > autopkgtest [06:39:56]: test control: prove debian/t/control.t > autopkgtest [06:39:56]: test control: [----------------------- > > # Failed test 'Breaks for libextutils-parsexs-perl in perl-modules-5.30 > matches Module::CoreList for ExtUtils::ParseXS' > # at debian/t/control.t line 219. > # got: '3.400000' > # expected: '3.40' > # s/libextutils-parsexs-perl (<< 3.400000)/libextutils-parsexs-perl (<< 3.40)/ > # s/libextutils-parsexs-perl (= 3.400000)/libextutils-parsexs-perl (= 3.40)/ > # Looks like you failed 1 test of 452. > debian/t/control.t .. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/452 subtests > (less 113 skipped subtests: 338 okay) > > (https://ci.debian.net/packages/p/perl/testing/amd64/) > > This test fails because debian/t/control.t relies on finding an existing > package in the archive in order to figure out how far to zero-extend the > version number that's provided by the upstream source data, before comparing > with the contents of debian/control. > > However, libextutils-parsexs-perl is not in testing /precisely because/ only > an older version is available in the archive which is broken by current perl > (bug #912682). The test still passes in unstable, but at some point it may > start to fail there also if the libextutils-parsexs-perl is removed from the > archive.
Indeed. I noticed this right after the 5.30.0-8 upload but wanted that to migrate first. It's fixed by https://salsa.debian.org/perl-team/interpreter/perl/commit/afc9c66ad31ca747d618d3109e94d54e55567bac though clearly the solution is somewhat fragile and there's a danger of accidentally reintroducing the issue in 5.32 again. I'll try to come up with something better, probably listing the number of digits for the special case packages. > Regardless, this is an unreliable test because it depends on the state of > packages in the archive which are not (test,build,runtime) dependencies of > perl. It looks like the release team may have overridden this failure once > in order to let perl 5.30.0-7 migrate into testing, but this really ought to > be resolved. The fragility wrt. packages not available in the archive suite that we're testing against could be fixed by listing the expected number of digits for all the packages. I guess I'll look at that too. However, the main point of the test is to have it fail if it spots new packages in the archive that would need a corresponding Breaks/Replaces entry. By your classification this makes it unreliable. I'm not sure if this means I should disable it. That seems counterproductive to me. -- Niko Tyni [email protected]
