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…
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.
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.
https://bugzilla.redhat.com/show_bug.cgi?id=2237669
Bug ID: 2237669
Summary: Key repeat doesn't work on Plasma Wayland
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
After configuring IBus through Input Devices on systemsettings5, key repeat
stopped working.
Reproducible: Always
Steps to Reproduce:
1.Change Virtual Keyboard from None to IBus Wayland
2.Open a app and press a key
3.
Actual Results:
Character corresponding to the key pressing appears only once on apps
Expected Results:
Character should be repeatedly added on apps
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2237669
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=2004265
Bug ID: 2004265
Summary: Official name of Taiwan is wrong
Product: Fedora
Version: 35
Hardware: All
Status: NEW
Component: iso-codes
Assignee: pnemade(a)redhat.com
Reporter: julian.g(a)posteo.de
QA Contact: extras-qa(a)fedoraproject.org
CC: caillon+fedoraproject(a)gmail.com,
gnome-sig(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, mclasen(a)redhat.com,
pnemade(a)redhat.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
The "official name" of the country on Taiwan is wrong. It states "Province of
China", which is obviously not its official name. No country would call itself
"Province" of another country. The official name is "Republic of China".
Some sources:
- Official government website https://www.taiwan.gov.tw by the RoC Ministry of
Foreign Affairs
- You can ask any person living on the Island.
- As an IT person, you might have some hardware labeled "Made in RoC".
- The Hong Kong and the Taiwanese locale both have "中華民國" as a translation,
which means "Republic of China".
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2004265
https://bugzilla.redhat.com/show_bug.cgi?id=2240167
Bug ID: 2240167
Summary: Need to press Super+space twice to activate/deactivate
on Cinnamon desktop
Product: Fedora
Version: 39
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. The first Super+space just inserts a space and no input
engine selector popped up. Super key needs to keep pressed though, the 2nd
Super+space pops up the selector as expected.
Reproducible: Always
Steps to Reproduce:
1.Install from Fedora-Cinnamon-Live-x86_64-39-20230920.n.0.iso with ja
2.Boot and open gnome-terminal and/or xed
3.Press Super and space
4.Release space key only and press space key again
Actual Results:
space character are inserted at 3, and the selector popped up at 4
Expected Results:
the selector should be popped up at 3 without inserting space
$ rpm -qa | grep -e ^ibus
ibus-libs-1.5.29~rc1-3.fc39.x86_64
ibus-gtk3-1.5.29~rc1-3.fc39.x86_64
ibus-gtk2-1.5.29~rc1-3.fc39.x86_64
ibus-setup-1.5.29~rc1-3.fc39.noarch
ibus-1.5.29~rc1-3.fc39.x86_64
ibus-panel-1.5.29~rc1-3.fc39.x86_64
ibus-anthy-python-1.5.15-2.fc39.noarch
ibus-anthy-1.5.15-2.fc39.x86_64
ibus-hangul-1.5.5-3.fc39.x86_64
ibus-libpinyin-1.15.4-1.fc39.x86_64
ibus-libzhuyin-1.10.2-4.fc39.x86_64
ibus-m17n-1.4.22-1.fc39.x86_64
ibus-typing-booster-2.24.1-1.fc39.noarch
ibus-gtk4-1.5.29~rc1-3.fc39.x86_64
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2240167
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=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=2244977
Bug ID: 2244977
Summary: [abrt] ibus: _g_utf8_normalize_wc():
ibus-engine-simple killed by SIGSEGV
Product: Fedora
Version: 38
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:1765528ff786f8c85e6c773f7b853c74efeaeea9;VAR
IANT_ID=workstation;
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: huk5zae3ut(a)gmail.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
Version-Release number of selected component:
ibus-1.5.28-6.fc38
Additional info:
reporter: libreport-2.17.11
type: CCpp
reason: ibus-engine-simple killed by SIGSEGV
journald_cursor:
s=b1e95832b3ee46349b838c2da0c21c1e;i=1b364;b=b05d5c31927b4a70a628c2b581a7856b;m=5db1f54d;t=608014c41ea6c;x=4c6f6cabcbe10eac
executable: /usr/libexec/ibus-engine-simple
cmdline: /usr/libexec/ibus-engine-simple
cgroup:
0::/user.slice/user-1000.slice/user@1000.service/session.slice/org.freedesktop.IBus.session.GNOME.service
rootdir: /
uid: 1000
kernel: 6.5.6-200.fc38.x86_64
package: ibus-1.5.28-6.fc38
runlevel: N 5
backtrace_rating: 4
crash_function: _g_utf8_normalize_wc
Truncated backtrace:
Thread no. 1 (13 frames)
#0 _g_utf8_normalize_wc at ../glib/gunidecomp.c:388
#1 g_utf8_normalize at ../glib/gunidecomp.c:550
#2 check_normalize_nfc at
/usr/src/debug/ibus-1.5.28-6.fc38.x86_64/src/ibuscomposetable.c:1706
#3 ibus_check_algorithmically at
/usr/src/debug/ibus-1.5.28-6.fc38.x86_64/src/ibuscomposetable.c:1798
#4 ibus_engine_simple_check_all_compose_table at
/usr/src/debug/ibus-1.5.28-6.fc38.x86_64/src/ibusenginesimple.c:840
#5 ibus_engine_simple_process_key_event at
/usr/src/debug/ibus-1.5.28-6.fc38.x86_64/src/ibusenginesimple.c:1293
#6 _ibus_marshal_BOOLEAN__UINT_UINT_UINT at
/usr/src/debug/ibus-1.5.28-6.fc38.x86_64/src/ibusmarshalers.c:280
#9 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:3851
#12 ibus_engine_service_method_call at
/usr/src/debug/ibus-1.5.28-6.fc38.x86_64/src/ibusengine.c:1282
#13 call_in_idle_cb at ../gio/gdbusconnection.c:5012
#17 g_main_context_iterate.isra.0 at ../glib/gmain.c:4276
#19 ibus_main at /usr/src/debug/ibus-1.5.28-6.fc38.x86_64/src/ibusshare.c:330
#20 _vala_main at /usr/src/debug/ibus-1.5.28-6.fc38.x86_64/engine/main.c:408
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2244977
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=2182291
Bug ID: 2182291
Summary: does imsettings-* need weak rich dependencies?
Product: Fedora
Version: rawhide
Status: NEW
Component: imsettings
Assignee: tagoh(a)redhat.com
Reporter: petersen(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
It might be good to add some rich weak deps to pull in imsettings-* for certain
desktop environments.
eg imsettings-plasma (maybe dependent on plasma-desktop?)
imsettings-cinnamon and imsettings-mate could be similarly handled perhaps.
imsettings-xfce.
On the other hand pre-installation seems preferable - so may need to think
if this really is useful/makes sense.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2182291