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, stev...@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

Reply via email to