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):
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
4. repeat step #2. Note that kinput2 send the hiragana "nihongo" to
FreeWnn's server, and the three kanji don't appear.
an error message in Japanese saying "no conversion server"
the hiragana "ã«ã»ãã" should transform into three kanji "æ¥æ¬èª"
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)
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).
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. ;)
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.
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
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
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).
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.
Ok, btw I was actually planning to turn off jserver for FC2.
Included your patch in update of xinput I'm preparing locally
for iiimf support.
A question about comment 1, is the "+kinput -xim" really
necessary, doesn't kinput2 uses XIM by default anyway?
Only kterm supports the kinput protocol, and kterm works well with
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
Fixed in xinitrc 3.36
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.)
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.
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
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.
Yeah, I agree.. the initscript code could change anytime, making
the method no longer work. Abstraction or another method does sound
The service status problem with enforcing selinux is bug 119408 btw.
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.
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
Thanks for the suggestion.
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.)