search

DavidoTek / ProtonUp-Qt

Install and manage GE-Proton, Luxtorpeda & more for Steam and Wine-GE & more for Lutris with this graphical user interface.
https://davidotek.github.io/protonup-qt
GNU General Public License v3.0
1.16k stars 39 forks source link

AppImage v2.9.2 uses the user's Python package instead of included ones #390

Closed sonic2kk closed 1 month ago

sonic2kk commented 2 months ago

Please fill out following when reporting a new bug:

Describe the bug
ProtonUp-Qt v2.9.2 AppImage will crash if the Wayland backend is used on Plasma 6 Wayland. It can be fixed by forcing X11 with QT_QPA_PLATFORM=xcb ./ProtonUp-Qt-2.9.2-x86_64.AppImage.

ProtonUp-Qt v2.9.1, prior to the AppImage bump, works fine.

The error is coming from the Qt side, so this is either a Qt bug or maybe a library has to be bumped somewhere in the AppImage build process? I'm not too familiar with how the AppImage stuff works but I've ran into annoying behaviour when trying to build AppImages.

To Reproduce
Steps to reproduce the behavior:

  1. Run the ProtonUp-Qt Flatpak
  2. ProtonUp-Qt will start loading ctmods and stall for about 5 seconds, likely loading everything and crashing at the point when it tries to open a window
  3. It will crash with the terminal output given below.

Expected behavior
ProtonUp-Qt v2.9.2 opens without having to force X11.

Screenshots
image

Desktop (please complete the following information):

Additional context
I did a quick search to try and find information about what might be causing the problem, as this is likely a "packaging" issue rather than a ProtonUp-Qt code bug. I found one other Qt project having similar errors with their AppImage a few years ago but there was no clear resolution other than the problem just went away: https://github.com/qbittorrent/qBittorrent/issues/13291

I did not find any other information in my searches around this issue happening for other projects, so I'm not sure what exactly is causing it.

I don't use the AppImage personally (I usually just run from source with whatever branch I'm working on at the time) but I discovered this by trying to check if it used portals for the file picker dialog for a PR I was working on.

I noticed in the terminal output that PySide6 6.3 is being used, perhaps this version needs updated?

Terminal output Note that the QFont errors happen on v2.9.1 also and are not very important. The two error messages of note here are:

These two messages are specific to the v2.9.2 AppImage.

QFont::fromString: Invalid description 'Inter Display,10,-1,5,500,0,0,0,0,0,0,0,0,0,0,1,Medium'
QFont::fromString: Invalid description 'JetBrains Mono,10,-1,5,500,0,0,0,0,0,0,0,0,0,0,1,Medium'
QFont::fromString: Invalid description 'Inter Display,10,-1,5,500,0,0,0,0,0,0,0,0,0,0,1,Medium'
QFont::fromString: Invalid description 'Inter Display,10,-1,5,500,0,0,0,0,0,0,0,0,0,0,1,Medium'
ProtonUp-Qt 2.9.2 by DavidoTek. Build Info: Official AppImage by DavidoTek.
Python 3.10.4 (main, Apr  2 2022, 09:04:19) [GCC 11.2.0], PySide 6.3.1
Platform: Arch rolling Linux-6.8.7-zen1-1-zen-x86_64-with-glibc2.39
qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Loading locale en / en_GB
Loaded ctmod GE-Proton
Loaded ctmod Wine-GE
Loaded ctmod Boxtron
Loaded ctmod D8VK (nightly)
Loaded ctmod Kron4ek Wine-Builds Vanilla
Loaded ctmod Lutris-Wine
Loaded ctmod Luxtorpeda
Loaded ctmod Northstar Proton (Titanfall 2)
Loaded ctmod Proton Tkg
Loaded ctmod Proton Tkg (Wine Master)
Loaded ctmod Roberta
Loaded ctmod Steam-Play-None
Loaded ctmod SteamTinkerLaunch
Loaded ctmod SteamTinkerLaunch-git
Loaded ctmod vkd3d-lutris
Loaded ctmod vkd3d-proton
Loaded ctmod Wine Tkg (Valve Wine Bleeding Edge)
Loaded ctmod Wine Tkg (Wine Master)
Loaded ctmod DXVK
Loaded ctmod DXVK Async
Loaded ctmod DXVK (nightly)
qt.pysideplugin: Environment variable PYSIDE_DESIGNER_PLUGINS is not set, bailing out.
qt.pysideplugin: No instance of QPyDesignerCustomWidgetCollection was found.
Attribute Qt::AA_ShareOpenGLContexts must be set before QCoreApplication is created.
Gamepad error: The user (that this program is being run as) does not have permission to access the input events, check groups and permissions, for example, on Debian, the user needs to be in the input group.
faith-healer commented 2 months ago

2.9.2 with KDE6 X11 fails to run as well, as well as 2.9.1 runs okay.

DavidoTek commented 2 months ago

Hmm, sounds like an issue with the bundled dependencies.

I noticed in the terminal output that PySide6 6.3 is being used, perhaps this version needs updated?

I wonder why that is. The requirements.txt allows versions newer than 6.3 and even 6.7.0 should be compatible with Python 3.10....

sonic2kk commented 2 months ago

@faith-healer Are you sure on X11 this isn't related to #378? Do the error messages you see match the ones I am seeing?

It would be good if you could double-check and if you're seeing different errors than the ones I showed in my terminal output, and if your issue is not fixed in the same way as #378, it may be a good idea to open a separate issue which may be X11/distro specific (e.g. a distro missing some package(s)).

For me, forcing ProtonUp-Qt to run with X11 resolves the problem, so I am not sure our issues are the same. Things can fail to run for a variety of reasons :-)

I did take a look at the AppImage manifest(?) and while a lot of it is over my head, I didn't spot anything immediately wrong.

I think we can build AppImages from source though so if there's anything you need me to try let me know!

faith-healer commented 2 months ago

@DavidoTek funny thing is that *-cursor0 not available in Arch, even in AUR. but if I install AppImage v2.9.1 from KDE Discovery - it seems it has it in package and runs okay.

DavidoTek commented 2 months ago

I did take a look at the AppImage manifest(?) and while a lot of it is over my head, I didn't spot anything immediately wrong.

I find it interesting that when I build the AppImage with an Ubuntu 22.04 Distrobox, it will use Python 3.11, but the GitHub Ubuntu 22.04 runner still uses Python 3.10....

Python 3.10.4 (main, Apr 2 2022, 09:04:19) [GCC 11.2.0], PySide 6.3.1

That is a bit weird. The AppImage includes PySide 6.7.0:

$ ./ProtonUp-Qt-2.9.2-x86_64.AppImage --appimage-extract
...
$ ls squashfs-root/usr/local/lib/python3.10/dist-packages/ | grep -i PySide6
PySide6
PySide6_Essentials-6.7.0.dist-info

It tested it on my system and it is using the correct version: Python 3.10.4 (main, Apr 2 2022, 09:04:19) [GCC 11.2.0], PySide 6.7.0 I also tried installing another PySide6 version to see if the AppImage just uses the system version, but that seems not to be the case.

Can you check what the output of the following commands is? Maybe it is actually loading a system installation of PySide6 on your system.

python3 -m pip | grep -i PySide6
find /usr/lib | grep -i PySide6 | head -n 5
find /usr/local/lib | grep -i PySide6 | head -n 5
find ~/.local/lib | grep -i PySide6 | head -n 5
sonic2kk commented 2 months ago

@faith-healer Maybe I'm mistaken, but are you sure this is the AppImage? Usually, Discover will list either Flatpaks or system packages (by way of PackageKit).

Also, if the issue is happening on X11 then I still think it's a different problem, since my issue is resolved when using X11.

You might want to see if that cursor package is provided elsewhere by Arch. Package names often differ between package managers, especially for libraries. I am not sure what would provide this package, however.

@DavidoTek

but the GitHub Ubuntu 22.04 runner still uses Python 3.10....

Maybe the GitHub runner base is a bit out of date? Maybe there was a point release it isn't using? I remember even on regular installs there are some oddities with certain packages only updating/not updating (can't remember which) depending on whether or not you do an in-place upgrade.

There could also be a deliberate decision by GitHub to use specific packages with their runners, I'm not sure.

I'll check the other details when I am home :-) However I think when running from source that I am using PySide 6.7.0, so I'll double check tjat too.

sonic2kk commented 2 months ago

Aha! Turns out this was a problem on my end, not a ProtonUp-Qt problem. Sorry about that!

There were Python 3.10 installation files at ~/.local/lib/python3.10. The AppImage was attempting to use this, despite my system not having Python 3.10 at all. This is why I should use virtual envs more :sweat_smile:

I confirmed with xeyes that Wayland is being used and this resolved my problem.

This probably came about when using pip with pyenv and not using a virtual environment. And 2.9.1 probably works because while there is a Python 3.8 packages folder here too, there is no PySide6 installation, so it should use the one from the AppImage.

Renaming this folder fixed the issue. It seems like the AppImage will attempt to, at least in my case, use the packages at ~/.local/lib (possibly even /usr/lib too?) if the Python version matches and there is a corresponding packages folder on this path.

I will probably delete this folder, and some other older ones like for Python 3.8, that are no longer on my system.

So for some reason the AppImage will try to use the system Python packages by default instead of the ones in the AppImage. I wonder if there's a way to change this? It makes more sense in my mind to use the packages bundled with the AppImage first, but I'm not sure what kind of configuration would be needed here to accomplish this.

@faith-healer Double-check that our issues are the same, by checking first and foremost if you get the same terminal output that I do. I really think your issue is more in line with #378 though, because you're using X11 and this issue is likely isolated to a PySide 6.3.0 + Wayland issue (using QT_QPA_PLATFORM=xcb as noted in my OP fixes the issue).

The exact package you're missing may vary, in that issue it was libxcb-cursor0 but on your system it could be different. On my Arch PC I did a search with find /usr/lib -iname "*libxcb*" | grep -i cursor and it came back with the following matches:

$ find /usr/lib -iname "*libxcb*" | grep -i cursor
/usr/lib/libxcb-cursor.so.0
/usr/lib/libxcb-cursor.so.0.0.0
/usr/lib/libxcb-cursor.so

A pacman -F /usr/lib/libxcb-cursor.so.0 returns usr/lib/libxcb-cursor.so.0 is owned by extra/xcb-util-cursor 0.1.5-1. You can check if you have this installed with pacman -Qi xcb-util-cursor. If you want to run the pacman -F command yourself, you first need to run, as root, pacman -Fy first to pull this ownership info for all of your packages from the Arch servers. This is likely worth doing.

I strongly suspect you will have this package as it is, on my system, listed as a requirement for kwin and qt6-base; two packages that Plasma would heavily rely on.

So I don't think you would be missing the same dependency. You may want to run the AppImage from the terminal and examine the output. In #378, there was the following telling line: qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin. - I would look for something similar to this. You may see other telling output though that points to this being a different issue altogether; I don't think it's the same as this issue, and it may not be the same as #378 if there is different error output, so in that case you may want to open a separate issue.

I would also be interested to know if Discover can install AppImages for you, so make sure you're not using the Flatpak, or perhaps an AUR package.

I'm going to close this issue as it was caused by a problem on my system from me doing silly things (the joys of a 6+ year old install is all of the gathered junk :sweat_smile:)

DavidoTek commented 1 month ago

Issue: AppImage uses the user's Python package

There were Python 3.10 installation files at ~/.local/lib/python3.10. The AppImage was attempting to use this, despite my system not having Python 3.10 at all. This is why I should use virtual envs more 😅 Renaming this folder fixed the issue. It seems like the AppImage will attempt to, at least in my case, use the packages at ~/.local/lib (possibly even /usr/lib too?)

I would say that is a problem with the AppImage and not your installation. The AppImage should in no case use the user's Python packages...

I wonder if there's a way to change this? It makes more sense in my mind to use the packages bundled with the AppImage first, but I'm not sure what kind of configuration would be needed here to accomplish this. And 2.9.1 probably works because while there is a Python 3.8 packages folder here too, there is no PySide6 installation, so it should use the one from the AppImage.

I'm not sure if the issue already existed with v2.9.1, maybe just no one was using the "ancient" Python 3.8. It might be possible to tell Python to not look at certain paths. It will have access to those as AppImage has no sandbox.

Were setting PYTHONHOME and PYTHONPATH in the AppImage here to ${APPDIR}/usr/lib/python3.10/site-packages. We may need to change this to ${APPDIR}/usr/local/lib/python3.10/dist-packages which is the actual path used by Python 3.10. I guess Python notices that the path does not exist and then defaults to some other path. Not sure how it even knows that it alternatively finds them at ${APPDIR}/usr/local/lib/python3.10/dist-packages....

https://github.com/DavidoTek/ProtonUp-Qt/blob/5ee4bdb02f906d4ff096d514db1afdcde5736c69/AppImageBuilder.yml#L44-L45