Bug#1093686: rhythmbox: FTBFS: test-rhythmdb intermittently fails
Control: reassign 1093686 src:rhythmbox
Control: reassign 1111542 src:rhythmbox
Control: merge 1093686 1111542
On Tue, 21 Jan 2025 at 10:59:38 +0000, Simon McVittie wrote:
Or running xvfb-run with -noreset might help (see also
<https://salsa.debian.org/xorg-team/xserver/xorg-server/-/merge_requests/6>
and <https://bugs.debian.org/981201>).
Looking more closely at rhythmbox, I think this is more likely to be the
actual problem with rhythmbox's tests than a race condition in xvfb-run,
so I've unmerged the two rhythmbox bugs from #1095028. rhythmbox has
several unit tests, each of which connects to the X11 display, so if the
X server has its default behaviour of "resetting" (and in the process,
briefly not listening on its socket) after each transition from 1 client
to 0 clients, we can expect that the tests will intermittently fail to
connect to X11.
It is possible that the giza package, whose test failures led to a race
condition in xvfb-run being hypothesized (#1095028), is in fact also
suffering from the same thing - but I have no particular knowledge of
the giza package or how it works, so I can't be sure about that. As a
result I've left #1095028 assigned to xvfb.
I still think that -noreset would be a better default for xvfb-run,
because the "reset" behaviour regularly gives packages a source of
intermittent test failures and I can't think of any situations where it
would actually be desirable; but if the maintainers of xvfb-run are
concerned about backward compatibility, then every package with two or
more X11-dependent unit tests (especially if they run in parallel) will
have to continue to work around it.
What I'm intending to try in rhythmbox is:
1. Run xvfb-run with `-s "-noreset"` (and other commonly-used options).
If this makes the tests apparently reliable, great, we can stop here.
2. Add a short sleep after starting Xvfb, something like:
xvfb-run ... sh -c 'sleep 3; exec "$@"' sh "$@"
If there is indeed a race condition in xvfb-run, that will work
around it by giving Xvfb an extra 3 seconds to start up, which in
practice should be enough to make Xvfb win the race. If that makes
the tests apparently reliable, great, we can stop here.
3. As a last resort, if neither of those works, temporarily ignore test
failures.
smcv
Reply to: