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

On 12/2/24 12:13 AM, Antonio Russo wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

On 12/2/24 12:26 AM, steve.b@osfda.org wrote:

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

On 12/2/24 12:13 AM, Antonio Russo wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Dec 01, 2024 at 10:13:30PM -0700, Antonio Russo wrote:

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.


--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmdNUL8tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh Tb0P+gJ8+M0sPpuDcOvLEfLL/UUGi+V7WjXz2KvrgR3PUjMeO5kPs95NzNqSi+ie +WmIXJ9bdfXKiGL+ENptJY/juOZ+smnzbd4RKZS5ijhh4s+92Mie+b3kcMVHthHF T1RL3+YN/qBNcU9h6lGvOs1Rfe12hxN+yzpBirQv08Br2v3+qP9Go3y9UH/0LpRr NJV44tpG1MDbanME2NbHlMoQd2Z8gt77ekOa7slqUvlOFhGGdQH+ao7izJE5EtGJ VH4lxPxPCpguow6wlUmfwgAY4r84+9BAcsDtSU/JZYX6phmcr7s1aX5OzQbLPIqI UkpOdYxb0Fli15uGlQlWOGEzlKrRSoxjH4Niuj8JquP6SHM9rDiF2a9VBWy3GdBt fKgQeHjiXwwCilfY8iOF+0fSocmLNgucrSApHmnMIPAVuvisiSufXRhANnTZma3P dB3A95e1TB/KAxr/WeDq7soxsb+opt/+A1h4NqrtRKIVSZGthCeUCOXG/InseZEH uyR7AB0KN/q4WzF25EHpDVnidtukHguzVylHp0/n326anzOgbW/hjOyJLtSIteWw JoKVNGsB9qZ/DhhXrKfizlrqtRjLKb7sHi+mEdUB8zTRKZ6fG9Un+VkF2qQ76dKU 3RfLakJSPeNjh+AN2sbArCtxxdCv0TGo8MUJeTL5oC2gC9FX
=X6dS
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

On 12/2/24 02:02 AM, Antonio Russo wrote:

On 12/1/24 23:16, Andrey Rakhmatullin wrote:

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.

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?

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-12-02, Antonio Russo <aerusso@aerusso.net> wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)