I can reproduce the issue with Python 3.8.3rc1. I'll check the other 3.8 versions to see if it exists in earlier versions.
On Mon, May 11, 2020 at 11:00 AM Paul Gevers <elb...@debian.org> wrote: > > Hi Martin, > > On 11-05-2020 02:01, Martin Kelly wrote: > >> Because your autopkgtest was part of the tests for glibc, I spotted that > >> the autopkgtest of python-gmpy2 regressed recently. On 2020-05-01 at > >> 19:13 we had the last successful run on arm64 in testing, the first > >> failure was also on 2020-05-01, even earlier: at 02:08 in unstable on > >> amd64. I copied some of the output at the bottom of this report. > >> > >> Can you please investigate the situation and fix it? > >> > >> More information about this bug and the reason for filing it can be > >> found on > >> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > >> > >> Paul > >> > >> https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-gmpy2/5338978/log.gz > >> > >> > > > > Thanks for the bug report. Given that no new python-gmpy2 package was > > uploaded on May 1, I'm guessing one of the dependencies of this package > > has broken, or changed in a way that broke this package. Is there a way > > to get a list of packages that were uploaded after the last successful > > test and before the first failure? > > The interesting thing is that it regressed in both unstable and testing > nearly at the same time. So either I would bet on something external to > the archive (like sources or time) or maybe a kernel update? You can see > the packages in the testbed if you inspect the artifacts linked from the > ci.d.n pages. > > > +Case Van Horsten, the upstream maintainer. Case, could you take a look > > at the failures here? They seem to have occurred without gmpy2 changing, > > so some dependency is failing. > > Paul >
