Hi, On 03-02-2023 16:51, Nilesh Patra wrote:
There is a "skip-not-installable" that you could decleare in d/t/control for these packages (for the corresponding tests that suffer from uninst test deps), more details here[1]
Please don't use this. I regret I added it to autopkgtest because more often than not it hides real installability issues.
On Fri, Feb 03, 2023 at 04:07:09PM +0100, Jonas Smedegaard wrote:How do I skip some known impossible to check architectures in autopkgtests?
There's the Architecture field in the spec, but ...
Concretely, the packages src:rust-hyper-rustls and src:rust-rustls-native-certs both fail on powerpc64 and s390x, due to missing packages on those architectures: https://tracker.debian.org/pkg/rust-hyper-rustls https://tracker.debian.org/pkg/rust-rustls-native-certs It is *not* that the packages are unusable on those architectures - or at least that is yet unknown. Instead, the underlying complexity is that the autopkgtest-dependencies are architecture-independent source code but packaged as architecture-dependent and not offered on those architectures. Any thoughts on how¹ to proceed?
The current best way is to ask the release team to hint the package through. The problem here is that the migration software of the Release Team isn't smart enough (and there are cases where I believe there's just information missing in our control files) to figure out to not schedule some of those tests. But as the migration software looks at regressions, once the test is accepted to fail in testing, it's no longer a problem (except it looks unpleasant on your ci.d.n page). (It's a bit like the recent FTBFS on some architecture discussion we had here).
Another way is to declare "Architecture: !s390x !ppc64el" in d/t/control but I think this is in-appropriate for the said case.
It's not in-appropriate, but it feels like just another place to keep track of things. So I think a one-time action is better than such a place that you have to keep up-to-date. Also, if it at one day happens to succeed, you get it for free. But if you rather not bother the Release Team....
Paul
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature