Qt5/KF6 build question

[Antonio Russo]

Hello,

I (as upstream) have ported my kcollectd package to Qt6 and KF6, and I'm able to build
and run it just fine using the Debian build chain. Now I (wearing my Debian hat) am
having trouble getting it to build as a .deb.

The first problem I ran into is that I'm doing the build inside an autopkgtest sid
virtual machine, started by sbuild on a bookworm server. The dh_clean target fails
(on the bookworm host) because I'm using `--with kf6`. I seem to have been able to
get around that by just installing pkg-kde-tools from unstable on bookworm (I know).
But it didn't pull in anything else, and the dh_clean target completed fine
afterwards.

So, that's my first question: can I build packages using newer dh sequences on an
older build server, or does the build server need to also be unstable to use that
dh sequence?

My second question is more specific to my package. I'm getting this error:

-- No Qt5 qmake executable found. Can't check QT_INSTALL_PREFIX
-- Configuring incomplete, errors occurred!
cd obj-x86_64-linux-gnu && tail -v -n \+0 CMakeCache.txt
CMake Error at /usr/share/ECM/modules/ECMQueryQt.cmake:82 (message):
No Qt5 qmake executable found. Can't check QT_INSTALL_PLUGINS as required
Call Stack (most recent call first):
/usr/share/ECM/kde-modules/KDEInstallDirs5.cmake:256 (ecm_query_qt)
/usr/share/ECM/kde-modules/KDEInstallDirs.cmake:15 (include)
CMakeLists.txt:15 (include)

(I tried to attach the full build log, but I think the mailserver rejected it;
it was ~250kb). It looks like maybe QT_MAJOR_VERSION is somehow being set to 5,
and /usr/share/ECM/kde-modules/KDEInstallDirs.cmake line 15 is pulling in
KDEInstallDirs5.cmake as a consequence? Why would that be happening
in a call to `dh_auto_configure --buildsystem=kf6`? Shouldn't the kf6
build sequence be smart enough to not try to use the qt5 qmake? Is there some
other place that the qt version might be specified that I'm not aware of?

Thanks,
Antonio

[s***@osfda.org]

Hmmm...I added python3-pyqt6 (>= 6.4.2) to the control file and didn't
specify a KDE (running on bookworm stable...) I figured it would suck in
the necessary KDE, and it did for me.

[Upgrading pyqt5 to pyqt6 is a pisser; the constants were reorganized
and are presently sparsely documented -you have to figure it out by
inspecting methods and properties on a number of classes. I seem to
remember some minor limitation on the buttons in pyqt6, which I guess
they will get around to addressing -was it font handling? indication
that the button was pressed with some trivial animation?? -sorry, it's
been a few weeks...]

Post by Antonio Russo
Hello,
I (as upstream) have ported my kcollectd package to Qt6 and KF6, and I'm able to build
and run it just fine using the Debian build chain.  Now I (wearing my
Debian hat) am
having trouble getting it to build as a .deb.
The first problem I ran into is that I'm doing the build inside an autopkgtest sid
virtual machine, started by sbuild on a bookworm server.  The dh_clean
target fails
(on the bookworm host) because I'm using `--with kf6`. I seem to have been able to
get around that by just installing pkg-kde-tools from unstable on bookworm (I know).
But it didn't pull in anything else, and the dh_clean target completed fine
afterwards.
So, that's my first question: can I build packages using newer dh sequences on an
older build server, or does the build server need to also be unstable to use that
dh sequence?
My second question is more specific to my package.  I'm getting this
 -- No Qt5 qmake executable found. Can't check QT_INSTALL_PREFIX
 -- Configuring incomplete, errors occurred!
     cd obj-x86_64-linux-gnu && tail -v -n \+0 CMakeCache.txt
   No Qt5 qmake executable found.  Can't check QT_INSTALL_PLUGINS as
required
   /usr/share/ECM/kde-modules/KDEInstallDirs5.cmake:256 (ecm_query_qt)
   /usr/share/ECM/kde-modules/KDEInstallDirs.cmake:15 (include)
   CMakeLists.txt:15 (include)
(I tried to attach the full build log, but I think the mailserver rejected it;
it was ~250kb).  It looks like maybe QT_MAJOR_VERSION is somehow being
set to 5,
and /usr/share/ECM/kde-modules/KDEInstallDirs.cmake line 15 is pulling in
KDEInstallDirs5.cmake as a consequence?  Why would that be happening
in a call to `dh_auto_configure --buildsystem=kf6`?  Shouldn't the kf6
build sequence be smart enough to not try to use the qt5 qmake? Is
there some
other place that the qt version might be specified that I'm not aware of?
Thanks,
Antonio

[s***@osfda.org]

Ah, I remember now: when a button is disabled, there's no grayed-out
visual cue; it looks exactly the same as an active button.

I worked around it for now by generating a popup message when it's not
"enabled" (so I leave it enabled...)

Post by s***@osfda.org
Hmmm...I added python3-pyqt6 (>= 6.4.2) to the control file and didn't
specify a KDE (running on bookworm stable...) I figured it would suck
in the necessary KDE, and it did for me.
[Upgrading pyqt5 to pyqt6 is a pisser; the constants were reorganized
and are presently sparsely documented -you have to figure it out by
inspecting methods and properties on a number of classes. I seem to
remember some minor limitation on the buttons in pyqt6, which I guess
they will get around to addressing -was it font handling? indication
that the button was pressed with some trivial animation?? -sorry, it's
been a few weeks...]

Post by Antonio Russo
Hello,
I (as upstream) have ported my kcollectd package to Qt6 and KF6, and I'm able to build
and run it just fine using the Debian build chain.  Now I (wearing my
Debian hat) am
having trouble getting it to build as a .deb.
The first problem I ran into is that I'm doing the build inside an autopkgtest sid
virtual machine, started by sbuild on a bookworm server.  The
dh_clean target fails
(on the bookworm host) because I'm using `--with kf6`. I seem to have been able to
get around that by just installing pkg-kde-tools from unstable on bookworm (I know).
But it didn't pull in anything else, and the dh_clean target
completed fine
afterwards.
So, that's my first question: can I build packages using newer dh sequences on an
older build server, or does the build server need to also be unstable to use that
dh sequence?
My second question is more specific to my package.  I'm getting this
 -- No Qt5 qmake executable found. Can't check QT_INSTALL_PREFIX
 -- Configuring incomplete, errors occurred!
     cd obj-x86_64-linux-gnu && tail -v -n \+0 CMakeCache.txt
   No Qt5 qmake executable found.  Can't check QT_INSTALL_PLUGINS as
required
   /usr/share/ECM/kde-modules/KDEInstallDirs5.cmake:256 (ecm_query_qt)
   /usr/share/ECM/kde-modules/KDEInstallDirs.cmake:15 (include)
   CMakeLists.txt:15 (include)
(I tried to attach the full build log, but I think the mailserver rejected it;
it was ~250kb).  It looks like maybe QT_MAJOR_VERSION is somehow
being set to 5,
and /usr/share/ECM/kde-modules/KDEInstallDirs.cmake line 15 is pulling in
KDEInstallDirs5.cmake as a consequence?  Why would that be happening
in a call to `dh_auto_configure --buildsystem=kf6`?  Shouldn't the kf6
build sequence be smart enough to not try to use the qt5 qmake? Is
there some
other place that the qt version might be specified that I'm not aware of?
Thanks,
Antonio

[Andrey Rakhmatullin]

Post by Antonio Russo
I (as upstream) have ported my kcollectd package to Qt6 and KF6, and I'm able to build
and run it just fine using the Debian build chain. Now I (wearing my Debian hat) am
having trouble getting it to build as a .deb.
The first problem I ran into is that I'm doing the build inside an autopkgtest sid
virtual machine, started by sbuild on a bookworm server. The dh_clean target fails
(on the bookworm host) because I'm using `--with kf6`. I seem to have been able to
get around that by just installing pkg-kde-tools from unstable on bookworm (I know).
But it didn't pull in anything else, and the dh_clean target completed fine
afterwards.
So, that's my first question: can I build packages using newer dh sequences on an
older build server, or does the build server need to also be unstable to use that
dh sequence?

You only need deps installed if you need to run clean. Nowadays, with git
and clean working copies you normally can skip running clean, by passing
--no-clean-source to sbuild or with something equivalent.

[Antonio Russo]

Post by Andrey Rakhmatullin
You only need deps installed if you need to run clean. Nowadays, with git
and clean working copies you normally can skip running clean, by passing
--no-clean-source to sbuild or with something equivalent.

Andrey: thank you. In retrospect, I suppose this is obvious.

Post by Andrey Rakhmatullin
 -- No Qt5 qmake executable found. Can't check QT_INSTALL_PREFIX
 -- Configuring incomplete, errors occurred!
     cd obj-x86_64-linux-gnu && tail -v -n \+0 CMakeCache.txt
   No Qt5 qmake executable found.  Can't check QT_INSTALL_PLUGINS as required
   /usr/share/ECM/kde-modules/KDEInstallDirs5.cmake:256 (ecm_query_qt)
   /usr/share/ECM/kde-modules/KDEInstallDirs.cmake:15 (include)
   CMakeLists.txt:15 (include)
(I tried to attach the full build log, but I think the mailserver rejected it;
it was ~250kb).  It looks like maybe QT_MAJOR_VERSION is somehow being set to 5,
and /usr/share/ECM/kde-modules/KDEInstallDirs.cmake line 15 is pulling in
KDEInstallDirs5.cmake as a consequence?  Why would that be happening
in a call to `dh_auto_configure --buildsystem=kf6`?  Shouldn't the kf6
build sequence be smart enough to not try to use the qt5 qmake?  Is there some
other place that the qt version might be specified that I'm not aware of?

On this front: I can reproduce the issue with this cmake invocation:

cmake \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_BUILD_TYPE=None \
-DCMAKE_INSTALL_SYSCONFDIR=/etc \
-DCMAKE_INSTALL_LOCALSTATEDIR=/var \
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON \
-DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF \
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON \
-DFETCHCONTENT_FULLY_DISCONNECTED=ON \
-DCMAKE_INSTALL_RUNSTATEDIR=/run \
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON \
"-GUnix Makefiles" \
-DCMAKE_VERBOSE_MAKEFILE=ON \
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu \
-DCMAKE_BUILD_TYPE=Debian \
-DKDE_INSTALL_USE_QT_SYS_PATHS=ON \
..

(modulo typesetting typos). By omitting the KDE_INSTALL_USE_QT_SYS_PATHS=ON last
option, I can get it to work (i.e., successfully run cmake).

I still get the error

-- No Qt5 qmake executable found. Can't check QT_INSTALL_PREFIX

but, now it is nonlethal, since it apparently isn't being trying to "check
QT_INSTALL_PLUGINS", whatever that means. So, it looks not having that option
only covers up the problem: qt6 builds are looking for qmake5. Why is the kf6
tooling causing that to happen?

I am also getting warnings like:

CMake Warning:
Manually-specified variables were not used by the project:

CMAKE_EXPORT_NO_PACKAGE_REGISTRY
CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY
FETCHCONTENT_FULLY_DISCONNECTED

So, it's reasonable to me that I might not have properly updated CMakeLists.txt .
I'm open to any suggestions.

Thanks,
Antonio

[s***@osfda.org]

I'm not a pyqt guru; but that looks like you have a remnant of qt5 lying
around. To fix when that happens, I do like dpkg --purge --force-all 
{your old package}; then something like an apt --fix-broken {path to
your deb file}

Something you can try while you are waiting for an answer from a
pyqt+package guru here...

Post by Andrey Rakhmatullin
You only need deps installed if you need to run clean. Nowadays, with git
and clean working copies you normally can skip running clean, by passing
--no-clean-source to sbuild or with something equivalent.

Andrey: thank you.  In retrospect, I suppose this is obvious.

Post by Andrey Rakhmatullin
My second question is more specific to my package.  I'm getting this
  -- No Qt5 qmake executable found. Can't check QT_INSTALL_PREFIX
  -- Configuring incomplete, errors occurred!
      cd obj-x86_64-linux-gnu && tail -v -n \+0 CMakeCache.txt
    No Qt5 qmake executable found.  Can't check QT_INSTALL_PLUGINS as
required
    /usr/share/ECM/kde-modules/KDEInstallDirs5.cmake:256 (ecm_query_qt)
    /usr/share/ECM/kde-modules/KDEInstallDirs.cmake:15 (include)
    CMakeLists.txt:15 (include)
(I tried to attach the full build log, but I think the mailserver rejected it;
it was ~250kb).  It looks like maybe QT_MAJOR_VERSION is somehow
being set to 5,
and /usr/share/ECM/kde-modules/KDEInstallDirs.cmake line 15 is pulling in
KDEInstallDirs5.cmake as a consequence?  Why would that be happening
in a call to `dh_auto_configure --buildsystem=kf6`?  Shouldn't the kf6
build sequence be smart enough to not try to use the qt5 qmake? Is
there some
other place that the qt version might be specified that I'm not aware of?

cmake \
 -DCMAKE_INSTALL_PREFIX=/usr \
 -DCMAKE_BUILD_TYPE=None \
 -DCMAKE_INSTALL_SYSCONFDIR=/etc \
 -DCMAKE_INSTALL_LOCALSTATEDIR=/var \
 -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON \
 -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF \
 -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON \
 -DFETCHCONTENT_FULLY_DISCONNECTED=ON \
 -DCMAKE_INSTALL_RUNSTATEDIR=/run \
 -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON \
 "-GUnix Makefiles" \
 -DCMAKE_VERBOSE_MAKEFILE=ON \
 -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu \
 -DCMAKE_BUILD_TYPE=Debian \
 -DKDE_INSTALL_USE_QT_SYS_PATHS=ON \
 ..
(modulo typesetting typos). By omitting the
KDE_INSTALL_USE_QT_SYS_PATHS=ON last
option, I can get it to work (i.e., successfully run cmake).
I still get the error
 -- No Qt5 qmake executable found. Can't check QT_INSTALL_PREFIX
but, now it is nonlethal, since it apparently isn't being trying to "check
QT_INSTALL_PLUGINS", whatever that means.  So, it looks not having
that option
only covers up the problem: qt6 builds are looking for qmake5. Why is
the kf6
tooling causing that to happen?
     CMAKE_EXPORT_NO_PACKAGE_REGISTRY
     CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY
     FETCHCONTENT_FULLY_DISCONNECTED
So, it's reasonable to me that I might not have properly updated CMakeLists.txt .
I'm open to any suggestions.
Thanks,
Antonio

[Sune Vuorela]

Post by Antonio Russo
I (as upstream) have ported my kcollectd package to Qt6 and KF6, and I'm able to build
and run it just fine using the Debian build chain. Now I (wearing my Debian hat) am
having trouble getting it to build as a .deb.

How did you (as upstream) do it ?

Do you have both qt5/6 supported at the same time? If so, how?
How does the find_package ECM call look like in your cmake file?

/Sune

[Antonio Russo]

All,

I was able to resolve this by dropping `--with=kf6` from debian/rules.
The mistake I made was not using a package that had already moved to
Qt6/KF6 as a reference point. Looking at kcalc 24.08.0's packaging
resolved the mystery.

Thanks for all the help, everyone! I'll be back with an ITP soon-ish.

Best,
Antonio