https://bugzilla.redhat.com/show_bug.cgi?id=2237664
Bug ID: 2237664
Summary: Emoji categories dialog has different state on cursor
with keyboard and mouse
Product: Fedora
Version: 39
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,
shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com
Target Milestone: ---
Classification: Fedora
The cursor on the emoji categories dialog is changed through moving mouse
cursor on it though, moving the cursor with keyboard doesn't follow it.
Reproducible: Always
Steps to Reproduce:
1.Press Super+period and space to show the categories dialog
2.move the cursor through mouse to somewhere else
3.press down-arrow key
Actual Results:
The cursor moves down where it initially pointed at. i.e. 2nd item at the list
in this case.
Expected Results:
The cursor should moves down where the mouse cursor pointed at the list. e.g.
if it points to 4th item after step 2, the cursor should move down to 5th item.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2237664
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2248636
Bug ID: 2248636
Summary: [abrt] ibus-libpinyin: std::__glibcxx_assert_fail():
ibus-engine-libpinyin killed by SIGABRT
Product: Fedora
Version: 39
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:90b337510822b74ec1264b8ed94bb02bf5d3006e;VAR
IANT_ID=workstation;
Component: ibus-libpinyin
Assignee: pwu(a)redhat.com
Reporter: jacknlliu(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:
upgrade to fedora 39
Version-Release number of selected component:
ibus-libpinyin-1.15.4-1.fc39
Additional info:
reporter: libreport-2.17.11
journald_cursor:
s=efe1502c004e4d8fb9e372c089ce0297;i=3204d5;b=3f4d4311a5ea437cb5394fb51d9e764d;m=3258aaa;t=6099aa3bced6f;x=7855a2569304aad2
crash_function: std::__glibcxx_assert_fail
rootdir: /
reason: ibus-engine-libpinyin killed by SIGABRT
cmdline: /usr/libexec/ibus-engine-libpinyin --ibus
kernel: 6.5.9-300.fc39.x86_64
backtrace_rating: 4
runlevel: N 5
comment: upgrade to fedora 39
type: CCpp
cgroup: 0::/user.slice/user-42.slice/session-c1.scope
uid: 42
executable: /usr/libexec/ibus-engine-libpinyin
package: ibus-libpinyin-1.15.4-1.fc39
Truncated backtrace:
Thread no. 1 (27 frames)
#4 std::__glibcxx_assert_fail at
../../../../../libstdc++-v3/src/c++11/debug.cc:61
#5 std::unique_ptr<PY::LibPinyinBackEnd,
std::default_delete<PY::LibPinyinBackEnd> >::operator* at
/usr/include/c++/13/bits/unique_ptr.h:451
#7 PY::LibPinyinBackEnd::instance at
/usr/src/debug/ibus-libpinyin-1.15.4-1.fc39.x86_64/src/PYLibPinyin.h:61
#8 PY::SuggestionEditor::~SuggestionEditor at
/usr/src/debug/ibus-libpinyin-1.15.4-1.fc39.x86_64/src/PYPSuggestionEditor.cc:48
#10 std::_Sp_counted_ptr<PY::SuggestionEditor*,
(__gnu_cxx::_Lock_policy)2>::_M_dispose at
/usr/include/c++/13/bits/shared_ptr_base.h:428
#11 std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release at
/usr/include/c++/13/bits/shared_ptr_base.h:346
#13 std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count at
/usr/include/c++/13/bits/shared_ptr_base.h:1071
#14 std::__shared_ptr<PY::Editor, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr
at /usr/include/c++/13/bits/shared_ptr_base.h:1524
#15 std::shared_ptr<PY::Editor>::~shared_ptr at
/usr/include/c++/13/bits/shared_ptr.h:175
#16 PY::PinyinEngine::~PinyinEngine at
/usr/src/debug/ibus-libpinyin-1.15.4-1.fc39.x86_64/src/PYPPinyinEngine.cc:123
#18 PY::ibus_pinyin_engine_destroy at
/usr/src/debug/ibus-libpinyin-1.15.4-1.fc39.x86_64/src/PYEngine.cc:185
#20 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:4020
#21 signal_emit_valist_unlocked at ../gobject/gsignal.c:3612
#24 ibus_object_dispose at /usr/src/debug/ibus-1.5.29
#27 g_list_foreach at ../glib/glist.c:1092
#28 g_list_free_full at ../glib/glist.c:246
#29 ibus_factory_destroy at /usr/src/debug/ibus-1.5.29
#31 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:4020
#32 signal_emit_valist_unlocked at ../gobject/gsignal.c:3612
#35 ibus_object_dispose at /usr/src/debug/ibus-1.5.29
#39 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:3980
#40 signal_emit_valist_unlocked at ../gobject/gsignal.c:3612
#43 emit_closed_in_idle at ../gio/gdbusconnection.c:1375
#46 g_main_context_dispatch_unlocked at ../glib/gmain.c:4284
#47 g_main_context_iterate_unlocked.isra.0 at ../glib/gmain.c:4349
#49 ibus_main at /usr/src/debug/ibus-1.5.29
#50 start_component at
/usr/src/debug/ibus-libpinyin-1.15.4-1.fc39.x86_64/src/PYMain.cc:155
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2248636
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2277158
Bug ID: 2277158
Summary: [abrt] ibus-libpinyin: std::__glibcxx_assert_fail():
ibus-engine-libpinyin killed by SIGABRT
Product: Fedora
Version: rawhide
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:90b337510822b74ec1264b8ed94bb02bf5d3006e;VAR
IANT_ID=workstation;
Component: ibus-libpinyin
Assignee: pwu(a)redhat.com
Reporter: mimijiaoju(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
Version-Release number of selected component:
ibus-libpinyin-1.15.7-1.fc40
Additional info:
reporter: libreport-2.17.15
type: CCpp
reason: ibus-engine-libpinyin killed by SIGABRT
journald_cursor:
s=61a6356769dd4676bcd80bd912ce2f65;i=7a80c7;b=119115d14b314b17b1deceefd3de4ca6;m=15fc7a0;t=616e3dd428c34;x=6e7cd2fd7a431da2
executable: /usr/libexec/ibus-engine-libpinyin
cmdline: /usr/libexec/ibus-engine-libpinyin --ibus
cgroup: 0::/user.slice/user-42.slice/session-c1.scope
rootdir: /
uid: 42
kernel: 6.9.0-0.rc5.20240423git71b1543c83d6.45.fc41.x86_64
package: ibus-libpinyin-1.15.7-1.fc40
runlevel: N 5
backtrace_rating: 4
crash_function: std::__glibcxx_assert_fail
Truncated backtrace:
Thread no. 1 (27 frames)
#4 std::__glibcxx_assert_fail at
../../../../../libstdc++-v3/src/c++11/assert_fail.cc:41
#5 std::unique_ptr<PY::LibPinyinBackEnd,
std::default_delete<PY::LibPinyinBackEnd> >::operator* at
/usr/include/c++/14/bits/unique_ptr.h:445
#7 PY::LibPinyinBackEnd::instance at
/usr/src/debug/ibus-libpinyin-1.15.7-1.fc40.x86_64/src/PYLibPinyin.h:61
#8 PY::SuggestionEditor::~SuggestionEditor at
/usr/src/debug/ibus-libpinyin-1.15.7-1.fc40.x86_64/src/PYPSuggestionEditor.cc:48
#10 std::_Sp_counted_ptr<PY::SuggestionEditor*,
(__gnu_cxx::_Lock_policy)2>::_M_dispose at
/usr/include/c++/14/bits/shared_ptr_base.h:428
#11 std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release at
/usr/include/c++/14/bits/shared_ptr_base.h:346
#13 std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count at
/usr/include/c++/14/bits/shared_ptr_base.h:1069
#14 std::__shared_ptr<PY::Editor, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr
at /usr/include/c++/14/bits/shared_ptr_base.h:1525
#15 std::shared_ptr<PY::Editor>::~shared_ptr at
/usr/include/c++/14/bits/shared_ptr.h:175
#16 PY::PinyinEngine::~PinyinEngine at
/usr/src/debug/ibus-libpinyin-1.15.7-1.fc40.x86_64/src/PYPPinyinEngine.cc:123
#18 PY::ibus_pinyin_engine_destroy at
/usr/src/debug/ibus-libpinyin-1.15.7-1.fc40.x86_64/src/PYEngine.cc:185
#20 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:3928
#21 signal_emit_valist_unlocked at ../gobject/gsignal.c:3520
#24 ibus_object_dispose at /usr/src/debug/ibus-1.5.30
#27 g_list_foreach at ../glib/glist.c:1008
#28 g_list_free_full at ../glib/glist.c:162
#29 ibus_factory_destroy at /usr/src/debug/ibus-1.5.30
#31 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:3928
#32 signal_emit_valist_unlocked at ../gobject/gsignal.c:3520
#35 ibus_object_dispose at /usr/src/debug/ibus-1.5.30
#39 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:3888
#40 signal_emit_valist_unlocked at ../gobject/gsignal.c:3520
#43 emit_closed_in_idle at ../gio/gdbusconnection.c:1352
#46 g_main_context_dispatch_unlocked at ../glib/gmain.c:4152
#47 g_main_context_iterate_unlocked.isra.0 at ../glib/gmain.c:4217
#49 ibus_main at /usr/src/debug/ibus-1.5.30
#50 start_component at
/usr/src/debug/ibus-libpinyin-1.15.7-1.fc40.x86_64/src/PYMain.cc:155
Potential duplicate: bug 2248636
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2277158
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=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…
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…
https://bugzilla.redhat.com/show_bug.cgi?id=2062407
Bug ID: 2062407
Summary: msgfmt cannot invoke javac
Product: Fedora
Version: rawhide
Hardware: All
OS: Linux
Status: NEW
Component: gettext
Severity: low
Assignee: suanand(a)redhat.com
Reporter: loganjerry(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org,
jjanco(a)redhat.com, nphilipp(a)redhat.com,
petersen(a)redhat.com, praiskup(a)redhat.com,
suanand(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
I noticed while building jmol that every invocation of msgfmt failed, e.g.:
update-application-catalog-lang:
[echo] msgfmt Updating messages_ar.class file for Jmol ...
[exec] msgfmt: Java compiler not found, try installing gcj or set $JAVAC
[exec] msgfmt: compilation of Java class failed, please try --verbose or
set $JAVAC
[exec] 65 translated messages, 3 fuzzy translations, 380 untranslated
messages.
[exec] Result: 1
Setting JAVAC does *not* help. I used strace to see how javac is invoked and
found the problem: msgfmt passes -target 1.6, and sometimes -source 1.6, to
javac. Now that OpenJDK 17 is the default in Fedora, those arguments are no
longer valid. I don't remember if the minimum allowed is 1.7 or 1.8, but it is
one of the two. Since Fedora doesn't ship a JDK lower than 1.8, then 1.8 might
as well be used.
Version-Release number of selected component (if applicable):
gettext-0.21-11.fc37.0.20220228
How reproducible:
Always
Steps to Reproduce:
1. fedpkg clone jmol
2. cd jmol
3. fedpkg srpm
4. mock -r fedora-rawhide-x86_64 --rebuild jmol-14.32.22-1.fc37.src.rpm
Actual results:
The msgfmt invocations all fail.
Expected results:
The msgfmt invocations should succeed.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2062407
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…
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
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…