Closed hermidalc closed 1 year ago
You can easily reproduce the issue showing that Wayland plugins are missing with the following:
$ ipython
Python 3.7.3 | packaged by conda-forge | (default, Jul 1 2019, 21:52:21)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.9.0 -- An enhanced Interactive Python. Type '?' for help.
In [1]: import matplotlib.pyplot as plt
In [2]: Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
In [2]:
Qt Wayland is intentionally skipped at https://github.com/conda-forge/qt-feedstock/blob/1725290e7d4d2ce3bd95231e1bde91770fe66b6a/recipe/build.sh#L173 I've no idea why that is. cc @mingwandroid
I can't speak for @mingwandroid, but it's probably left out because Wayland is still very new and not supported by all desktop environments (I think KDE still doesn't support it).
I can't speak for @mingwandroid, but it's probably left out because Wayland is still very new and not supported by all desktop environments (I think KDE still doesn't support it).
It's been the default desktop protocol on Fedora Linux since v25 which was released November 2016. Should be easy to include in the conda-forge qt5 package as it just means including the files I've listed?
No, that's not an easy process. If you have the possibility to use XOrg instead of Wayland, I'd suggest you to use that instead of waiting for Wayland support here.
No, that's not an easy process. If you have the possibility to use XOrg instead of Wayland, I'd suggest you to use that instead of waiting for Wayland support here.
I haven't used Xorg in 3 years. Sorry to bother, but could you explain in more detail why it's a difficult process? Seems from https://github.com/conda-forge/qt-main-feedstock/issues/116 it would first involve not specifying the -skip wayland
option during build then the shared object files will be included in the package. Is there anything else that would make this a more cumbersome process?
Sorry to bother, but could you explain in more detail why it's a difficult process?
It seems you haven't compiled packages before, much less conda packages, so sorry, but I don't have time to explain you that.
But you're welcome to try to add support for Wayland here by creating CDT packages for it and its dependencies (I don't know how they are created, sorry), adding them as dependencies to the conda recipe here, then removing the -skip wayland
flag and solving all compilation problems that could appear.
It seems you haven't compiled packages before, much less conda packages, so sorry, but I don't have time to explain you that.
But you're welcome to try to add support for Wayland here by creating CDT packages for it and its dependencies (I don't know how they are created, sorry), adding them as dependencies to the conda recipe here, then removing the
-skip wayland
flag and solving all compilation problems that could appear.
I've built libraries from source many times, though not conda packages. Looking here https://wiki.qt.io/QtWayland#How_do_I_build_QtWayland.3F it seems that with a working build of Qt5 it would involve downloading the source, qmake, make, make install and working through any missing dependency errors by finding the equivalent conda-forge (or defaults) packages.
I've built libraries from source many times
Sorry. Then you're probably not too familiar with building Qt, which is one of the hardest libraries to create packages for in the conda ecosystem.
it seems that with a working build of Qt5 it would involve downloading the source, qmake, make, make install
That's already done here.
and working through any missing dependency errors by finding the equivalent conda-forge (or defaults) packages.
That's what I referred to when talking about creating CDT packages for Wayland and its deps. Here you can find what they are and how to build packages for them.
One important note: I don't know if Wayland requires a recent kernel, glibc or userspace tools to work. I mention that because all conda packages are built in a CentOS 6 docker image.
As Carlos says, this is not possible without requiring a more recent base Distro than centos6 and that would exclude a huge amount of current users. Otherwise you could try to build Wayland packages in conda forge. That's not easy.
Does XWayland not work here? @hermidalc please don't make assumptions like this. It's disheartening.
As Carlos says, this is not possible without requiring a more recent base Distro than centos6 and that would exclude a huge amount of current users. Otherwise you could try to build Wayland packages in conda forge. That's not easy.
Does XWayland not work here? @hermidalc please don't make assumptions like this. It's disheartening.
Isn’t this the conda-forge qt feedstock? Sorry I’m confused because I’ve always assumed this is the case ie to update the Qt5 conda-forge package not for defaults channel.
Hmm, where to start with this? Deep breaths probably ..
You can see the maintainers of this feedstock here: https://github.com/conda-forge/qt-feedstock#feedstock-maintainers (@isuruf, you should be in this list too!)
2/3 of them are Anaconda Inc, employees, 1 (Carlos) is an ex-employee.
Anaconda Distribution
and conda-forge
have large overlaps in many regards beyond personel, we see conda-forge
as our upstream and with regards to the Qt package, I contribute to it a lot.
You didn't answer my question though. Does XWayland not work for you? If it does work then is this a big deal? Also, are you prepared to do this work?
You didn't answer my question though. Does XWayland not work for you? If it does work then is this a big deal? Also, are you prepared to do this work?
Sorry about that was writing on my phone. Apologies too for making any assumptions didn't mean to, just trying to figure things out like most users. It is automatically falling back to XWayland XCB plugin after giving you the warning shown above, so just more of an annoyance than anything else as the warning pops up every time I use a library that uses qt5 (like matplotlib on Linux).
Wayland has been where the Linux desktop is headed since a few years now. While KDE might not have it as default yet it's been the default for GNOME (which I use), Plasma, and Enlightenment desktop environments for years. Just thought for the conda-forge channel (not defaults) package this maybe should eventually be supported?
Even now with the latest Fedora 31 release they have made Qt5 Wayland plugin the default not XCB. https://fedoraproject.org/wiki/Changes/Qt_Wayland_By_Default_On_Gnome
Just thought for the conda-forge channel (not defaults) package this maybe should eventually be supported?
That's fine, but it is not at all fine at the expense of CentOS6 compatibility. But mainly, conda-forge
is open-source, so if you want to find out how difficult things really get, please feel free to attempt this. There are two ways:
Way 1:
1.1. Add a `wayland` package to conda-forge.
1.2. Make this recipe depend upon that.
1.3. Add it to the configure line then fix the myriad of build problems.
or ..
Way 2
2.1. Add CDT packages for CentOS7/x86_64 including wayland (if it's available, I don't use Wayland and don't care about it, I tried it once, it didn't work well so I went back to X11).
2.2. Make this recipe depend upon that.
2.3. Add it to the configure line then fix the myriad of build problems.
I'm not sure why you bring up Fedora or any other very modern linux distro. They have a lot more freedom than we do, they do not build software that also runs on all the other linux distros!
But since XWayland works I don't see any point. You could try to make a patch for Qt so the warning is disabled if it troubles you enough.
Thanks.
That's fine, but it is not at all fine at the expense of CentOS6 compatibility. But mainly,
conda-forge
is open-source, so if you want to find out how difficult things really get, please feel free to attempt this. There are two ways:Way 1: 1.1. Add a `wayland` package to conda-forge. 1.2. Make this recipe depend upon that. 1.3. Add it to the configure line then fix the myriad of build problems.
or ..
Way 2 2.1. Add CDT packages for CentOS7/x86_64 including wayland (if it's available, I don't use Wayland and don't care about it, I tried it once, it didn't work well so I went back to X11). 2.2. Make this recipe depend upon that. 2.3. Add it to the configure line then fix the myriad of build problems.
I will attempt this and see how it goes.
I'm not sure why you bring up Fedora or any other very modern linux distro. They have a lot more freedom than we do, they do not build software that also runs on all the other linux distros!
I'm brought it up because this issue is only relevant to people using conda-forge qt5 on modern Linux distros with GNOME, KDE5 Plasma, or Enlightenment desktops which run Wayland by default. For people using X11 this issue isn't relevant. Does that make sense?
But since XWayland works I don't see any point. You could try to make a patch for Qt so the warning is disabled if it troubles you enough.
The workaround to suppress the warnings is simple, so for other users who come here you need to set the XDG_SESSION_TYPE
to x11
in code that will use conda-forge qt5, such as matplotlib. Though of course don't change that env var permanently as your entire Wayland desktop will go back to X11.
import os
import numpy as np
import matplotlib.pyplot as plt
os.environ['XDG_SESSION_TYPE'] = 'x11'
t = np.arange(0.0, 2.0, 0.01)
s = 1 + np.sin(2 * np.pi * t)
fig, ax = plt.subplots()
ax.plot(t, s)
ax.set(xlabel='time (s)', ylabel='voltage (mV)',
title='About as simple as it gets, folks')
ax.grid()
plt.show()
@mingwandroid @isuruf @ccordoba12 may I ask what is pkgw-forge
?
I'm with @mingwandroid here: if you're so annoyed by that warning, simply look for it in the Qt source code and comment it.
Also, sorry for not reading your original post in depth, but I really don't understand all this fuss for a warning. I thought things were failing for you, which would be a completely different story.
Also, sorry for not reading your original post in depth, but I really don't understand all this fuss for a warning. I thought things were failing for you, which would be a completely different story.
I don't see where I've been making "a big fuss". Just reported an issue on here how Wayland isn't supported on the conda-forge qt5 package and having a polite discussion about it, is that allowed?
@mingwandroid @isuruf @ccordoba12 may I ask what is
pkgw-forge
?
Dear @pkgw - apologies in advance for roping you into this discussion, but seems like you have a lot of experience and insight regarding this issue. Would you be interested in porting your packages and bringing Wayland support to conda-forge?
I'm brought it up because this issue is only relevant to people using conda-forge qt5 on modern Linux distros with GNOME, KDE5 Plasma, or Enlightenment desktops which run Wayland by default. For people using X11 this issue isn't relevant. Does that make sense?
Again, this is a warning. XWayland is an appropriate option for everyone using Wayland AFAIK. I for one can easily ignore irrelevant warnings (until such a time as something breaks because they aren't expected; at that point they become very relevant!)
Again, this is a warning. XWayland is an appropriate option for everyone using Wayland AFAIK. I for one can easily ignore irrelevant warnings (until such a time as something breaks because they aren't expected; at that point they become very relevant!)
This brings up an important point and another reason why I originally opened this issue. Today it is just a warning that can be easily suppressed, but by no means does that mean it will stay that way as long as the conda-forge qt5 package doesn't intend to include the Wayland QPA plugin. In future this could cause things not to work and a work stoppage for users, so just trying to make it known by opening the issue.
but by no means does that mean it will stay that way
If it were to be changed to a hard error then that would by necessity happen when the Qt Project releases a new version. If and when that happens, we'll do something about it (before publishing the release, hopefully, but even then, we can and do pull broken package builds).
Good luck!
But since XWayland works I don't see any point. You could try to make a patch for Qt so the warning is disabled if it troubles you enough.
On HiDPI displays, everything using XWayland is blurry to the point of being really painful. E.g. matplotlib is only barely tolerable using current conda forge packages with the xwayland fallback to xcb.
It's been another two years, wayland usage has only increased since then and CENTOS 6 has reached end of life.
Sorry to be bugging here again and I want to stress that I would be willing to help, but looking at the list here: https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Desktop_Linux_distributions
are now all Wayland by default.
In addition to CentOS 6 being EOL and that conda should not care anymore about supporting compatibility, Wayland has been default already since CentOS 7.8 and CentOS 7 reaches EOL in only a couple years.
So since it is such a difficult time consuming process to rebuild all conda linux pkgs on a new CentOS distro every few years, I would suggest leap frogging past 7 and 8 and using a good Stream rolling release point that will exclude fewer Linux users while keeping in mind you can’t make everyone happy and this is a PITA to redo every few years so gotta push people forward.
We have in qt 5.15 moved to centos 7.
It seems that libwayland can be a plugin.
Generally, I suggest that you do all the experiments in your own branch, then demonstrate results at conda-forge.
I may be interested in trying my hand at it in a few weeks.
For reference, here is ubuntu's package https://packages.ubuntu.com/jammy/qtwayland5
PS. I'm also moving this to qt-main since that is where the new work is being done
So I made a few PRs to staged recipes that are probably ready for review:
They should be readily buildable, and installable with python build_locally.py
. As people interested in conda/qt/wayland, it would be appreciated if you could test and give feedback.
I've still found the X11 backend to be faster than wayland for my opengl work (even when the desktop environment is running in wayland).
I think the issues brought up in https://github.com/githubuser0xFFFF/Qt-Advanced-Docking-System/issues/288 are worth a read for those thinking of taking the plunge into wayland for qt.
I just wanted to say that the package qt-wayland
is now available.
https://github.com/conda-forge/qt-wayland-feedstock/
PRs for qt6-wayland
would be appreciated.
Given that that the package now exists. I'm going to close this issue.
Thank you all for your patience.
Thank you so much! matplotlib finally works on wayland without being a blurry mess on HiDPI!
The conda-forge Linux Qt package is missing the Wayland QPA plugin, i.e. not bundling libQt5WaylandClient.so.5 and and libQt5WaylandCompositor.so.5. Therefore on Linux systems which run Wayland I get constant warnings when using conda packages that use Qt:
and if I try to set
QT_QPA_PLATFORM=wayland
you get a core dump:Even if I set the env var to use
xcb
(XWayland) I still get the warning. My Fedora system Qt of the same version 5.12.5 bundles the Wayland QPA plugin:But these are missing from the conda-forge package. Could you bundle it?
Environment (
conda list
):Details about
conda
and system (conda info
):