Source: clevis Version: 20-1 Severity: important User: debian...@lists.debian.org Usertags: flaky X-Debbugs-Cc: debian...@lists.debian.org Control: affects -1 + src:glib2.0
clevis appears to have a "flaky" autopkgtest: that is, an autopkgtest that usually passes, but is not reliable. This means that when packages that are depended on by the test suite, such as the glib2.0 security fix currently in unstable, are trying to migrate to testing, the test will randomly pass or fail, causing those packages to be detected as having caused a regression when in fact they have not. For example see https://ci.debian.net/packages/c/clevis/testing/amd64/46456138/ (while testing a new glib2.0) and https://ci.debian.net/packages/c/clevis/testing/amd64/46260455/ (while testing a new glibc). I suspect this is a race condition in the test (perhaps starting a new server before the previous server has been cleaned up?) rather than genuinely being a regression in glib2.0 or glibc. If this test or this feature cannot be made fully reliable, one option is to skip it in debian/tests/unittests, and re-run it in a separate autopkgtest script that is marked as "Restrictions: flaky". A few GNOME packages use the convention that flaky tests are marked like this: @unittest.skipIf('DEB_ALLOW_FLAKY_TESTS' not in os.environ, 'https://bugs.debian.org/123456') def test_something_flaky(...): ... so that they are normally skipped, but we can force them to be run (to assess whether they are still a problem!) by using "export DEB_ALLOW_FLAKY_TESTS=1". smcv
