Description of problem: httx does not get activated for bn_IN, gu_IN, pa_IN in KDE, so user is unable to input native language text in these locales. Version-Release number of selected component (if applicable): kdebase-3.3.0-5 How reproducible: Every time Steps to Reproduce: 1. login to KDE in any of the above locales. 2. start gedit 3. ctrl+space to switch to native language Actual results: Input still happens in english, and not in native language Expected results: Input shd happen in native language Additional info:
Deferred due to X limitation on Indic rendering.
Well, text in Indic cannot be composed in status window because of the limitation of X rendering but the input to applications thru htx should still work. So it maybe still good idea to enable them other than no default on Indic input in KDE. Tagoh-san, you had a patch on this a while ago to enable several extra locales and seems that it didn't get committed into svn. Shao, Tagoh-san, please confirm if this patch still vaild for latest r12.
Created attachment 104996 [details] additional langlist patch from openi18n-im
no, that patch was obsoletes. instead, -xiiimp-locale.patch has already been committed. 2004-08-25 Akira TAGOH <tagoh> * iiimp/iiimpIM.c (get_IM_language): try to find the supported language with ll_cc and ll if ll_cc.charset was not found.
I have talked to Tagoh-san, it is related to X does not have those three locale in the locale.alias. Mike, if Xorg upstream cannot able to commit the patch in time, can we able to do it locally?
Leon: Please paste the X.org bugzilla URL here so we can track this issue. TIA
Mike, generally we got a OK sign from Sun which is what the upstream has requested: http://freedesktop.org/bugzilla/show_bug.cgi?id=860 It would be great if you can leave this bug open for tracking on our side too. Thanks.
Once it is committed to X.Org CVS it will have been officially approved by X.Org, at which point we will review the changes committed, and consider adding the same changes to our own rpm packaging. >It would be great if you can leave this bug open for tracking on our >side too. Thanks. This is done by setting status to "UPSTREAM", which indicates we are tracking it in the upstream bugzilla. Once it is committed to CVS upstream, please set the status back to ASSIGNED here if you notice it change. We poll upstream for changes in bugs from time to time and will eventually notice it change once it changes. Thanks Leon.
It is upstream CVS now: https://freedesktop.org/bugzilla/show_bug.cgi?id=860 It would be great if you can include it in next xorg bulid in RHEL4. Thanks Mike.
We should get this one closed, since we already have a fix.
ping, who is doing this? It needs to be done asap
Mike, would you tell us what is timeframe for the next xorg rebuild with this patch? Thanks
Leon: I'm planning on reviewing this patch in the next day or so and applying it to FC3/4, RHEL4 builds. Once the patch has been integrated into CVS, and successfully built in a beehive collinst, I will update the bug report to reflect the status so testing can begin. Thanks Leon
Update: <mharris> when will bugzilla be avail? <mharris> I need a patch desperately <daniels> as soon as gabe.fd.o comes back up Once it's up, I'll put it into a build.
Patch was integrated into CVS on Thursday or Friday last week, and will now be in all future builds for FC3/FC4/RHEL4.
Thanks for your update, Mike. Any idea on the next build date for RHEL4? It would be great if there are some time before the RC freeze for QA to test the changes.
We're trying to work out problems in the current unified rpm which cause it to fail to build in FC4, since we share the same patches/spec between multiple OS releases, however CVS is not set up correctly for this, so it needs some love. If we absolutely need a build of this for RHEL4 immediately, that can be accomodated, just say the word. I'd prefer to fix the FC4 problem and get CVS fixed so we have a single unified source rpm once again though. Not sure how long that will take just yet, as I'm still trying to figure out how to do this in our current CVS infrastructure. I assume it'll take a couple of days to work the details out and take a stab at fixing CVS. Just let me know if a build is needed before then.
Tested with xorg-x11-6.8.1-19 in dist-4E-HEAD, bn, gu and pa now gets activated in KDE desktop. Manually startup is ok as well.
Ok, thanks for the testing results guys. Setting status to "NEXTRELEASE" and "RAWHIDE"
Mike, this appears to be in dist-4E-HEAD only, can we make sure it gets moved to dist-4E? Its blocking some OOo gu_IN functionality.
I feel the same way too. Let close the bug after the package has been moved to dist-4E.
I did patch integration for FC3, and merged everything across all branches, then did builds for each OS release. Kristian IIRC is going to handle the RHEL4 late revision process. I'm unfamiliar with how things get from dist-4E-HEAD to dist-4E, and assumed that was something performed by RELENG. Since Thurs/Fri were US holidays, krh and other X developers were on holiday. You may want to email krh today if this is critically important. If he's not around however, ping me again and I'll see what I can do. Hope this helps.
Kristian: We need to get a build of Xorg with this patch into RHEL4, Mike said you were heading the late revision process for Xorg, so this one is yours. The work is done (and the bug is verfied fixed), all that needs to happen is to make sure this fixed X11 gets moved from 4E-HEAD -> 4E. Thanks!
xorg-x11-6.8.1-20.EL includes the fix and is now built and nominated for inclusion into RHEL4, see tracker bug #141350.
Look like it is in 4E.
xorg-x11-6.8.1-21.EL is included in re1201.0. Closing out.