Quoting Paul Gevers (2023-02-08 21:20:04) > On 08-02-2023 19:31, Jonas Smedegaard wrote: > > omething seems wrong in autopkgtests for rust-ureq: status is listed as > > "Test in progress" on all arches, except ppc64el and s390x that had > > failed, seemingly due to choking on the src:rust-rustls package recently > > switching from arch-any to arch-all - I have requested rechecking of > > those. The others that are "in progress" for suspiciously long do not > > offer me a request to recheck, so I am asking you to please try > > investigate what is going on there... > > I think this is more something for debian-ci (in cc). Very interesting. > On all architectures, there's 1 package pending longer than 5 days, and > on all but one that's rust-ureq. What worries me however, is that > https://ci.debian.net/packages/r/rust-ureq/ mentions also 2 days old > triggered tests in unstable that haven't run. The queue on most > architectures is empty at the moment. > > I've just started a manual run on one of our workers (ci-worker01, > amd64) to see if I see something odd. [some time later] ... and it > passes without issues. (You probably have an unintended test name with > gzip, but otherwise, manual running is OK) > > So it's either the timing was extremely unfortunate and your package hit > something unknown on our infrastructure, or it's actually the package > that's causing issues on our infrastructure. @terceiro; do you have > ideas where to look? I suspect somehow the results of this package cause > the rabbitmq to choke, so the test gets removed from the queue, but its > results not added to the database (that's the opposite of our s390x (and > old riscv64) issue). In case it is helpful: That same day I released between 20 and 40 package updates, all Rust libraries and all involving a switch from arch-any to arch-all, and received some feedback that it had triggered temporary FTBFS for other Rust library packages. My vague impression is that some infrastructure caches package names for virtually provided packages, and then fails to resolve a dependency on "rust-foo-2+bar-dev" which it internally assumes should resolve to "rust-foo-dev:same-arch" but has changed to resolve to "rust-foo-dev:all". - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature