https://bugzilla.redhat.com/show_bug.cgi?id=2380583
Bug ID: 2380583
Summary: fcitx-anthy: FTBFS with change proposal CMake 4.0
Product: Fedora
Version: rawhide
Status: NEW
Component: fcitx-anthy
Assignee: robinlee.sysu(a)gmail.com
Reporter: fedora(a)lecris.me
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
robinlee.sysu(a)gmail.com, yanqiyu01(a)gmail.com
Blocks: 2376114
Target Milestone: ---
Classification: Fedora
\
Dear package maintainer,
This is an automated bug created due to a FTBFS when rebuilding this package
for the change proposal CMake 4.0.
The rebuild is being tracked in
https://copr.fedorainfracloud.org/coprs/cmake-4.0.
See https://fedoraproject.org/wiki/Changes/CMake4.0 for more information on how
to make the package compatible.
More specifically, depending on the state of the project:
- If it is actively maintained, please update the `cmake_minimum_required`, and
instruct upstream to do so as well.
To minimize future maintenance, please add a higher bound as well,
preferrably with the highest CMake version being
tested. You may use 4.0 as the higher bound as this is being tested in the
tracked copr project.
- If the project is not maintained, you may add
`CMAKE_POLICY_VERSION_MINIMUM=3.5` as a CMake variable or environment
variable.
You can check the build locally following the instructions in the change
proposal, or submit your build to the tracking
copr project.
Let me know if you encounter any issues, or need any other help.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=2376114
[Bug 2376114] CMake 4.0
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2380583
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2442573
Bug ID: 2442573
Summary: ibus-engine-typing-booster --xml can trigger
display/gtk/dbus
Product: Fedora
Version: 44
Hardware: All
OS: Linux
Status: NEW
Whiteboard: AcceptedFreezeException
Component: ibus-typing-booster
Keywords: AutomationTriaged
Severity: high
Assignee: mfabian(a)redhat.com
Reporter: petersen(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: adscvr(a)gmail.com, alpha(a)bookwar.info,
anaconda-maint(a)bot.bugzilla.redhat.com,
awilliam(a)redhat.com, bugzilla(a)colorremedies.com,
extras-qa(a)fedoraproject.org, fmuellner(a)redhat.com,
gnome-sig(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, jadahl(a)redhat.com,
johan.o.hedin(a)gmail.com, kkoukiou(a)redhat.com,
kparal(a)redhat.com, mclasen(a)redhat.com,
mfabian(a)redhat.com, mkolman(a)redhat.com,
ngompa13(a)gmail.com, otaylor(a)redhat.com,
petersen(a)redhat.com, philip.wyett(a)kathenas.org,
robatino(a)fedoraproject.org, tfujiwar(a)redhat.com,
w(a)wizard.zone
Depends On: 2439813
Blocks: 2362357 (BetaBlocker,F44BetaBlocker), 2362358
(BetaFreezeException,F44BetaFreezeException)
Target Milestone: ---
Classification: Fedora
+++ 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-…
--- 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.fedoraproj…
.
--- 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/c0bac5f73142c7f2cd8…
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.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=2362357
[Bug 2362357] Fedora 44 Beta blocker bug tracker
https://bugzilla.redhat.com/show_bug.cgi?id=2362358
[Bug 2362358] Fedora 44 Beta freeze exception bug tracker
https://bugzilla.redhat.com/show_bug.cgi?id=2439813
[Bug 2439813] KDE network installs hang during scriptlets (%triggerin on ibus)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2442573
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2445691
Bug ID: 2445691
Summary: IBus misrecognize LXQt desktop as Plasma desktop
Product: Fedora
Version: 44
OS: Linux
Status: NEW
Component: ibus
Severity: medium
Assignee: tfujiwar(a)redhat.com
Reporter: tagoh(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, tfujiwar(a)redhat.com
Target Milestone: ---
Classification: Fedora
I installed Fedora-LXQt-Live-44-20260308.n.0.x86_64.iso and ibus is brought up
by imsettings though, ibus warns it should be setup by systemsettings on KDE.
Even though it isn't KDE and there are no systemsettings nor similar equipment.
Reproducible: Always
Steps to Reproduce:
1.Install LXQt from Live with Japanese
2.Log into LXQt desktop
3.
Actual Results:
The notification from ibus open
Expected Results:
No notifications about KDE
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2445691
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2451645
Bug ID: 2451645
Summary: CVE-2026-34085 fontconfig: Fontconfig: Security flaw
allows arbitrary code execution or system crash
[fedora-all]
Product: Fedora
Version: rawhide
Status: NEW
Whiteboard: {"flaws": ["65df9a0b-8d8a-40c1-a4e1-f6ae7b5cc3e9"]}
Component: fontconfig
Keywords: Security, SecurityTracking
Severity: medium
Priority: medium
Assignee: tagoh(a)redhat.com
Reporter: trathi(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ajax(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, mclasen(a)redhat.com,
rstrode(a)redhat.com, tagoh(a)redhat.com
Blocks: 2451414 (CVE-2026-34085)
Target Milestone: ---
Classification: Fedora
Disclaimer: Community trackers are created by Red Hat Product Security team on
a best effort basis. Package maintainers are required to ascertain if the flaw
indeed affects their package, before starting the update process.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=2451414
[Bug 2451414] CVE-2026-34085 fontconfig: Fontconfig: Security flaw allows
arbitrary code execution or system crash
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2451645
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2402600
Bug ID: 2402600
Summary: google-roboto-fonts-3.013 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: google-roboto-fonts
Keywords: FutureFeature, Triaged
Assignee: dtardon(a)redhat.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: davide(a)cavalca.name, dtardon(a)redhat.com,
epel-packagers-sig(a)lists.fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Releases retrieved: 3.000, 3.001, 3.002, 3.003, 3.004, 3.005, 3.006, 3.007,
3.008, 3.009, 3.010, 3.011, 3.012, 3.013
Upstream release that is considered latest: 3.013
Current version/release in rawhide: 2.138-20.fc43
URL: https://github.com/googlefonts/roboto-3-classic
Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_M…
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
Based on the information from Anitya:
https://release-monitoring.org/project/12041/
To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/google-roboto-fonts
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2402600
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…