Bug#1057346: qt6-base-dev-tools is wrongly marked Multi-Arch: foreign
Package: qt6-base-dev-tools
User: debian-cross@lists.debian.org
Severity: important
Usertags: ftcbfs
Control: affects -1 + src:kuserfeedback
X-Debbugs-Cc: debian-cross@lists.debian.org
Hi Qt maintainers and cross people,
I think I've found one of those innocent looking cross build failures
that turn into something big. src:kuserfeedback actually cross builds
successfully, but what comes out is broken:
qml6-module-org-kde-userfeedback_1.3.0-3_arm64.deb contains
./usr/lib/x86_64-linux-gnu/qt6/qml/org/kde/userfeedback/libKUserFeedbackQmlQt6.so
qt6-kuserfeedback-dev_1.3.0-3_arm64.deb contains
./usr/lib/x86_64-linux-gnu/qt6/mkspecs/modules/qt_KUserFeedbackCoreQt6.pri
and
./usr/lib/x86_64-linux-gnu/qt6/mkspecs/modules/qt_KUserFeedbackWidgetsQt6.pri
Evidently, something inserts build architecture multiarch libdirs
somehow and that's bad. Digging into kuserfeedback, I think the origin
of the earlier one is KDE_INSTALL_QMLDIR (see
src/provider/qml/CMakeLists.txt). Looking beyond, I think this is set
from extra-cmake-modules. It's not exactly clear to me how this comes
about to be. If you know please tell.
So I looked into how extra-cmake-modules constructs such paths and found
kde-modules/KDEInstallDirs6.cmake which looks related. I cannot really
draw the connection and assume there is one. Is that still convincing
enough? Is someone able to fill this gap?
Assuming we're still on track, I think stuff comes out of ecm_query_qt,
which is defined in modules/ECMQueryQt.cmake. This works differently for
Qt5 and Qt6. For Qt5, it invokes Qt5::qmake -query. This is something we
redirected to point at ${DEB_HOST_GNU_TYPE}-qmake and this generally
gives the right variables. Getting there was a longer journey, but this
now works neatly. What we're looking at here though is the Qt6 case and
there we use Qt6::qtpaths. As far as I understand it, this is new in
Qt6. While we did add a ${DEB_HOST_GNU_TYPE}-qmake6 wrapper script, I am
not aware of any qtpaths6 wrapper. Running it like qtpaths6 --query
QT_INSTALL_QML gives /usr/lib/x86_64-linux-gnu/qt6/qml here and that
very plausibly explains the original failure.
It also tells us that qtpaths6 definitely is not something that is
appropriate for shipping in a Multi-Arch: foreign package as is.
qt6-base-dev-tools is that package and it is currently marked
Multi-Arch: foreign. Just removing the marking is not the solution here.
We really want the qtpaths6 executable to reside in a Multi-Arch:
foreign package. Otherwise, we cannot run it. What we need here is a
wrapper script ${DEB_HOST_GNU_TYPE}-qtpaths6 for qtpaths6 that sets
architecture-dependent properties in matching ways. This probably
belongs to some Multi-Arch: same package. Then Qt6::qtpaths needs to be
redefined to point at the triplet-prefixed one. It is not clear to me
how packages have to be reorganized. That package containing
${DEB_HOST_GNU_TYPE}-qtpaths6 somehow needs to be pulled into the build
for kuserfeedback. The most obvious option is to rename
qt6-base-dev-tools to qt6-base-dev-tools-bin and use the previous name
for the Multi-Arch: same package. That may not be the best of solutions
though. Possibly, there already is a suitable Multi-Arch: same package
that is required anyway, which can hold these wrappers.
This is as far as I got. Does that make sense to you? Is that actionable
to Qt maintainers?
Helmut
Reply to: