https://bugzilla.redhat.com/show_bug.cgi?id=1036462
Fedora Update System <updates(a)fedoraproject.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ON_QA |CLOSED
Fixed In Version| |unifont-6.3.20131221-2.fc20
Resolution|--- |ERRATA
Last Closed| |2014-01-11 03:29:02
--- Comment #25 from Fedora Update System <updates(a)fedoraproject.org> ---
unifont-6.3.20131221-2.fc20 has been pushed to the Fedora 20 stable repository.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=twN9P5vMvp&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1051431
Bug ID: 1051431
Summary: [RHEL7] fi_FI compose keys not working with ibus
Product: Red Hat Enterprise Linux 7
Version: 7.0
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: petersen(a)redhat.com
QA Contact: qe-i18n-bugs(a)redhat.com
CC: i18n-bugs(a)lists.fedoraproject.org, mfabian(a)redhat.com,
myllynen(a)redhat.com, shawn.p.huang(a)gmail.com,
tfujiwar(a)redhat.com, tiagomatos(a)gmail.com
Depends On: 1013651
Group: redhat
+++ This bug was initially created as a clone of Bug #1013651 +++
Description of problem as discussed on IRC:
With F18 and later setting LC_CTYPE=fi_FI.UTF-8 does not make
/usr/share/X11/locale/fi_FI.UTF-8/Compose keys to work, one needs to set also
XMODIFIERS=@im=none as ibus has special casing only for pt_BR.UTF-8 currently.
ibus should handle also other relevant compose maps in addition to pt_BR.UTF-8.
The list of compose file which really differ from en_US.UTF-8 is:
/usr/share/X11/locale/am_ET.UTF-8/Compose
/usr/share/X11/locale/el_GR.UTF-8/Compose
/usr/share/X11/locale/fi_FI.UTF-8/Compose
/usr/share/X11/locale/pt_BR.UTF-8/Compose
Version-Release number of selected component (if applicable):
ibus-1.5.4-1.fc20
Additional info:
The quick test to see whether fi_FI compose keys work is that with
LC_CTYPE=fi_FI.UTF-8 dead_acute + space should produce acute (not apostrophe as
with en_US.UTF-8).
--- Additional comment from Marko Myllynen on 2013-09-30 23:24:51 JST ---
Note that /etc/X11/xinit/xinitrc.d/50-xinput.sh defines:
_xcompose_language_list="am_ET el_GR fi_FI pt_BR ru_RU"
--- Additional comment from fujiwara on 2013-10-03 13:36:25 JST ---
(In reply to Marko Myllynen from comment #0)
I compared en_US.UTF-8/Compose and fi_FI.UTF-8/Compose and it seems only
'<dead_acute> <space>' is different and others are same.
--- Additional comment from Marko Myllynen on 2013-10-03 13:44:10 JST ---
(In reply to fujiwara from comment #2)
> I compared en_US.UTF-8/Compose and fi_FI.UTF-8/Compose and it seems only
> '<dead_acute> <space>' is different and others are same.
That should pretty much be the case nowadays, some time ago the mappings which
were only in fi_FI.UTF-8 were added to en_US.UTF-8:
http://cgit.freedesktop.org/xorg/lib/libX11/commit/nls/en_US.UTF-8/Compose.…
Thanks.
--- Additional comment from fujiwara on 2013-10-04 13:46:05 JST ---
(In reply to Marko Myllynen from comment #3)
> http://cgit.freedesktop.org/xorg/lib/libX11/commit/nls/en_US.UTF-8/Compose.
> pre?id=9b8d8c9e5b27273e8856a3851ba9b68022bed3cd
OK, thank you for the link and then we need to fix en_US.UTF-8.
ibus en_US.UTF-8 was copied from GTK+ one and it seems it's old.
Now I created the patch of en_US.UTF-8 and fi_FI.UTF-8 but others are not yet.
I'm a bit tired to convert the data and probably it's better to fix this in
post f20 since the change is big and the f20 beta is coming.
Probably it's also better for me to fix the fi problem when running apps with
GTK_IM_MODULE=gtk-im-context-simple .
--- Additional comment from fujiwara on 2013-10-04 14:27:21 JST ---
Attached the ongoing patch at the moment.
--- Additional comment from Marko Myllynen on 2013-10-04 18:47:08 JST ---
(In reply to fujiwara from comment #4)
> OK, thank you for the link and then we need to fix en_US.UTF-8.
> ibus en_US.UTF-8 was copied from GTK+ one and it seems it's old.
>
> I'm a bit tired to convert the data and probably it's better to fix this in
> post f20 since the change is big and the f20 beta is coming.
No prob - just one additional data point (which you probably already noticed)
that when looking at the changelog for en_US.UTF-8/Compose.pre it looks like a
yearly update or so might be warranted:
http://cgit.freedesktop.org/xorg/lib/libX11/log/nls/en_US.UTF-8/Compose.pre
Thanks.
--- Additional comment from fujiwara on 2013-10-04 19:03:14 JST ---
(In reply to Marko Myllynen from comment #6)
> http://cgit.freedesktop.org/xorg/lib/libX11/log/nls/en_US.UTF-8/Compose.pre
Yes, my patch was generated with that file by compose-parse.py :
https://git.gnome.org/browse/gtk+/tree/gtk/compose-parse.py#n24
The script referred the old pointer and I changed it to your link yesterday.
--- gtk+-3.9.8/gtk/compose-parse.py.orig
+++ gtk+-3.9.8/gtk/compose-parse.py
@@ -21,8 +21,8 @@
import getopt
# We grab files off the web, left and right.
-URL_COMPOSE =
'http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=blob_plain;f=nls/en_…'
-URL_KEYSYMSTXT = "http://www.cl.cam.ac.uk/~mgk25/ucs/keysyms.txt"
+URL_COMPOSE =
'http://cgit.freedesktop.org/xorg/lib/libX11/plain/nls/en_US.UTF-8/Compose.p…'
+URL_KEYSYMSTXT =
"https://raw.github.com/substack/node-keysym/master/data/keysyms.txt"
URL_GDKKEYSYMSH = "http://git.gnome.org/browse/gtk%2B/plain/gdk/gdkkeysyms.h"
URL_UNICODEDATATXT = 'http://www.unicode.org/Public/6.0.0/ucd/UnicodeData.txt'
FILENAME_COMPOSE_SUPPLEMENTARY = 'gtk-compose-lookaside.txt'
--- Additional comment from fujiwara on 2013-10-07 17:27:05 JST ---
OK, now I finished to generate the candidate patch.
I commented out am_ET Compose file until get the actual request because it uses
ASCII key at first but not compose keys.
--- Additional comment from fujiwara on 2013-10-08 12:34:25 JST ---
I created the test rpms:
http://fujiwara.fedorapeople.org/ibus/20131008/6034085/
Could you try the packages?
Please note I fix ibus only but not gtk-im-context-simple .
If you use GNOME, need to add some input methods with 'gnome-control-center
region' command and then GNOME will launch ibus-daemon. You could refer 'ps'
command.
(You don't have to use input method engines actually but need to list the
engines on panel icon to enable IBus on GNOME.)
If you use non-GNOME, ibus can be enabled by im-chooser command and you need to
install some XKB layout engines with ibus-setup command.
:
--- Additional comment from Mike FABIAN on 2013-10-09 16:10:20 JST ---
I tested the packages from comment#9 on Fedora 20 Beta TC1 and they
work fine.
--- Additional comment from Marko Myllynen on 2013-10-09 16:53:30 JST ---
(In reply to fujiwara from comment #9)
> I created the test rpms:
> http://fujiwara.fedorapeople.org/ibus/20131008/6034085/
>
> Could you try the packages?
>
> Please note I fix ibus only but not gtk-im-context-simple .
>
> If you use GNOME, need to add some input methods with 'gnome-control-center
> region' command and then GNOME will launch ibus-daemon. You could refer 'ps'
> command.
> (You don't have to use input method engines actually but need to list the
> engines on panel icon to enable IBus on GNOME.)
I updated the packages, rebooted, logged in via GDM, launched gnome-terminal
under gnome-shell and confirmed that LC_CTYPE is fi_FI.UTF-8. Then I added with
'gnome-control-center region' Finnish and French as Input Sources. fi is in use
and 'ps -ef | grep ibus' shows ibus running. However, the simple test
dead_acute + space still produces apostrophe not acute as expected.
Please let me know if there was a hickup in my testing procedure.
Thanks.
--- Additional comment from Marko Myllynen on 2013-10-09 18:21:28 JST ---
> Please let me know if there was a hickup in my testing procedure.
After some IRC discussion it turned out that I needed to add English (English
AG (Hunspell)) as an Input Source then ibus is enabled and the test packages
work as expected. So from ibus point of view the issue is solved.
Thanks.
--- Additional comment from fujiwara on 2013-10-10 11:57:27 JST ---
(In reply to Marko Myllynen from comment #13)
> After some IRC discussion it turned out that I needed to add English
> (English AG (Hunspell)) as an Input Source then ibus is enabled and the test
> packages work as expected. So from ibus point of view the issue is solved.
Thank you for the test.
Now I'm working on both ibus and gtk.
--- Additional comment from fujiwara on 2013-11-01 17:17:45 JST ---
The patch is upstreamed:
https://github.com/ibus/ibus/commit/e64b25c0ab8fadeae97fe78dcfcbc3a5d0869c6b
:
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1013651
[Bug 1013651] fi_FI compose keys not working with ibus
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=NGA0tKiZbZ&a=cc_unsubscribe
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=924046
Bug ID: 924046
Summary: switching between en and libpinyin is too slow
Product: Fedora
Version: 18
Component: libpinyin
Severity: unspecified
Priority: unspecified
Assignee: pwu(a)redhat.com
Reporter: yshao(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
Description of problem:
My usual way to switch between IMs are Ctrl-Space, but with F18, I found that
after I pressed Ctrl and Space, if I release the keys in the normal way, almost
immediately, the Gnome desktop won't do the switching, I have to release the
keys in 1 or 2 seconds delay, so the switching could get effective.
Version-Release number of selected component (if applicable):
ibus-1.5.1-2.fc18.x86_64
ibus-libpinyin-1.4.93-4.fc18.x86_64
libpinyin-data-0.8.1-1.fc18.x86_64
libpinyin-0.8.1-1.fc18.x86_64
How reproducible:
always
Steps to Reproduce:
1. Enable libpinyin, setup Ctrl-Space as switching hot key
2. press ctrl-space to switch IMs
3. enter following sentence to test as well "我在Red Hat工作“,key stoke squence in
pinyin is "wo zai Red Hat gong zuo"
Actual results:
Expected results:
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=XNtfGXE1Tt&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1051308
Bug ID: 1051308
Summary: Cannot change the order of input methods
Product: Fedora
Version: 20
Component: ibus
Severity: high
Assignee: tfujiwar(a)redhat.com
Reporter: by(a)moscito.org
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com
Description of problem:
There is no way to change the other of input methods under ibus, at least when
using xfce4. When running ibus-setup to get to ibus preferences, and when the
Input Methods tab is chosen, we see a list of currently active input methods
ex: [AA] Chewing
[CC] Cangjie5
[oo] English (US)
There is a paragraph of explanations that goes:
The default input method is the top one in the list,
you may use up/down buttons to change it
But there are no up or down button, and up or down arrow key
does not change the order of the method. It is especially bothersome
that all chinese input methods appear ahead of English(US).
This is serious when you choose not to have the same input method order
for every window, because unless you are lucky, you will always have
the input methods arranged in the wrong order.
Version-Release number of selected component (if applicable):
1.5.4-2.fc20
How reproducible:
every time
Steps to Reproduce:
1. install a few input methods
2. use ibus-setup or right-click the ibus icon on the status bar
3. choose the Input Methods tab
Actual results:
There is no way to rearrange the order of the input methods
Expected results:
there should be up and down arrow buttons somewhere as described by the text,
and up and down arrow keys (possibly with some modifier) should achieve same.
Additional info:
this makes it impossible to have every window use its own input method order,
because they always come up in some wrong order. In particular all Chinese
input methods appear ahead of English(US).
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=PbiXfvKumj&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=499220
Ondrej Vasik <ovasik(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |CLOSED
Fixed In Version| |coreutils-8.22-8.fc21
Resolution|--- |RAWHIDE
Last Closed| |2014-01-08 09:39:18
--- Comment #18 from Ondrej Vasik <ovasik(a)redhat.com> ---
It turned out that cut field is actually the only one scenario which could be
reasonably easily improved.
Fixed by
https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20140106/…
- closing RAWHIDE, as we don't plan any other multibyte handling performance
improvements in coreutils in near future.
Here are results of my testing:
(input file 3M4, 100k lines with 6 columns (each column with word beginning
with F)
Old package: cut -f3 mytestfile >/dev/null -> time : 0.223s
New package: cut -f3 mytestfile >/dev/null -> time : 0.029s
Old package: cut -d'F' -f3- mytestfile >/dev/null -> time : 0.264s
New package: cut -d'F' -f3- mytestfile >/dev/null -> time : 0.032s
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=KFaav3x7gT&a=cc_unsubscribe
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=920895
Bug ID: 920895
Summary: [abrt] ibus-pinyin-1.5.0-1.fc18:
PY::BopomofoEditor::updateLookupTableLabel: Process
/usr/libexec/ibus-engine-pinyin was killed by signal 7
(SIGBUS)
Product: Fedora
Version: 18
Component: ibus-pinyin
Severity: unspecified
Priority: unspecified
Reporter: li1zhong(a)163.com
Version-Release number of selected component:
ibus-pinyin-1.5.0-1.fc18
Additional info:
backtrace_rating: 4
cmdline: /usr/libexec/ibus-engine-pinyin --ibus
crash_function: PY::BopomofoEditor::updateLookupTableLabel
executable: /usr/libexec/ibus-engine-pinyin
kernel: 3.8.2-206.fc18.x86_64
uid: 1000
Truncated backtrace:
Thread no. 1 (10 frames)
#0 PY::BopomofoEditor::updateLookupTableLabel at PYBopomofoEditor.cc:214
#1 PY::BopomofoEditor::updateLookupTable at PYBopomofoEditor.cc:243
#2 PyZy::PhoneticContext::update at PhoneticContext.cc:160
#3 PyZy::PhoneticContext::reset at PhoneticContext.cc:69
#4 PY::BopomofoEngine::reset at PYBopomofoEngine.cc:151
#5 PY::ibus_pinyin_engine_focus_out at PYEngine.cc:213
#6 _g_closure_invoke_va at gclosure.c:840
#9 ibus_engine_service_method_call at ibusengine.c:845
#10 call_in_idle_cb at gdbusconnection.c:4737
#15 ibus_main at ibusshare.c:295
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=YTSNbGa9Sg&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1037082
Bug ID: 1037082
Summary: gettext FTBFS if "-Werror=format-security" flag is
used
Product: Fedora
Version: rawhide
Component: gettext
Assignee: dueno(a)redhat.com
Reporter: dkholia(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, praiskup(a)redhat.com
Description of problem
----------------------
gettext fails to build if "-Werror=format-security" flag is used.
...
m-fgrep.c:109:9: error: format not a string literal and no format arguments
[-Werror=format-security]
m-fgrep.c:117:5: error: format not a string literal and no format arguments
[-Werror=format-security]
m-regex.c:109:11: error: format not a string literal and no format arguments
[-Werror=format-security]
...
We are working on a proposal to enable "-Werror=format-security" for all
packages. Once this flag is enabled, GCC will refuse to compile code that could
be vulnerable to a string format security flaw. For more details, please see
https://fedorahosted.org/fesco/ticket/1185 page.
To understand why it is important to fix this, please see
https://fedoraproject.org/wiki/Format-Security-FAQ page.
How to fix this
---------------
The fix for these errors is quite simple. It's a matter of changing a
line like,
printf(foo);
to read,
printf("%s", foo);
That's it.
Please fix this issue in rawhide with a patch (which you should submit
to upstream to merge moving forward). Please do a new build with the
fix in rawhide. Other releases do not need to be directly fixed, but
there should be no harm in pushing out this fix/patch with other needed
changes to those branches.
In the event you don't fix this bug before the next mass rebuild,
provenpackagers may step in and update your package(s) to fix this
issue.
How reproducible
----------------
Build gettext-0.18.3.1-1.fc21.src.rpm with "-Werror=format-security" flag to
reproduce the problem.
To make this process easier, you can use a modified "redhat-rpm-config" package
from http://people.fedoraproject.org/~halfie/artifacts/redhat-rpm-config/ URL.
$ sha256sum redhat-rpm-config-9.1.0-56.fc20.*
faad7594b2080fe76497d0ce50808c905a93dd7b41c1defdde5ca57e3833d3d2
redhat-rpm-config-9.1.0-56.fc20.noarch.rpm
5aa9357174305c7285ffdbc92d7ffe1c07a8a95d5459b930461308f5aad75413
redhat-rpm-config-9.1.0-56.fc20.src.rpm
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=zc5sgateUf&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1045811
Bug ID: 1045811
Summary: [abrt] ibus-anthy-python:
engine.py:40:<module>:ImportError: cannot import name
Anthy
Product: Fedora
Version: 20
Component: ibus-anthy
Assignee: tfujiwar(a)redhat.com
Reporter: rcyriac(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, tagoh(a)redhat.com,
tfujiwar(a)redhat.com
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fIg7imjRCJ&a=cc_unsubscribe