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 <os...@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++ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
