i18n-bugs September 2024

i18n-bugs@lists.fedoraproject.org

1 participants
69 discussions

[Bug 2292805] New: [abrt] ibus-table: tcache_thread_shutdown(): python3.12 killed by SIGABRT
by bugzilla＠redhat.com 25 Apr '25

25 Apr '25

https://bugzilla.redhat.com/show_bug.cgi?id=2292805 Bug ID: 2292805 Summary: [abrt] ibus-table: tcache_thread_shutdown(): python3.12 killed by SIGABRT Product: Fedora Version: 40 Hardware: x86_64 Status: NEW Whiteboard: abrt_hash:49912628f88fad8ef32c365c9a170d6066e7e2cb;VAR IANT_ID=workstation; Component: ibus-table Assignee: mfabian(a)redhat.com Reporter: cinxiafortis(a)tutanota.de QA Contact: extras-qa(a)fedoraproject.org CC: dchen(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org, mfabian(a)redhat.com, pwu(a)redhat.com Target Milestone: --- Classification: Fedora Description of problem: It has a conflict with tha app from flathub named app.drey.Warp. When I start app.drey.Warp, my ibus-table stop and I cannot use my input method (canjie5). After I stopped app.drey.Warp, the ibus-table works again and I can use my input method. Version-Release number of selected component: ibus-table-1.17.4-3.fc40 Additional info: reporter: libreport-2.17.15 type: CCpp reason: python3.12 killed by SIGABRT journald_cursor: s=b851438adea5488c9c2c2087cbad4e16;i=1a5736;b=16be98526b23462598842ccaa91bc721;m=3c46437d;t=61b1fbb08a027;x=4fab5ac69ab93a00 executable: /usr/bin/python3.12 cmdline: /usr/bin/python3 /usr/share/ibus-table/engine/main.py --ibus cgroup: 0::/user.slice/user-1000.slice/user@1000.service/session.slice/org.freedesktop.IBus.session.GNOME.service rootdir: / uid: 1000 kernel: 6.8.11-300.fc40.x86_64 package: ibus-table-1.17.4-3.fc40 runlevel: N 5 dso_list: /usr/bin/python3.12 python3-3.12.3-2.fc40.x86_64 (Fedora Project) 1715406510 backtrace_rating: 4 crash_function: tcache_thread_shutdown comment: It has a conflict with tha app from flathub named app.drey.Warp. When I start app.drey.Warp, my ibus-table stop and I cannot use my input method (canjie5). After I stopped app.drey.Warp, the ibus-table works again and I can use my input method. Truncated backtrace: Thread no. 1 (4 frames) #6 tcache_thread_shutdown at malloc.c:3231 #7 __malloc_arena_thread_freeres at /usr/src/debug/glibc-2.39-15.fc40.x86_64/malloc/arena.c:897 #8 __libc_thread_freeres at thread-freeres.c:41 #10 clone3 at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2292805 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 1

[Bug 2090204] New: [abrt] ibus: __strndup(): ibus-extension-gtk3 killed by SIGSEGV
by bugzilla＠redhat.com 25 Apr '25

25 Apr '25

https://bugzilla.redhat.com/show_bug.cgi?id=2090204 Bug ID: 2090204 Summary: [abrt] ibus: __strndup(): ibus-extension-gtk3 killed by SIGSEGV Product: Fedora Version: 36 Hardware: x86_64 Status: NEW Whiteboard: abrt_hash:8c2b2d109d6c6600cfdf1e41632f3398d6d21e15;VAR IANT_ID=workstation; Component: ibus Assignee: tfujiwar(a)redhat.com Reporter: mfabian(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com Target Milestone: --- Classification: Fedora Description of problem: Version-Release number of selected component: ibus-1.5.26-6.fc36 Additional info: reporter: libreport-2.17.1 backtrace_rating: 4 cgroup: 0::/user.slice/user-1000.slice/user@1000.service/session.slice/org.freedesktop.IBus.session.GNOME.service cmdline: /usr/libexec/ibus-extension-gtk3 crash_function: __strndup dso_list: /usr/libexec/ibus-extension-gtk3 ibus-1.5.26-6.fc36.x86_64 (Fedora Project) 1653401127 executable: /usr/libexec/ibus-extension-gtk3 journald_cursor: s=3da4198b50ed40bb8e39aac19c44f062;i=15b44;b=4f87f45459b64f7299ca0a57d8a15df6;m=51ec68d6;t=5dfc2daddfca9;x=e27b7bc9d78e7740 kernel: 5.17.9-300.fc36.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2090204

1 7

[Bug 2209413] New: Prepare for DNF 5, don't depend on `dnf`
by bugzilla＠redhat.com 21 Apr '25

21 Apr '25

https://bugzilla.redhat.com/show_bug.cgi?id=2209413 Bug ID: 2209413 Summary: Prepare for DNF 5, don't depend on `dnf` Product: Fedora Version: rawhide Hardware: All OS: Linux Status: NEW Component: system-config-language Severity: high Assignee: pnemade(a)redhat.com Reporter: egoode(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, pnemade(a)redhat.com Target Milestone: --- Classification: Fedora (I'm filing issues with all the packages that currently depend on `dnf`.) DNF 5 is a new package manager that will replace DNF 4 in Fedora 39+: Starting in Fedora 39, the `dnf` command will be provided by the `dnf5` package rather than the `dnf` package, and `dnf5` will obsolete `dnf`. Since system-config-language currently depends on DNF 4, it should choose one of the following strategies to avoid breaking the Fedora upgrade: - Add support for DNF 5, and depend on the `dnf5` package in Fedora 39+ instead of `dnf`. Builds of DNF 5 are available in this COPR repository: https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf-nightly/, and documentation is available here: https://dnf5.readthedocs.io/en/latest/. - Alternatively, or in the meantime, change the system-config-language package to depend on `python3-dnf` instead of `dnf`, and call the `dnf-3` binary instead of `dnf`. The old DNF 4 command will still be available in the distribution, but only as `dnf-3` (the binary is called `dnf-3` rather than `dnf4` for historical reasons; it is the "Python 3 version" of DNF). The first option is preferred to this one; it is not recommended to modify installed software using both DNF 4 and DNF 5 on the same system. - Or, if this package is no longer being maintained, consider removing it from Fedora. At some point, this project should adopt DNF 5, but the immediate issue is removing the dependency on `dnf`. We are planning to replace DNF with DNF5 in Fedora Rawhide very soon, by 2023-06-01, and the system-config-language package will break as long as it still depends on the `dnf` package. For more information about the switch to DNF 5, see https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5. Reproducible: Always -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2209413

1 12

[Bug 2241601] New: Fedora input broke the fr(oss) French layout (default Fedora French layout)
by bugzilla＠redhat.com 14 Apr '25

14 Apr '25

https://bugzilla.redhat.com/show_bug.cgi?id=2241601 Bug ID: 2241601 Summary: Fedora input broke the fr(oss) French layout (default Fedora French layout) Product: Fedora Version: rawhide OS: Linux Status: NEW Component: xkeyboard-config Severity: medium Assignee: peter.hutterer(a)redhat.com Reporter: nicolas.mailhot(a)laposte.net QA Contact: extras-qa(a)fedoraproject.org CC: ajax(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org, negativo17(a)gmail.com, peter.hutterer(a)redhat.com, rhughes(a)redhat.com, rstrode(a)redhat.com Target Milestone: --- Classification: Fedora fr(oss) is supposed to emit French upper case accented letters in caps locks mode ÉÈÇÀ Something changed in the past months and it emits lower case instead. So you get very annoying mixed-case éLéGANT runs of text in caps locks. Explicit level 4 capital selection still works but this change breaks existing user habits and is very inconvenient for new users. To be honest I’ve noticed the breakage for some time but was hoping it was a stupid mistake that would go away with time. Reproducible: Always Steps to Reproduce: 1. switch to fr(oss) 2. set cap locks 3. tap the first (number) row → letters with diacritics should be emitted in upper case, for example É, not lower case é It is not a bug that cap locks produces symbols and accented letters. In azerty, unlike qwerty, access to the diacritics necessary to type proper French is prioritized over access to numbers -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2241601 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 3

[Bug 2267613] New: emojier listing control codes and non-BMP tofu characters early with partial annotation
by bugzilla＠redhat.com 14 Apr '25

14 Apr '25

https://bugzilla.redhat.com/show_bug.cgi?id=2267613 Bug ID: 2267613 Summary: emojier listing control codes and non-BMP tofu characters early with partial annotation Product: Fedora Version: 40 OS: Linux Status: NEW Component: ibus Severity: medium Assignee: tfujiwar(a)redhat.com Reporter: petersen(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com Target Milestone: --- Classification: Fedora eg input of egir ^ emoji prompt Lists candidates: 1. ㌓ 2. ꟼ 3. 𒁞 4. 𒁬 5. 𒂕 6. 𒃐 7. 𒄈 8. 𒄉 9. 𒄊 0. 𒄋 1. 𒄌 2. 𒄍 3. 𒄎 4. 𒄏 5. 𒅨 6. 𒒕 7. 👧 8. 🛊 9. 🦒 (I was actually looking for giraffe) Reproducible: Always Expected Results: Hide or show tofu last -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2267613 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 8

[Bug 2002446] New: zinnia-0.07 is available
by bugzilla＠redhat.com 12 Apr '25

12 Apr '25

https://bugzilla.redhat.com/show_bug.cgi?id=2002446 Bug ID: 2002446 Summary: zinnia-0.07 is available Product: Fedora Version: rawhide Status: NEW Component: zinnia Keywords: FutureFeature, Triaged Assignee: liangsuilong(a)gmail.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, liangsuilong(a)gmail.com, petersen(a)redhat.com, pwu(a)redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.07 Current version/release in rawhide: 0.06-55.fc35 URL: https://github.com/silverhikari/zinnia/ 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://fedoraproject.org/wiki/Upstream_release_monitoring 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/5302/ -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1974076] New: Chinese input methods use previously enabled layout
by bugzilla＠redhat.com 27 Mar '25

27 Mar '25

https://bugzilla.redhat.com/show_bug.cgi?id=1974076 Bug ID: 1974076 Summary: Chinese input methods use previously enabled layout Product: Fedora Version: 34 Hardware: All OS: Linux Status: NEW Component: ibus-libpinyin Severity: medium Assignee: pwu(a)redhat.com Reporter: nickolay.ilyushin(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, petersen(a)redhat.com, pwu(a)redhat.com Target Milestone: --- Classification: Fedora Description of problem: ibus-libpinyin (and most probably several other input methods) uses `default` keyboard layout instead of `us` or whatever fits best. This effectively means that the last keyboard layout (non-IME) will be used for the pinyin input. For users which use non-Latin keyboard layouts, such as Russian or Ukrainian, this makes pinyin input unusable. Version-Release number of selected component (if applicable): 1.12.0 How reproducible: easily. Steps to Reproduce: 1. Enable pinyin input method in your settings. 2. Switch to e.g. Russian layout. 3. Switch to pinyin IME. 4. You will type Russian letters and pinyin IME will not trigger. Actual results: `4. You will type Russian letters and pinyin IME will not trigger.` Expected results: `4. You will type *Latin* letters and pinyin IME *will* trigger.` Additional info: There are two workarounds: 1. Manually patch `/usr/share/ibus/component/libpinyin.xml` and change `layout` to `us` from `default`. I don't know how this will work with non-QWERTY keyboards though. 2. Switch to a Latin layout before switching to pinyin. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 2267618] New: "ibus restart" repeats sending Enter key event at konsole
by bugzilla＠redhat.com 18 Mar '25

18 Mar '25

https://bugzilla.redhat.com/show_bug.cgi?id=2267618 Bug ID: 2267618 Summary: "ibus restart" repeats sending Enter key event at konsole Product: Fedora Version: 40 OS: Linux Status: NEW Component: ibus Keywords: i18n 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, shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com Target Milestone: --- Classification: Fedora Summary says it all. there are nothing more than that. I really have no idea what exactly happened. maybe good to try. it is easy to reproduce. I installed Fedora-KDE-Live-x86_64-40-20240303.n.1.iso and enable IBus from Virtual Keyboard settings. Reproducible: Always Steps to Reproduce: 1.Open konsole 2.ibus restart 3. Actual Results: Apparently someone is sending Enter keys at konsole repeatedly and scrolling a lot. Expected Results: "ibus restart" command should be done without any extra scrolling. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2267618 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 8

[Bug 2267629] New: liberation-mono-fonts breaks default font for Hebrew
by bugzilla＠redhat.com 03 Mar '25

03 Mar '25

https://bugzilla.redhat.com/show_bug.cgi?id=2267629 Bug ID: 2267629 Summary: liberation-mono-fonts breaks default font for Hebrew Product: Fedora Version: 40 OS: Linux Status: NEW Component: google-noto-fonts Keywords: i18n Severity: medium Assignee: tagoh(a)redhat.com Reporter: tagoh(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, petersen(a)redhat.com, pwu(a)redhat.com, tagoh(a)redhat.com Target Milestone: --- Classification: Fedora google-noto-sans-hebrew-vf-fonts is supposed to be a default monospace font for Hebrew though, liberation-mono-fonts is picked up as the default monospace font when it is installed. This happens because liberation use 59 as the priority number although google-noto-sans-hebrew-vf-fonts use 66. The priority number needs to be updated. Reproducible: Always -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2267629 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 3

[Bug 2277345] New: NotoSansMono[wght].ttf file name causes scripts with failglob enabled to fail
by bugzilla＠redhat.com 03 Mar '25

03 Mar '25

https://bugzilla.redhat.com/show_bug.cgi?id=2277345 Bug ID: 2277345 Summary: NotoSansMono[wght].ttf file name causes scripts with failglob enabled to fail Product: Fedora Version: 40 Hardware: All OS: Linux Status: NEW Component: google-noto-fonts Severity: medium Assignee: tagoh(a)redhat.com Reporter: hartsjc(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, petersen(a)redhat.com, pwu(a)redhat.com, tagoh(a)redhat.com Target Milestone: --- Classification: Fedora shopt failglob If set, patterns which fail to match filenames during pathname expansion result in an expansion error. Using this feature is good practice in scripts as helps prevent scripting mistakes; however, having file name with square brackets causes failures. And with Fedora 40 upgrade seems google-noto-sans-mono-vf-fonts-20240301-2.fc40.noarch has added one with: /usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf Reproducible: Always Steps to Reproduce: 1. Causes globs that don't expand to cause errors $ shopt -s failglob 2. Try use files from rpm as variable, and fail $ for file in $(rpm -q --list google-noto-sans-mono-vf-fonts) ; do [[ -f "/${file}" ]] || echo "${file}" done -bash: no match: /usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf 3. Note the RC $ echo $? 1 4. Or even command line $ rpm -qf /usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf -bash: no match: /usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf $ rpm -qf '/usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf' google-noto-sans-mono-vf-fonts-20240301-2.fc40.noarch Actual Results: -bash: no match: /usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf Expected Results: no error accessing files with failglob shopt enabled started fedora 40 upgrade, as daily script of mine fails because this file is included in initramfs too. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2277345 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs September 2024