On 12/1/20 10:55 AM, Nicholas Guriev wrote: > Hello! > On Sat, 28 Nov 2020 17:21:05 +0100 Matthias Klose <d...@debian.org> > wrote: >> Now, there's at least one test (the clang-12 one), which never will > succeed. So >> what's the value of these tests when you always have failures due to >> non-existing versions? Please just test for the default gcc and > clang. > > The main idea is to let me discover issues as early as possible, before > new toolchains become default. When a new compiler goes into archive, > this CI test is triggered, although it does not block migrating when the > compiler is not available yet due to "skip-not-installable" restriction. > > Testing against default GCC and Clang is already done on buildd trough > the d/rules file and thanks to debhelper(7) which calls to `make test` > during package build. Does it make sense to duplicate the work and do > the same trough autopkgtest(1)?
but the problem is that you don't get any valid test result for testing. The test will always fail in testing, and the migration to testing is not blocked because this is not seen as a regression. It doesn't matter if the tests will fail in unstable or not. So no, autopkg tests should not depend on packages which are not available in testing.
