March 2014 - i18n-bugs - Fedora Mailing-Lists

[Fedora-i18n-bugs] [Bug 1037008] New: Canna FTBFS if "-Werror=format-security" flag is used

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1037008 Bug ID: 1037008 Summary: Canna FTBFS if "-Werror=format-security" flag is used Product: Fedora Version: rawhide Component: Canna Assignee: tagoh(a)redhat.com Reporter: dkholia(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, tagoh(a)redhat.com Description of problem ---------------------- Canna fails to build if "-Werror=format-security" flag is used. ... can.c:1239:6: error: format not a string literal and no format arguments [-Werror=format-security] can.c:1300:9: error: format not a string literal and no format arguments [-Werror=format-security] can.c:1304:9: error: format not a string literal and no format arguments [-Werror=format-security] can.c:1494:7: 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 Canna-3.7p3-40.fc20.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=7QAOMinhOi&a=cc_unsubscribe

10 years

1
11
0 / 0

[Fedora-i18n-bugs] [Bug 1074879] New: iBus does not honor layout options (e.g. cz(qwerty))

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1074879 Bug ID: 1074879 Summary: iBus does not honor layout options (e.g. cz(qwerty)) Product: Fedora Version: 20 Component: ibus Severity: medium Assignee: tfujiwar(a)redhat.com Reporter: martin.sourada(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, kas(a)fi.muni.cz, shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com Depends On: 760213 +++ This bug was initially created as a clone of Bug #760213 +++ Description of problem: I want to use multiple keyboard layouts: English/US, and Czech(qwerty) and Japanese (mozc). I have added the Japanese one to ibus, but there's no option for Czech(qwerty) and it does not pick up system defined layouts (via XFCE's Preferences -> Keyboard -> Layouts). This in Xfce. Last time this used to work was a few releases back, probably F17, sorry about reporting it so late. Happens both on upgraded installs (tested on i686) and fresh install where I even added the czech(qwerty) in anaconda (tested on x86_64). Version-Release number of selected component (if applicable): ibus-1.5.5-2.fc20.i686 How reproducible: 100 % Steps to Reproduce: 1. Run an XFCE4 session 2. Run (main menu) -> Settings -> Keyboard 3. In Layout make sure there's English (US) and Czech with Czech (qwerty) variant. 4. Choose "Use iBus (recommended)" in (main menu)->Settings->Input Method Selector, then click on the "Preferences..." next to iBus. Actual results: System layouts are present neither in config dialog nor ibus layout switcher, nor can czech(qwerty) be added. Expected results: Either pick up system layouts automagically or let the user pick up all variants of given national layout. Additional info: I want to use iBus because I occasionally need also Japanese input (with mozc engine) and I want to have only one way (one shortcut) to switch between all the different layouts/ims. I don't think it is XFCE4 specific, but I currently don't have GNOME3 installed in order to verify this. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=760213 [Bug 760213] iBus does not honor layout options (e.g. cz(qwerty)) -- 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=xkEhf8ejIt&a=cc_unsubscribe

10 years

1
11
0 / 0

[Fedora-i18n-bugs] [Bug 1074883] New: English layout is added every time ibus is restarted resulting in duplicate entries

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1074883 Bug ID: 1074883 Summary: English layout is added every time ibus is restarted resulting in duplicate entries Product: Fedora Version: 20 Component: ibus Assignee: tfujiwar(a)redhat.com Reporter: martin.sourada(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 Created attachment 872993 --> https://bugzilla.redhat.com/attachment.cgi?id=872993&action=edit iBus preferences, Xfce keyboard preferences and iBus layout switch list on top of each other Description of problem: I have system keyboard layouts (set via Xfce) English (US) and Czech (qwerty) which aren't picked up by ibus (see Bug 1074879 ). In ibus I have set English (US), Czech (no qwerty available -- see Bug 1074879 again), Japanese - mozc and Russian - translit (m17n). Everytime I restart ibus (or is started by logging in) new English US layout is added. Only to the layout switch list. It does not appear in the settings so it cannot be removed. Currently I have 8 times more English US layouts in the list than set up. Happens both in fresh install as well as upgrade from F19. Version-Release number of selected component (if applicable): ibus-gtk2-1.5.5-2.fc20.i686 How reproducible: Always Steps to Reproduce: 1. Set up both system and ibus layouts 2. Restart ibus. Actual results: Two English layouts (and growing) present in layout switch list, only one in settings. Expected results: Same layouts in settings as in the layout switch list. Additional info: see the attachment -- 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=Dh97vIEuKe&a=cc_unsubscribe

10 years

1
10
0 / 0

[Fedora-i18n-bugs] [Bug 1056912] New: Home and End keys in preedit cause commit

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1056912 Bug ID: 1056912 Summary: Home and End keys in preedit cause commit Product: Fedora Version: 20 Component: ibus-kkc Assignee: dueno(a)redhat.com Reporter: petersen(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Description of problem: When in preedit using ibus-kkc pressing the Home or End keys causes the current preedit text to be committed. I would like to be able to use Home and End to move to the beginning and end of the preedit buffer. Version-Release number of selected component (if applicable): ibus-kkc-1.5.19-1.fc20 libkkc-0.3.2-1.fc20 Steps to Reproduce: 1. start inputting Japanese with libkkc 2. press Home or End while still in pre-edit 3. continue input Actual results: 2. pre-edit text is committed Expected results: 2. cursor to move to beginning or end of preedit buffer -- 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=BGjCPZSq2U&a=cc_unsubscribe

10 years

1
6
0 / 0

[Fedora-i18n-bugs] [Bug 1024421] New: ibus-kkc has problems when capslock is hit after conversion has started

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1024421 Bug ID: 1024421 Summary: ibus-kkc has problems when capslock is hit after conversion has started Product: Fedora Version: 20 Component: ibus-kkc Assignee: dueno(a)redhat.com Reporter: mfabian(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Created attachment 817127 --> https://bugzilla.redhat.com/attachment.cgi?id=817127&action=edit hitting-capslock-causes-problems-in-ibus-kkc-when-conversion-has-started.ogv Fedora 20 Beta TC6, ibus-anthy-1.5.4-1.fc20.x86_64 - Use ibus-kkc to type in gnome-terminal. - Make sure capslock is off - type ‘a’ → one sees ‘あ’ in preëdit. - Hit the capslock key → the ‘あ’ is commited. OK. - type ‘a’ again → again one sees ‘あ’ in preëdit. - type space to start conversion to kanji → one sees ‘亜’ in preëdit (or some other kanji ...) - Now hit the capslock key again The ‘亜’ is *not* committed, it stays white on black as if still were in the conversion phase. But typing space does not give other candidates, it just moves the ‘亜’ (still white on black) to the right. Typing RETURN a few times now moves the ‘亜’ down some lines, leaving partial remains in the previous lines. See attached video. -- 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=AezmtoysHR&a=cc_unsubscribe

10 years

1
6
0 / 0

[Fedora-i18n-bugs] [Bug 1024061] New: ibus-kkc: A change of the pagination_start option in the setup tool is not applied immediately

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1024061 Bug ID: 1024061 Summary: ibus-kkc: A change of the pagination_start option in the setup tool is not applied immediately Product: Fedora Version: 20 Component: ibus-kkc Assignee: dueno(a)redhat.com Reporter: mfabian(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org [mfabian@Fedora-20-Beta-TC6-x86_64-netins ~]$ rpm -q ibus-kkc ibus-kkc-1.5.18-1.fc20.x86_64 [mfabian@Fedora-20-Beta-TC6-x86_64-netins ~]$ - Japanese install - Select ibus-kkc in the gnome panel - Type some hiragana - Hit space to convert to kanji - Hit space again → candidate table pops up - Click the あ in the gnome panel, click on 設定 (setup) in the menu which pops up → The setup tool of ibus-kkc starts - In the first tab of the setup tool (labelled 動作) the second last option is: 候補ウィンドウの表示開始位置(G): [0 -+] Change this option to 7: 候補ウィンドウの表示開始位置(G): [7 -+] - Type some hiragana again - Hit space to convert to kanji - Hit space again → candidate table pops up ! Here is a problem, the candidate table should not pop up now after typing space only twice, we changed that option to 7! - click the あ in the gnome-panel and switch to some other input source - switch back to ibus-kkc using the gnome-panel - Type some hiragana again - Hit space until the canditatetable pops up → Now hitting space 8 times is necessary That is correct. So changing this option does not become effective immediately, only after switching to some other input source and back to ibus-kkc this works. This is *different* from the other options 句読点の形式(P): [。、 ↓] ... 候補ウィンドウの項目数(W): [7 -+] [✓] 候補の注釈を表示する these options become effective *immediately* when the are changed without having to switch the engine back and forth. So I think that the 候補ウィンドウの表示開始位置 does not become effective immediately is a bug. -- 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=9r661P6WB5&a=cc_unsubscribe

10 years

1
5
0 / 0

[Fedora-i18n-bugs] [Bug 1016984] New: [ml_IN] Unicode standard sequence for stacked chillu-N and RRA not supported in Lohit Malayalam

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1016984 Bug ID: 1016984 Summary: [ml_IN] Unicode standard sequence for stacked chillu-N and RRA not supported in Lohit Malayalam Product: Fedora Version: rawhide Component: lohit-malayalam-fonts Assignee: psatpute(a)redhat.com Reporter: samjnaa(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com Description of problem: As per TUS 6.2 chapter 9.9 p 321 (p 351 of PDF) the correct sequence to get the display of stacked chillu-N on top of RRA in Malayalam is: CHILLU N + VIRAMA + RRA. That is: ൻ്റ = 0d7b 0d4d 0d31. However, currently Lohit Malayalam font does not support this sequence. Testing Lohit Malayalam and Google Noto Sans Malayalam with latest HarfBuzz git head shows that Lohit is not capable of rendering this sequence correctly whereas Noto is capable. Please fix it so that ൻ്റ = 0d7b 0d4d 0d31 is correctly rendered as stacked chillu-N on top of RRA. Version-Release number of selected component (if applicable): 2.5.4 -- 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=DqJbnx7nVd&a=cc_unsubscribe

10 years

1
11
0 / 0

[Fedora-i18n-bugs] [Bug 1075892] New: update package URL to typingbooster.org

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1075892 Bug ID: 1075892 Summary: update package URL to typingbooster.org Product: Fedora Version: rawhide Component: ibus-typing-booster Assignee: apatil(a)redhat.com Reporter: petersen(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: apatil(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org, mfabian(a)redhat.com Description of problem: Package is still pointing to fedorahosted git can it please be updated typingbooster.org. -- 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=fEjwWC1FJd&a=cc_unsubscribe

10 years, 1 month

1
7
0 / 0

[Fedora-i18n-bugs] [Bug 1077558] New: kakasi-2.3.6 is available

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1077558 Bug ID: 1077558 Summary: kakasi-2.3.6 is available Product: Fedora Version: rawhide Component: kakasi Keywords: FutureFeature, Triaged Assignee: tagoh(a)redhat.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, tagoh(a)redhat.com Latest upstream release: 2.3.6 Current version/release in Fedora Rawhide: 2.3.5-1.fc21 URL: http://kakasi.namazu.org/stable/ 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 -- 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=bOQOnJYzC6&a=cc_unsubscribe

10 years, 1 month

1
6
0 / 0

[Fedora-i18n-bugs] [Bug 1072940] New: Left Shift stopped work for ibus-table-1.5.0.20140218-1.fc20.noarch

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1072940 Bug ID: 1072940 Summary: Left Shift stopped work for ibus-table-1.5.0.20140218-1.fc20.noarch Product: Fedora Version: 20 Component: ibus-table Severity: medium Assignee: mfabian(a)redhat.com Reporter: danielsun3164(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: dchen(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org, kent.neo(a)gmail.com, me(a)kaio.net, mfabian(a)redhat.com, pwu(a)redhat.com, shawn.p.huang(a)gmail.com Description of problem: After update to ibus-table-1.5.0.20140218-1.fc20.noarch, Left Shift stopped work for me. Version-Release number of selected component (if applicable): $ rpm -q ibus-table ibus-table-1.5.0.20140218-1.fc20.noarch How reproducible: Everytime Steps to Reproduce: 1. Start a input method using ibus-table(ex. ibus-table-chinese-wubi-jidian). 2. Input "a" key, then click "left shift" key. 3. nothing happens. Actual results: 1. Nothing happens when click "left shift" key. 2. The following error log can be found in ~/.ibus/table/debug.log AttributeError: 'editor' object has no attribute 'l_shift' Traceback (most recent call last): File "/usr/share/ibus-table/engine/table.py", line 1570, in do_process_key_event result = self._process_key_event (key) File "/usr/share/ibus-table/engine/table.py", line 1592, in _process_key_event return self._table_mode_process_key_event (key) File "/usr/share/ibus-table/engine/table.py", line 1646, in _table_mode_process_key_event res = self._editor.l_shift () Expected results: "Left Shift" key is the hot key to create new phrase. I expect to create new phrase by clicking "left shift". -- 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=HFd4bM3avA&a=cc_unsubscribe

10 years, 1 month

1
25
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs March 2014