Bug#1030883: release.debian.org: CI for rust-ureq mysteriously "in progress" for 5 days even on most powerful arches
On Thu, Feb 09, 2023 at 09:59:57PM +0100, Paul Gevers wrote: > Control: reassign -1 debci-collector > Control: retitle -1 missing filename sanitizing > > Hi Jonas, > > On 08-02-2023 21:20, Paul Gevers wrote: > > 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. > > We have tracked down the issue and it turns out that this: > > -ureq-2:gzip PASS > triggers a bug in debci. The testname is used for filenames and the hyphen > is interpreted as an option to tar, triggering: > tar: You may not specify more than one '-Acdtrux', '--delete' or > '--test-label' option > > We're working on a fix. > > @terceiro: thinking of it, should we request a CVE for this? Do you think we have enough users of debci to justify this? (as in people who are actually running their own debci service). signature.asc Description: PGP signature
Bug#1030883: release.debian.org: CI for rust-ureq mysteriously "in progress" for 5 days even on most powerful arches
Control: reassign -1 debci-collector Control: retitle -1 missing filename sanitizing Hi Jonas, On 08-02-2023 21:20, Paul Gevers wrote: 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. We have tracked down the issue and it turns out that this: -ureq-2:gzip PASS triggers a bug in debci. The testname is used for filenames and the hyphen is interpreted as an option to tar, triggering: tar: You may not specify more than one '-Acdtrux', '--delete' or '--test-label' option We're working on a fix. @terceiro: thinking of it, should we request a CVE for this? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1030883: release.debian.org: CI for rust-ureq mysteriously "in progress" for 5 days even on most powerful arches
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 signature.asc Description: signature
Bug#1030883: release.debian.org: CI for rust-ureq mysteriously "in progress" for 5 days even on most powerful arches
Hi Jonas, 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). Paul rust-ureq-2:@PASS rust-ureq-2: PASS rust-ureq-2:brotli PASS rust-ureq-2:cookies PASS rust-ureq-2:default PASS rust-ureq-2:charset PASS -ureq-2:gzip PASS rust-ureq-2:json PASS rust-ureq-2:native-certs PASS rust-ureq-2:native-tls PASS rust-ureq-2:socks-proxy PASS rust-ureq-2:tls PASS OpenPGP_signature Description: OpenPGP digital signature
Bug#1030883: release.debian.org: CI for rust-ureq mysteriously "in progress" for 5 days even on most powerful arches
Package: release.debian.org Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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... Kind regards, - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmPj6mkACgkQLHwxRsGg ASFRDhAAj8TkU5voEEtYUYqRTKO6em1sDezRY3o2VBY2yXZ/bw09nrR2BxpvGyri jOFpdOEVVitL6MTpjU2zALT6Gk1jWJfOT6FIrRbCo43J1fFyDuse+p+TI5nr2iWq jRyL81TF+F6UssK2qw5oKVijbc7pEEXvReHSF4MHAkQm0vaIH4mX9bFvTBByfa8l v2FqLo3EeYvuR8mLDig7h9uv2XmR2zbZq1A/wCP02O+YRaGFEsjWeVDo8LzH93ef aQ883hzWYYEXNFwqHd+M5pj4+jeuD3iEVCjFmlF4a4NAWMKLFO5FYhaAgzrOGGO4 kck51HCq/4p1tfp+UtDqpItsYImyfNR9FiI//Sb/drA40d73yY01CB9yj1fFlaS4 iHc2kgzEIMSbUxNCJMf8BRIj+MZUuHjkvYklGxFzwciG/flFDPq1QMXudOI2+R43 jGNblioXBsh32W367J1YPgaGm6zubudaWauoMqtGnLP+ajWQ7tErAAl8Jy8E/Xt0 ksHsx3dV9eKN7iX875Cvglhko1hPPpQe57qgekm3p2wkBp9TSZeRv1dybnUNnflT 1TLuGxaHwothyoNJZetdR61NZVM4S7dey6hX5LyBkuDmnyMRt1PG95VBfSVImleo rHdvIsk4lVVLyY+d8yepPfxnbwzwZj4yIX05aLC82/0zrAr225o= =rupV -END PGP SIGNATURE-
