Source: cloud-sptheme Version: 1.10.1.post20200504175005-3 Severity: serious X-Debbugs-CC: debian...@lists.debian.org Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:python3-defaults
Dear maintainer(s),With a recent upload of python3-defaults the autopkgtest of cloud-sptheme fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form:
pass fail
python3-defaults from testing 3.9.8-1
cloud-sptheme from testing 1.10.1.post20200504175005-3
all others from testing from testing
I copied some of the output at the bottom of this report. Seems you test
for all supported Python3 versions but you don't ensure they are
actually all installed during autopkgtesting.
Currently this regression is blocking the migration of python3-defaults to testing [1]. Of course, python3-defaults shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in python3-defaults was intended and your package needs to update to the new situation.
If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from python3-defaults should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests.
More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/c/cloud-sptheme/17290350/log.gz === python3.10 ===/tmp/autopkgtest-lxc.gop2f388/downtmp/build.veH/src/debian/tests/unittests: 8: python3.10: not found
autopkgtest [19:10:44]: test unittests
OpenPGP_signature
Description: OpenPGP digital signature
