Bug 644771

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>

Upstreamed the fix:
http://github.com/ibus/ibus-anthy/commit/91ddf1fe0a88a97bbc34d248ef675761c5ef2d2e

(In reply to comment #2)
> Upstreamed the fix:
> http://github.com/ibus/ibus-anthy/commit/91ddf1fe0a88a97bbc34d248ef675761c5ef2d2e

This fixes the problem.
Thanks.

O-i! Thanks for the confirmation.
I'd think to fix f14 besides upstream :).

*** Bug 645436 has been marked as a duplicate of this bug. ***

Fixed in rawhide
http://koji.fedoraproject.org/koji/buildinfo?buildID=201882

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

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

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

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

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

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

(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.

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

(In reply to comment #14)

Thanks for your explanation.

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

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.

*** Bug 647804 has been marked as a duplicate of this bug. ***

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.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

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.

(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

Ah, ibus-anthy-1.2.5-3.fc14 is still testing repository.
ibus-anthy-1.2.5-1.fc14 is the latest at present.

(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.