OK. We have a really "funny" story here...
the failing test use /usr/bin/busted, that is provided by lua-busted
$ head -n1 /usr/bin/busted
#!/usr/bin/env lua
lua-busted used to depends on 'lua5.2 | lua' so both lua5.4 and lua5.2
were installed during the previous (successful) builds
but... lua5.2 was used as the default lua interpreter
https://salsa.debian.org/lua-team/lua5.2/-/blob/master/debian/lua5.2.postinst?ref_type=heads#L6
https://salsa.debian.org/lua-team/lua5.4/-/blob/master/debian/lua5.4.postinst?ref_type=heads#L8
so even if the game was linked to liblua5.4-0, the tests ran with lua5.2
since the upload of lua-busted 2.2.0-2, lua5.2 isn't pulled anymore and
'/usr/bin/busted' use lua5.4.
One of corsix-th tests is really unstable with lua5.4, it succeed ~15%
of the time. But it was always flaky with lua5.4, we just didn't know it
because lua5.2 was used.
corsix-th has been linked to liblua5.4 since bookworm and even if that
particular test was failing, the game remained playable and no one
complained.
lua5.2 is actively being remove from debian so simply going back to it
isn't an option
Short term solution (to complete the ffmpeg8 transition):
* build-depends on lua5.3 that also have a higher priority than lua5.4
(almost the same situation than previously but with lua5.3 instead of
lua5.2)
* remove the flaky test
A more long term solution will likely involves corsix-th upstream developers
br,
Sébastien
