i18n-bugs

i18n-bugs@lists.fedoraproject.org

1 participants
19630 discussions

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

21 Apr '26

https://bugzilla.redhat.com/show_bug.cgi?id=1326470 Florian Weimer <fweimer(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|fberat(a)redhat.com |glibc-bugzilla(a)redhat.com Status|ASSIGNED |NEW --- Comment #17 from Florian Weimer <fweimer(a)redhat.com> --- Next step: We should reach out to the systemd maintainers and raise the bug that they filter out UTF-8-only locales (unless glibc-all-langpacks is installed). -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1326470 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 0

[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 2459606] New: harfbuzz-14.2.0 is available
by bugzilla＠redhat.com 20 Apr '26

20 Apr '26

https://bugzilla.redhat.com/show_bug.cgi?id=2459606 Bug ID: 2459606 Summary: harfbuzz-14.2.0 is available Product: Fedora Version: rawhide Status: NEW Component: harfbuzz Keywords: FutureFeature, Triaged Assignee: pnemade(a)redhat.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, kalevlember(a)gmail.com, moceap(a)hotmail.com, pnemade(a)redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 14.2.0 Upstream release that is considered latest: 14.2.0 Current version/release in rawhide: 14.1.0-2.fc45 URL: https://harfbuzz.github.io 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/1299/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/harfbuzz -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2459606 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 4

[Bug 2459650] New: [abrt] ibus: g_type_check_instance_is_fundamentally_a(): ibus-x11 killed by SIGSEGV
by bugzilla＠redhat.com 20 Apr '26

20 Apr '26

https://bugzilla.redhat.com/show_bug.cgi?id=2459650 Bug ID: 2459650 Summary: [abrt] ibus: g_type_check_instance_is_fundamentally_a(): ibus-x11 killed by SIGSEGV Product: Fedora Version: 43 Hardware: x86_64 Status: NEW Whiteboard: abrt_hash:d5b9a38a7fc38ceaf4c7f723514a21714c6429b2;VAR IANT_ID=kde; Component: ibus Assignee: tfujiwar(a)redhat.com Reporter: prumsadofaikr(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-1.5.33-5.fc43 Additional info: reporter: libreport-2.17.15 type: CCpp reason: ibus-x11 killed by SIGSEGV journald_cursor: s=92553229c6fb44a98e44d783155a86da;i=3413b;b=6d02051cb8a2448995a67a43c7f1a26b;m=c7a560c;t=64fdf8b665dba;x=5a20067653313333 executable: /usr/libexec/ibus-x11 cmdline: /usr/libexec/ibus-x11 cgroup: 0::/user.slice/user-1000.slice/user@1000.service/session.slice/plasma-kwin_wayland.service rootdir: / uid: 1000 kernel: 7.0.0 package: ibus-1.5.33-5.fc43 runlevel: /bin/sh: 줄 1: runlevel: 명령을 찾을 수 없음 backtrace_rating: 4 crash_function: g_type_check_instance_is_fundamentally_a Truncated backtrace: Thread no. 1 (7 frames) #0 g_type_check_instance_is_fundamentally_a at ../gobject/gtype.c:3917 #1 g_object_ref at ../gobject/gobject.c:4656 #2 g_task_new at ../gio/gtask.c:830 #3 g_async_initable_real_init_async at ../gio/gasyncinitable.c:281 #4 g_async_initable_new_valist_async at ../gio/gasyncinitable.c:438 #5 g_async_initable_new_async at ../gio/gasyncinitable.c:347 #6 g_dbus_connection_new_for_address at ../gio/gdbusconnection.c:3255 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2459650 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 0

[Bug 2456894] New: translate-toolkit-3.19.4 is available
by bugzilla＠redhat.com 15 Apr '26

15 Apr '26

https://bugzilla.redhat.com/show_bug.cgi?id=2456894 Bug ID: 2456894 Summary: translate-toolkit-3.19.4 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.19.4 Upstream release that is considered latest: 3.19.4 Current version/release in rawhide: 3.19.3-1.fc45 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=2456894 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 8

[Bug 2457897] New: CVE-2026-34478 cldr-emoji-annotation: Apache Log4j Core: Log injection via CRLF sequences due to configuration attribute renames [fedora-all]
by bugzilla＠redhat.com 14 Apr '26

14 Apr '26

https://bugzilla.redhat.com/show_bug.cgi?id=2457897 Bug ID: 2457897 Summary: CVE-2026-34478 cldr-emoji-annotation: Apache Log4j Core: Log injection via CRLF sequences due to configuration attribute renames [fedora-all] Product: Fedora Version: rawhide Status: NEW Whiteboard: {"flaws": ["3b3e57ac-d7bc-486b-86c6-b7be7077654f"]} Component: cldr-emoji-annotation Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: tfujiwar(a)redhat.com Reporter: jmoroney(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, tfujiwar(a)redhat.com Blocks: 2457323 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. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2457897 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 1

[Bug 2457887] New: CVE-2026-34480 cldr-emoji-annotation: Apache Log4j Core: Invalid XML output causes denial of service in logging [fedora-all]
by bugzilla＠redhat.com 14 Apr '26

14 Apr '26

https://bugzilla.redhat.com/show_bug.cgi?id=2457887 Bug ID: 2457887 Summary: CVE-2026-34480 cldr-emoji-annotation: Apache Log4j Core: Invalid XML output causes denial of service in logging [fedora-all] Product: Fedora Version: rawhide Status: NEW Whiteboard: {"flaws": ["43e81c52-9a5c-4fd5-8679-d40721c51d82"]} Component: cldr-emoji-annotation Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: tfujiwar(a)redhat.com Reporter: jmoroney(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, tfujiwar(a)redhat.com Blocks: 2457328 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. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2457887 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 1

[Bug 2457905] New: CVE-2026-34477 cldr-emoji-annotation: Apache Log4j Core: Man-in-the-middle attack due to incomplete hostname verification [fedora-all]
by bugzilla＠redhat.com 14 Apr '26

14 Apr '26

https://bugzilla.redhat.com/show_bug.cgi?id=2457905 Bug ID: 2457905 Summary: CVE-2026-34477 cldr-emoji-annotation: Apache Log4j Core: Man-in-the-middle attack due to incomplete hostname verification [fedora-all] Product: Fedora Version: rawhide Status: NEW Whiteboard: {"flaws": ["7c2c7a23-223c-4fc8-a8cb-4a45291c236a"]} Component: cldr-emoji-annotation Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: tfujiwar(a)redhat.com Reporter: jmoroney(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, tfujiwar(a)redhat.com Blocks: 2457319 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. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2457905 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 1

[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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs