Bug#1108040: ibus: FTBFS: FAIL: xkb-latin-layouts

2025-07-01 Thread Boyuan Yang 

Hi all,

在 2025/6/30 19:37, Santiago Vila 写道:

On Sat, Jun 28, 2025 at 01:53:44PM +0100, Simon McVittie wrote:

Please don't treat this as precedent for "remove dbus-run-session from the
command-line" being a good first thing to try whenever there is a build or
build-time-test failure. If a test suite or a piece of build-time batch
processing is wrapped in dbus-run-session, it's usually there for a reason.


Ok. I take note.


If my theory about this particular FTBFS is correct, removing the use of
dbus-run-session results in the build using D-Bus X11 autolaunching
(dbus-launch, dbus-x11) instead, which works around the test failure via an
internal implementation detail of dbus-launch (the fact that it's an X11
client); and if that theory is correct, `xeyes &` would have been an almost
equivalent workaround (I say "almost" because it would have a race
condition), but the real solution would be to use
`xvfb-run -s "-noreset"` to suppress the X server's unwanted "reset"
behaviour.


I confirm that by adding those options to the xvfb-run call in
dh_auto_test (as in the attached patch), the problem disappears completely
(tested 50 times on machines with 1 cpu and 50 times on machines with 2 cpus).

Question for Boyuan: Since you did the last upload, would you please
consider making another team upload to fix this? (This is a very
targeted fix, so I think it should be ok).


Thanks for the discussion, and especially the explanation from smcv. Yes,
this now looks reasonable to me.

At the current stage of freeze, I don't think a direct upload to Unstable is
a good idea. Let me obtain an unblock pre-approval first.

Thanks,
Boyuan Yang


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1108040: ibus: FTBFS: FAIL: xkb-latin-layouts

2025-06-30 Thread Santiago Vila 
On Sat, Jun 28, 2025 at 01:53:44PM +0100, Simon McVittie wrote:
> Please don't treat this as precedent for "remove dbus-run-session from the
> command-line" being a good first thing to try whenever there is a build or
> build-time-test failure. If a test suite or a piece of build-time batch
> processing is wrapped in dbus-run-session, it's usually there for a reason.

Ok. I take note.

> If my theory about this particular FTBFS is correct, removing the use of
> dbus-run-session results in the build using D-Bus X11 autolaunching
> (dbus-launch, dbus-x11) instead, which works around the test failure via an
> internal implementation detail of dbus-launch (the fact that it's an X11
> client); and if that theory is correct, `xeyes &` would have been an almost
> equivalent workaround (I say "almost" because it would have a race
> condition), but the real solution would be to use
> `xvfb-run -s "-noreset"` to suppress the X server's unwanted "reset"
> behaviour.

I confirm that by adding those options to the xvfb-run call in
dh_auto_test (as in the attached patch), the problem disappears completely
(tested 50 times on machines with 1 cpu and 50 times on machines with 2 cpus).

Question for Boyuan: Since you did the last upload, would you please
consider making another team upload to fix this? (This is a very
targeted fix, so I think it should be ok).

Thanks.
diff -Nru ibus-1.5.32/debian/changelog ibus-1.5.32/debian/changelog
--- ibus-1.5.32/debian/changelog2025-04-11 02:22:56.0 +0200
+++ ibus-1.5.32/debian/changelog2025-07-01 00:30:00.0 +0200
@@ -1,3 +1,10 @@
+ibus (1.5.32-2) unstable; urgency=medium
+
+  * Team upload.
+  * Run xvfb-run with -s "-noreset". Closes: #1108040.
+
+ -- Boyuan Yang   Tue, 01 Jul 2025 00:30:00 +0200
+
 ibus (1.5.32-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru ibus-1.5.32/debian/rules ibus-1.5.32/debian/rules
--- ibus-1.5.32/debian/rules2025-03-20 23:24:46.0 +0100
+++ ibus-1.5.32/debian/rules2025-07-01 00:30:00.0 +0200
@@ -99,7 +99,7 @@
env \
  GVFS_DISABLE_FUSE=1 \
  dbus-run-session -- \
- xvfb-run --auto-servernum -- \
+ xvfb-run -s "-noreset" --auto-servernum -- \
  dh_auto_test -- \
  HOME=$(CURDIR)/debian/tmp-home \
  XDG_CACHE_HOME= \

Bug#1108040: ibus: FTBFS: FAIL: xkb-latin-layouts

2025-06-28 Thread Simon McVittie 

On Fri, 27 Jun 2025 at 04:19:40 +0200, Santiago Vila wrote:

I'm Cc:ing Simon McVittie who fixed a similar bug not a long time ago,
maybe he can explain better than me.


Are you referring to #1102099 in game-data-packager?

That was a rather different situation, where running Inkscape without 
access to a D-Bus session bus caused it to log warnings, but running it 
with access to an empty session bus (but without typical desktop session 
services) crashed out with an uncaught Gio::DBus::Error exception. I 
think that was really a bug in Inkscape: instead of crashing out with an 
uncaught exception when a non-fatal error occurred, it should have 
caught the exception and handled it appropriately (most likely by 
logging a warning or an informational message and continuing). We were 
able to work around the Inkscape bug by setting environment variables 
such as GIO_USE_VFS=local to suppress use of features that require D-Bus 
services, which are attempted by default but happen to be unnecessary 
for game-data-packager's batch-processing use-case.


Please don't treat this as precedent for "remove dbus-run-session from 
the command-line" being a good first thing to try whenever there is a 
build or build-time-test failure. If a test suite or a piece of 
build-time batch processing is wrapped in dbus-run-session, it's usually 
there for a reason.


If my theory about this particular FTBFS is correct, removing the use of 
dbus-run-session results in the build using D-Bus X11 autolaunching 
(dbus-launch, dbus-x11) instead, which works around the test failure via 
an internal implementation detail of dbus-launch (the fact that it's an 
X11 client); and if that theory is correct, `xeyes &` would have been an 
almost equivalent workaround (I say "almost" because it would have a 
race condition), but the real solution would be to use
`xvfb-run -s "-noreset"` to suppress the X server's unwanted "reset" 
behaviour.


If a test suite needs a D-Bus session bus, which many do, then 
dbus-run-session is a more appropriate tool to achieve that than 
dbus-launch.


smcv

Bug#1108040: ibus: FTBFS: FAIL: xkb-latin-layouts

2025-06-28 Thread Simon McVittie 

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 
. 

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 .


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

Bug#1108040: ibus: FTBFS: FAIL: xkb-latin-layouts

2025-06-26 Thread Osamu Aoki 
Hi,

Oops, I misunderstand your patch.  (I thought you were dropping some compile
option for ibus. I agree that there should be no system issue with this test
environment  change.)

It is still worth asking rational for this part of code to the original author
or assessing its validity by someone like Simon.

Osamu

Bug#1108040: ibus: FTBFS: FAIL: xkb-latin-layouts

2025-06-26 Thread Santiago Vila 
On Fri, Jun 27, 2025 at 10:49:10AM +0900, Osamu Aoki wrote:
> I understand disabling dbus-run-session solves build issue.
> 
> But, does anyone assessed impacts of disabling dbus-run-session for X11,
> GNOME/Wayland, KDE/Plasma, ?

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.

I'm Cc:ing Simon McVittie who fixed a similar bug not a long time ago,
maybe he can explain better than me.

> Without someone assessing its impacts and ordinate updates of affected 
> packages,
> it may be premature.

I don't understand what do you mean here. There are not affected packages,
we would only change the way the build-time tests are run for this package, and
we would do so by removing a line in dh_auto_test.

> In the mean time, should we downgrade severity of this bug to avoid package
> removal?

What about actually fixing the bug? Do you need a VM to reproduce the
problem? Please contact me privately and I will provide one.

Thanks.

Bug#1108040: ibus: FTBFS: FAIL: xkb-latin-layouts

2025-06-26 Thread Osamu Aoki 
Hi,

I understand disabling dbus-run-session solves build issue.

But, does anyone assessed impacts of disabling dbus-run-session for X11,
GNOME/Wayland, KDE/Plasma, ?

Without someone assessing its impacts and ordinate updates of affected packages,
it may be premature.

In the mean time, should we downgrade severity of this bug to avoid package
removal?

Best regards,

Osamu

Bug#1108040: ibus: FTBFS: FAIL: xkb-latin-layouts

2025-06-19 Thread Boyuan Yang 

X-Debbugs-CC: [email protected]

Hi,

在 2025/6/19 12:28, Santiago Vila 写道:

El 19/6/25 a las 18:13, Boyuan Yang escribió:

The build failure may not happen everywhere, but it happens very
consistently here. If you could not reproduce the bug please contact
me privately, as I am willing to provide ssh access to a virtual
machine where the bug is fully reproducible.

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.


Indeed I cannot reproduce the bug with the "official" modern sbuild
toolchain (i.e. mmdebootstrap-based one) as described in 
https://wiki.debian.org/sbuild .
If it does not FTBFS on official Debian buildd network, this bug does
not warrant an RC severity.


That's not really accurate. It's only an approximate rule which some people use
to discard misconfigured autobuilders, but that's not the case here.
In either case, this is a violation of Policy 4.2.


OTOH I wonder what's the difference between your setup and mine.
I don't have time for remote debugging recently, but probably we
can find some time slots later.


Apparently, for this failure, the less CPUs, the greater the probability of 
failure.

If you want to reproduce it yourself, please try GRUB_CMDLINE_LINUX="nr_cpus=1".
If that does not work, contact me privately and I will gladly offer a VM
to test (I already have ansible rules for that sort of thing).

[ However, I can tell you that I have already tested the patch and built
the package successfully 100 times on the same systems where it used
to fail, so I believe the patch is ok ]


I tried with exposing only a single CPU for the OS and repeated package builds,
but no luck yet with all builds being successful.

In this case I would handle this bug report to the listed package maintainers,
especially Changwoo who authored the current test lines as in commit
https://salsa.debian.org/debian/ibus/-/commit/0c0df35bcb388c79b17f24a35f7f00b23be1e2ea
 .
It has been several years, and I am not sure if that is still our best approach
for executing tests.

Thanks,
Boyuan Yang


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1108040: ibus: FTBFS: FAIL: xkb-latin-layouts

2025-06-19 Thread Santiago Vila 

El 19/6/25 a las 18:13, Boyuan Yang escribió:

The build failure may not happen everywhere, but it happens very
consistently here. If you could not reproduce the bug please contact
me privately, as I am willing to provide ssh access to a virtual
machine where the bug is fully reproducible.

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.


Indeed I cannot reproduce the bug with the "official" modern sbuild
toolchain (i.e. mmdebootstrap-based one) as described in 
https://wiki.debian.org/sbuild .
If it does not FTBFS on official Debian buildd network, this bug does
not warrant an RC severity.


That's not really accurate. It's only an approximate rule which some people use
to discard misconfigured autobuilders, but that's not the case here.
In either case, this is a violation of Policy 4.2.


OTOH I wonder what's the difference between your setup and mine.
I don't have time for remote debugging recently, but probably we
can find some time slots later.


Apparently, for this failure, the less CPUs, the greater the probability of 
failure.

If you want to reproduce it yourself, please try GRUB_CMDLINE_LINUX="nr_cpus=1".
If that does not work, contact me privately and I will gladly offer a VM
to test (I already have ansible rules for that sort of thing).

[ However, I can tell you that I have already tested the patch and built
the package successfully 100 times on the same systems where it used
to fail, so I believe the patch is ok ]

Thanks.

Bug#1108040: ibus: FTBFS: FAIL: xkb-latin-layouts

2025-06-19 Thread Boyuan Yang 

Hi,

在 2025/6/19 11:07, Santiago Vila 写道:

Package: src:ibus
Version: 1.5.32-1
Severity: serious
Tags: ftbfs trixie sid patch

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
FAIL: xkb-latin-layouts
===


(ibus-daemon:128538): IBUS-WARNING **: 13:46:54.504: 13:46:54.504290: Failed to unlink 
/<>/src/tests/tmp-xkb-latin-layouts/ibus-daemon.pid: No such file 
or directory
portal is not running: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: 
The name org.freedesktop.portal.IBus was not provided by any .service files
setxkbmap -layout af
setxkbmap -layout af -variant fa-olpc
setxkbmap -layout af -variant ps-olpc
setxkbmap -layout af -variant ps
setxkbmap -layout af -variant uz
setxkbmap -layout af -variant uz-olpc
setxkbmap -layout am
setxkbmap -layout am -variant eastern
setxkbmap -layout am -variant eastern-alt
setxkbmap -layout am -variant phonetic
setxkbmap -layout am -variant phonetic-alt
setxkbmap -layout am -variant western
setxkbmap -layout ara
setxkbmap -layout ara -variant azerty
setxkbmap -layout ara -variant azerty_digits
setxkbmap -layout ara -variant buckwalter
setxkbmap -layout ara -variant digits
setxkbmap -layout ara -variant qwerty
setxkbmap -layout ara -variant qwerty_digits
setxkbmap -layout az -variant cyrillic
setxkbmap -layout bd
setxkbmap -layout bd -variant probhat
setxkbmap -layout bg
setxkbmap -layout bg -variant bas_phonetic
setxkbmap -layout bg -variant phonetic
setxkbmap -layout brai
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)


Testsuite summary for ibus 1.5.32

# TOTAL: 15
# PASS:  11
# SKIP:  3
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See src/tests/test-suite.log for debugging.
Some test(s) failed.  Please report this to https://github.com/ibus/ibus/issues,
together with the test-suite.log file (gzipped) and your system
information.  Thanks.

make[7]: *** [Makefile:1376: test-suite.log] Error 1
make[7]: Leaving directory '/<>/src/tests'
make[6]: *** [Makefile:1511: check-TESTS] Error 2
make[6]: Leaving directory '/<>/src/tests'
make[5]: *** [Makefile:1680: check-am] Error 2
make[5]: Leaving directory '/<>/src/tests'
make[4]: *** [Makefile:2964: check-recursive] Error 1
make[4]: Leaving directory '/<>/src'
make[3]: *** [Makefile:3115: check] Error 2
make[3]: Leaving directory '/<>/src'
make[2]: *** [Makefile:725: check-recursive] Error 1
make[2]: Leaving directory '/<>'
dh_auto_test: error: make -j1 check "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 HOME=/<>/debian/tmp-home XDG_CACHE_HOME= XDG_CONFIG_HOME= XDG_DATA_HOME= XDG_DATA_DIRS= XDG_RUNTIME_DIR=/<>/debian/tmp-home/run 
DISABLE_DAEMONIZE_IN_TESTS=1 "DISABLE_GUI_TESTS=ibus-bus ibus-compose ibus-keypress test-stress" returned exit code 2

make[1]: *** [debian/rules:99: override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:28: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


The above is just how the build ends and not necessarily the most relevant part.
If required, the full build log is available here:

https://people.debian.org/~sanvila/build-logs/202506/

The build failure may not happen everywhere, but it happens very
consistently here. If you could not reproduce the bug please contact
me privately, as I am willing to provide ssh access to a virtual
machine where the bug is fully reproducible.

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.


Indeed I cannot reproduce the bug with the "official" modern sbuild
toolchain (i.e. mmdebootstrap-based one) as described in 
https://wiki.debian.org/sbuild .
If it does not FTBFS on official Debian buildd network, this bug does
not warrant an RC severity.

OTOH I wonder what's the difference between your setup and mine.
I don't have time for remote debugging recently, but probably we
can find some time slots later.

Thanks,
Boyuan Yang


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1108040: ibus: FTBFS: FAIL: xkb-latin-layouts

2025-06-19 Thread Santiago Vila 

Package: src:ibus
Version: 1.5.32-1
Severity: serious
Tags: ftbfs trixie sid patch

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
FAIL: xkb-latin-layouts
===


(ibus-daemon:128538): IBUS-WARNING **: 13:46:54.504: 13:46:54.504290: Failed to unlink 
/<>/src/tests/tmp-xkb-latin-layouts/ibus-daemon.pid: No such file 
or directory
portal is not running: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: 
The name org.freedesktop.portal.IBus was not provided by any .service files
setxkbmap -layout af
setxkbmap -layout af -variant fa-olpc
setxkbmap -layout af -variant ps-olpc
setxkbmap -layout af -variant ps
setxkbmap -layout af -variant uz
setxkbmap -layout af -variant uz-olpc
setxkbmap -layout am
setxkbmap -layout am -variant eastern
setxkbmap -layout am -variant eastern-alt
setxkbmap -layout am -variant phonetic
setxkbmap -layout am -variant phonetic-alt
setxkbmap -layout am -variant western
setxkbmap -layout ara
setxkbmap -layout ara -variant azerty
setxkbmap -layout ara -variant azerty_digits
setxkbmap -layout ara -variant buckwalter
setxkbmap -layout ara -variant digits
setxkbmap -layout ara -variant qwerty
setxkbmap -layout ara -variant qwerty_digits
setxkbmap -layout az -variant cyrillic
setxkbmap -layout bd
setxkbmap -layout bd -variant probhat
setxkbmap -layout bg
setxkbmap -layout bg -variant bas_phonetic
setxkbmap -layout bg -variant phonetic
setxkbmap -layout brai
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)


Testsuite summary for ibus 1.5.32

# TOTAL: 15
# PASS:  11
# SKIP:  3
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See src/tests/test-suite.log for debugging.
Some test(s) failed.  Please report this to https://github.com/ibus/ibus/issues,
together with the test-suite.log file (gzipped) and your system
information.  Thanks.

make[7]: *** [Makefile:1376: test-suite.log] Error 1
make[7]: Leaving directory '/<>/src/tests'
make[6]: *** [Makefile:1511: check-TESTS] Error 2
make[6]: Leaving directory '/<>/src/tests'
make[5]: *** [Makefile:1680: check-am] Error 2
make[5]: Leaving directory '/<>/src/tests'
make[4]: *** [Makefile:2964: check-recursive] Error 1
make[4]: Leaving directory '/<>/src'
make[3]: *** [Makefile:3115: check] Error 2
make[3]: Leaving directory '/<>/src'
make[2]: *** [Makefile:725: check-recursive] Error 1
make[2]: Leaving directory '/<>'
dh_auto_test: error: make -j1 check "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 
HOME=/<>/debian/tmp-home XDG_CACHE_HOME= XDG_CONFIG_HOME= XDG_DATA_HOME= XDG_DATA_DIRS= 
XDG_RUNTIME_DIR=/<>/debian/tmp-home/run DISABLE_DAEMONIZE_IN_TESTS=1 
"DISABLE_GUI_TESTS=ibus-bus ibus-compose ibus-keypress test-stress" returned exit code 2
make[1]: *** [debian/rules:99: override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:28: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


The above is just how the build ends and not necessarily the most relevant part.
If required, the full build log is available here:

https://people.debian.org/~sanvila/build-logs/202506/

The build failure may not happen everywhere, but it happens very
consistently here. If you could not reproduce the bug please contact
me privately, as I am willing to provide ssh access to a virtual
machine where the bug is fully reproducible.

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.

Thanks.commit 590938184e22c5a08ea35ff8ee6ce8441d539433
Author: Santiago Vila 
Date:   Thu Jun 19 14:37:09 2025 +0200

Do not use dbus-run-session to run tests. Closes: #XXX.

diff --git a/debian/rules b/debian/rules
index 491c553d..35cc7da7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -98,7 +98,6 @@ override_dh_auto_test:
mkdir -p -m700 $(CURDIR)/debian/tmp-home/run
env \
  GVFS_DISABLE_FUSE=1 \
- dbus-run-session -- \
  xvfb-run --auto-servernum -- \
  dh_auto_test -- \
  HOME=$(CURDIR)/debian/tmp-home \