Bug 2442573

+++ This bug was initially created as a clone of Bug #2439813 +++

On both Fedora 44 (branched) and Rawhide currently, if you try to do a network install of KDE, the install process hangs during package scriptlets; it seems to get stuck during %triggerin of the ibus package. The GUI shows "Configuring gtk3.x86_64", but /tmp/dnf5.log shows the gtk3 scriptlet completed with return code 0, then shows 'start' for the ibus %triggerin , but that's the last entry - there's no 'stop' line for ibus. So it seems like we're stuck on ibus.

This has been happening on Fedora 44 since Fedora-44-20260206.n.3, but it only started happening on Rawhide with Fedora-Rawhide-20260210.n.0; the test uses default repos, so it was actually probably installing the package set from the previous compose, Fedora-Rawhide-20260209.n.0 , so that's most likely where the problem appeared in Rawhide. Though I can't see any obviously-related packages in the changelog.

Just installing @core plus ibus (via a kickstart) doesn't reproduce the problem, so some other packages have to be involved somehow.

I'll look into this more next week if nobody else can get to it.

--- Additional comment from Adam Williamson on 2026-02-24 00:17:37 +08 ---



--- Additional comment from Adam Williamson on 2026-02-24 00:34:13 +08 ---

In the dupe, kparal guessed we might actually be in the `dconf update || :` call in %posttrans, which is possible I guess. (It should be fairly easy to check with ps, so I'll take a look in a minute). He also proposed it as a blocker:

"Proposing for F44 blocker discussion. KDE is a release blocking environment, and Everything netinst is a release blocking deliverable."

I'm not sure that holds up, but we can talk about it in the meeting.

--- Additional comment from Adam Williamson on 2026-02-24 01:20:33 +08 ---

Nope, that's not it. I've just reproduced this and looked at the ps list, and I see `/bin/sh /var/tmp/rpm-tmp.G1eBN2 1`. /mnt/sysimage/var/tmp/rpm-tmp.G1eBN2 says:

[ -x /usr/bin/ibus ] && \
  /usr/bin/ibus write-cache --system &>/dev/null || :

so that's what we're stuck on. I do indeed see an `ibus write-cache --system` process, and a `/usr/bin/python3 /usr/share/ibus-typing-booster/engine/main.py --xml`, and `dbus-launch --autolaunch=(randomstrng) --binary-syntax --close-stderr`.

--- Additional comment from Kamil Páral on 2026-02-24 01:31:49 +08 ---

Discussed during blocker review meeting on 2025-02-23 [1]:

agreed 2439813 - punt (delay decision) - there's substantial sentiment that this ought to be blocking, but the current criteria don't clearly allow for that. whether the criteria should be adjusted to make this a blocker is a somewhat complex question we don't want to try and resolve live during a meeting, so we'll punt this to allow for more calm consideration of that

[1] https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/

--- Additional comment from Kamil Páral on 2026-02-24 01:45:04 +08 ---

(In reply to Kamil Páral from comment #4)
> Discussed during blocker review meeting on 2025-02-23 [1]:

I almost got the year correct. 2026-02-23.

--- Additional comment from Adam Williamson on 2026-02-24 03:09:23 +08 ---

Hmm. If I chroot into /mnt/sysimage and run `/usr/bin/ibus write-cache --system`, it runs and returns quite quickly, it doesn't get stuck. Not sure why the scriptlet invocation gets stuck.

--- Additional comment from Adam Williamson on 2026-02-24 03:58:50 +08 ---

I'm running an install with an ibus build patched to drop the `&>/dev/null` from the ibus write-cache call, so we get the messages from it. It looks like it prints:

INFO [scriptlet] (ibus write-cache:29935): IBUS-WARNING **: 19:50:24.268: Engines exec:/usr/libexec/ibus-engine-table --xml is failed:
INFO [scriptlet]
INFO [scriptlet] (ibus write-cache:29935): IBUS-WARNING **: 19:50:24.373: Engines exec:/usr/libexec/ibus-engine-anthy --xml is failed:

literally that - the messages look like there should be some more text indicating the reason, but there isn't.

If I run the command manually in chroot /mnt/sysimage , I get the same two messages first, but then I also get:

Engines exec:/usr/libexec/ibus-engine-typing-booster --xml is failed:
Engines exec:/usr/libexec/ibus-engine-libpinyin --xml is failed:
Engines exec:/usr/libexec/ibus-engine-m17n --xml is failed:

and a couple other things. That ties in with the apparently-stuck `/usr/bin/python3 /usr/share/ibus-typing-booster/engine/main.py --xml` process, obviously (the next message we're expecting from ibus write-cache is the "Engines exec:/usr/libexec/ibus-engine-typing-booster --xml is failed:" one).

Still don't know why the scriptlet call gets stuck while a manual one works, though.

--- Additional comment from Adam Williamson on 2026-02-24 05:36:01 +08 ---

OK, took a bit of fiddling but I managed to backtrace the dbus-launch process which seems to be at the bottom of the stuck processes pile, here's the trace:

#0  __internal_syscall_cancel (a1=a1@entry=140722696347344, a2=a2@entry=1, a3=a3@entry=-1, a4=a4@entry=0, a5=a5@entry=0, a6=a6@entry=0, nr=7) at cancellation.c:44
        result = -516
        pd = <optimized out>
        ch = <optimized out>
#1  0x00007f6340e5e234 in __syscall_cancel (a1=a1@entry=140722696347344, a2=a2@entry=1, a3=a3@entry=-1, a4=a4@entry=0, a5=a5@entry=0, a6=a6@entry=0, nr=7) at cancellation.c:75
        r = <optimized out>
#2  0x00007f6340ed843e in __GI___poll (fds=fds@entry=0x7ffc8e53ded0, nfds=nfds@entry=1, timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
No locals.
#3  0x00007f6340c8dbb0 in poll (__fds=0x7ffc8e53ded0, __nfds=1, __timeout=-1) at /usr/include/bits/poll2.h:44
No locals.
#4  read_block (fd=3, buf=0x558600568ab0, len=8) at /usr/src/debug/libxcb-1.17.0-7.fc44.x86_64/src/xcb_in.c:394
        pfd = {fd = 3, events = 1, revents = 0}
        ret = <optimized out>
        done = 0
#5  _xcb_in_read_block (c=c@entry=0x5586005637d0, buf=0x558600568ab0, len=len@entry=8) at /usr/src/debug/libxcb-1.17.0-7.fc44.x86_64/src/xcb_in.c:1087
        ret = <optimized out>
        done = 0
#6  0x00007f6340c9173e in read_setup (c=0x5586005637d0) at /usr/src/debug/libxcb-1.17.0-7.fc44.x86_64/src/xcb_conn.c:180
        newline = 10 '\n'
#7  xcb_connect_to_fd (fd=fd@entry=3, auth_info=<optimized out>) at /usr/src/debug/libxcb-1.17.0-7.fc44.x86_64/src/xcb_conn.c:386
        c = 0x5586005637d0
#8  0x00007f6340c919cf in xcb_connect_to_display_with_auth_info (displayname=displayname@entry=0x0, auth=auth@entry=0x0, screenp=screenp@entry=0x0) at /usr/src/debug/libxcb-1.17.0-7.fc44.x86_64/src/xcb_util.c:568
        fd = <optimized out>
        display = 1
        host = 0x5586005620f0 ""
        protocol = 0x0
        ourauth = {namelen = 0, name = 0x7f63411b6f31 <_dl_map_object_deps+1057> "H\203\275x\373\377\377", datalen = 1, data = 0x7f6340c8a530 ""}
        c = <optimized out>
        parsed = <optimized out>
#9  0x00007f6340c9225e in xcb_connect (displayname=displayname@entry=0x0, screenp=screenp@entry=0x0) at /usr/src/debug/libxcb-1.17.0-7.fc44.x86_64/src/xcb_util.c:522
No locals.
#10 0x00007f6341016f6a in _XConnectXCB (dpy=0x558600562410, display=0x0, screenp=0x7ffc8e53e26c) at /usr/src/debug/libX11-1.8.12-3.fc44.x86_64/src/xcb_disp.c:78
        host = 0x5586005620f0 ""
        n = 1
        c = <optimized out>
#11 0x00007f634100ea9d in XOpenDisplay (display=display@entry=0x0) at /usr/src/debug/libX11-1.8.12-3.fc44.x86_64/src/OpenDis.c:129
        dpy = 0x558600562410
        i = <optimized out>
        j = <optimized out>
        k = <optimized out>
        display_name = 0x5586005620d0 ":1"
        setup = 0x0
        iscreen = 0
        prefix = <optimized out>
        vendorlen = <optimized out>
        u = <optimized out>
        setuplength = <optimized out>
        usedbytes = 0
        mask = <optimized out>
        conn_buf_size = <optimized out>
        xlib_buffer_size = <optimized out>
#12 0x00005585c27ce1a3 in open_x11 () at ../tools/dbus-launch-x11.c:229
No locals.
#13 x11_init () at ../tools/dbus-launch-x11.c:472
        ok = <optimized out>
#14 0x00005585c27cbf12 in main (argc=4, argv=0x7ffc8e53ea18) at ../tools/dbus-launch.c:1060
        prev_arg = 0x7ffc8e540aed "--close-stderr"
        shname = <optimized out>
        runprog = <optimized out>
        remaining_args = <optimized out>
        exit_with_session = <optimized out>
        exit_with_x11 = 1
        binary_syntax = <optimized out>
        c_shell_syntax = 0
        bourne_shell_syntax = 0
        auto_shell_syntax = <optimized out>
        autolaunch = 1
        requires_arg = <optimized out>
        close_stderr = <optimized out>
        i = <optimized out>
        ret = <optimized out>
        bus_pid_to_launcher_pipe = {1089986000, 32611}
        bus_pid_to_babysitter_pipe = {-1907104524, 32764}
        bus_address_to_launcher_pipe = {-1907104520, 32764}
        config_file = 0x0
        existing_bus_supported = 0
        existing_bus = {dummy1 = 0x0, dummy2 = 0, dummy3 = 0, dummy_bit1 = 0, dummy_bit2 = 0, dummy_bit3 = 0, dummy_bits = 0}
        error_str = 0x0
        error = {name = 0x0, message = 0x0, dummy1 = 1, dummy2 = 0, dummy3 = 0, dummy4 = 0, dummy5 = 0, padding1 = 0x0}

so we're in X init stuff, here...theory: because the installer is running in a graphical environment we get into this codepath and get stuck, but when I do chroot /mnt/sysimage and run the command from a tty on vt3, we're *not* a graphical environment so we don't hit this codepath and everything's fine?

--- Additional comment from Adam Williamson on 2026-02-24 06:52:25 +08 ---

Another interesting finding: despite the fact that this happens during the install process in a scriptlet run in the installed system root, the bug depends on the *installer environment*. If I use the 20260209.n.0 netinst image, the bug doesn't happen, no matter whether I use the 20260209.n.0, 20260210.n.0 or today's compose as the repository. If I use the 20260210.n.0 netinst, or today's netinst, the bug always happens, even if I use the 20260209.n.0 compose as the install repo.

So, something changed in the installer environment between 0209.n.0 and 0210.n.0 that triggers this, somehow. The changelog is at https://lists.fedoraproject.org/archives/list/test-reports@lists.fedoraproject.org/thread/PPRJACJZSSRQMZ5SJKWNPNFRAYIZHCAD/ .

--- Additional comment from Adam Williamson on 2026-02-24 08:28:41 +08 ---

I was all set to guess that glib2 would be the culprit and get into bisecting it, only...it seems not to be. I tried both an updates.img with the previous glib2 build in it and a custom netinst ISO build with a '2.87.3' which is actually just a rebuild of 2.87.0, and both of those still hit the bug. So it must be something else, but nothing else looks as obvious of a suspect unfortunately. Possibly glibc? There's no changes to dbus or ibus-related bits that I can see, or libxcb, or anaconda. I guess gnome-kiosk is another vaguely plausible suspect? I'll keep trying options.

--- Additional comment from Adam Williamson on 2026-02-24 09:21:04 +08 ---

OK, I think this is somewhere in the gnome-shell / gnome-kiosk / mutter triad. https://adamwill.fedorapeople.org/updates-gs49.img is an updates.img containing the files from gnome-kiosk-49.0-4.fc44.x86_64.rpm , gnome-shell-49.2-4.fc44.x86_64.rpm and mutter-49.2-8.fc44.x86_64.rpm - I built it with:

[adamw@toolbx fedora-toolbox-43 anaconda (main %)]$ ./scripts/makeupdates -a ~/Downloads/gnome-kiosk-49.0-4.fc44.x86_64.rpm ~/Downloads/gnome-shell-49.2-4.fc44.x86_64.rpm ~/Downloads/mutter-49.2-8.fc44.x86_64.rpm

if I run a KDE install from the 20260210.n.0 Rawhide netinst using that updates.img , it completes successfully. If I run the same install from the same netinst without the updates.img, it hits the bug.

Another thing I forgot to post earlier, trimmed backtrace of the /usr/bin/python3 /usr/share/ibus-typing-booster/engine/main.py --xml process showing it is indeed the thing that spawned the dbus-launch process, via gtk and glib (I cut it off at the point where we get back into python gobject-introspection):

#0  __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
No locals.
#1  0x00007efdd44751ec in __internal_syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=a4@entry=0, a5=a5@entry=0, a6=a6@entry=0, nr=7) at cancellation.c:49
        result = <optimized out>
        pd = <optimized out>
        ch = <optimized out>
#2  0x00007efdd4475234 in __syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=a4@entry=0, a5=a5@entry=0, a6=a6@entry=0, nr=7) at cancellation.c:75
        r = <optimized out>
#3  0x00007efdd44ef43e in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:29
No locals.
#4  0x00007efdc5d0c26c in g_spawn_sync_impl (working_directory=0x0, argv=<optimized out>, envp=0x0, flags=G_SPAWN_SEARCH_PATH, child_setup=0x0, user_data=0x0, standard_output=<optimized out>, standard_error=<optimized out>, wait_status=0x7ffe3c39afc4, error=0x7ffe3c39b048) at ../glib/gspawn-posix.c:284
        fds = {{fd = 5, events = 25, revents = 0}, {fd = 7, events = 25, revents = 0}}
        outpipe = 5
        errpipe = 7
        pid = 29723
        ret = <optimized out>
        outstr = 0x563d19ee31a0
        errstr = <optimized out>
        failed = 0
        status = 22077
        __func__ = <optimized out>
        _g_boolean_var_10 = <optimized out>
        _g_boolean_var_11 = <optimized out>
        _g_boolean_var_12 = <optimized out>
        _g_boolean_var_13 = <optimized out>
        _g_boolean_var_14 = <optimized out>
#5  g_spawn_sync (working_directory=working_directory@entry=0x0, argv=<optimized out>, envp=envp@entry=0x0, flags=flags@entry=G_SPAWN_SEARCH_PATH, child_setup=child_setup@entry=0x0, user_data=user_data@entry=0x0, standard_output=0x7ffe3c39afd0, standard_error=0x7ffe3c39afc8, wait_status=0x7ffe3c39afc4, error=0x7ffe3c39b048) at ../glib/gspawn.c:153
        __func__ = "g_spawn_sync"
#6  0x00007efdc5d0c67f in g_spawn_command_line_sync (command_line=command_line@entry=0x563d19ee2ff0 "dbus-launch --autolaunch=51ec2262ee88469f9a84975e48057f59 --binary-syntax --close-stderr", standard_output=standard_output@entry=0x7ffe3c39afd0, standard_error=standard_error@entry=0x7ffe3c39afc8, wait_status=wait_status@entry=0x7ffe3c39afc4, error=error@entry=0x7ffe3c39b048) at ../glib/gspawn.c:590
        retval = <optimized out>
        argv = 0x563d19ee3250
        __func__ = "g_spawn_command_line_sync"
#7  0x00007efdc475b267 in get_session_address_dbus_launch (error=error@entry=0x7ffe3c39b048) at ../gio/gdbusaddress.c:1143
        ret = 0x0
        machine_id = 0x563d19ee2fc0 "51ec2262ee88469f9a84975e48057f59"
        command_line = 0x563d19ee2ff0 "dbus-launch --autolaunch=51ec2262ee88469f9a84975e48057f59 --binary-syntax --close-stderr"
        launch_stdout = 0x0
        launch_stderr = 0x0
        wait_status = 32766
        old_dbus_verbose = 0x0
        restore_dbus_verbose = 0
#8  0x00007efdc475cda4 in get_session_address_platform_specific (error=0x7ffe3c39b048) at ../gio/gdbusaddress.c:1258
        ret = <optimized out>
#9  g_dbus_address_get_for_bus_sync (bus_type=G_BUS_TYPE_SESSION, cancellable=0x0, error=0x0) at ../gio/gdbusaddress.c:1354
        has_elevated_privileges = 0
        ret = <optimized out>
        s = <optimized out>
        starter_bus = <optimized out>
        local_error = 0x0
        __func__ = "g_dbus_address_get_for_bus_sync"
#10 0x00007efdc476f566 in get_uninitialized_connection (bus_type=bus_type@entry=G_BUS_TYPE_SESSION, cancellable=cancellable@entry=0x0, error=error@entry=0x0) at ../gio/gdbusconnection.c:7979
        address = <optimized out>
        singleton = 0x7efdc486a008 <the_session_bus>
        ret = 0x0
        __func__ = "get_uninitialized_connection"
#11 0x00007efdc476f62e in g_bus_get_sync (bus_type=bus_type@entry=G_BUS_TYPE_SESSION, cancellable=cancellable@entry=0x0, error=error@entry=0x0) at ../gio/gdbusconnection.c:8079
        connection = <optimized out>
        __func__ = "g_bus_get_sync"
#12 0x00007efdc328c6b5 in environment_has_portals () at ../gdk/gdk.c:464
        bus = 0x0
        result = 0x0
        activatable_names = 0x0
        name = 0x0
        error = 0x0
        cached = <optimized out>
        has_portals = <optimized out>
        __func__ = <optimized out>
#13 gdk_display_should_use_portal (display=<optimized out>, portal_interface=0x0, min_version=0) at ../gdk/gdk.c:642
        sandboxed = <optimized out>
#14 gdk_display_should_use_portal (display=<optimized out>, portal_interface=0x0, min_version=0) at ../gdk/gdk.c:619
        sandboxed = <optimized out>
#15 0x00007efdc32b07f7 in file_transfer_portal_register () at ../gdk/filetransferportal.c:606
        called = <optimized out>
#16 0x00007efdc2f2de61 in file_transfer_portal_register () at ../gdk/gdk.c:239
        called = <optimized out>
        _pp = <optimized out>
        _ptr = <optimized out>
#17 gdk_content_init_serializers () at ../gdk/gdkcontentserializer.c:1054
        formats = <optimized out>
        f = <optimized out>
        charset = 0x0
        initialized = <optimized out>
#18 gdk_content_init_serializers () at ../gdk/gdkcontentserializer.c:966
        formats = <optimized out>
        f = <optimized out>
        charset = <optimized out>
        initialized = <optimized out>
        fmt = <optimized out>
        mimes = <optimized out>
        m = <optimized out>
        name = <optimized out>
        mime = <optimized out>
#19 gdk_pre_parse () at ../gdk/gdk.c:357
        disabled_features = <optimized out>
#20 do_pre_parse_initialization () at ../gtk/gtkmain.c:524
        env_string = <optimized out>
        slowdown = <optimized out>
        __func__ = <optimized out>
#21 gtk_init_check () at ../gtk/gtkmain.c:658
        ret = <optimized out>
        __func__ = <optimized out>
#22 gtk_init_check () at ../gtk/gtkmain.c:643
        ret = <optimized out>
        __func__ = "gtk_init_check"
#23 0x00007efdc5c0c056 in ffi_call_unix64 () at ../src/x86/unix64.S:104
No locals.
#24 0x00007efdc5c0805c in ffi_call_int (cif=cif@entry=0x563d19eda5c0, fn=fn@entry=0x7efdc2f2cc10 <gtk_init_check>, rvalue=<optimized out>, rvalue@entry=0x7ffe3c39b520, avalue=avalue@entry=0x0, closure=closure@entry=0x0) at ../src/x86/ffi64.c:676
        classes = {435004864, 22077, 1010414832, 32766}
        stack = <optimized out>
        argp = 0x7ffe3c39b370 "\003"
        arg_types = <optimized out>
        gprcount = 0
        ssecount = <optimized out>
        ngpr = 32509
        nsse = -976775186
        i = <optimized out>
        avn = <optimized out>
        flags = <optimized out>
        reg_args = <optimized out>
#25 0x00007efdc5c0ad8e in ffi_call (cif=cif@entry=0x563d19eda5c0, fn=0x7efdc2f2cc10 <gtk_init_check>, rvalue=rvalue@entry=0x7ffe3c39b520, avalue=0x0) at ../src/x86/ffi64.c:713
        arg_types = <optimized out>
        i = <optimized out>
        nargs = <optimized out>
        max_reg_struct_size = <optimized out>
#26 0x00007efdc5e3a080 in pygi_invoke_c_callable (function_cache=0x563d19eda530, state=<optimized out>, py_args=<optimized out>, py_nargsf=<optimized out>, py_kwnames=<optimized out>) at ../gi/pygi-invoke.c:722
        _save = 0x7efdd4c3c560 <_PyRuntime+315648>
        cache = 0x563d19eda530
        ffi_return_value = {v_boolean = 0, v_int8 = 0 '\000', v_uint8 = 0 '\000', v_int16 = 0, v_uint16 = 0, v_int32 = 0, v_uint32 = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_short = 0, v_ushort = 0, v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_ssize = 0, v_size = 0, v_string = 0x0, v_pointer = 0x0}
        ret = 0x0

--- Additional comment from Fedora Admin user for bugzilla script actions on 2026-02-24 09:21:14 +08 ---

Bug reports for this component on Red Hat Bugzilla are not actively monitored. Please consider reporting your issue directly to GNOME at https://gitlab.gnome.org/GNOME/ to improve the chances that your issue will be resolved. This issue should only be kept open if it:

1. Relates to Fedora packaging or integration with other Fedora components
2. Is required for Fedora release processes, such as blocker bugs and freeze exceptions

If this issue isn't needed for either of these two reasons, please:

 * create an issue with GNOME
 * add a link to the GNOME issue here
 * close this issue as CLOSED/UPSTREAM

Thank you!

--- Additional comment from fujiwara on 2026-02-24 12:53:53 +08 ---

ibus-daemon should not require to open any displays so I'd always say ibus-typing-booster should not open a display with "--xml" option.

But ibus-anthy does not require any displays with "--xml" option.

(In reply to Adam Williamson from comment #7)
> INFO [scriptlet] (ibus write-cache:29935): IBUS-WARNING **: 19:50:24.373:
> Engines exec:/usr/libexec/ibus-engine-anthy --xml is failed:

> Engines exec:/usr/libexec/ibus-engine-typing-booster --xml is failed:
> Engines exec:/usr/libexec/ibus-engine-libpinyin --xml is failed:
> Engines exec:/usr/libexec/ibus-engine-m17n --xml is failed:


I'm not sure why the script was failed.
You could run `/usr/libexec/ibus-engine-anthy --xml` command locally by manual and notice it just combines the XML strings.

--- Additional comment from Adam Williamson on 2026-02-24 14:40:18 +08 ---

The failures per se aren't necessarily a problem unless we really need these commands to actually *work* at install time (I'm assuming not since all it's doing is building/updating a cache). It's not uncommon for scriptlets running in the installer chroot environment to fail as it's a somewhat odd environment. It's the hang that's the problem, as it prevents the transaction completing.

--- Additional comment from Matthias Clasen on 2026-02-25 00:07:49 +08 ---

I would consider this an ibus (more specifically ibus-typing-booster) bug if it runs something in a trigger that tries to open a display or a dbus connection, or somesuch.

That being said, dbus calls should still time out after 25 seconds, allowing things to eventually fail. What is the deadlock here ?

--- Additional comment from Adam Williamson on 2026-02-25 01:35:44 +08 ---

I don't know. All I know is up above: the fact that the hang started happening with the GNOME 50 update, and the backtraces of the stuck processes.

I'm looking at ibus-typing-booster now and it looks like it does specifically try to *not* do anything that would open a display when running in the --xml mode, e.g. there's a long comment about it here:

https://github.com/mike-fabian/ibus-typing-booster/blob/c0bac5f73142c7f2cd846741402b7d627e909035/engine/main.py#L138

In the XML mode, large chunks of main.py are skipped. Essentially all that actually gets run is the environment discovery stuff and arg parsing at the start, the imports from xml.etree.ElementTree , and the write_xml() function. The IMApp class never gets instantiated. I'm trying now to think/see how it could still wind up in us getting into display code. I guess we also don't know how exactly the behaviour changed with GNOME 50. Did this display code path not get hit at all with GNOME 49? Or did we still hit it, but it didn't hang? I guess the latter is more likely, but I don't know for sure.

--- Additional comment from Adam Williamson on 2026-02-25 01:39:33 +08 ---

aha, so, main.py (unconditionally) imports itb_util.py , and itb_util.py imports Gdk and Gtk from itb_gtk . That's one obvious thing. There's also code in write_xml which is explicitly poking at desktop-y stuff:

        symbol = '🚀'
        if (itb_util.is_desktop('gnome')
            and itb_util.get_gnome_shell_version() >= (48, 3)):
            # If running on Gnome and gnome-shell is new enough to contain
            # https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3753
            # make the symbol black and white:
            symbol = '🚀\uFE0E'

so, all of that likely has something to do with this. I'll go do some git blame'ing on all this stuff and see if there's a pattern where the idea of avoiding display code in the XML output path got lost over time...

--- Additional comment from Adam Williamson on 2026-02-25 01:46:47 +08 ---

Yeah, looks like that's the case.

The big long comment comes from 2021: https://github.com/mike-fabian/ibus-typing-booster/commit/93ce0203c
The import of itb_util comes from 2024: https://github.com/mike-fabian/ibus-typing-booster/commit/e87d24c51
The code snippet in the previous comment comes from June 2025: https://github.com/mike-fabian/ibus-typing-booster/commit/295ae18e

so it does look like when adding various enhancements in 2024 and 2025, Mike might've forgotten about trying to avoid setting up a display on the --xml path.

--- Additional comment from Fedora Update System on 2026-02-25 05:26:58 +08 ---

FEDORA-2026-d8b30d5a3b (ibus-1.5.34~beta1-3.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-d8b30d5a3b

--- Additional comment from Adam Williamson on 2026-02-25 06:50:50 +08 ---

The update uses a suggestion from mclasen: it runs the trigger scriptlets via `env -i` so all environment variables are unset. This either avoids us going down the gdk->dbus-session path at all, or makes it not hang, we don't know which (probably the former), but it works. We suspect the install transaction uses the *installer environment's* environment variables (despite the fact it's installing into a chroot), which might or might not be considered a bug in itself, but we probably shouldn't poke it during a beta freeze; just changing these scriptlets is safer.

So there are a few different things here:

1) ibus-typing-booster should go back to avoiding the gtk/gdk path when just doing --xml. We can probably achieve that by separating the m17n bits it really needs in itb_util out from the rest of it.
2) arguably, all the desktop environment detection stuff in ibus-typing-booster is fragile at least for use in RPM scriptlets, because those don't always run within the same environment in which ibus-typing-booster will actually be used (e.g. when doing offline updates, as well as in this installer path).
3) there probably is a bug of some kind in gnome-shell/gnome-kiosk/mutter here, since we survived ibus-typing-booster going down the gtk/gdk path with GNOME 49, but we don't with GNOME 50.
4) we might want to consider dropping some or all of the installer environment's env vars from the set used for running the install package transaction.

Since there are criteria issues around accepting this as a blocker, but we have a fix/workaround now, I'm proposing it as an FE so we can get the fix in without worrying about the criteria.

--- Additional comment from Fedora Update System on 2026-02-25 07:10:20 +08 ---

FEDORA-2026-d8b30d5a3b has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-d8b30d5a3b`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-d8b30d5a3b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

--- Additional comment from Adam Williamson on 2026-02-25 07:22:30 +08 ---

+3 FE in https://pagure.io/fedora-qa/blocker-review/issue/2048 , marking accepted.

--- Additional comment from fujiwara on 2026-02-25 09:53:09 +08 ---

@Adam Williamson:
Thank you for the evaluation.

If we will enhance ibus-typing-booster, it would be better to fork this bug to the new one since a change was applied to ibus this time.