[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: how to skip some archs for autopkgtests


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

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:


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

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....


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply to: