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

Simon McVittie wrote...
(...)

Unfortunately, these log files are no longer available. Do you have
an indicationing which test is failing? I guess it's not a particular one.

However, I was able to produce a similar pattern, and I guess it's the
same story:

| I: Running test pin-tang
| 2024/11/05 17:55:00 socat[184783] E bind(6, {AF=2 0.0.0.0:8888}, 16): Address already in use
randomly, and that might either hit an existing port, or one used a few
seconds earlier.

Do you have an indication how often this autopkgtest failure happens? A
listening socket is openend 22 times during the test, out of 64512
possible port numbers. If my birthday paradoxon calculations are
correct, a collision has a likelyhood of roughly 0.3 percent. So I'm not
certain whether I'm looking into the right corner, and therefore I'm a
bit reluctant to implement a workaround.

    Christoph

...

The amd64 tests have been more reliable recently, but these logs look
like they might be the same thing:
https://ci.debian.net/packages/c/clevis/testing/armel/53675144/
https://ci.debian.net/packages/c/clevis/testing/i386/54098643/
https://ci.debian.net/packages/c/clevis/testing/i386/54085472/
https://ci.debian.net/packages/c/clevis/testing/i386/53646677/
https://ci.debian.net/packages/c/clevis/testing/ppc64el/53647044/

You have access to all of the same information I do, via
<https://ci.debian.net/packages/c/clevis/>.

    smcv

Simon McVittie wrote...
(...)

Upstream did some work in that area, so I'll upload the new release in
the next days in the hope this issue will go away. I'll occasionally
check the CI logs, still feel free to ping me if you see something in
the upcoming 21-1.

Kind regards,

    Christoph

Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.

Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.