Bug 112631 - kinput2 parameters for using FreeWnn are incorrect
kinput2 parameters for using FreeWnn are incorrect
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xinitrc (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-25 01:30 EST by Eido Inoue
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version: 3.36
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-03-16 10:22:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
correctly senses whether Canna or FreeWnn is available (730 bytes, patch)
2003-12-25 01:32 EST, Eido Inoue
no flags Details | Diff
revised patch which mimics current distro behavior (732 bytes, patch)
2003-12-30 16:01 EST, Eido Inoue
no flags Details | Diff

  None (edit)
Description Eido Inoue 2003-12-25 01:30:29 EST
Description of problem:
The condition in the script /etc/X11/xinit/xinitrc.d/xinput to check
whether to use the canna or the FreeWnn Japanese conversion server is
incorrect for FreeWnn. This normally isn't noticed because we start up
both conversion servers (wasteful, I might add, since you can only use
one at a time) with a default Japanese install, and our script
picks/prefers the cannaserver.

Version-Release number of selected component (if applicable):
xinitrc-3.35-1

How reproducible:
always

Steps to Reproduce:
1. Boot a known working Japanese install. Confirm that both canna and
FreeWnn successfully start during the initscript phase
2. Using redhat-config-servers, turn off the FreeWnn server to prove
that it isn't being used
2. Start a gnome-terminal in a Japanese session. Press Shift-Space to
turn on kinput2, type "nihongo", then press the space bar to send the
hiragana three character phrase to the cannaserver to prove that it's
working. It should convert into three kanji.
3. Now using redhat-config-servers, turn off cannaserver, turn on
FreeWnn, and restart the machine so that the xinput file in xinitrc.d
is re-read
4. repeat step #2. Note that kinput2 send the hiragana "nihongo" to
FreeWnn's server, and the three kanji don't appear.
  
Actual results:

an error message in Japanese saying "no conversion server"

Expected results:

the hiragana "にほんご" should transform into three kanji "日本語"

Additional info:

xinput should be passing "-canna" as a parameter to kinput only if the
cannaserver is alive and listening, and should not pass that parameter
just because canna libraries are linked to it (which is the current test)
Comment 1 Eido Inoue 2003-12-25 01:32:50 EST
Created attachment 96695 [details]
correctly senses whether Canna or FreeWnn is available

The patch also forces kinput2 to use the modern XIM protocol, which is more
consistent with all of our other CJK languages (vs the Japanese only and
not-part-of-X kinput protocol).
Comment 2 Eido Inoue 2003-12-25 01:41:41 EST
typo in the steps-to-reproduce: typing "nihongo" into kinput2 produces
FOUR, not three, Japanese hiragana characters: "にほんご". The four
characters should convert into three han ideographs: "日本語".

also, the patch, when given a choice between FreeWnn and Canna server
(both are running), will prefer Wnn (aka jserver in the ps list). This
behavior is changed from before, where it would pick the cannaserver
if both were running.

I changed this because Canna sucks compared to Wnn. ;)
Comment 3 Akira TAGOH 2003-12-25 02:20:58 EST
Even if you hate Canna's convertion behavior, I disagree your changes,
because the upstream continues to maintains Canna again (by another
people on sourceforge.jp) and there are a possibility that behavior is
fixed in the future. but FreeWnn isn't maintained for a long time and
FreeWnn is also not enough to input Japanese. it's just little better
than FC1's Canna. I would respect the upstream's activity.
Comment 4 Eido Inoue 2003-12-30 15:58:17 EST
My apologies for disrespecting the Canna team. I meant to say that
FreeWnn currently does not suffer from the bug 112760 , bug 112762 ,
or bug 112763 , among other things, and may present a more friendlier,
easier to use environment for the non-power/non-hobbyist desktop user.

The patch submitted can trivially be changed to prefer Canna over
FreeWnn should both be running.

However, this bug is still valid in that the current conversion
chooser code in xinput is incorrect; FreeWnn will NEVER be chosen,
because the choser code incorrectly uses ldd to determine if
cannaserver, aka irohaserver, is running.

Also, I stand by my assertion that running two conversion servers is
not necessary.

As part of our desktop reform program, we have chosen one application
to be the "supported" application in most cases (i.e. Mozilla for
browsing, Evolution for mail (if someone wants Mozilla for mail, they
can still get it by going to Main Menu->Internet->Other Internet
Applications)

I'm not saying that either Canna or FreeWnn should be removed from the
distribution. I'm just saying that only one should be running by
default. kinput2 can only use one at a time, after all.

To have a server running and not being used (currently jserver) not
only waste resources, it unnecessarily increases ones security risk
(both Canna and FreeWnn have had a history of security related problems).
Comment 5 Eido Inoue 2003-12-30 16:01:24 EST
Created attachment 96733 [details]
revised patch which mimics current distro behavior

The only difference between the previous patch is the priority order. If both
Canna (cannaserver/irohaserver) and FreeWnn server (jserver) are running,
kinput connected to Canna, which mimics current behavior.
Comment 6 Jens Petersen 2004-03-10 07:37:19 EST
Ok, btw I was actually planning to turn off jserver for FC2.



Comment 7 Jens Petersen 2004-03-10 07:42:00 EST
Included your patch in update of xinput I'm preparing locally
for iiimf support.
Comment 8 Jens Petersen 2004-03-11 00:30:10 EST
A question about comment 1, is the "+kinput -xim" really
necessary, doesn't kinput2 uses XIM by default anyway?
Comment 9 Nakai 2004-03-11 02:54:41 EST
Only kterm supports the kinput protocol, and kterm works well with
xim protocol...
Comment 10 Eido Inoue 2004-03-11 12:53:07 EST
comment 8: the parameters may be pedantic (I'm not sure), but they
don't hurt. Like Nakai implied, there's no reason to use the
kinput/kinput2 protocol anymore, even for kterm
Comment 11 Mike A. Harris 2004-03-16 10:22:10 EST
Fixed in xinitrc 3.36
Comment 12 Jens Petersen 2004-03-31 10:07:22 EST
Adrian, btw with selinux in enforcing mode, "service [server] status"
no longer works for non-privileged users... any idea for alternatives?
(For Canna there exists cannaping.)
Comment 13 Eido Inoue 2004-03-31 12:03:22 EST
I'm new to SELinux. Lemme get a grasp on it and figure out what you
can and can't do. My first thought is to get the pid from /var/run and
use ps to check to see if it's alive.

The second alternative would be to connect a socket to the wnn port to
see if it's listening.
Comment 14 Mike A. Harris 2004-03-31 15:54:56 EST
Why not read the initscript and see how it checks status, then try to
do the same thing.  It's probably checking /var/lock/subsys/<foo>
and getting the PID then checking for that PID running with kill -0
or something?
Comment 15 Eido Inoue 2004-03-31 16:11:20 EST
comment 14: I could, but 1) the point of using the /sbin/service
command was to abstract the interface should the details change, and
2) I assume that if /sbin/service can't be executed, then neither can
the files/pids that the service script touches internally.

The cleanest way I can think of that survives upgradability is to send
a NOP to it's listening port.
Comment 16 Mike A. Harris 2004-03-31 16:31:06 EST
Yeah, I agree..  the initscript code could change anytime, making
the method no longer work. Abstraction or another method does sound
better.
Comment 17 Jens Petersen 2004-03-31 22:18:07 EST
The service status problem with enforcing selinux is bug 119408 btw.
Comment 18 Jens Petersen 2004-03-31 22:23:05 EST
Anyway we'd like to separate all the individual IM configuration stuff
out of xinput into separate shell config files belonging to the
inidividual IMs, which xinput will source depending on the locale
- which will simply future xinput maintenance significantly - so then
this will no longer be a xinitrc issue fwiw.
Comment 19 Mike A. Harris 2004-04-01 03:34:08 EST
That sounds like a fantastic idea Jens.  If you'd like to discuss
this sometime let me know and we can work out together what is
best.

Thanks for the suggestion.
Comment 20 Jens Petersen 2004-04-02 01:23:14 EST
Mike, I'm glad to hear you feel that way. :)

Sure, I'd be happy to discuss in bugzilla and/or irc some time.
(I opened bug 119785 for this since it doesn't really belong here.)

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