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)
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 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).
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 xim protocol...
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 or something?
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 better.
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 best. 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.)