Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
Hi, On Mon, 26 Dec 2022 at 20:36, Patrick Franz wrote: > > Hi, > > I agree that solution a) sounds like the better option, especially since > we've gone this route with Qt 5. > > However, I will revisit this issue once we have transitioned 6.4 into > unstable. It's up to you, but the patch is straightforward and will not introduce any problems with the transition. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
Hi, On Mon, 26 Dec 2022 at 20:07, Helmut Grohne wrote: [snip] > In any case, I've attached a patch for it now. It is based on what we do > for qt5. Thanks! > I caution though that selecting version 5 or 6 is kinda messed up. If > you run qmake6 or -qmake6, it'll use qt6 as expected. If you > run plain qmake, it'll go through qtchooser and select the relevant > version via QT_SELECT. Howeve, -qmake is presently owned by > qt5-qmake only and will bypass qtchoser without honouring QT_SELECT. If > we want "QT_SELECT=6 -qmake" to run the cross qt6 qmake, we'll > also have to modify qtchooser and qt5-qmake. We don't want to mix qtchooser and Qt 6. qtchooser is currently deprecated and will disappear with Qt 5. It's not worth the effort to remove it right now (I think). so the current behavior makes sense. Thanks! -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
Hi, I agree that solution a) sounds like the better option, especially since we've gone this route with Qt 5. However, I will revisit this issue once we have transitioned 6.4 into unstable. -- Med vänliga hälsningar Patrick Franz
Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
Control: tags -1 + patch
On Mon, Dec 26, 2022 at 10:27:18AM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> I would very much prefer (a). Now, as you said, timing is important
> here. Do we need a pass through NEW? If that's the case then that will
> need to happen after the next transition, if time allows it. If it can
> be easily added to the existing packaging without the need of NEW then
> we might add it right now.
No, (a) does not require going through NEW. There already is qmake6-bin.
qmake6 and qmake6-bin even have the needed Multi-Arch values already.
> Last time you did the packaging with DMitry, so I'm kind of lost here.
Dmitry also expressed being in favour of (a). Notably missing is a
response from Patrick.
In any case, I've attached a patch for it now. It is based on what we do
for qt5.
I caution though that selecting version 5 or 6 is kinda messed up. If
you run qmake6 or -qmake6, it'll use qt6 as expected. If you
run plain qmake, it'll go through qtchooser and select the relevant
version via QT_SELECT. Howeve, -qmake is presently owned by
qt5-qmake only and will bypass qtchoser without honouring QT_SELECT. If
we want "QT_SELECT=6 -qmake" to run the cross qt6 qmake, we'll
also have to modify qtchooser and qt5-qmake.
Helmut
diff -Nru qt6-base-6.3.1+dfsg/debian/changelog
qt6-base-6.3.1+dfsg/debian/changelog
--- qt6-base-6.3.1+dfsg/debian/changelog2022-10-01 18:58:47.0
+0200
+++ qt6-base-6.3.1+dfsg/debian/changelog2022-12-26 22:56:51.0
+0100
@@ -1,3 +1,10 @@
+qt6-base (6.3.1+dfsg-10.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Install -qmake6 cross wrapper. (Closes: #1025663)
+
+ -- Helmut Grohne Mon, 26 Dec 2022 22:56:51 +0100
+
qt6-base (6.3.1+dfsg-10) unstable; urgency=medium
[ Lisandro Damián Nicanor Pérez Meyer ]
diff -Nru qt6-base-6.3.1+dfsg/debian/qmake-cross-wrapper.in
qt6-base-6.3.1+dfsg/debian/qmake-cross-wrapper.in
--- qt6-base-6.3.1+dfsg/debian/qmake-cross-wrapper.in 1970-01-01
01:00:00.0 +0100
+++ qt6-base-6.3.1+dfsg/debian/qmake-cross-wrapper.in 2022-12-26
22:56:51.0 +0100
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+if [ "x$1" = x-qt6 ] || [ "x$1" = "x-qt=6" ] || [ "x$1" = "x-qt=qt6" ]; then
+ shift
+fi
+
+QMAKE_MODE=
+
+if [ "x$1" = x-query ]; then
+ exec /usr/lib/qt6/bin/qmake "$@" -qtconf
/usr/lib/@DEB_HOST_MULTIARCH@/qt6/qt6.conf
+elif [ "x$1" = x-makefile ] || [ "x$1" = x-project ]; then
+ QMAKE_MODE="$1"
+ shift
+fi
+
+exec /usr/lib/qt6/bin/qmake6 \
+ $QMAKE_MODE \
+ -qtconf /usr/lib/@DEB_HOST_MULTIARCH@/qt6/qt6.conf \
+ -early \
+ QMAKE_CC=${CC:-@DEB_HOST_GNU_TYPE@-gcc} \
+ QMAKE_CXX=${CXX:-@DEB_HOST_GNU_TYPE@-g++} \
+ QMAKE_LINK=${CXX:-@DEB_HOST_GNU_TYPE@-g++} \
+ QMAKE_STRIP=${STRIP:-@DEB_HOST_GNU_TYPE@-strip} \
+ QMAKE_QMAKE=/usr/bin/@DEB_HOST_GNU_TYPE@-qmake6 \
+ PKG_CONFIG=@DEB_HOST_GNU_TYPE@-pkg-config \
+ -before \
+ "$@"
diff -Nru qt6-base-6.3.1+dfsg/debian/qmake6.install
qt6-base-6.3.1+dfsg/debian/qmake6.install
--- qt6-base-6.3.1+dfsg/debian/qmake6.install 2022-04-22 19:50:08.0
+0200
+++ qt6-base-6.3.1+dfsg/debian/qmake6.install 2022-12-26 22:56:45.0
+0100
@@ -1,3 +1,4 @@
+usr/bin/*-qmake6
usr/lib/${DEB_HOST_MULTIARCH}/qt6/mkspecs/aix-g++-64/qmake.conf
usr/lib/${DEB_HOST_MULTIARCH}/qt6/mkspecs/aix-g++-64/qplatformdefs.h
usr/lib/${DEB_HOST_MULTIARCH}/qt6/mkspecs/aix-g++/qmake.conf
diff -Nru qt6-base-6.3.1+dfsg/debian/rules qt6-base-6.3.1+dfsg/debian/rules
--- qt6-base-6.3.1+dfsg/debian/rules2022-09-17 19:21:11.0 +0200
+++ qt6-base-6.3.1+dfsg/debian/rules2022-12-26 22:56:51.0 +0100
@@ -89,6 +89,12 @@
sed 's/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/' debian/qt.conf.in \
> debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/qt6/qt6.conf
+ mkdir -p debian/tmp/usr/bin
+ sed -e 's/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g' \
+ -e 's/@DEB_HOST_GNU_TYPE@/$(DEB_HOST_GNU_TYPE)/g' \
+ < debian/qmake-cross-wrapper.in >
debian/tmp/usr/bin/$(DEB_HOST_GNU_TYPE)-qmake6
+ chmod +x debian/tmp/usr/bin/$(DEB_HOST_GNU_TYPE)-qmake6
+
override_dh_makeshlibs:
dh_makeshlibs -XlibQt6EglFSDeviceIntegration -XlibQt6EglFsKmsGbmSupport
-XlibQt6EglFsKmsSupport -XlibQt6XcbQpa
Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
Hi all,
as I was mentioned in this discussion...
On Mon, Dec 26, 2022 at 10:27:18AM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> I would very much prefer (a). Now, as you said, timing is important
> here. Do we need a pass through NEW? If that's the case then that will
> need to happen after the next transition, if time allows it. If it can
> be easily added to the existing packaging without the need of NEW then
> we might add it right now.
>
> Last time you did the packaging with DMitry, so I'm kind of lost here.
...I would also prefer if Qt 6 used a similar setup to Qt 5. This way the
transition from Qt 5 to Qt 6 would be more transparent for the reverse
dependencies. E.g. they will only need to replace ${DEB_HOST_GNU_TYPE}-qmake
with ${DEB_HOST_GNU_TYPE}-qmake6.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
Hi! As usual I'm a little bit behind this with emails, so I just saw this. On Thu, 8 Dec 2022 at 08:48, Helmut Grohne wrote: [snip] > I'd like to get some reply from Patrick before moving forward with this > though. And it would be super awesome if this could be included in > bookworm, so time isn't infinite here. I would very much prefer (a). Now, as you said, timing is important here. Do we need a pass through NEW? If that's the case then that will need to happen after the next transition, if time allows it. If it can be easily added to the existing packaging without the need of NEW then we might add it right now. Last time you did the packaging with DMitry, so I'm kind of lost here. Regards, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
Hi Fab,
please keep debian-cr...@lists.debian.org in the loop. Full quoting.
On Thu, Dec 08, 2022 at 08:29:52AM +0100, Fab Stz wrote:
> Not sure this fits your issue and if this could work.
>
> I used to produce android-builds that are sort of 'target' builds (and not
> host builds). There is a specific qmake to be called when building with a
> target-build. That qmake is in the bin directory of the target build. And
> that
> qmake uses the "target_qt.conf" file which should contain the path you expect.
Before we delve into this, I'd like to clarify terminology. I'm going to
assume that when you say "target" you mean "host" in GNU terminology and
when you say "host" you mean "build" in GNU terminology. Please correct
me if I got that wrong.
I think this is similar to what I called "a" and I'll call your variant
"a2" to ease comparison. In both cases, there is a specific qmake (either
a binary in case of a2 or a wrapper script in case of a). Both reference
separate qtconf. In case of qt5, the wrapper injects a -qtconf argument.
The aspect where this differ is the location. In a2 you have the
standard qmake6 name on a non-$PATH directory whereas in a, you a
different executable name on $PATH.
> However, for now, not all path are there and especially the Plugins dir isn't
> there. They will be once this is merged:
>
> https://codereview.qt-project.org/c/qt/qtbase/+/436758/19/cmake/
> QtQmakeHelpers.cmake
>
> Maybe a solution could be to run qmake by specifying your own target_qt.conf
> that has the values you need ?
I think we're closer that you might expect. For most non-Debian
ecosystems, you need a specific target_qt.conf due to the need for
sysroots. It is specific to the combination of build architecture and
host architecture (in Qt terminology: host architecture and target
architecture). However, cross building on Debian has done away with sysroots
and replaced them with multiarch. As such, we can remove the build
architecture (in Qt terminology: host architecture) from the
configuration and just use the existing
/usr/lib/${DEB_HOST_MULTIARCH}/qt6/qt6.conf. This is what we do for qt5
already.
To me this reinforces the view that we should rather go for a wrapper
than have our build matrix explode into O(n^2) (for n being the count of
architectures).
Let me give an example:
$ dpkg --print-architecture
amd64
$ sudo dpkg --add-architecture armhf
$ sudo apt update
...
$ sudo apt install qmake6:armhf
...
$ qmake6 -qtconf /usr/lib/arm-linux-gnueabihf/qt6/qt6.conf -query
QT_INSTALL_PLUGINS
/usr/lib/arm-linux-gnueabihf/qt6/plugins
$
And to do proposal a, we'd have a wrapper
/usr/bin/arm-linux-gnueabihf-qmake6 (just like the one for qt5) that
would inject the -qtconf argument. So that would become:
$ arm-linux-gnueabihf-qmake6 -query QT_INSTALL_PLUGINS
/usr/lib/arm-linux-gnueabihf/qt6/plugins
$
And then we could point Qt6::qmake at this path.
In order to support other workflows, we can also have a separate
directory with a symlink to this named just qmake6 to support the
sysroot approach.
I'd like to get some reply from Patrick before moving forward with this
though. And it would be super awesome if this could be included in
bookworm, so time isn't infinite here.
Helmut
Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
Hello, Not sure this fits your issue and if this could work. I used to produce android-builds that are sort of 'target' builds (and not host builds). There is a specific qmake to be called when building with a target-build. That qmake is in the bin directory of the target build. And that qmake uses the "target_qt.conf" file which should contain the path you expect. However, for now, not all path are there and especially the Plugins dir isn't there. They will be once this is merged: https://codereview.qt-project.org/c/qt/qtbase/+/436758/19/cmake/ QtQmakeHelpers.cmake Maybe a solution could be to run qmake by specifying your own target_qt.conf that has the values you need ? Regards Fab On Wed, 7 Dec 2022 08:04:54 +0100 Helmut Grohne wrote: > Package: qmake6 > Version: 6.3.1+dfsg-10 > Severity: important > Control: affects -1 + src:fcitx-qt5 > User: debian-cr...@lists.debian.org > Usertags: ftcbfs > X-Debbugs-Cc: debian-cr...@lists.debian.org > > Hi, > > we've hit an interesting issue with qmake for QT6. This almost certainly > is a pattern and I'll use fcitx-qt5 as an example. > > fcitx-qt5 looks for a target Qt6::qmake and queries its LOCATION > property to be able to run it. Then it runs that with -query > QT_INSTALL_PLUGINS to locate the installation directory for plugins. > Unfortunately, what it gets is the build architecture one rather than > the host architecture one. > > The crux of this is that /usr/bin/qmake6 cannot know about the host > architecture. That information is a parameter of the build and nothing > has passed this information along to it. It cannot just pull this > information out of nothing. So we basically have two options: > > a) Make sure that Qt6::qmake's LOCATION resolves to something that >includes the information of the host architecture somehow. > b) Declare that this method of querying qmake is unsupported and fix >every package (including fcitx-qt5) in some other way. > > For b), I have no clue what that other way would be. If someone knows, > that would be great. I also have little clue how frequent this pattern > is and how many packages we would have to fix. The expectation is "many" > from my experience with QT5. > > The implications of a) are quite well understood, because that's the > route we opted for with QT5. It's a fairly involved route that took us > more than a year to work properly, but maybe we can speed up by learning > from earlier mistakes, so how does it work? > > The qmake6 package gains new binaries /usr/bin/-qmake6. These > actually are shell scripts that wrap qmake6 and inject the information > about the host architecture into the command line. Then, we centrally > divert Qt6::qmake to this location and everything will magically work. > To get an idea how this works, install qt5-qmake and look at > /usr/bin/$(dpkg -qDEB_BUILD_GNU_TYPE)-qmake. That should be fairly > obvious. We're in a far better position than we started with QT5 as we > already have the necessary qmake6 vs qmake6-bin split in place in > exactly the way it needs to be. Also a number of client packages have > been switched from AC_PATH_PROG to AC_PATH_TOOL for locating qmake > already. > > What we need now is a choice on which way we do it. The choice > essentially is: > > a) Add architecture-specific qmake wrappers for QT6. > b) Declare that running qmake6 -query SOMEVAR is unsupported. > > Patrick and Pino, what's your thoughts on this? If you feel like you > cannot make such a choice, let us figure out what information is > missing.
Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
Package: qmake6 Version: 6.3.1+dfsg-10 Severity: important Control: affects -1 + src:fcitx-qt5 User: debian-cr...@lists.debian.org Usertags: ftcbfs X-Debbugs-Cc: debian-cr...@lists.debian.org Hi, we've hit an interesting issue with qmake for QT6. This almost certainly is a pattern and I'll use fcitx-qt5 as an example. fcitx-qt5 looks for a target Qt6::qmake and queries its LOCATION property to be able to run it. Then it runs that with -query QT_INSTALL_PLUGINS to locate the installation directory for plugins. Unfortunately, what it gets is the build architecture one rather than the host architecture one. The crux of this is that /usr/bin/qmake6 cannot know about the host architecture. That information is a parameter of the build and nothing has passed this information along to it. It cannot just pull this information out of nothing. So we basically have two options: a) Make sure that Qt6::qmake's LOCATION resolves to something that includes the information of the host architecture somehow. b) Declare that this method of querying qmake is unsupported and fix every package (including fcitx-qt5) in some other way. For b), I have no clue what that other way would be. If someone knows, that would be great. I also have little clue how frequent this pattern is and how many packages we would have to fix. The expectation is "many" from my experience with QT5. The implications of a) are quite well understood, because that's the route we opted for with QT5. It's a fairly involved route that took us more than a year to work properly, but maybe we can speed up by learning from earlier mistakes, so how does it work? The qmake6 package gains new binaries /usr/bin/-qmake6. These actually are shell scripts that wrap qmake6 and inject the information about the host architecture into the command line. Then, we centrally divert Qt6::qmake to this location and everything will magically work. To get an idea how this works, install qt5-qmake and look at /usr/bin/$(dpkg -qDEB_BUILD_GNU_TYPE)-qmake. That should be fairly obvious. We're in a far better position than we started with QT5 as we already have the necessary qmake6 vs qmake6-bin split in place in exactly the way it needs to be. Also a number of client packages have been switched from AC_PATH_PROG to AC_PATH_TOOL for locating qmake already. What we need now is a choice on which way we do it. The choice essentially is: a) Add architecture-specific qmake wrappers for QT6. b) Declare that running qmake6 -query SOMEVAR is unsupported. Patrick and Pino, what's your thoughts on this? If you feel like you cannot make such a choice, let us figure out what information is missing. I have a preference for a) at this time, because it's changing one package versus a rabbit hole. Do you agree? Helmut
