qtchooser does not properly work with multiarch

Bug #1176686 reported by Harald Sitter on 2013-05-05
120
This bug affects 30 people
Affects Status Importance Assigned to Milestone
qt4-x11 (Ubuntu)
Undecided
Unassigned
Raring
Undecided
Unassigned
Saucy
Undecided
Unassigned
qtbase-opensource-src (Ubuntu)
Undecided
Unassigned
Raring
Undecided
Unassigned
Saucy
Undecided
Unassigned
qtchooser (Ubuntu)
Critical
Timo Jyrinki
Raring
Critical
Unassigned
Saucy
Critical
Timo Jyrinki

Bug Description

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

Changed in qtchooser (Ubuntu Raring):
status: New → Triaged
importance: Undecided → Critical
milestone: none → raring-updates
Changed in qtchooser (Ubuntu Saucy):
assignee: nobody → Timo Jyrinki (timo-jyrinki)
Timo Jyrinki (timo-jyrinki) wrote :

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) wrote :

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) wrote :

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

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

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) wrote :

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) wrote :

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.

Changed in qtchooser (Ubuntu Saucy):
status: Triaged → Fix Released
Changed in qtbase-opensource-src (Ubuntu Raring):
status: New → Fix Released
status: Fix Released → New
Changed in qtbase-opensource-src (Ubuntu Saucy):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in qt4-x11 (Ubuntu Raring):
status: New → Confirmed
Changed in qt4-x11 (Ubuntu):
status: New → Confirmed
Changed in qtbase-opensource-src (Ubuntu Raring):
status: New → Confirmed
Turbo (axelhc) wrote :

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) wrote :

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)

Changed in qt4-x11 (Ubuntu):
status: Confirmed → Fix Released
Rolf Leggewie (r0lf) wrote :

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

Changed in qtchooser (Ubuntu Raring):
status: Triaged → Won't Fix
Rolf Leggewie (r0lf) on 2014-12-05
Changed in qtbase-opensource-src (Ubuntu Raring):
status: Confirmed → Won't Fix
Changed in qt4-x11 (Ubuntu Raring):
status: Confirmed → Won't Fix
Rolf Leggewie (r0lf) wrote :

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

Changed in qt4-x11 (Ubuntu Saucy):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers