[Bug 1659748] New: Characters get deleted as you type
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1659748
Bug ID: 1659748
Summary: Characters get deleted as you type
Product: Fedora
Version: 29
Status: NEW
Component: ibus-m17n
Severity: high
Assignee: pnemade(a)redhat.com
Reporter: lohang(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, pnemade(a)redhat.com,
shawn.p.huang(a)gmail.com
Target Milestone: ---
Classification: Fedora
Description of problem:
When you type Sinhala using Wijesekera keyboard layout through ibus the first
character gets deleted as soon as you start typing the second character. This
is similar to the bug previously reported for Fedora 28
https://bugzilla.redhat.com/show_bug.cgi?id=1617978
How reproducible:
(1) Steps to Reproduce:
1. Open Libre Office Writer (6.1.2.1)
2. Switch to Sinhala; Sinhalese (wijesekera (m17n))
3. Type keys vksIal kjSka
4. Hit space to separate the second word from the first word. And hit space at
the end of the first word.
Actual results: ක වීන්
Expected results: ඩනිෂ්ක නවීන්
Additional info:
(2) When you try this with emacs the results are a little different. I am
including it here assuming this is related to the same issue:
This is how to reproduce with emacs:
1. Open emacs 26.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.23.2)
of 2018-08-13
2. Switch to Sinhala; Sinhalese (wijesekera (m17n))
3. Type keys vksIal kjSka
4. Hit space to separate the second word from the first word. And hit space at
the end of the first word.
Actual results: ඩනිෂ් කනවී න්
Expected results: ඩනිෂ්ක නවීන්
This adds a space before the last character of the first word, not where you
want the space to be.
--
You are receiving this mail because:
You are on the CC list for the bug.
2 weeks, 3 days
[Bug 1830709] New: Invalid metainfo files
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1830709
Bug ID: 1830709
Summary: Invalid metainfo files
Product: Fedora
Version: 32
Status: NEW
Component: google-noto-fonts
Assignee: petersen(a)redhat.com
Reporter: mohd.akram(a)outlook.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, psatpute(a)redhat.com,
pwu(a)redhat.com, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
Metainfo files provided by the package are deemed invalid by appstream.
Version-Release number of selected component (if applicable):
20181223-7.fc32
How reproducible:
Always.
Steps to Reproduce:
1. appstreamcli validate
/usr/share/metainfo/google-noto-sans-sinhala-vf.metainfo.xml
Actual results:
E: google-noto-sans-sinhala-vf:~: font-no-font-data
E: google-noto-sans-sinhala-vf:4: cid-is-not-rdns google-noto-sans-sinhala-vf
I: google-noto-sans-sinhala-vf:~: font-description-missing
E: google-noto-sans-sinhala-vf:~: component-summary-missing
E: google-noto-sans-sinhala-vf:~: component-name-missing
E: google-noto-sans-sinhala-vf:~: extends-not-allowed
I: google-noto-sans-sinhala-vf:4: cid-contains-hyphen
google-noto-sans-sinhala-vf
Validation failed: errors: 5, infos: 2
Expected results:
Validation was successful.
--
You are receiving this mail because:
You are on the CC list for the bug.
1 month
[Bug 1807534] New: pyzy requires Python 2 to build
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1807534
Bug ID: 1807534
Summary: pyzy requires Python 2 to build
Product: Fedora
Version: rawhide
Status: NEW
Component: pyzy
Assignee: pwu(a)redhat.com
Reporter: pviktori(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, pwu(a)redhat.com
Blocks: 1803205 (BRPY27)
Target Milestone: ---
Classification: Fedora
Python 2 reached upstream end-of-life in January 2020. In Fedora Rawhide, it's
now provided from the compat package `python27`.
Packages that only use Python 2 at build time, like pyzy, had a general
exception to keep using it in Fedora 31. Now, the dependency should be removed.
Let us know if you need any help investigating or removing the dependency.
(There are dozens of packages like this, so we didn't investigate this one
thoroughly. We assume you know the package best.)
If it's possible that the dependency won't be removed in Fedora 33. Please
request a FESCo exception. You can refer to the exception for mercurial as an
example: https://pagure.io/fesco/issue/2243
It's good to mention:
- What is the reason for the Python 2 build dependency?
- What are the upstream/community plans/timelines regarding Python 2?
- What is the guidance for porting the build to Python 3? (Assuming that there
is someone who generally knows how to port to Python 3, but doesn't know
anything about the particular package, what are the next steps to take?)
If you need anything from us, or something is unclear, please mention it here.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1803205
[Bug 1803205] Tracking: Packages BuildRequiring python27
--
You are receiving this mail because:
You are on the CC list for the bug.
1 month, 1 week
[Bug 1850832] New: The Gujarati & Hindi itrans methods are not able to type sentences correctly.
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1850832
Bug ID: 1850832
Summary: The Gujarati & Hindi itrans methods are not able to
type sentences correctly.
Product: Fedora
Version: 32
Hardware: x86_64
OS: Linux
Status: NEW
Component: ibus-m17n
Severity: high
Assignee: pnemade(a)redhat.com
Reporter: nirmalpathak(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, mfabian(a)redhat.com,
pnemade(a)redhat.com, shawn.p.huang(a)gmail.com
Target Milestone: ---
Classification: Fedora
Created attachment 1698739
--> https://bugzilla.redhat.com/attachment.cgi?id=1698739&action=edit
Actual result while typing in GEdit using Gujarati and Hindi using itrans(m17n)
input method.
Description of problem:
The Gujarati & Hindi itrans methods are not able to type sentences correctly.
When you start typing in Gujarati or Hindi using itrans(m17n) input method, the
letters at times are replaced by 'space' or it simply doesn't print. At times,
the special characters like "?" are printed before the previously typed/printed
character.
This happens abruptly but in most cases, once you enter a new line by pressing
'enter' or 'return' key and start new sentence.
Version-Release number of selected component (if applicable):
m17n-db-1.8.0-9.fc32.noarch
ibus-m17n-1.4.2-2.fc32.x86_64
m17n-lib-1.8.0-7.fc32.x86_64
How reproducible:
Type in Gujarati or Hindi language using ibus itrans(m17n) method.
Steps to Reproduce:
1. Select Gujarati (itrans - m17n) or Hindi (itrans - m17n) method from ibus
input method.
2. Start typing multiple sentences in Gujarati or Hindi.
3. Press 'enter' or 'return' key to start a new sentence in a new line.
Actual results:
- કે મછે?
- બરાબ રનથી લખાતું
- कै से ?हो
- ऐसा क्युं छ परहा है?
Expected results:
- કેમ છે?
- બરાબર નથી લખાતું
- कैसे हो?
- ऐसा क्युं छप रहा है?
Additional info:
Please check attached GIF image for actual results.
--
You are receiving this mail because:
You are on the CC list for the bug.
1 month, 1 week
[Bug 1707001] New: Ibus-pinyin ERROR
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1707001
Bug ID: 1707001
Summary: Ibus-pinyin ERROR
Product: Fedora
Version: 30
Hardware: All
OS: Linux
Status: NEW
Component: ibus-pinyin
Severity: urgent
Assignee: pwu(a)redhat.com
Reporter: 1990konger(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, pwu(a)redhat.com,
shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
The input method is incorrect and cannot be recognized correctly. The text to
be entered is required.
For example, 'nihao' should be right, '你好'.
Now enter 'nihao' to show 'niha o'.Unrecognized what you need
'ni' is a word.
'hao' is a word.
'ha' is a word but the display is wrong at this time and cannot be selected.
Unable to recognize 'hao'. Affect all input suggestions to withdraw to the old
version
Version-Release number of selected component (if applicable):
Name : ibus-pinyin
Version : 1.5.0
Release : 16.fc30
How reproducible:
'nihao' is meaning is 'Hello'
'niha o', it is an error
Steps to Reproduce:
1.All Chinese input is wrong
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
1 month, 2 weeks
[Bug 1809989] New: By default install Noto fonts for Unicode scripts not already covered by default
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1809989
Bug ID: 1809989
Summary: By default install Noto fonts for Unicode scripts not
already covered by default
Product: Fedora
Version: 31
Status: NEW
Component: google-noto-fonts
Assignee: petersen(a)redhat.com
Reporter: hsivonen(a)hsivonen.fi
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com,
pwu(a)redhat.com, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
There is currently movement towards protecting browser users from font
fingerprinting. This means refusing, by default, to load user-installed fonts,
which makes the set of fonts that each OS installs by default even more
important than before.
Firefox bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1582687
W3C CSS WG issue:
https://github.com/w3c/csswg-drafts/issues/4497
Currently, Windows 10, macOS, Android, and Chrome OS provide broader
installed-by-default Unicode coverage than Fedora.
Examples of living scripts that have enough active users to make it to the list
at
https://en.wikipedia.org/wiki/List_of_writing_systems#List_of_writing_scr...
but are not supported by default in Fedora 31 include Javanese, Sundanese,
Batak, Balinese, Mongolian, and New Tai Lue.
Egyptian hieroglyphs is an example of a dead script the Fedora 31 doesn't
support out of the box but Windows 10, macOS, Chrome OS, and Android do.
To remedy this with minimal disk space impact, I suggest the same approach that
Apple took. Apple bundles with macOS those Noto fonts that cover scripts that
were not already covered by the previous installed-by-default set of fonts on
macOS. In the macOS case, the on-disk footprint of the Noto fonts that were
required to take macOS to Android/Chrome OS-competitive Unicode coverage was
only a couple of megabytes. (The fonts are hidden in /Library/Application
Support/Apple/Fonts/Language Support/.) In the case of Fedora, the set of Noto
fonts required to reach the Chrome OS / Android level of script coverage is a
bit larger than in the macOS case but should still be manageable.
Please install, by default, those Noto fonts that provide support for scripts
that are not properly supported by the fonts that Fedora already installs by
default.
--
You are receiving this mail because:
You are on the CC list for the bug.
3 months
[Bug 1753295] New: Pango no longer supports bitmap fonts
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1753295
Bug ID: 1753295
Summary: Pango no longer supports bitmap fonts
Product: Fedora
Version: 31
Status: NEW
Component: pango
Assignee: tagoh(a)redhat.com
Reporter: jsbillin(a)umich.edu
QA Contact: extras-qa(a)fedoraproject.org
CC: caillon+fedoraproject(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
john.j5live(a)gmail.com, mclasen(a)redhat.com,
pwu(a)redhat.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com,
tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
In pango 1.44, pango dropped support for bitmap fonts, so font packages like
terminus-fonts and ucs-miscfixed-fonts no longer appear in GNOME applications
that use pango, such as Terminal. If you did a dnf system-upgrade from Fedora
30 and were using a bitmap font like Terminus, all your terminals will show the
rectangular placeholders the first time you start a terminal.
Bitmap fonts like terminus and ucs-miscfixed are much easier to read in a
terminal since they are pixel perfect. If Fedora 31 is going to disable
support for bitmap fonts, it needs to be announced and the package maintainers
of those bitmap font packages are going to need to find a way to convert their
fonts.
Version-Release number of selected component (if applicable):
pango-1.44.6-1.fc31.x86_64
How reproducible:
always
Steps to Reproduce:
1. install 'terminus-fonts'
2. Start GNOME terminal
3. Open Terminal Preferences
4. Attempt to change the font to Terminus font
Actual results:
If you upgraded from Fedora 30 and had Terminus fonts as the default font, the
first time you launch Terminal, all the text will be the rectangular
placeholders. If you search for the Terminus font in the preferences, you
won't be able to find it.
Expected results:
Use the Terminus font as usual
Additional info:
It appears that pango switched from using FreeType to HarfBuzz, which only
supports truetype. I rebuilt the Fedora 30 pango package (1.43) for Fedora 31,
downgraded it, and now my terminals are fine showing my bitmap fonts.
--
You are receiving this mail because:
You are on the CC list for the bug.
3 months
[Bug 1751061] New: Compose doesn’t work when using ibus
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1751061
Bug ID: 1751061
Summary: Compose doesn’t work when using ibus
Product: Fedora
Version: 31
Status: NEW
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
I installed Fedora-Everything-netinst-x86_64-31-20190909.n.0.iso in
qemu.
Ibus version is:
ibus-1.5.21-1.fc31.x86_64
I installed the gnome-tweaks package and set the compose key (Multi_key) to
“Scroll Lock”.
Configured input methods and keyboard layouts (as seen in the gnome panel) are:
English (US, euro on 5) en
日本語 ja
日本語（かな漢字） ja
その他（Typing Booster） 🚀
I choose the "English (US, euro on 5)" keyboard layout and
try to type into gedit.
When pressing <Multi_key> , I see
⎄
i.e. I see U+2384 COMPOSITION SYMBOL as expected.
But if I wait about a second, it disappears again.
Now I type <Multi_key> <'> fast, not waiting after <Multi_key>
I see
⎄'
and it disappears again after about a second.
<Multi_key> <'> <a> fast and I see:
á
After waiting for about a second, it turns into
á⎄
i.e. U+2384 COMPOSITION SYMBOL is added after the á without pressing any more
keys, just by waiting. This U+2384 COMPOSITION SYMBOL stays there, even if I
wait more. If I continue to type <'> <a>, I finally get:
áá
i.e. I have produced this “áá” by typing <Multi_key> <'> <a> <'> <a>.
--
You are receiving this mail because:
You are on the CC list for the bug.
3 months, 1 week
[Bug 1843643] New: Space bar wrongly mapping to "switch IME" on first login (plasma + ibus)
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1843643
Bug ID: 1843643
Summary: Space bar wrongly mapping to "switch IME" on first
login (plasma + ibus)
Product: Fedora
Version: 31
Hardware: x86_64
OS: Linux
Status: NEW
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: billcrawford1970(a)googlemail.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:
When I first login and open a konsole window, spaces don't get input to the
shell, but seem to cause an input method switch.
Version-Release number of selected component (if applicable):
1.5.21-9.fc31
How reproducible:
Log in. Try to type.
Steps to Reproduce:
1. Choose ibus using im-chooser, configure Meta + Space as IME switcher
2. Reboot machine
3. Log in
Actual results:
Typing a space doesn't enter a space in the terminal, but switches IME.
Expected results:
Entering a space enters a space.
Additional info:
· Configured "switch engine" shortcut it Meta + Space.
· Meta is Right Win Key, configured in KDE system settings.
· I suspect there is a startup ordering issue between keyboard layout
configuration and ibus starting.
· Restarting ibus (via right-click on "ibus panel" notification icon) fixes
it. It also causes the icon to reappear to the left of the "keyboard layout"
icon, which bolsters my suspicion this is an ordering issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
3 months, 2 weeks
[Bug 1787190] New: Windows+ Space shortcut opened KRunner instead of switch keyboard (ibus) in KDE plasma
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1787190
Bug ID: 1787190
Summary: Windows+ Space shortcut opened KRunner instead of
switch keyboard (ibus) in KDE plasma
Product: Fedora
Version: 31
Status: NEW
Component: kf5-plasma
Keywords: i18n
Assignee: me(a)dvratil.cz
Reporter: aalam(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
jgrulich(a)redhat.com, kde-sig(a)lists.fedoraproject.org,
me(a)dvratil.cz, rdieter(a)gmail.com, than(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
after updating KDE with Fedora 31, Windows+Space is opening 'Krunner', but not
switching keyboard (which is default shortcut for ibus keybaord switch).
Krunner is not running with Alt+F2
Krunner is running with Windows +F2
Version-Release number of selected component (if applicable):
plasma-desktop-5.17.4-1.fc31.x86_64
plasma-nm-openswan-5.17.4-1.fc31.x86_64
plasma-desktop-doc-5.17.4-1.fc31.noarch
plasma-browser-integration-5.17.4-1.fc31.x86_64
plasma-workspace-5.17.4-1.fc31.x86_64
plasma-nm-vpnc-5.17.4-1.fc31.x86_64
plasma-workspace-common-5.17.4-1.fc31.x86_64
plasma-nm-5.17.4-1.fc31.x86_64
plasma-workspace-geolocation-5.17.4-1.fc31.x86_64
plasma-milou-5.17.4-1.fc31.x86_64
plasma-integration-5.17.4-1.fc31.x86_64
plasma-discover-5.17.4-1.fc31.x86_64
plasma-nm-openvpn-5.17.4-1.fc31.x86_64
plasma-breeze-5.17.4-1.fc31.x86_64
plasma-drkonqi-5.17.4-1.fc31.x86_64
kdeplasma-addons-5.17.4-1.fc31.x86_64
plasma-user-manager-5.17.4-1.fc31.x86_64
plasma-pk-updates-0.3.2-4.fc31.x86_64
plasma-nm-l2tp-5.17.4-1.fc31.x86_64
plasma-nm-openconnect-5.17.4-1.fc31.x86_64
kf5-plasma-5.64.0-1.fc31.x86_64
plasma-workspace-geolocation-libs-5.17.4-1.fc31.x86_64
plasma-lookandfeel-fedora-5.17.4-1.fc31.noarch
plasma-nm-pptp-5.17.4-1.fc31.x86_64
plasma-workspace-libs-5.17.4-1.fc31.x86_64
plasma-systemsettings-5.17.4-1.fc31.x86_64
kde-settings-plasma-31.0-1.fc31.noarch
glibc-2.30-8.fc31.x86_64
glibc-langpack-pa-2.30-8.fc31.x86_64
glibc-langpack-en-2.30-8.fc31.x86_64
glibc-all-langpacks-2.30-8.fc31.x86_64
glibc-common-2.30-8.fc31.x86_6
ibus-setup-1.5.21-5.fc31.noarch
ibus-gtk3-1.5.21-5.fc31.x86_64
ibus-m17n-1.4.1-3.fc31.x86_64
ibus-gtk2-1.5.21-5.fc31.x86_64
ibus-qt-1.3.3-22.fc31.x86_64
ibus-libs-1.5.21-5.fc31.x86_64
ibus-1.5.21-5.fc31.x86_64
How reproducible:
Everytime after updating Fedora 31 KDE desktop with latest package
Steps to Reproduce:
1. Fresh install KDE Plasma with language (Punjabi, Hindi, any language using
iBus)
2. try to input by switching keyboard (ibus) pressing Windows+Space
3. sudo dnf update
4. Reboot
5. try to input by switching keyboard (ibus) pressing Windows+Space
Actual results:
Opened 'KRunner'
Expected results:
input keyboard layout should switch with 'Windows+space'.
Krunner should run with 'Alt+F2', which is not working
Additional info:
before updating, opened system setting -> Shortcut -> Global Shortcut - There
is NO krunner'
After update, system setting -> Shortcut -> Global Shortcut -> Krunner (this is
something new)
--
You are receiving this mail because:
You are on the CC list for the bug.
3 months, 3 weeks