[Pkg-ime-devel] Bug#704705: Bug#704705: ibus: cannot use with both Mozilla i386 apps and emacs

Toni Mueller support at oeko.net
Sat Apr 6 14:37:51 UTC 2013


Hi,

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:
> > My conclusion:
> >  * ibus-gtk:i386  issue is possibly user issue with downgrade.
> >  * ibus-gtk3:i386 issue is possibly user issue with downgrade.

I don't understand this comment.

> AFAIK, ibus:i386 and ibus:amd64 should not be co-installable.

Indeed, I can have only one of these at the time.

> 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.

Sounds good to me. But I don't understand much about GUI
programming... :/

> > 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-*.

Yes, sorry for the confusion.

> I think there is no need for ibus-table-* to be Multiarch because the
> reason I said above.

Yes, they are all architecture "all", so there is no action required.

> >> 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 was struggling with this as well, and that led to my initial bug
report. As I wrote, trying to co-install these, and other relevant,
packages is quite a bit of a hit-and-miss experience. I think this
should be a limitation in apt and aptitude. What I did to co-install
these packages, was to actually download the packages individually, then
installing them like this:

# dpkg -i pkg1 pkg2 pkg3 ...

Please note that this is neither an acceptable solution for the average
end user, nor is it straightforward: You have to co-install all relevant
packages in one go, otherwise, you'll end up with eg. only the i386
versions of it, or whichever version you specified last.

> I haven't tried myself, but if they aren't co-installable then it
> reveals some packaging mistakes.

As things currently stand, it looks like these packages are
co-installable, just not via apt or aptitude.

> > 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

$ dpkg -l libgdk-pixbuf2.0-0   libgtk2.0-0 libjasper1
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                 Version                 Architecture
+++-====================================-=======================-============
ii  libgdk-pixbuf2.0-0:amd64             2.26.1-1                amd64
ii  libgdk-pixbuf2.0-0:i386              2.26.1-1                i386
ii  libgtk2.0-0:amd64                    2.24.10-2               amd64
ii  libgtk2.0-0:i386                     2.24.10-2               i386
ii  libjasper1:amd64                     1.900.1-13              amd64
ii  libjasper1:i386                      1.900.1-13              i386

libjasper1 1.900.1-14 is in unstable, not in testing.

> > OK downgrade libjasper1.  Similarly downgrade libcolord1 for ibus-gtk3.

$ dpkg -l libcolord1 ibus-gtk3
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                 Version                 Architecture
+++-====================================-=======================-============
ii  ibus-gtk3:amd64                      1.5.1.is.1.4.2-1        amd64
ii  ibus-gtk3:i386                       1.5.1.is.1.4.2-1        i386
ii  libcolord1:amd64                     0.1.21-1                amd64

Maybe I have a problem there, with libcolord1...

> > Anyway, you need to be careful for this kind of downgrade resolution
> > problem if you are running mixed system.

Yes. I've written a script to download packages at specific versions to have
the same versions for both architectures. Otherwise, if the versions differ,
dpkg refuses to install anything. But I had to use --force-overwrite plenty
of times, anyway.

> > 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.

That would be great!

> 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
> support.

I am currently running fcitx, but this has problems of its own, most
notably (in my experience, anyway - I guess it works better elsewhere):
It's impossible to activate and deactivate it using Super_R (one of my
only unused keys not already captivated by other applications), keyboard
shortcuts are hard to configure, and the popup menu that indicates the
current settings, and the preview window that offers the choices, is so
tiny that it is very hard to read for me (oh, and I cannot scroll the
list of choices, too). @Aron: Should I file bugs for any of these?


Kind regards,
--Toni++



More information about the Pkg-ime-devel mailing list