Package: qt6-base-dev-tools User: debian-cr...@lists.debian.org Severity: important Usertags: ftcbfs Control: affects -1 + src:kuserfeedback X-Debbugs-Cc: debian-cr...@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