Red Hat Bugzilla – Bug 133880
[xorg] httx does not get activated for bn_IN, gu_IN, pa_IN
Last modified: 2007-11-30 17:07:13 EST
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):
Steps to Reproduce:
1. login to KDE in any of the above locales.
2. start gedit
3. ctrl+space to switch to native language
Input still happens in english, and not in native language
Input shd happen in native language
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 <email@example.com>
* 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
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
>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.
It is upstream CVS now:
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
<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
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.