[Pkg-ime-devel] Bug#704705: Bug#704705: ibus: cannot use with both Mozilla i386 apps and emacs
osamu at debian.org
Sat Apr 6 18:06:33 UTC 2013
On Sat, Apr 06, 2013 at 08:35:33PM +0800, Aron Xu wrote:
> On Sat, Apr 6, 2013 at 2:54 PM, Osamu Aoki <osamu at debian.org> wrote:
> > Hi,
> > Thanks for investigating this. I did similar.
> > My conclusion:
> > * ibus-gtk:i386 issue is possibly user issue with downgrade.
> > * ibus-gtk3:i386 issue is possibly user issue with downgrade.
> > * ibus-qt4:i386 issue is the issue of libibus-qt1 not being multiarch.
> >> > ibus being "Multi-Arch: foreign" it can serve both i386 and amd64
> >> > applications by either one of ibus:i386 and ibus:amd64 but ibus:i386 and
> >> > ibus:amd64 are not co-installable.
> > But as I re-think ibus:i386 and ibus:amd64 should be co-installable. I
Oops. My mistake. ... ibus:i386 and ibus:amd64 are not co-installable.
ibus-gtk:i386 and ibus-gtk:amd64 should be co-installable.
> > I should have said the previous following text as the following instead.
> > ibus-gtk:i386 run-time support programs and co-installable because it is "Multi-Arch: same".
> > ibus-gtk:amd64 run-time support programs and co-installable because it is "Multi-Arch: same".
> AFAIK, ibus:i386 and ibus:amd64 should not be co-installable.
And now I recall I made sure ibus-gtk:i386 and ibus-gtk:amd6
co-installable. Their libraries are installed in different path.
$ dpkg -L ibus-gtk:i386
$ dpkg -L ibus-gtk:amd64
> The story for input method framework's Multiarch support is that, only
> one input method framework run at a time,
daemon side (ibus) yes.
> thus if you use amd64 more
> then you install an amd64 version of ibus, including engines like
> anthy, hangul, and pinyin, and also ibus-table-*. IM Modules are
> run-time plugins to UI toolkit, so they must be co-installable, so if
> you have GTK+ of both amd64 and i386, then you need both of the IM
> Modules. The IM Modules should communicate with the core framework
> using sockets, dbus, or something likewise, and the communication
> should not be architecture-specific.
> In this way can we accomplish
> Multiarch support of input method frameworks.
> > So there should be some reason why these were not co-installable here.
> >> To wit, I now have, excluding tables-* etc:
> > Oh great but what are the tables-*. I guess you mean ibus-table-*.
> > but .. wait ...
> > [2011-12-26] Accepted 126.96.36.19900528-3 in unstable (low) (Osamu Aoki)
> > ibus-table-others (188.8.131.5200528-3) unstable; urgency=low
> > * Move to utils section. Closes: #646673
> > * Convert to dh syntax and update package description.
> > * Remove non-ASCII keys. Closes: #653216
> > -- Osamu Aoki <osamu at debian.org> Sun, 25 Dec 2011 20:12:41 +0900
> > No multiarch updates were done by me but these are Architecture: all packages.
> > So this problem can not be caused by ibus-tables-*. What is going
> > on....
> I think there is no need for ibus-table-* to be Multiarch because the
> reason I said above.
I missed to understand which part of reason you mentioned, but I agree
it does not intefare with Multiarch since "Architecture: all" packages
are always installable to all arch.
> >> ii ibus-gtk:amd64 1.5.1.is.1.4.2-1 amd64 Intelligent Input Bus - GTK+2 support
> >> ii ibus-gtk:i386 1.5.1.is.1.4.2-1 i386 Intelligent Input Bus - GTK+2 support
> > For you, they were co-installable eventually for you? I could not do
> > this here too initially. When I tried first, it caused major package
> > removal situation.
> I haven't tried myself, but if they aren't co-installable then it
> reveals some packaging mistakes.
No this is caused by downgrade issues involving dependency packages
which are multiarch. It is not the problem with ibus-gtk.
> > I tried to install all dependency packages of ibus-gtk and faced problem
> > with some dependency packages. If that was caused by packages from
> > unstable, I downgraded to testing ones.
> > Then I was still stack with libgdk-pixbuf2.0-0 and libgtk2.0-0.
> > Tracing this goes to libjasper. Here libjasper1 (!= 1.900.1-13) but I
> > have 1.900.1-14
> > OK downgrade libjasper1. Similarly downgrade libcolord1 for ibus-gtk3.
> > Hmmm... aptitude can select downgrade right but its display does not
> > reflect it. This is confusing but usable... Now I have
> > ibus-gtk/ibus-gtk3 have both i386 and amd64 co-installed.
> > Anyway, you need to be careful for this kind of downgrade resolution
> > problem if you are running mixed system.
Look at libjasper1. If you have both libjasper1:i386 and
libjasper1:amd64 installed, downgrading requires you to do both at once.
Otherwise Breaks: ...(!= 1.900.1-13) type dependency or something will
cause problem. This is as empirical as it can be. i may be looking at
wrong thing. But manually downgrading both worked fine for me.
> > libibus-qt1 is not multiarch. So we can not have ibus-gt* for both
> > arch I guess. So ibus-qt package needs to be updated for multiarch to
> > support ibus-qt4 in multiarch setting.
> > Multiarch is major major change. So expect some rough ride if you wish
> > to use that functionality. It should be smoother for Jessie but wheezy
> > is first trial.
> Please have a try with Fcitx, as I'm using its Multiarch support in my
> everyday life. It works fine since the #1 day of getting Multiarch
It is working fine with other IM here too except when i tried to
More information about the Pkg-ime-devel