Since OpenOffice.org is an i386 package, if you want to use IIIMF on an x86-64/EM64T platform with OOo, you have to install the i386 IIIMF packages in parallel so that the i386 GTK that OOo links against can use the input stuff. However, the packages have conflicts being installed at the same time: [root@dolemite RPMS]# rpm -Uvh iiim* warning: iiimf-csconv-12.1-10.EL.i386.rpm: V3 DSA signature: NOKEY, key ID 897da07a Preparing... ########################################### [100%] file /etc/iiim/le.xml.conf from install of iiimf- server-12.1-10.EL conflicts with file from package iiimf- server-12.1-10.EL file /usr/share/emacs/site-lisp/iiimecf/EIMIL.elc from install of iiimf-emacs-12.1-10.EL conflicts with file from package iiimf- emacs-12.1-10.EL file /usr/share/emacs/site-lisp/iiimecf/PCE.elc from install of iiimf-emacs-12.1-10.EL conflicts with file from package iiimf- emacs-12.1-10.EL file /usr/share/emacs/site-lisp/iiimecf/iiimcf-UI.elc from install of iiimf-emacs-12.1-10.EL conflicts with file from package iiimf-emacs-12.1-10.EL file /usr/share/emacs/site-lisp/iiimecf/iiimcf-sc.elc from install of iiimf-emacs-12.1-10.EL conflicts with file from package iiimf-emacs-12.1-10.EL file /usr/share/emacs/site-lisp/iiimecf/iiimcf.elc from install of iiimf-emacs-12.1-10.EL conflicts with file from package iiimf- emacs-12.1-10.EL file /usr/share/emacs/site-lisp/iiimecf/iiimp.elc from install of iiimf-emacs-12.1-10.EL conflicts with file from package iiimf- emacs-12.1-10.EL Severity: Without fixing im-sdk, International users will not be able to input international text in OpenOffice.org.
In this example, the x86-64 packages have already been installed on this EM64T machine, and we are attempting to install the i386 packages in parallel.
Ed and I aren't entirely sure what the problem is, since we can't quite get XIM/IIIMF stuff to work on x86-64 with OOo. We removed the x86_64 IIIMF RPMs and installed the i386 ones, but we still have no luck after having done the following: service canna restart service iiim restart export LANG=ja_JP.UTF-8 export GTK_IM_MODULE=iiim oowriter Ctl+Space The Ctl+Space doesn't give us anything and OOo doesn't think that international input is enabled.
Clarification: the iiimf packages with the conflicts are *not* currently in the x86-64 tree, correct?
No, there are no conflicts because the i386 im-sdk packages aren't in the x86-64 composes. However, were they to be added, there would be conflicts. Somebody needs to figure out if we want customers to be able to do international input with OOo on x86-64/EM64T and if so, then we need to fix this bug, otherwise punt it to U1.
Jens is maintaining iiimf-emacs. Jens, do you have any comments?
Comment #2: If you are sure that OOo uses gtk2 vclplug, then please make sure if there is /usr/lib/gtk-2.0/2.4.0/im-iiim.so. for a workaround, OOo wrapper script could set GTK_IM_MODULE=xim for x86_64 only. then gtk2 immodule won't be required and people won't needs to install i386 binaries of im-sdk into x86_64 box.
iiimf-emacs is actually noarch (ie arch independent): there is definitely no need to install both iiimf-emacs.i386 and iiimf-emacs.x86_64: I think iiimf-emacs.i386 should not be included to any i386 iiimf packages added for multilib archs.
I don't test im-sdk to install both binaries at the same time on x86-64 box yet, but just asked upstream about this. the client/server should be able to connects to/from different architectures, I mean, for instance, 32-bit client can connects to 64-bit server, also 64-bit client can connects to 32-bit server as well. So it looks like a packaging issue at this moment. perhaps we will need to do similar stuff like gtk2 does, in order to install both binaries at the same time anyway. Naming change proposal: For 32-bit htt => htt32 htt_server => htt32_server htt_xbe => htt32_xbe httx => httx32 /etc/iiim => /etc/iiim/%{_host}-gnu For 64-bit htt => htt64 htt_server => htt64_server htt_xbe => htt64_xbe httx => httx64 /etc/iiim => /etc/iiim/%{_host}-gnu For wrapper script htt_server htt_xbe httx
From my own experience, all that is needed is to include iiimf-gtk.i386 (and its dep iiimf-libs.i386) in comps for multilib archs which include Oo.o. So re-assigning to comps. (For the recent FC3 update of im-sdk we included those i386 pkgs for x86_64.)
There is no logic in comps for 'arch where OO.o is a multlib package.'
Arguably, it should just be in the same group that the compat gtk2 is in. So generic compat arch support. Otherwise, gtk2 apps in general won't be able to use iiimf. OOo is just the example of this we ship, but it's just as relevant for, eg, eclipse probably or realplayer.
As it is in RHEL4, assigning to mike
Actually the iiimf-gtk and iiimf-libs packages are built for ppc64 and are listed in the errata as well as the latest night compose, so this is ready to go. Moving to PROD_READY.
shipped. closing.