QT 5.12 on Ubuntu 20.04 has bugs. What are my options?

snapcraft
#1

HI Everyone

I am trying to port my application to core 20.04. My app uses the webengine module of QT, but the qt version in 20.04 is not working properly (tested on my normal desktop). In the 20.10 version my software works as expected.

Which are my options? can I install another version of qt in the snap? If so, someone has done it before?

Sadly, I will have to distribute my app using the classic .deb format… I hope I can use snap again.

The sorry state of snapping Qt5 apps
#2

So, if the bugs which appear in Ubuntu 20.04 have patches available then they’d probably be candidates for an SRU. Once the fixed packages were in 20.04, a new build of a core20-based snap would pick them up.

But snaps are also free to include any version of their dependencies that they want. You can build and use any version of Qt in there. I don’t have an example of bundling a Qt install, but the FluffyChat snap needs a newer version of libolm than Ubuntu 18.04 provides, so it builds it from source here. Something reasonably similar should work for Qt.

#3

Thanks for the answer. I know I can wait for a fix to come… but I doubt it will happen any day soon. The problem is the version of webengine…

I know that I can include any software I want in a snap, but I think it would be very difficult to add it. Launching a qt is already difficult, I do not want to do that in a qt installed by me… I think that… maybe, I will wait for 22.04 to include a qt without the bug…

Thanks RAOF!

#4

You could probably use a PPA for a newer version of Qt. I do this for one of the snap’s that I maintain requiring qt5.14 or later. To do this I had to add this block in:

package-repositories:
  - type: apt
    ppa: beineri/opt-qt-5.15.2-focal

This is an experimental feature as of snapcraft version 4.4.4 (the current version as of writing in the stable channel, dont know if this due to change in 4.5) and therefore requires running snapcraft with the --enable-experimental-package-repositories flag.

You’ll also have to point environment variables like LD_LIBRARY_PATH, QT_DIR and PATH to the location of Qt libraries installed via the PPA under $SNAP/opt/[QTVERSION], for the final snap to use at runtime.

I’ve used this approach with the RPCS3 snap, seems to work fine for me. https://github.com/Nightmayr-snaps/rpcs3-snap/blob/master/snap/snapcraft.yaml

#5

It’ll happen sooner if you file a bug in launchpad.net :wink: Without knowing that a bug exists, how to reproduce it, and what the bad behaviour is (also helpful is what you expected to happen) the developers can’t be expected to fix it…

#6

Is it worth to report a big bug Qt folks didn’t backport the fix to Qt 5.12 for, due to a required major rewrite of a subsystem in order to fix the bug? Or there are no chance that fix for such a bug will be backported by Ubuntu maintainers?

I’m talking about a bug in qtwayland that prevents using hotkeys (even for copy and paste) with non-english layouts. Given that snapcraft-desktop-helpers enforces Wayland even when a compositor is blacklisted by Qt (I reported that a lot of time ago, but there’s no any input for a half of the year :confused:), people reporting that from time to time and I can’t suggest anything except of waiting two years for core22 with new Qt version… :cry:

#7

I don’t see any equivalent code in the desktop-launch script generated by the kde-neon extension (extensions being the system that replaced cloud parts like snapcraft-desktop-helpers), so perhaps you could try that.

If you are still need snapcraft-desktop-helpers though, it does offer a way to disable that code if your application is otherwise incompatible with Wayland:

You can take advantage of this by adding something like the following to your snapcraft.yaml file:

environment:
  DISABLE_WAYLAND: 1
#8

I tried it some time ago and there’s multiple things wrong with it:

  1. It is only for amd64, I need more (arm64, armhf, ppc64el)
  2. It forces some QT_QPA_PLATFORMTHEME value: https://github.com/snapcore/snapcraft/blob/b5138e03e53727347f65b0b1499a02fccd1ef9b4/extensions/desktop/kde-neon/launcher-specific#L7-L16
    For instance, this leads to a bad situation with tray icons: if an app detects that current icon theme contains an icon and sets it to a SNI tray icon, users may get a broken icon (since this icon may present in Breeze, but there’s might another theme be used on host, without the icon.
    This commit says that QT_QPA_PLATFORMTHEME=gtk3 will lead to QGnomeTheme, but it’s wrong, it will use xdgdesktopportal instead: https://github.com/qt/qtbase/blob/5.12/src/gui/kernel/qguiapplication.cpp#L1239-L1241
    And xdgdesktopportal doesn’t look for QT_QPA_PLATFORMTHEME value when creating platform integration: https://github.com/qt/qtbase/blob/cafda99d2cf1bc42a5c793b2c2119b14b6b4e762/src/plugins/platformthemes/xdgdesktopportal/qxdgdesktopportaltheme.cpp#L70-L92
    On other side, if you remove it, some users will lose ability to open file dialog since Qt doesn’t have any fallback when it uses portal dialogs and xdg-desktop-portal is not a dependency of snapd in most distros.
  3. A problem with svg icon themes: https://forum.snapcraft.io/t/broken-theming-and-missing-icons-on-gtk-file-picker-using-kde-neon-extension
  4. KDE Neon maintainers removing QtWayland private headers, I need them.
  5. It uses core18, I need core20 with newer libraries.
  6. Finally, last time I tried, kde-neon extension used kde-frameworks-5-core18 with Qt 5.12, so there’s no any benefit.

It will disable Wayland completely without ability to enable it for users. snapcraft-desktop-helpers should let Qt (and GTK) decide should it use Wayland or not, so that users will be allowed to override QT_QPA_PLATFORM manually if they want Wayland when Qt thinks that a compositor is incompatible.

#11