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