app-i18n/ibus-qt-1.3.3 appears to be built against qt 4 libraries. As a result, it is impossible to use ibus in any KDE 5 applications. See: http://linux.overshoot.tv/app-i18n/ibus-qt > app-i18n/ibus-qt is necessary in order to be able to use the ibus input system within KDE applications. > Make sure that the ibus-qt package is built against the same qt library versions as your KDE applications. > For example (output truncated): $ equery depgraph ibus-qt-1.3.1 * dependency graph for app-i18n/ibus-qt-1.3.1 `-- dev-qt/qtcore-4.8.7-r2 (dev-qt/qtcore) amd64 `-- dev-qt/qtdbus-4.8.7 (dev-qt/qtdbus) amd64 > At the same time, we have (ouptut truncated): $ eix dev-qt/qtcore Installed versions: 4.8.7-r2 5.7.1-r3 > Thus it can be inferred that ibut-qt will work with KDE packages built against 4.8 qtcore, but not with KDE 5 packages. Which leads to bug reports like: ibus (chewing, etc.) does not work in KDE applications http://linux.overshoot.tv/ticket/9148
Oops. Sorry for the formatting. Is there a guide as to what formatting is applicable here?
If you are the one creating those bugs anyway, then instead of linking to a different tracker add any relevant information on bugs.gentoo.org. If there's nothing relevant added by an external tracker, then don't link to it.
I believe that a version bump alone would not fix the bug (though it would be welcome anyway). As mentioned in the wiki here: http://linux.overshoot.tv/wiki/ibus_chinese_input_not_working_specific_applications and here: http://linux.overshoot.tv/app-i18n/ibus-qt The package ibus-qt should be built against the proper qt library. This is relevant in distributions (like gentoo) which may ship with several qt libraries installed (e.g. qt4 and qt5). ibus-qt will only work within applications built for the same libraries as itself. Since gentoo has had the policy of a progressive upgrade of KDE application from 4 to 5, the two versions of the qt libraries co-exist. The same scenario is likely to appear again in the future when we upgrade from qt5 to qt6 (kde5 to kd6 applications). Thus, for ibus to work with *all* KDE applications, the ideal fix would introduce a slot so that two versions of ibus-qt can be installed, leaving the current app-i18n/ibus-qt-1.3.3 in the tree, built with qt4, and the newest version being built in a different slot against qt5. As to the bug report in the other tracker, it was created almost a year ago (October 2016), and I have been asking left and right ever since, including in the gentoo forums, but none of the solution offered seemed to work. It's only recently that it dawned on me that it might be a gentoo packaging problem as just explained. I was amused when I realised that in order to experience this bug, one had to be a gentoo-kde5-ibus-chinese user, and that I may be the only such individual in the world! :) No wonder nobody could help me! Thus I offer this complete bug report in the best spirit of the Open Source community and in gratitude to the Qt, KDE, Ibus, Gentoo developers! :)
Please don't rename again. The specifics will be figured out by the maintainers anyway.
The version bump is a (In reply to augustin from comment #3) > I believe that a version bump alone would not fix the bug (though it would > be welcome anyway). A version bump is required in any case because 1.3.3 does not support build with Qt5. It seems though that ibus-1.5.16 is well packaged in portage, and it pulls in qtgui:5 via USE=kde. Is that maybe all you need?
app-i18n/ibus-qt includes an immodule for Qt4. The IBus immodule for Qt5 is included in Qt: $ USE=ibus emerge dev-qt/qtgui:5 FYI, the repository for ibus-qt is https://github.com/ibus/ibus-qt
Thank you Akinori. I confirm that adding the 'ibus' use flag in make.conf and updating the system fixes the problem. The package qtgui is such a non-intuitive place to look, and the documentation make no mention of the ibus use flag. I'll document everything I learned in details. Thanks.
