* gregor herrmann: > > No, they are green all across the board (for tests _within_ testing > or unstable): > https://ci.debian.net/packages/libd/libdevice-cdio-perl/
Thanks for pointing this out. * Paul Gevers: > > I'm the first to admit that properly testing transitions in the Debian > CI setup is a hard problem because of trade-offs. How it currently works > is that britney2 tries to figure out for a source package in unstable > what packages need to come from unstable in order to fulfill the test > requirements of a reverse (test) dependency in testing. Because > libraries are typically co-installable, britney2 doesn't currently know > that we have a rebuild that we want to test (bug 944458). However, if we > are going to wait for rebuilds and their test results, we basically > loose the ability to do smooth-updates, which make transitions > longer/harder. So far, we have not fixed bug 944458 because of that. Thanks for the explanation. It makes sense to me. > That does mean that occasionally we run into issues where tests fail, > but so far we've been able to manage that. Are you saying that I might need some sort of manual intervention? Anyhow, I did a little bit more digging (and awful hacking) and I found out that the issue happens when we have libdevice-cdio-perl built against libcdio19t64 (2.1.0-5), but the testbed has the newer version of libcdio19t64 (2.2.0-1). Steps to reproduce: Install the following versions: dpkg --no-pager --list libdevice-cdio-perl libiso9660-12 libiso9660-11t64 libiso9660-dev libcdio19t64 libcdio-dev Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=====================-============-============-============================================================ ii libcdio-dev 2.1.0-5 i386 library to read and control CD-ROM (development files) ii libcdio19t64:i386 2.1.0-5 i386 library to read and control CD-ROM ii libdevice-cdio-perl 2.0.0-2+b4 i386 CD Input and control library ii libiso9660-11t64:i386 2.1.0-5 i386 library to work with ISO9660 filesystems ii libiso9660-12:i386 2.2.0-1 i386 library to work with ISO9660 filesystems ii libiso9660-dev:i386 2.1.0-5 i386 library to work with ISO9660 filesystems (development files) Run `autopkgtest -B . -- null' and check that it passes. Then, since installing the newer version of libcdio19t64 (2.2.0-1) with `dpkg -i' would require reinstalling other packages too, I manually extracted the library binary and copied it to the file system, i.e.: # dpkg-deb --extract libcdio19t64_2.2.0-1_i386.deb ext/ # cp ext/usr/lib/i386-linux-gnu/libcdio.so.19.0.0 /usr/lib/i386-linux-gnu/libcdio.so.19.0.0 Re-run `autopkgtest -B . -- null' and check that it now fails! Finally, installing a freshly built version of libdevice-cdio-perl (one that is linked against the new version of libcdio (2.2.0-1)), makes the test pass again. * Gabriel F. T. Gomes: > I think it is impossible to do what you're suggesting I said this before, but I found this hacky way of doing it to pin-point (somewhat) the source of the test failures.
