On Fri, 27 Jun 2025 at 04:19:40 +0200, Santiago Vila wrote:
On Fri, Jun 27, 2025 at 10:49:10AM +0900, Osamu Aoki wrote:
I understand disabling dbus-run-session solves build issue.
In an earlier message where I was not cc'd, Santiago wrote:
There was a package which failed in a similar way, and we found
a very simple fix which is to not use dbus-run-session, as in
the attached patch.
I'm surprised that this works, and the symptom from the failing build log
doesn't immediately look like it would be the right solution. I have a
theory for why it does work, but it's pretty much "by coincidence".
The build log says:
setxkbmap -layout af
...
setxkbmap -layout brai -variant left_hand
setxkbmap -layout brai -variant right_hand
setxkbmap -layout bt
Cannot open display ":99"
Error in layout bt variant right_hand
FAIL xkb-latin-layouts (exit status: 1)
To me, this looks like the X11 display (Xvfb) is exiting or crashing
after a while, resulting in the 29th or 30th of a series of setxkbmap
commands failing.
The first thing I would try is passing
-e /dev/stderr
to xvfb-run so that its diagnostic output is not suppressed, and also
-s "-noreset"
to avoid the failure mode described in
<https://salsa.debian.org/xorg-team/xserver/xorg-server/-/merge_requests/6>.
I think that failure mode is consistent with the observed symptoms, and
also the fact that it appears to be timing-related, with Santiago
reproducing the failure more easily on single-CPU virtual machines
(presumably having more than one CPU available perturbs the timing).
I see that ibus still build-depends on dbus-x11, despite using
dbus-run-session to run tests. I think what is happening with Santiago's
patch (not using dbus-run-session) is:
* something in the test tries to use the D-Bus session bus
* this has the side-effect that it forks and execs dbus-launch
* dbus-launch connects to the X11 server
* this means the transition from 1 to 0 clients never happens
* so the X server never resets
* so there is no time at which the X server is not accepting clients
If that is what is happening, then I don't think Santiago's patch is the
best solution - it's more like hiding the symptoms. Instead, I think it
would be better to keep the use of dbus-run-session, and pass the
`-s "-noreset"` options to xvfb-run.
I would prefer all software in Debian to stop relying on X11
autolaunching (dbus-launch), because dbus-launch is error-prone and
poorly-understood legacy code, and it results in the dbus-daemon being
run in an arbitrary execution environment inherited from whichever
client happens to have tried to use it first.
See also <https://lists.debian.org/debian-devel/2016/07/msg00484.html>.
Autobuilders in general do not have any of that. I would say that if
we have to choose between ensuring that packages build ok in a system
configured as an autobuilder or in a system running X11/GNOME/KDE,
we should choose the first.
Yes, running unit tests does not have much in common with running the
software in production. In a unit test environment, we usually want the
D-Bus session bus to be a temporary bus that is disconnected from all of
the desktop environment infrastructure (if any) so that everything is
under the build-time tests' control.
smcv
