i18n-bugs March 2026

i18n-bugs@lists.fedoraproject.org

1 participants
61 discussions

[Bug 2380583] New: fcitx-anthy: FTBFS with change proposal CMake 4.0
by bugzilla＠redhat.com 20 Apr '26

20 Apr '26

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…

1 2

[Bug 2442573] New: ibus-engine-typing-booster --xml can trigger display/gtk/dbus
by bugzilla＠redhat.com 10 Apr '26

10 Apr '26

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…

1 4

[Bug 2326455] New: [abrt] ibus-panel: wl_proxy_get_version(): ibus-ui-gtk3 killed by SIGSEGV
by bugzilla＠redhat.com 08 Apr '26

08 Apr '26

https://bugzilla.redhat.com/show_bug.cgi?id=2326455 Bug ID: 2326455 Summary: [abrt] ibus-panel: wl_proxy_get_version(): ibus-ui-gtk3 killed by SIGSEGV Product: Fedora Version: 41 Hardware: x86_64 Status: NEW Whiteboard: abrt_hash:c75ecfa14c60b64aa5a0248ea5b67ce73f59fb4e;VAR IANT_ID=kde; Component: ibus Assignee: tfujiwar(a)redhat.com Reporter: josiah.kelsall(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, tfujiwar(a)redhat.com Target Milestone: --- Classification: Fedora Version-Release number of selected component: ibus-panel-1.5.31-1.fc41 Additional info: reporter: libreport-2.17.15 type: CCpp reason: ibus-ui-gtk3 killed by SIGSEGV journald_cursor: s=bddcfc14326c495fb4104e9a987039d9;i=5494c7d;b=02ef6094b287413cb6d4e63a1ff0a693;m=2ae2fdda6;t=626e97fe3eeec;x=3ac86f5e15988c executable: /usr/libexec/ibus-ui-gtk3 cmdline: /usr/libexec/ibus-ui-gtk3 --enable-wayland-im --exec-daemon --daemon-args $'--xim --panel disable' cgroup: 0::/user.slice/user-5120.slice/user@5120.service/session.slice/plasma-kwin_wayland.service rootdir: / uid: 5120 kernel: 6.11.7-300.fc41.x86_64 package: ibus-panel-1.5.31-1.fc41 runlevel: N 5 backtrace_rating: 4 crash_function: wl_proxy_get_version Truncated backtrace: Thread no. 1 (15 frames) #0 wl_proxy_get_version at ../src/wayland-client.c:2313 #1 zwp_input_method_context_v1_preedit_string at ../../client/wayland/input-method-unstable-v1-client-protocol.h:389 #2 _context_hide_preedit_text_cb at ../../client/wayland/ibuswaylandim.c:500 #5 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:3887 #6 signal_emit_valist_unlocked at ../gobject/gsignal.c:3519 #9 ibus_input_context_g_signal at /usr/src/debug/ibus-1.5.31-1.fc41.x86_64/src/ibusinputcontext.c:605 #11 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:3927 #12 signal_emit_valist_unlocked at ../gobject/gsignal.c:3519 #15 on_signal_received at ../gio/gdbusproxy.c:874 #16 emit_signal_instance_in_idle_cb at ../gio/gdbusconnection.c:4189 #19 g_main_context_dispatch_unlocked at ../glib/gmain.c:4208 #20 g_main_context_iterate_unlocked.isra.0 at ../glib/gmain.c:4273 #22 gtk_main at ../gtk/gtkmain.c:1329 #23 application_run at /usr/src/debug/ibus-1.5.31-1.fc41.x86_64/ui/gtk3/application.vala:87 #24 application_main at /usr/src/debug/ibus-1.5.31-1.fc41.x86_64/ui/gtk3/application.vala:354 Potential duplicate: bug 2252227 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2326455 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 13

[Bug 2445691] New: IBus misrecognize LXQt desktop as Plasma desktop
by bugzilla＠redhat.com 07 Apr '26

07 Apr '26

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…

1 9

[Bug 2451645] New: CVE-2026-34085 fontconfig: Fontconfig: Security flaw allows arbitrary code execution or system crash [fedora-all]
by bugzilla＠redhat.com 07 Apr '26

07 Apr '26

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…

1 1

[Bug 2402600] New: google-roboto-fonts-3.013 is available
by bugzilla＠redhat.com 05 Apr '26

05 Apr '26

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…

1 7

[Bug 2402531] New: fedora is using obselete version of Roboto font
by bugzilla＠redhat.com 05 Apr '26

05 Apr '26

https://bugzilla.redhat.com/show_bug.cgi?id=2402531 Bug ID: 2402531 Summary: fedora is using obselete version of Roboto font Product: Fedora Version: 42 Status: NEW Component: google-roboto-fonts Assignee: dtardon(a)redhat.com Reporter: uneasy_latitude544(a)simplelogin.com 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 Description of problem: fedora is using old version of Roboto font, see readme in https://github.com/googlefonts/roboto-2?tab=readme-ov-file, more updated version https://github.com/googlefonts/roboto-3-classic v3.012 Version-Release number of selected component (if applicable): v2.138 How reproducible: Yes. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2402531 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 3

[Bug 2401389] New: translate-toolkit-3.16.2 is available
by bugzilla＠redhat.com 31 Mar '26

31 Mar '26

https://bugzilla.redhat.com/show_bug.cgi?id=2401389 Bug ID: 2401389 Summary: translate-toolkit-3.16.2 is available Product: Fedora Version: rawhide Status: NEW Component: translate-toolkit Keywords: FutureFeature, Triaged Assignee: sshil(a)redhat.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, mfabian(a)redhat.com, petersen(a)redhat.com, sshil(a)redhat.com, sundeep_anand(a)yahoo.com Target Milestone: --- Classification: Fedora Releases retrieved: 3.16.2 Upstream release that is considered latest: 3.16.2 Current version/release in rawhide: 3.16.1-1.fc44 URL: http://toolkit.translatehouse.org/ 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/3685/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/translate-toolkit -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2401389 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 21

[Bug 2453024] langpacks-ar is missing google-noto-sans-arabic-ui-vf-fonts
by bugzilla＠redhat.com 30 Mar '26

30 Mar '26

https://bugzilla.redhat.com/show_bug.cgi?id=2453024 Jens Petersen <petersen(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |i18n-bugs(a)lists.fedoraproje | |ct.org -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2453024

1 0

[Bug 1326470] glibc `locale -a` output does not exactly match between locale-archive and langpacks.
by bugzilla＠redhat.com 30 Mar '26

30 Mar '26

https://bugzilla.redhat.com/show_bug.cgi?id=1326470 Frédéric Bérat <fberat(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1326470

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs March 2026