Recently, PlayOnLinux 4 (https://aur.archlinux.org/packages/playonlinux) has stopped working on my Artix Linux install when it had been working perfectly fine about a week ago. At first, I thought it might be related to python3 getting upgraded to 3.11.x, but after testing PoL4 on upstream Arch, it works fine with that same python3 3.11.x version.
Any suggestions on how to get PoL4 working again on Artix? Is it now missing a dependency?
Launch it from a terminal to see what's missing.
I get the following running playonlinux from the CLI, which led me to believe that it was a python 3.11.x issue as it was working perfectly fine before "[testing] -> [core] 'python-3.11.3-1' move " (https://gitea.artixlinux.org/packagesP/python/commits/branch/master) when the system was running 'python-3.10.10-1.1'
$ playonlinux4
Looking for python3... 3.11.3 - selected
1.0
[main] Message: PlayOnLinux (4.4.1) is starting
[clean_tmp] Message: Cleaning temp directory
[Check_OpenGL] Message: 32bits direct rendering is enabled
[Check_OpenGL] Message: 64bits direct rendering is enabled
[POL_System_CheckFS] Message: Checking filesystem for /home/USERNAME/.PlayOnLinux/
[main] Message: Filesystem is compatible
Traceback (most recent call last):
File "/usr/share/playonlinux4/python/mainwindow.py", line 1195, in OnInit
self.frame = MainWindow(None, -1, os.environ["APPLICATION_TITLE"])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/share/playonlinux4/python/mainwindow.py", line 330, in __init__
self.plugin_item = wx.MenuItem(self.expertmenu, 300 + self.j, files[self.i])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: MenuItem(): argument 2 has unexpected type 'int'
OnInit returned false, exiting...
[update_check] Message: List is up to date
Then nothing loads and it sits stuck at the command prompt. After I hit ctrl+C, I get the following:
Ctrl+C pressed. Killing all processes...
Exception ignored in: <module 'threading' from '/usr/lib/python3.11/threading.py'>
Traceback (most recent call last):
File "/usr/lib/python3.11/threading.py", line 1583, in _shutdown
lock.acquire()
File "/usr/share/playonlinux4/python/mainwindow.py", line 1114, in ForceClose
self.POLDie()
File "/usr/share/playonlinux4/python/mainwindow.py", line 1096, in POLDie
app.POLServer.closeServer()
^^^
NameError: name 'app' is not defined
That's an aur package. You have to rebuild it.
I rebuilt & re-installed it but it still isn't working. I get the same errors when running it from the CLI. Anyone have any suggestions?
Did a quick check myself and it seems to not work even on a fresh build. It looks like the app class comes from playonlinux itself so if that's not working; seems like an upstream bug to me.
This is a strange upstream bug as this works perfectly fine on Arch Linux but fails to work on Artix Linux. Systemd is not a working factor in PlayOnLinux working here, so I'm still not clear why this is now failing to work. This application worked fine before the python 3.11 upgrade on Artix and is still working perfectly fine on Arch Linux also with python 3.11.
Does this actually work on Arch with python 3.11? I gave this another try directly from git with commit d0ae9ce61668861dacd5c4981e7f3b020e3cc327 (from the PKGBUILD) and it gives this Traceback:
Just looks like an error in the python code to me?
wxPython doesn't work right with python 3.11, the only solution from the developer at this time is to downgrade python (https://github.com/wxWidgets/Phoenix/issues/2398#issuecomment-1564648605). If it still works on a fully upgraded Arch machine then I'm leaning toward calling that a coincidence, and I wouldn't expect it to last long if wxPython can't get up to speed.
It just doesn't make sense for all the same packages installed on Artix are also installed on Arch but PoL doesn't work on Artix anymore. It was all working well. Any other ideas?
Bump for any ideas on how to fix a still broken playonlinux4
It's an upstream issue. They need to support python 3.11. I just checked again and it still has the same error (directly from master) that I posted.
running this on a container or venv that provides the exact library versions might help to workaround this..