Hi Iain, On Tue, Nov 10, 2020 at 11:26:07AM +0000, Iain Lane wrote: > On Tue, Nov 10, 2020 at 09:32:46AM +0100, Andreas Tille wrote: > > drop-seq-tools/arm64 has unsatisfiable dependency > > This is what's blocking you.
That's what I assumed. > > uninstallable on arch *, not running autopkgtest there > > Not this one. Yes, that's true but its part of my question: Why should all these tests be run if the dependencies are not available on that architecture. Wouldn't it be more sane to check dependencies first before running a test that will fail for sure? > > While the package itself is > > > > Architecture: all > > > > it depends from picard-tools which is amd64 only. > > The release team recently swapped i386 for arm64 in > "NOBREAKALL_ARCHES"[0][1]. That means that arch:all packages need to be > installable on arm64 and yours isn't. AFAIK. OK, fine. For the example drop-seq-tools I could make it Architecture: amd64 which is solving the current migration problem. However, I'm currently checking failing autopkgtests for Debian Med packages and add Architecture fields to debian/tests/control. In most cases this is perfectly easy auto-detectable from the package dependencies that the test will fail. I would love to see that dependency issue resolved by debci in the first place instead of assuming that maintainers will maintain this inside the control file. Chances are pretty good that once those dependencies might become available maintainers will simply forget to add a new architecture to debian/tests/control. That way we might hide future tests on those architectures from debci. > > [ snip the rest which was about tests and I don't think that's the > > problem here ] Not really. My example was possibly not the best - I hope I was able to clarify this now. Kind regards Andreas. > [0] > https://salsa.debian.org/release-team/britney2/-/commit/5cb5235c06012b2a56e50e544f6cbe3adbbf35ab > [1] > https://salsa.debian.org/release-team/britney2/-/commit/2caf0fe4ea4de5541f3d8e71d5d69737f8d84fee -- http://fam-tille.de