This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 644771 - ibus-anthy [F7] key cannot work with SEGV
ibus-anthy [F7] key cannot work with SEGV
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ibus-anthy (Show other bugs)
14
All Linux
high Severity medium
: ---
: ---
Assigned To: fujiwara
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs
: 645436 647804 (view as bug list)
Depends On:
Blocks: F14-accepted/F14FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2010-10-20 04:41 EDT by Masao Takahashi
Modified: 2013-02-01 09:49 EST (History)
10 users (show)

See Also:
Fixed In Version: ibus-anthy-1.2.4-2.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-28 18:17:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Masao Takahashi 2010-10-20 04:41:16 EDT
Description of problem:
In japanese mode, [F7] key cannot convert "hiragana" into "katakana".
example
  input "い" 
  press [F7]
  then convert to "イ"
  But remains "い"  

Version-Release number of selected component (if applicable):
ibus-anthy-1.2.3-2.fc14

How reproducible:
certainly

Steps to Reproduce:
1.input "い"
2.push [F7]
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 fujiwara 2010-10-20 21:14:20 EDT
I'd suggest this can be a blocker for f14 because ibus-anthy causes a SEGV with a useful feature:

segment.py:67:to_katakana:UnicodeDecodeError: 'utf8' codec can't decode byte 0xe3 in position 0: unexpected end of data

Traceback (most recent call last):
  File "/usr/share/ibus-anthy/engine/engine.py", line 990, in __update
    self.__update_convert_chars()
  File "/usr/share/ibus-anthy/engine/engine.py", line 920, in __update_convert_chars
    text, cursor = self.__preedit_ja_string.get_katakana(True)
  File "/usr/share/ibus-anthy/engine/jastring.py", line 232, in get_katakana
    text_before = R(u"".join(map(conv, self.__segments[:self.__cursor])))
  File "/usr/share/ibus-anthy/engine/jastring.py", line 230, in <lambda>
    conv = lambda s: s.to_katakana()
  File "/usr/share/ibus-anthy/engine/segment.py", line 67, in to_katakana
    return u"".join(map(lambda c: hiragana_katakana_table.get(c, (c, c, c))[0], self._jachars))
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe3 in position 0: unexpected end of data

Local variables in innermost frame:
self: <romaji.RomajiSegment object at 0x1340310>
Comment 3 Masao Takahashi 2010-10-20 23:11:53 EDT
(In reply to comment #2)
> Upstreamed the fix:
> http://github.com/ibus/ibus-anthy/commit/91ddf1fe0a88a97bbc34d248ef675761c5ef2d2e

This fixes the problem.
Thanks.
Comment 4 fujiwara 2010-10-20 23:24:41 EDT
O-i! Thanks for the confirmation.
I'd think to fix f14 besides upstream :).
Comment 5 fujiwara 2010-10-21 20:52:33 EDT
*** Bug 645436 has been marked as a duplicate of this bug. ***
Comment 6 fujiwara 2010-10-26 03:25:21 EDT
Fixed in rawhide
http://koji.fedoraproject.org/koji/buildinfo?buildID=201882
Comment 7 James Laska 2010-10-26 07:38:38 EDT
Ah, python and unicode ... fun! :)

It certainly sounds like a valid issue, but I'm unable to link this failure to a use case on the Fedora Release Criteria [1].  Does this issue in any way prevent a user from accessing the network and downloading updates?  I suspect it does not, and therefore I believe it will be acceptable to push out a F14 build as a day-0 update.

If there is a tested bodhi update for F14 available that resolves the issue, I would recommend this as a 'nice-to-have' fix and also document the failure on Common_F14_Bugs [2].

[1] https://fedoraproject.org/wiki/Fedora_14_Final_Release_Criteria
[2] http://fedoraproject.org/wiki/Common_F14_bugs
Comment 8 Adam Williamson 2010-10-26 17:50:05 EDT
it would be great to build an f14 package for this and submit it to Bodhi so it can be available as an update on release day.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 9 Fedora Update System 2010-10-26 21:42:44 EDT
ibus-anthy-1.2.4-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/ibus-anthy-1.2.4-2.fc14
Comment 10 Fedora Update System 2010-10-26 22:24:20 EDT
ibus-anthy-1.2.4-2.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/ibus-anthy-1.2.4-2.fc13
Comment 11 fujiwara 2010-10-26 22:58:16 EDT
Probably I think this bug effects the following criteria:
9. All known bugs that can cause corruption of user data must be fixed or documented at Common F14 bugs
12. All elements of the default panel configuration must be functional 

I updated the document:
https://fedoraproject.org/wiki/Common_F14_bugs#Crash_of_ibus-anthy_with_F7_or_F8_keys
Comment 12 Adam Williamson 2010-10-27 01:36:02 EDT
How can this cause corruption of user data? That means 'corrupt the data that's already there', not 'make it difficult to create new data in the form you want it to be in'.

"All elements of the default panel configuration must be functional" is a viable candidate, but we've declared gold now, so it's done...

this shouldn't be too terrible to go as a 0-day, right? I can't think of any reason you'd need to input katakana during the installation process, and then you can pull down the update to fix it. I wish we'd caught this earlier, though.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 13 fujiwara 2010-10-27 02:08:27 EDT
(In reply to comment #12)
> viable candidate, but we've declared gold now, so it's done...

I agree this is not blocker. Probably the schedule was very tight than my expectation. I thought it would be good to fix this if we still have the window.
Comment 14 Adam Williamson 2010-10-27 02:30:36 EDT
nope, as I said, we've gone gold, which means nothing changes now, I'm afraid.

We did try to do our best to communicate the schedule on the development and test mailing lists. It was also available here:

http://poelstra.fedorapeople.org/schedules/f-14/f-14-devel-tasks.html

that's the 'development' calendar, there's a range of calendars available and an 'all' view too, see the strip of links across the top. It clearly notes the Final Change Deadline was Mon 2010-10-18 (after which only blocker and NTH fixes were accepted). The QA calendar notes the Fedora 14 Final Go/No-Go Meeting (17:00 US Eastern) today; practically speaking the latest we can spin an RC before the go/no-go meeting and avoid slipping is the Friday prior, which was the 22nd.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 15 fujiwara 2010-10-27 03:25:50 EDT
(In reply to comment #14)

Thanks for your explanation.
Comment 16 Fedora Update System 2010-10-28 01:44:36 EDT
ibus-anthy-1.2.4-2.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update ibus-anthy'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/ibus-anthy-1.2.4-2.fc14
Comment 17 Fedora Update System 2010-10-28 18:17:10 EDT
ibus-anthy-1.2.4-2.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Takehiko Abe 2010-10-29 10:35:39 EDT
*** Bug 647804 has been marked as a duplicate of this bug. ***
Comment 19 Fedora Update System 2010-10-29 16:41:52 EDT
ibus-anthy-1.2.4-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 20 Adam Williamson 2010-11-01 19:50:37 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 21 Iwao Yagami 2010-12-10 08:37:25 EST
This is still a problem. Does the fix being pushed to the stable repository not necessarily mean that the fix has been actually pushed yet? (I don't seem to have any outstanding patches from the update repository, either~?)

On Japanese keyboards the カタカナ/ひらがな/ローマ字 button to the left of the [Alt] key does lots of weird stuff, none of them correct for a Japanese keyboard. The F7 key removes whatever was typed in Hiragana once the enter key is pressed.
There is no clean way to flip between input modes within Japanese at the moment, the closest thing to a solution is to type whatever you want in Hiragana and then hit space to flip through possibilities -- which is unbelievably cumbersome for people writing technical documents.

This indeed *is* a show stopper / adoption blocker for the construction company I would like to pitch Linux to next week. I must test some other input methods (Canna?) and hope they work as expected or find a different distro with clean input methods to demo Linux on.
Comment 22 fujiwara 2010-12-10 10:21:43 EST
(In reply to comment #21)
> This is still a problem. Does the fix being pushed to the stable repository not
> necessarily mean that the fix has been actually pushed yet? (I don't seem to
> have any outstanding patches from the update repository, either~?)

Hi,
The latest is ibus-anthy-1.2.5-3.fc14 .
Would you download it with yum?

# yum install ibus-anthy
Comment 23 fujiwara 2010-12-10 10:23:46 EST
Ah, ibus-anthy-1.2.5-3.fc14 is still testing repository.
ibus-anthy-1.2.5-1.fc14 is the latest at present.
Comment 24 Iwao Yagami 2010-12-22 11:45:10 EST
(In reply to comment #23)
> Ah, ibus-anthy-1.2.5-3.fc14 is still testing repository.
> ibus-anthy-1.2.5-1.fc14 is the latest at present.

We are getting by using mozc for the time being, which works surprisingly well (some note-taking is in order). We'll test Anthy before reverting once 1.2.5 actually makes it to the stable repository.

Off-topic thought worthy of a separate discussion: I wonder if it would be possible to pass a user's individual kanji-use preferences and history between methods to simplify transitioning between method managers.

Note You need to log in before you can comment on or make changes to this bug.