Debian: after upgrading the system the program became unusable. How to approach the problem?
-
@Pl45m4 said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
Hi and welcome,
under GitHub issue it's stated that the left panel does not open on Debian.
What widget/class is this?Sorry, no idea. I don't (yet?) understand the code.
Any log / error message? Or just nothing?
No errors reported at runtime, nothing suspicious in the compilation log.
I dont have a Debian system at hand to test it right now, but maybe there is something standing out in the code file.
Thank you very much for your interest, but I'm afraid it is Debian specific.
-
@SGaist said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
@JanuszSB Hi,
What exactly was upgraded ? Debian itself ? Qt ?
A routine upgrade of Debian. Looks like Qt was upgraded automatically. To compile the program I had to remove qt5-default from dependencies and use qt6-base-dev.
The problem occurs both for the binaries compiled with Qt5 and the new ones compiled with Qt6,
JSB
-
@SGaist said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
@JanuszSB Hi,
What exactly was upgraded ? Debian itself ? Qt ?
A routine upgrade of Debian. Looks like Qt was upgraded automatically. To compile the program I had to remove qt5-default from dependencies and use qt6-base-dev.
The problem occurs both for the binaries compiled with Qt5 and the new ones compiled with Qt6,
-
@SGaist said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
@JanuszSB are you still on bullseye or did you uprage to bookworm ?
Bookworm. I have still a virtual machine with bullseye and the program works there.
-
An update: I forgot I had an almost identical problem in 2020: https://github.com/jsbien/djview4shapes/issues/1. It was solved by Alexander Trufanov. His commit
https://github.com/jsbien/djview4shapes/commit/6bf0683671c1599dc6af0e16bebee4bcc5d7387e shows which fragment of code may be relevant for the present problem. -
Looks like I found the culprit:
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
It works correctly under X.So the upgrade of Wayland broke the program. How to fix it?
@JanuszSB
Unless you get a better reply. There are quite a few features which used to work under Xorg but do not under Wayland, at least with the default compositor. Other than changing to X11 you are then stuck with the new behaviour, which is by design under Wayland. -
Looks like I found the culprit:
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
It works correctly under X.So the upgrade of Wayland broke the program. How to fix it?
-
Looks like I found the culprit:
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
It works correctly under X.So the upgrade of Wayland broke the program. How to fix it?
-
Might be helpful to read:
-
@JanuszSB if memory serves well, you can use X application under Wayland. You can try forcing your application to use xcb backend.
@SGaist said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
@JanuszSB if memory serves well, you can use X application under Wayland. You can try forcing your application to use xcb backend.
Yes, this should solve the problem. Unfortunately it is not clear how to do it. As I said above,
QT_QPA_PLATFORM=xcbdoesn't work for me.For the time being switching to X at the login time is acceptable, but I will continue to look for a more elegant solution.
JSB
-
@SGaist said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
@JanuszSB if memory serves well, you can use X application under Wayland. You can try forcing your application to use xcb backend.
Yes, this should solve the problem. Unfortunately it is not clear how to do it. As I said above,
QT_QPA_PLATFORM=xcbdoesn't work for me.For the time being switching to X at the login time is acceptable, but I will continue to look for a more elegant solution.
-
On that linked page someone also mention that it might be fixed in Qt6.3+
At least the error message was gone, it I understand this right...
What version are you using? Can you upgrade?@Pl45m4 said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
On that linked page someone also mention that it might be fixed in Qt6.3+
At least the error message was gone, it I understand this right...
What version are you using? Can you upgrade?qmake -query QT_VERSIONreports5.15.8but I installed also qt6-base-dev .The question "How do I install Qt 6 in Debian Bookworm?" (https://unix.stackexchange.com/questions/752145/how-do-i-install-qt-6-in-debian-bookworm) has practically no answer since 6 months :-(
QT is split on Bookworm into over 20 packages, installing all of them doesn't seem reasonable. I have no idea which of them I really need.
There is an option to install it from https://www.qt.io/download-qt-installer-oss, but I'm afraid of creating a mess by mixing various versions.JSB
-
@Pl45m4 said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
On that linked page someone also mention that it might be fixed in Qt6.3+
At least the error message was gone, it I understand this right...
What version are you using? Can you upgrade?qmake -query QT_VERSIONreports5.15.8but I installed also qt6-base-dev .The question "How do I install Qt 6 in Debian Bookworm?" (https://unix.stackexchange.com/questions/752145/how-do-i-install-qt-6-in-debian-bookworm) has practically no answer since 6 months :-(
QT is split on Bookworm into over 20 packages, installing all of them doesn't seem reasonable. I have no idea which of them I really need.
There is an option to install it from https://www.qt.io/download-qt-installer-oss, but I'm afraid of creating a mess by mixing various versions.For the packages you need: look at the modules your application uses and just install those.
The Qt online installer does not mess with your system. It either install Qt in your home folder or in
/optso unless you do some pretty convoluted things, it will have no impact on your system. -
For the packages you need: look at the modules your application uses and just install those.
The Qt online installer does not mess with your system. It either install Qt in your home folder or in
/optso unless you do some pretty convoluted things, it will have no impact on your system.@SGaist said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
For the packages you need: look at the modules your application uses and just install those.
The Qt online installer does not mess with your system. It either install Qt in your home folder or in
/optso unless you do some pretty convoluted things, it will have no impact on your system.Thanks for the information. Looks like I have some mess already :-(
I prefer to focus now on xcb. I have both
/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.soand
/usr/lib/x86_64-linux-gnu/qt6/plugins/platforms/libqxcb.so.qtchooser reports 7 (!) versions:
4
5
default
qt4-x86_64-linux-gnu
qt4
qt5-x86_64-linux-gnu
qt5All of them has been installed some time ago just to compile two programs: djview4shapes discussed here and djview4poliqarp (https://github.com/jsbien/djview-poliqarp_fork); they share a lot of code, so it is a little strange that the latter has no problem with opening panels.
QTCreator reports 5.15.8 twice:
/usr/lib/qt5/bin/qmakeand/usr/lib/x86_64-linux-gnu/qt5/bin/qmakeSo the question is: when I write
QT_QPA_PLATFORM=xcbon the command line what actually happens? How to check whether the plugin is activated?I noticed mentions of the platform parameter. Does it work for all programs? Should
djview-shapes -platform xcb'work? -
@SGaist said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
For the packages you need: look at the modules your application uses and just install those.
The Qt online installer does not mess with your system. It either install Qt in your home folder or in
/optso unless you do some pretty convoluted things, it will have no impact on your system.Thanks for the information. Looks like I have some mess already :-(
I prefer to focus now on xcb. I have both
/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.soand
/usr/lib/x86_64-linux-gnu/qt6/plugins/platforms/libqxcb.so.qtchooser reports 7 (!) versions:
4
5
default
qt4-x86_64-linux-gnu
qt4
qt5-x86_64-linux-gnu
qt5All of them has been installed some time ago just to compile two programs: djview4shapes discussed here and djview4poliqarp (https://github.com/jsbien/djview-poliqarp_fork); they share a lot of code, so it is a little strange that the latter has no problem with opening panels.
QTCreator reports 5.15.8 twice:
/usr/lib/qt5/bin/qmakeand/usr/lib/x86_64-linux-gnu/qt5/bin/qmakeSo the question is: when I write
QT_QPA_PLATFORM=xcbon the command line what actually happens? How to check whether the plugin is activated?I noticed mentions of the platform parameter. Does it work for all programs? Should
djview-shapes -platform xcb'work?@JanuszSB said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
So the question is: when I write QT_QPA_PLATFORM=xcb on the command line what actually happens? How to check whether the plugin is activated?
QT_QPA_PLATFORM=xcb djview-shapeswill startdjview-shapeswith QT_QPA_PLATFORM in the environment. When QApplication initialises it forces the xcb Qt Platform Abstraction (QPA) plugin where it would normally auto-select Wayland.If you add QT_DEBUG_PLUGINS you see much more information about plugins found and loaded.
QT_DEBUG_PLUGINS=1 QT_QPA_PLATFORM=xcb djview-shapesI noticed mentions of the platform parameter. Does it work for all programs?
Yes for anything using QGuiApplication or the QApplication subclass.
-
@JanuszSB said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
So the question is: when I write QT_QPA_PLATFORM=xcb on the command line what actually happens? How to check whether the plugin is activated?
QT_QPA_PLATFORM=xcb djview-shapeswill startdjview-shapeswith QT_QPA_PLATFORM in the environment. When QApplication initialises it forces the xcb Qt Platform Abstraction (QPA) plugin where it would normally auto-select Wayland.If you add QT_DEBUG_PLUGINS you see much more information about plugins found and loaded.
QT_DEBUG_PLUGINS=1 QT_QPA_PLATFORM=xcb djview-shapesI noticed mentions of the platform parameter. Does it work for all programs?
Yes for anything using QGuiApplication or the QApplication subclass.
@ChrisW67 said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
If you add QT_DEBUG_PLUGINS you see much more information about plugins found and loaded.
QT_DEBUG_PLUGINS=1 QT_QPA_PLATFORM=xcb djview-shapesNothing changed, no output. However if instead of xcb I write some other string then I get an error report.
In https://stackoverflow.com/questions/55731797/custom-plugin-for-qt-is-not-loaded-how-to-debug I found "you apparently have QT to build with debug information". Can it be relevant for my case?
-
@ChrisW67 said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
If you add QT_DEBUG_PLUGINS you see much more information about plugins found and loaded.
QT_DEBUG_PLUGINS=1 QT_QPA_PLATFORM=xcb djview-shapesNothing changed, no output. However if instead of xcb I write some other string then I get an error report.
In https://stackoverflow.com/questions/55731797/custom-plugin-for-qt-is-not-loaded-how-to-debug I found "you apparently have QT to build with debug information". Can it be relevant for my case?
@JanuszSB I get plugin debug information for both debug and release builds of a small example. For example:
$ ~/Qt/6.6.1/gcc_64/bin/qmake CONFIG+=release $ make ... $ file ./simple_example ./simple_example: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=89d8e1eca37d300fbcfd802cd1f2bb82ce9e708c, for GNU/Linux 3.2.0, not stripped $ QT_DEBUG_PLUGINS=1 QT_QPA_PLATFORM=xcb ./simple_example qt.core.plugin.factoryloader: checking directory path "/home/chrisw/Qt/6.6.1/gcc_64/plugins/platforms" ... qt.core.plugin.factoryloader: looking at "/home/chrisw/Qt/6.6.1/gcc_64/plugins/platforms/libqminimal.so" qt.core.plugin.loader: Found metadata in lib /home/chrisw/Qt/6.6.1/gcc_64/plugins/platforms/libqminimal.so, metadata= { "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3", "MetaData": { "Keys": [ "minimal" ] }, "archlevel": 1, "className": "QMinimalIntegrationPlugin", "debug": false, "version": 394752 } ... qt.core.library: "/home/chrisw/Qt/6.6.1/gcc_64/plugins/platforms/libqxcb.so" loaded library ...I guess your application could be doing something creative to trash the output.
-
@JanuszSB I get plugin debug information for both debug and release builds of a small example. For example:
$ ~/Qt/6.6.1/gcc_64/bin/qmake CONFIG+=release $ make ... $ file ./simple_example ./simple_example: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=89d8e1eca37d300fbcfd802cd1f2bb82ce9e708c, for GNU/Linux 3.2.0, not stripped $ QT_DEBUG_PLUGINS=1 QT_QPA_PLATFORM=xcb ./simple_example qt.core.plugin.factoryloader: checking directory path "/home/chrisw/Qt/6.6.1/gcc_64/plugins/platforms" ... qt.core.plugin.factoryloader: looking at "/home/chrisw/Qt/6.6.1/gcc_64/plugins/platforms/libqminimal.so" qt.core.plugin.loader: Found metadata in lib /home/chrisw/Qt/6.6.1/gcc_64/plugins/platforms/libqminimal.so, metadata= { "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3", "MetaData": { "Keys": [ "minimal" ] }, "archlevel": 1, "className": "QMinimalIntegrationPlugin", "debug": false, "version": 394752 } ... qt.core.library: "/home/chrisw/Qt/6.6.1/gcc_64/plugins/platforms/libqxcb.so" loaded library ...I guess your application could be doing something creative to trash the output.
@ChrisW67 said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
@JanuszSB I get plugin debug information for both debug and release builds of a small example. For example:
$ ~/Qt/6.6.1/gcc_64/bin/qmake CONFIG+=releaseWhat is it for?
$ make
...$ file ./simple_example
./simple_example: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=89d8e1eca37d300fbcfd802cd1f2bb82ce9e708c, for GNU/Linux 3.2.0, not strippedCan you somehow share the program?
$ QT_DEBUG_PLUGINS=1 QT_QPA_PLATFORM=xcb ./simple_example
I guess your application could be doing something creative to trash the output.
The program was written12 years ago, can this be relevant?
JSB
-
@ChrisW67 said in Debian: after upgrading the system the program became unusable. How to approach the problem?:
@JanuszSB I get plugin debug information for both debug and release builds of a small example. For example:
$ ~/Qt/6.6.1/gcc_64/bin/qmake CONFIG+=releaseWhat is it for?
$ make
...$ file ./simple_example
./simple_example: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=89d8e1eca37d300fbcfd802cd1f2bb82ce9e708c, for GNU/Linux 3.2.0, not strippedCan you somehow share the program?
$ QT_DEBUG_PLUGINS=1 QT_QPA_PLATFORM=xcb ./simple_example
I guess your application could be doing something creative to trash the output.
The program was written12 years ago, can this be relevant?
@JanuszSB can you share your own build ?
Tested on KDE Neon with wayland as backend and it looks like it's working as expected. The widget on the left is a scroll area where widgets are added. It does not do anything special.
