https://bugzilla.redhat.com/show_bug.cgi?id=1683395
Bug ID: 1683395
Summary: emacs-common-ddskk-20150927 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: emacs-common-ddskk
Keywords: FutureFeature, Triaged
Assignee: dueno(a)redhat.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Latest upstream release: 20150927
Current version/release in rawhide: 16.2-5.fc30
URL: http://openlab.ring.gr.jp/skk/maintrunk/
Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/679/
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1897782
Bug ID: 1897782
Summary: ibus pinyin input with special characters like '/'
will repeat itself non-stop and cause strange
behaviours with background applications
Product: Fedora
Version: 33
Status: NEW
Component: ibus-libpinyin
Assignee: pwu(a)redhat.com
Reporter: yemoran-2020(a)outlook.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:
In Fedora 33 Workstation, with a Chinese system language, when I try to input
with the ibus input (intelligent pinyin), and I pressed the slash key'/', then
the slash character '/' will automatically keep repeating itself, even if I
only pressed the slash key '/' once.
Not only this caused unwanted '/' to spam, but:
1. Also prevents me from pressing alphabetical characters to use pinyin input
normally, unless I delete all my remaining characters to exit pinyin prompt and
start over;
2. Can possibly delete my already-saved text, in combination with
<Ctrl-Backspace>.
It seems that I have completely lost control within the pinyin prompt. I have
met with other surprising conditions, though cannot be immediately reproduced
now, but I believe more combinations of inputs triggering different bugs will
be confirmed later.
Version-Release number of selected component (if applicable):
Any kind of version. I also tested with Fedora 32 Workstation, still have this
bug.
How reproducible:
Always
Steps to Reproduce:
1. Fetch any Fedora Workstation version, be it 32 or 33 or any updates applied.
2. Add Chinese input method 'Intelligent Pinyin' and switch to it
3. In GNOME(Wayland), open any GTK-based application, be it Firefox, GNOME
Terminal, gedit, Libreoffice, ... (take gedit as an example)
4. Input 你好,今天天气 (keypress: nihao<1>,jintian<1>) as a start up example, confirm
input use number key '1'. or keys like <Enter> or <Space>.
5. Input 怎么样/ (keypress: zenmy/). Do not confirm immediately after 'zenmy', but
press '/' exactly once.
6. The '/' character is repeating itself within several hundred milliseconds.
7. Press <Ctrl-Backspace>. gedit will highlight "你好,今天天气" (with a lot of
trailing '/').
8. Press <Backspace> to delete these Chinese characters.
Actual results:
Not only '/' is repeating itself, but also I lost control to gedit and gedit
thinks you want to press '/' forever or even wants to delete my
already-confirmed characters before this input.
Expected results:
1. '/' Should not trigger anything, unless I have pressed this key and did not
release this key press (but I always release keys)
2. '/' Should not make me lost control over pinyin prompt to gedit
3. <Backspace> Should only delete pinyin alphabets in pinyin prompt panel, and
should not do anything to the background gedit texts, unless I have exited the
pinyin prompt panel (because I confirmed my input or have deleted every pinyin
alphabet in it)
Additional info:
1. I did not found this bug on Debian buster or Arch with latest updates.
Additionally, '/' did not even input a single character '/' in these
distributions, but I cannot confirm if this is the expected behaviour. In
Fedora 33 KDE, '/' did input a single character '/', but immediately stopped.
2. I didn't find this behaviour in qt-based applications (like Fedora Image
Writer or Octave) in GNOME, or any application in other desktop environments
(including KDE, or even GTK-based Cinnamon Desktop). This bug seems to only
occur on GTK-based applications on GNOME.
3. I can be very sure that this is not caused by something wrong with my
specific keyboard, because (a) Other distributions worked very well (b) Other
Fedora spins worked very well (c) Qt-based applications in GNOME worked very
well (d) GNOME X11 session worked very well (e) I replicated this bug on a
fresh install of Fedora 32 Workstation in another laptop of mine.
4. I guess other special characters (or keys) like '[', ']', '\', '<Esc>',
'<Backspace>', etc. may trigger similar bugs, but I cannot confirm. '/' will
surely trigger this. ',' and '.' are used in pinyin input method to flip
candidate characters pages, so they doesn't trigger this bug. ' does not
trigger this bug (used in xi'an for 西安)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1847347
Bug ID: 1847347
Summary: gnome-terminal and xfce4-terminal get surrounding text
from previous application
Product: Fedora
Version: 32
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 made the following screenshots and video by testing on Gnome-Xorg, but the
problem occurs on Gnome-Wayland as well.
How to reproduce (see also attached screenshots and video):
- To show what happens with the surrounding text, I first opened the
setup tool of ibus-typing-booster and set the debug level in the
options tab to 3.
When the debug level is high, the auxiliary text above the candidate
list shows what context has been obtained by using surrounding text
(if surrounding text is available, if it is not available like when
using xterm, the context is just remembered from what was typed
last).
- I opened 3 windows: gedit, firefox, and gnome-terminal.
- I focus on gedit and type "a b c d e"
On top of the candidate list one can see: "Context: b c d"
This is because when the letter "e" was typed, ibus-typing-booster
got the surrounding text at the cursor position and parsed the last
3 tokens left of the cursor out of the result. And these
last 3 tokens left of the cursor are "b c d".
- Now I focus on firefox and type "f g h i j"
On top of the candidate list one can see: "Context: g h i"
I.e. the correct context "g h i" to the left of the just typed "j"
(which is still in preedit) has been found using surrounding text.
- Now I focus on gnome-terminal and type "k l m"
On top of the candidate list one can see: "Context h i j"
This comes from the surrounding text left of the cursor in
*firefox*, *not* from gnome-terminal.
Although gnome-terminal reports that surrounding text is supported, i.e.
self.client_capabilities & IBus.Capabilite.SURROUNDING_TEXT
is True (see the code to get the context at:
https://github.com/mike-fabian/ibus-typing-booster/blob/master/engine/hunsp…
)
gnome-terminal does not really seem to support surrounding text.
The surrounding text comes from the previous client which really supported
surrounding text.
If the previous client was firefox, one still gets the surrounding text from
firefox while typing in gnome-terminal.
Same with gedit, if the previous client before focussing on gnome-terminal
was gedit, one still gets the surrounding text from gedit while typing in
gnome-terminal.
- The same problem occurs when using xfce4-terminal instead of gnome-terminal.
- When using xterm, the problem does *not* occur because when using xterm
self.client_capabilities & IBus.Capabilite.SURROUNDING_TEXT
is False and then the get_context() immediately returns and the context
remembered from the last text typed is used as a fallback.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1790554
Bug ID: 1790554
Summary: Keyboard layout of Kana Kanji wont show up
Product: Fedora
Version: rawhide
Hardware: x86_64
Status: NEW
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: sumukher(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:
The keyboard layout for Kana Kanji Japanese doesnt show up
Version-Release number of selected component (if applicable):
Fedora-Rawhide-20200112.n.0
How reproducible:
Everytime
Steps to Reproduce:
1. Install Fedora-Rawhide-20200112.n.0 WS from live boot
2. Open settings and navigate to Region and Language
3. Add Japanese Kana Kanji in the input source
4. Click the icon looking like an eye button which should open the keyboard
layout
Actual results:
Doesn't show up the keyboard layout
Expected results:
The keyboard layout should show up like it shows up for english
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=1919963
Bug ID: 1919963
Summary: /usr/share/doc/libunistring-devel/libunistring.html
missing in devel
Product: Fedora
Version: 32
Hardware: All
OS: All
Status: NEW
Component: libunistring
Severity: medium
Assignee: p(a)draigbrady.com
Reporter: reini.urban(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org,
jim(a)meyering.net, p(a)draigbrady.com,
redhat-bugzilla(a)linuxnetz.de
Target Milestone: ---
Classification: Fedora
Description of problem:
after installing libunistring and libunistring-devel the main doc entrypoint
for html is missing.
/usr/share/doc/libunistring-devel/libunistring.html
Version-Release number of selected component (if applicable):
libunistring-devel-0.9.10-7.fc32.x86_64
How reproducible:
Open a html doc, and click on Contents.
e.g firefox /usr/share/doc/libunistring-devel/libunistring_1.html
Haven't checked if that is an upstream problem, or just a bad rpm spec.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1910836
Bug ID: 1910836
Summary: stardict-3.0.6.2 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: stardict
Keywords: FutureFeature, Triaged
Assignee: psatpute(a)redhat.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: anish.developer(a)gmail.com,
i18n-bugs(a)lists.fedoraproject.org, nav007(a)gmail.com,
petersen(a)redhat.com, psatpute(a)redhat.com,
pwu(a)redhat.com, robinlee.sysu(a)gmail.com
Target Milestone: ---
Classification: Fedora
Latest upstream release: 3.0.6.2
Current version/release in rawhide: 3.0.6-15.fc33
URL: http://sourceforge.net/projects/stardict-4
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/4887/
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1813728
Bug ID: 1813728
Summary: Square four dot Unicode character has incorrect glyph
Product: Fedora
Version: 31
Hardware: x86_64
OS: Linux
Status: NEW
Component: pango
Severity: low
Assignee: pwu(a)redhat.com
Reporter: guillaumepoiriermorency(a)gmail.com
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:
The glyph for the Unicode "square four dot" character is incorrect.
Version-Release number of selected component (if applicable):
I think this problem arose when upgrading from Fedora 30 to Fedora 31.
How reproducible:
The simplest way is to start GNOME Characters Map and search for "square four
dot".
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1938251
Bug ID: 1938251
Summary: update_preedit_text_with_mode(..., .., ...,
IBus.PreeditFocusMode.COMMIT) doesn’t work in Gnome
Wayland (works fine in Gnome Xorg)
Product: Fedora
Version: 34
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-Workstation-Live-x86_64-34-20210308.n.0.iso into qemu.
Add the ibus-typing-booster input method in the Gnome control center and
also add the “Vietnamese (telex (m17n))” input method from ibus-m17n.
Both input methods use
update_preedit_text_with_mode(..., .., ..., IBus.PreeditFocusMode.COMMIT)
and this problem can be reproduced with either of them.
Open a gedit and a gnome-terminal.
Select ibus-typing-booster in the Gnome panel and type “test”.
The word “test” is underlined, indicating that it is in preedit and not yet
committed to gedit.
Now click on gnome-terminal to change the focus to gnome-terminal.
The string “test” vanishes from gedit. It should *not* vanish, it should
be committed i.e. the underline under “test” should vanish and the string
“test” should be in gedit.
Same problem with the Vietnamese (telex (m17n)) input method.
Select it in the Gnome panel.
Type “a” into gedit. The “a” is underlined because it is in preedit.
Click on gnome-terminal to change the focus to gnome-terminal.
The “a” vanishes. Here as well the “a” should be commited to gedit, i.e.
the underline should disappear and the “a” should remain in gedit.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1779123
Bug ID: 1779123
Summary: Pango no longer supports type1 fonts
Product: Fedora
Version: rawhide
Status: NEW
Component: pango
Assignee: pwu(a)redhat.com
Reporter: mjg(a)fedoraproject.org
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 type1 fonts. Therefore, no application
which uses pango for font loading can use type1 fonts any more.
Version-Release number of selected component (if applicable):
pango-1.44.6-1.fc31.x86_64 (and later)
How reproducible:
always
Steps to Reproduce:
1. Upgrade F31 or rawhide
2. Open any pango-using application
3. Try to use type1 font
Actual results:
No type1 font is usable
Expected results:
Type1 font is usable
Additional info:
bug 1753295 is the same bug for dropped bitmap font support. Over there,
workarounds specific for bitmap fonts (conversion to opentype bitmap fonts) are
discussed. An attempt to discuss type1 there failed.
This bug here is specifically about type1 fonts to discuss ways (or their
absence) to deal with pangos dropped type 1 support.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1895482
Bug ID: 1895482
Summary: Liberation Fonts Support For Serbian locl Glyphs
Incomplete
Product: Fedora
Version: rawhide
Hardware: x86_64
OS: Linux
Status: NEW
Component: liberation-fonts
Assignee: vishalvijayraghavan(a)gmail.com
Reporter: aleslavista(a)outlook.it
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, mclasen(a)redhat.com,
petersen(a)redhat.com, psatpute(a)redhat.com,
rhughes(a)redhat.com, rstrode(a)redhat.com,
sandmann(a)redhat.com, vishalvijayraghavan(a)gmail.com
Target Milestone: ---
Classification: Fedora
Created attachment 1727218
--> https://bugzilla.redhat.com/attachment.cgi?id=1727218&action=edit
Correctly Localized Glyphs
Description of problem:
Liberation Fonts do NOT provide full support for Serbian localized glyphs.
Version-Release number of selected component (if applicable):
Liberation-Fonts 2.1-1-1
How reproducible:
You need a program that is able to access the font's localized glyphs: usually
that's LibreOffice Writer.
Steps to Reproduce:
1. Open LibreOffice Writer
2. Type бгдпт, then бгдпт in Italic, бгдпт in Bold and finally бгдпт in Italic
Bold with Liberation Serif, and do the same with Liberation Sans
3. Set the language to "Serbian Cyrillic"
Actual results:
Not all glyphs are correctly localized
Expected results:
See attachment for correctly localized glyphs
Additional info:
Liberation Mono has slanted Italic, therefore only the first glyph should be
localized: CYRILLIC LETTER SMALL BE.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1931294
Bug ID: 1931294
Summary: URL tag is outdated
Product: Fedora
Version: 32
Status: NEW
Component: scim-anthy
Severity: low
Assignee: tagoh(a)redhat.com
Reporter: tim(a)tim-landscheidt.de
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
The URL "http://scim-imengine.sourceforge.jp/" used in the URL tag for the
binary package scim-anthy is outdated. https://github.com/scim-im/scim-anthy
seems to be working.
--
You are receiving this mail because:
You are on the CC list for the bug.
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.
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1733869
Bug ID: 1733869
Summary: gettext: Getting errors in double free with msgfmt
command.
Product: Fedora
Version: 30
Status: NEW
Component: gettext
Assignee: panovotn(a)redhat.com
Reporter: poyadav(a)redhat.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,
panovotn(a)redhat.com, petersen(a)redhat.com,
praiskup(a)redhat.com, suanand(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem: Error in poc, please refer the result section for
details.
Version-Release number of selected component (if applicable):
gettext-0.19.8.1-18.fc30.x86_64
How reproducible:
Always
Steps to Reproduce:
1. Clone https://github.com/CCCCCrash/POCs.git.
2. Run valgrind msgfmt poc command.
3. Observe the output.
Actual results:
[poyadav@localhost doublefree]$ valgrind msgfmt poc
==8072== Memcheck, a memory error detector
==8072== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==8072== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==8072== Command: msgfmt poc
==8072==
==8072== Conditional jump or move depends on uninitialised value(s)
==8072== at 0x48D9940: freea (in /usr/lib64/libgettextlib-0.19.8.1.so)
==8072== by 0x487E8EA: po_lex_charset_set (in
/usr/lib64/libgettextsrc-0.19.8.1.so)
==8072== by 0x487E098: po_gram_parse (in
/usr/lib64/libgettextsrc-0.19.8.1.so)
==8072== by 0x487EB9A: ??? (in /usr/lib64/libgettextsrc-0.19.8.1.so)
==8072== by 0x487A773: catalog_reader_parse (in
/usr/lib64/libgettextsrc-0.19.8.1.so)
==8072== by 0x10E7C7: ??? (in /usr/bin/msgfmt)
==8072== by 0x10D8EB: ??? (in /usr/bin/msgfmt)
==8072== by 0x4AABF32: (below main) (in /usr/lib64/libc-2.29.so)
==8072==
poc:17: duplicate message definition...
poc:16: ...this is the location of the first definition
poc:18:3: syntax error
poc:18: keyword "n" unknown
poc:19: end-of-line within string
poc:28: duplicate message definition...
poc:24: ...this is the location of the first definition
poc:35: keyword "msgud_plural" unknown
poc:34: missing 'msgstr' section
poc:35:13: syntax error
poc:40: end-of-line within string
poc:46: end-of-line within string
poc: warning: Charset missing in header.
Message conversion to user's charset will not work.
poc:42: duplicate message definition...
poc:6: ...this is the location of the first definition
poc:46:2: syntax error
poc:46: keyword "Ep" unknown
poc:47: keyword "C" unknown
poc:48: keyword "s" unknown
poc:49: keyword "bo" unknown
poc:50: keyword "S" unknown
poc:50:236: invalid control sequence
poc:50:397: invalid control sequence
poc:51: end-of-line within string
msgfmt: too many errors, aborting
==8072==
==8072== HEAP SUMMARY:
==8072== in use at exit: 59,783 bytes in 123 blocks
==8072== total heap usage: 547 allocs, 424 frees, 99,479 bytes allocated
==8072==
==8072== LEAK SUMMARY:
==8072== definitely lost: 650 bytes in 82 blocks
==8072== indirectly lost: 0 bytes in 0 blocks
==8072== possibly lost: 0 bytes in 0 blocks
==8072== still reachable: 59,133 bytes in 41 blocks
==8072== suppressed: 0 bytes in 0 blocks
==8072== Rerun with --leak-check=full to see details of leaked memory
==8072==
==8072== Use --track-origins=yes to see where uninitialised values come from
==8072== For lists of detected and suppressed errors, rerun with: -s
==8072== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Expected results:
No errors.
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=1954716
Bug ID: 1954716
Summary: Fonts not used correctly
Product: Fedora
Version: rawhide
Status: NEW
Component: fontconfig
Assignee: tagoh(a)redhat.com
Reporter: barbarah.duarte(a)fluocomunicacao.com.br
QA Contact: extras-qa(a)fedoraproject.org
CC: ajax(a)redhat.com, caillon+fedoraproject(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
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,
tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Created attachment 1776799
--> https://bugzilla.redhat.com/attachment.cgi?id=1776799&action=edit
LibreOffice with all three fonts displayed in regular, italic and bold face.
I have installed some company-provided fonts for use in presentations etc.:
$ ls /usr/share/fonts/neo-sans-intel/
NeoSansIntel-Italic.ttf NeoSansIntel-MediumItalic.ttf
NeoSansIntel-LightItalic.ttf NeoSansIntel-Medium.ttf
NeoSansIntel-Light.ttf NeoSansIntel.ttf
In LibreOffice I have a choice of three separate fonts: Neo Sans Intel, Neo
Sans Intel Medium, and Neo Sans Intel Light.
For each of those three, the italic version of the font (from the separate TTF
file) is used. I can tell by the tail on the 'f' character. For bold text,
however, an 'emboldening' algorithm seems to be used instead of using the
appropriate separate font file.
In GNOME font selection dialogs, I see just one 'Neo Sans Intel' family, with a
choice of 8 styles. I'll ignore the italic versions since those do actually
seem to work as expected, so there are four weights listed:
- Light (== Neo Sans Intel Light)
- Regular (== Neo Sans Intel Medium)
- Medium (== Neo Sans Intel Medium)
- Bold (== Neo Sans Intel Medium + emboldening algorithm?)
I *don't* seem to have an option in GNOME which will just use the straight 'Neo
Sans Intel' font.
So both seem to be getting it wrong, in different ways. Or perhaps there's
something wrong with the fonts themselves?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1771836
Bug ID: 1771836
Summary: ibus not responsive on wayland with sway as
windowmanager
Product: Fedora
Version: 31
Status: NEW
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: chorn(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
Created attachment 1635626
--> https://bugzilla.redhat.com/attachment.cgi?id=1635626&action=edit
strace when running ibus-wayland from a terminal in sway
Description of problem:
ibus not responsive on wayland with sway as windowmanager
Version-Release number of selected component (if applicable):
ibus-wayland-1.5.21-3.fc31.x86_64
ibus-1.5.21-3.fc31.x86_64
ibus-mozc-2.23.2815.102-8.fc31.x86_64
How reproducible:
always
Steps to Reproduce:
1. install Fedora31, select lxde-desktop-environment to get wayland installed
2. dnf -y install sway ibus-wayland ibus-mozc
3. useradd -m chris; passwd chris
4. Use this in the users .bashrc :
[[ $(pgrep ibus-daemon) ]] || ibus-daemon --xim --daemonize -r
export IMSETTINGS_INTEGRATE_DESKTOP=yes
export IMSETTINGS_MODULE=ibus
export QT_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
export GTK_IM_MODULE=ibus
5. Boot system into multi-usermode, for example in setting it as default target
and rebooting
6. login as user chris
7. run sway in executing 'sway'
8. get a terminal in pressing $mod + return (by default, $mod is the
windows-key)
9. verify ibus-daemon is running: 'ps ax|grep ibus'
10. try to run ibuswayland: '/usr/libexec/ibus-wayland'
Actual results:
No input_method global
Expected results:
ibus-wayland should run, and I should be able to switch input method to mozc as
configured with 'ibus-setup'.
Additional info:
- Might very well be an issue on my side.. but after trying this now for a
week, taking that to bugzilla.
- fcitx4 from Fedora works under sway.
- When setting up ibus as above, I was never able to run ibus-wayland, and ibus
did never react to attempts to switch the input method with shift+space or
ctrl+space, I tried these combinations after setting them up with ibus-setup
- Instead of running ibus-daemon from user .bashrc, I did run it from sway
directly. Steps:
mkdir ~/.config/sway
cp /etc/sway/config ~/.config/sway/config
echo 'exec /usr/bin/ibus-daemon --xim --daemonize' >>~/.config/sway/config
The result is the same though.
- When running ibus-daemon non-daemonizing from a terminal, I get this:
[chris@космос ~]$ ibus-daemon -r -v
(ibus-ui-gtk3:75725): IBUS-WARNING **: 15:00:43.303: panel.vala:255: If you
launch KDE5 on xterm, export XDG_CURRENT_DESKTOP=KDE before launch KDE5.
(ibus-ui-gtk3:75725): IBUS-WARNING **: 15:00:43.335: ibus_bus_call_sync:
org.freedesktop.DBus.Properties.Get:
GDBus.Error:org.freedesktop.DBus.Error.Failed: No global engine.
(and ibus-daemon stays running)
- I tried various terminals, for example xterm and terminator
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1933539
Bug ID: 1933539
Summary: Require mkfontdir/mkfontscale directly, not
xorg-x11-xkb-utils
Product: Fedora
Version: rawhide
Status: NEW
Component: liberation-fonts
Assignee: vishalvijayraghavan(a)gmail.com
Reporter: peter.hutterer(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: caillon+fedoraproject(a)gmail.com,
extras-qa(a)fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, mclasen(a)redhat.com,
mtasaka(a)tbz.t-com.ne.jp, petersen(a)redhat.com,
psatpute(a)redhat.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com,
vishalvijayraghavan(a)gmail.com
Depends On: 1933537
Blocks: 1932731
Target Milestone: ---
Classification: Fedora
liberation-fonts currently BuildRequires: xorg-x11-font-utils
xorg-x11-font-utils is to be split up into multiple packages, see Bug 1932731.
This package only requires mkfontscale and mkfontdir, so let's BuildRequires
these directly. xorg-x11-font-utils has had Provides for those for ages now
anyway, so this is largely a noop from this package's POV.
Suggested diff:
diff --git a/liberation-fonts.spec b/liberation-fonts.spec
index a9cc575..583e224 100644
--- a/liberation-fonts.spec
+++ b/liberation-fonts.spec
@@ -24,7 +24,8 @@ Source8: %{fontname}-sans.metainfo.xml
Source9: %{fontname}-serif.metainfo.xml
BuildArch: noarch
-BuildRequires: fontpackages-devel >= 1.13, xorg-x11-font-utils
+BuildRequires: fontpackages-devel >= 1.13
+BuildRequires: mkfontscale mkfontdir
BuildRequires: fontforge
BuildRequires: libappstream-glib
BuildRequires: python3
Verified successful build in a local F33 container with only the mkfontscale
(Bug 1932734) and bdftopcf (Bug 1932736) packages installed, no
xorg-x11-font-utils.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1932731
[Bug 1932731] X.org Utility Deaggregation - xorg-x11-font-utils
https://bugzilla.redhat.com/show_bug.cgi?id=1933537
[Bug 1933537] Require mkfontdir/mkfontscale directly, not xorg-x11-xkb-utils
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1858617
Bug ID: 1858617
Summary: vlgothic-fonts-20200719 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: vlgothic-fonts
Keywords: FutureFeature, Triaged
Assignee: tagoh(a)redhat.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Latest upstream release: 20200719
Current version/release in rawhide: 20141206-16.fc32
URL: https://osdn.jp/projects/vlgothic/releases/
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/5103/
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1916743
Bug ID: 1916743
Summary: Fedora Scientific Spin does not include ibus-table*
packages
Product: Fedora
Version: 33
Hardware: x86_64
OS: Linux
Status: NEW
Component: ibus-table
Severity: high
Assignee: mfabian(a)redhat.com
Reporter: pa_ubach(a)alum.mit.edu
QA Contact: extras-qa(a)fedoraproject.org
CC: dchen(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org,
kent.neo(a)gmail.com, mfabian(a)redhat.com,
pwu(a)redhat.com, shawn.p.huang(a)gmail.com
Target Milestone: ---
Classification: Fedora
Description of problem:
Clean install of Fedora Scientific (KDE) does not include the ibus-table*
packages that are necessary for local distributions of the keyboard.
Version-Release number of selected component (if applicable):
How reproducible:
Haven't tried
Steps to Reproduce:
1. Install Fedora Scientific
2. Try to type using dead keys in any KDE program or LibreOffice.
3.
Actual results: Vowel letters don't include accents.
Expected results: áàäâéèéêíïîóòöôúùüû
Additional info: To fix the problem, the user must install ibus-table*
packages, which is not described in the documentation, but it should not be
necessary to search it in the documentation anyway.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1757760
Bug ID: 1757760
Summary: Hiragana to English conversion with F10 key adds
unwanted letters
Product: Fedora
Version: rawhide
Status: NEW
Component: ibus-kkc
Assignee: dueno(a)redhat.com
Reporter: ykatabam(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Description of problem:
When we enter an English word with consecutive double letters (e.g. assembly)
in Hiragana mode and use F10 to convert into English, the double letters
becomes the triple letters in some cases (e.g. asssembly).
This happens irregularly, but tends to happen more often for longer words.
Here are some examples:
communication becomes commmunication
bugzilla becomes bugzilla
Pittsburgh becomes Pitttsburgh
FYI, auto-correct is disabled, as auto-correct changes the input when it's not
a dictionary word so it doesn't allow us to convert into English properly in
hiragana mode.
--
You are receiving this mail because:
You are on the CC list for the bug.