Package: perl Version: 5.28.1-5 Severity: important As seen at https://autopkgtest.ubuntu.com/packages/perl the NDBM autopkgtest checks are failing on several 64-bit architectures.
These checks bundle binary NDBM databases generated on current sid/buster and stretch versions of perl, and the purpose is to check that those databases remain readable with the current version of perl. We used to test this with just amd64 databases, but it turned out that they are architecture specific, so we now ship separate test data files for the different architectures. All the test failures are issues with reading the stretch NDBM. autopkgtest [05:12:53]: test ndbm: [----------------------- testing NDBM reading... buster-ndbm OK opening NDBM file failed: No such file or directory at -e line 1. autopkgtest [05:12:54]: test ndbm: -----------------------] ndbm FAIL non-zero exit status 1 The "No such file or directory" is a misleading diagnostic here; the files get opened correctly. The issue seems to be an actual incompatibility with the stretch databases. I can reproduce these on Debian porter machines. Clearly I should have tested this better before including the data. Apologies for any inconvenience caused. The Perl NDBM support in Debian are built on the GDBM "old style dbm" support (in the libgdbm-compat-dev package). The resulting database are made of two identical files (*.dir and *.pag). I've checked that the "gdbm_dump" utility from the gdbmtool package sid/buster can still read the stretch database files. So this seems to be specific to the way the Perl NDBM support is implemented. A recent (separate) LFS-related backwards binary compatibility issue in gdbm, #923609, was resolved by shipping a separate gdbm_dump-nolfs utility that can be used to dump Stretch databases so that they can be upgraded manually. The same avenue seems adequate for this issue as well. I'm not sure if it's worth investigating what exactly goes wrong with the compatibility, particularly as the combination of a non-mainstream architecture and an obsolete database format makes it quite improbable that any actual users will ever hit this. I'm therefore inclined to just remove the stretch databases from the test data on these architectures and be done with it. I'm undecided on whether to do this for Buster or not. Will probably check with the release team what they think. In any case, I'll wait for -5 to enter testing first. -- Niko Tyni [email protected]
