Control: tags -1 moreinfo On 4/17/25 10:23 AM, Paul Gevers wrote:
I looked at the results of the autopkgtest of your package. I noticed that it regularly fails on arm64, while other architectures seem fine. Unfortunately, the test doesn't produce any output, so I can't give any advice on the failure based on that. I noticed that this test downloads some data from the internet, maybe adding a timeout to wget and some debugging info might help identify problems related to that. Maybe having a retry in case of network issues might be prudent. The arm64 ci.d.n hosts are located in China (as are the loong64 and riscv64 hosts, which don't seem to suffer (or less)).
wget already retries 20 times by default I don't see how that can be improved. If the network fails, the autopkgtest cannot be run. Runner with unreliable network should not satisfy the needs-internet requirement.
Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests.
Gotta love how autopkgtest are just another hindrance to testing migration.
Don't hesitate to reach out if you need help and some more information from our infrastructure.
I've made the wget and tar commands verbose, but that doesn't solve the problem. Removing the autopkgtest or excluding unreliable architectures will be needed instead. I don't really want to do either, but nuking the autopkgtest from the package resolves this class of issues forever. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
