qtchooser does not properly work with multiarch

[Harald Sitter]

qtchooser reads the path to resolve a binary from default.conf which always points to the architecture qtchooser was built for. e.g. /x86_64-linuxwhateverblahblah/ on amd64

this in particular means that if one is on amd64 and installs qdbus:i386 it will replace (i.e. remove) qdbus:amd64 and from that point on /usr/bin/qdbus (which is backed by qtchooser) will no longer work because it will look in the x86_64 path but not the x86_32 one.

> qdbus: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qdbus': No such file or directory

this has a rather grave impact on users that get their qdbus replaced with qdbus:i386 as large parts of kde software expect qdbus to simply work (such as startkde - bug 827815) and even platform stuff does (such as the power button handler - bug 1124149).

and judging from those bugs this can happen rather easily, and has already happened to a lot of users.

to resolve this qtchooser either needs to also look in the 32bit path OR the package deps need to be adjusted such that one cannot have a mixture of arch packages (which I doubt will be feasible because switching the tooling to i386 will likely cause all of kde/qt to be switched to i386 too...).

[Timo Jyrinki (timo-jyrinki)]

Hmm, this is a bit complicated. qtchooser shouldn't be installed on non-development machines, so KDE does not currently directly use it anyhow. It seems that for 13.04 some KDE package was patched to forcefully add /usr/lib/[your-arch]/qt4/bin to PATH which is why it works for most people now (but causes Qt5 to not be easily usable for KDE users since the addition is before /usr/bin).

The root problem within qtchooser itself is that it handles qdbus the same as purely development oriented binaries, so qdbus cannot be installed to /usr/bin as before, so on non-development machines qdbus is not available at all via default PATH, regardless of multi-arch or not.

One more change is that qdbus has now been split to its own qdbus-qt5 package in Debian, so it will come to saucy as well. But I believe this is currently about Qt4's qdbus usage.

So with the current forced PATH the qtchooser side of the story shouldn't affect KDE users, but it will affect if a) qtchooser is started to be used for everyone (requires configuration to be moved to a non-dev package), b) the PATH hack is removed.

I believe the options strictly related on what to do now regarding qdbus usage in KDE are:
1) Continue to use the PATH hack, whichever package it comes from, but add support for multi-arch
2) Patch KDE to use the deep paths /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/qt4/bin when calling dbus.

And regarding qtchooser itself, I'm not sure. The upstream probably hasn't considered multi-arch so far.

[Felix Geyer (debfx)]

KDE wasn't patched in raring to prepend qt4 bin dir to $PATH. The (upstream) /usr/bin/startkde script does that:
http://quickgit.kde.org/?p=kde-workspace.git&a=blob&h=fde85473019d37a50d3d233dc45ad96ee76359d8&hb=07d3ac9d8c781755d19c71ccde6d182868a2bfb5&f=startkde.cmake#l19

We should probably get rid of that in saucy.

> I believe the options strictly related on what to do now regarding qdbus usage in KDE are:
> 1) Continue to use the PATH hack, whichever package it comes from, but add support for multi-arch

That would mean prepending $PATH also with /usr/lib/i386-linux-gnu/qt4/.
Not something I'm particularly fond of.

> 2) Patch KDE to use the deep paths /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/qt4/bin when calling dbus.

That's not feasible as qdbus is called in many places and we'd always have to check from which architecture qdbus is installed.

Here is my proposal for a fix/workaround in raring:
- Remove qdbus from qtchooser since we don't have a qdbus-qt5 anyway.
- Add a /usr/bin/qdbus -> /usr/lib/<ARCH>/qt4/qdbus symlink to qdbus

We have to come up with a proper plan for saucy.
Maybe we can move the qt binaries from /usr/lib/<ARCH>/qt{4,5}/ to /usr/lib/qt{4,5}/.
That way qtchooser would be able to cope with tools from different architectures (e.g. when qtchooser:amd64, qdbus:i386, libqt4-dev-bin:amd64 is installed).

[Timo Jyrinki (timo-jyrinki)]

Hi. Thanks for the good thoughts, they clarify things well. I think I'd be fine with both qtchooser not handling qdbus and binary moving away from multi-arch directory. Although the direct /usr/bin/qdbus symlink would be problematic since the executable inside qdbus-qt5 package is still called just 'qdbus' like the Qt4 version, and it should be allowed to be used.

Crucially though, I'd like to have the same solution as Debian will have, and I haven't yet had the time to bring the topic fully to them (via #debian-qt-kde @ OFTC). If I remember correctly it was very briefly thought about, mainly the first question was that why would anyone want to install/use the 32-bit versions (but of course, lack of support in qtchooser for that is still an omission). The related Debian git:s are http://anonscm.debian.org/gitweb/?p=pkg-kde/qt/qtchooser.git;a=summary , http://anonscm.debian.org/gitweb/?p=pkg-kde/qt/qttools.git;a=summary (qdbus-qt5) and http://anonscm.debian.org/gitweb/?p=pkg-kde/qt/qtbase.git;a=summary (configuration of bindir).

[Jean-Louis Hens (jean-louis-hens)]

What about waiting for solution with this symbolic links ?

/usr/bin/qdbus -> /usr/lib/x86_64-linux-gnu/qt4/bin/qdbus
/usr/bin/qdbus.bk -> qtchooser

and what about
/usr/bin/qdbuscpp2xml -> qtchooser
/usr/bin/qdbusviewer -> qtchooser
/usr/bin/qdbusxml2cpp -> qtchooser

[Jean-Louis Hens (jean-louis-hens)]

Linux M3-581T 3.8.0-21-generic #32-Ubuntu SMP Tue May 14 22:16:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
my apology, I'm waiting for with this symbolic link, of course :

/usr/bin/qtchooser -> /usr/lib/x86_64-linux-gnu/qt4/bin/qdbus
/usr/bin/qtchooser.bk

[Timo Jyrinki (timo-jyrinki)]

There is now a lot of progress in Debian, and qtchooser 26 got now synced to Ubuntu thanks to Dmitry's sync request.

I should also do a sync qtbase once again to get the latest changes - there will be qt5-triplet kind of configurations for qtchooser, they will be again in libqt5core5 instead of -dev package, and there should also be a fallback so that Qt4's qdbus for example always gets called by default. I've yet to evaluate or test these changes, but it sounds like getting the qtbase modifications also in could go a long way to addressing the concerns in this bug as well.

I'll continue to do my Qt5 saucy test builds at https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta-proper PPA.

Raring backports is another topic of course.

[Timo Jyrinki (timo-jyrinki)]

The qtchooser 26-3ubuntu1 should support everything needed for qtchooser itself. Qt 5.0.2 was released with related changes. Qt 4 has changes in Debian that should be synced, since they are the final piece of the puzzle.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Turbo (axelhc)]

This is a copy-paste from bug 1124149:

--------------------
Hi,

Yesterday I downloaded and installed the daily build of Kubuntu 13.10 beta and the bug is still there. I also installed qt4-default and libqt4-dev with no change at all. Only formated the root ( / ) partition, keeping intact the Home with my settings.

Regards.

Turbo.
-------------------

[Timo Jyrinki (timo-jyrinki)]

qt4-x11 has now been synced with Debian, so that part should be fixed.

https://launchpad.net/ubuntu/trusty/+source/qt4-x11/4:4.8.5+git192-g085f851+dfsg-2ubuntu1 (ubuntu3 got into release pocket)

[Rolf Leggewie (r0lf)]

raring has seen the end of its life and is no longer receiving any updates. Marking the raring task for this ticket as "Won't Fix".

[Rolf Leggewie (r0lf)]

saucy has seen the end of its life and is no longer receiving any updates. Marking the saucy task for this ticket as "Won't Fix".