Trying to run the VoVT Lutris install Script will cause it to get stuck at the extraction step of the 7zip archive while the logs are getting spammed with lutris[753082]: 2025-11-01 16:24:19,958: Starting Lutris 0.5.19 as well as the available gpu's. This will keep going without any progress beeing made until the user manually stops the process. Reproducible: Always Steps to Reproduce: 1.Search Voices of the Void lutris script in lutris 2.go trough the prompts to install Voices of the Void 3.When you reach the extraction step of the archive check logs and wait no progress will be made Actual Results: Installer will be stuck at the extraction step with no indication that it has even started to extract the files from the archive. Expected Results: Extraction step should go for about a minute or 2 and then move on the the setup of the wine prefix Modified: Extra Details: This issue only happens in the fedora native package the flatpak works fine.
Hi aspacegamer, Thanks for the report. This seems to be an upstream issue, probably with the script for voices of the void. Please file your bug report there, we cannot fix this.
(In reply to Chris King from comment #1) > Hi aspacegamer, > > Thanks for the report. This seems to be an upstream issue, probably with the > script for voices of the void. > > Please file your bug report there, we cannot fix this. Sorry i have forgotten to mention in the inital bugreport that this issue only appears in the native lutris package in the fedora repository not in the flatpak version of lutris.
I think this is due to Fedora 43 shipping Python 3.14 and this now defaulting to "forkserver" instead of "fork". So this probably does not affect the Flatpak version that would use an older version of Python. Not sure how that's causing the issue though. It looks like all the newly started processes run "LutrisApplication::do_command_line()" and then exit before running the command they were spawned to run. Then the next attempt is started, and so on... I was able to work around this by adding this code to "/usr/bin/lutris" to force using "fork" again: import multiprocessing multiprocessing.set_start_method('fork')
(In reply to Sebastian Keller from comment #3) > I think this is due to Fedora 43 shipping Python 3.14 and this now > defaulting to "forkserver" instead of "fork". So this probably does not > affect the Flatpak version that would use an older version of Python. Not > sure how that's causing the issue though. It looks like all the newly > started processes run "LutrisApplication::do_command_line()" and then exit > before running the command they were spawned to run. Then the next attempt > is started, and so on... > > I was able to work around this by adding this code to "/usr/bin/lutris" to > force using "fork" again: > > import multiprocessing > multiprocessing.set_start_method('fork') that worked yeah
(In reply to Sebastian Keller from comment #3) > I think this is due to Fedora 43 shipping Python 3.14 and this now > defaulting to "forkserver" instead of "fork". So this probably does not > affect the Flatpak version that would use an older version of Python. Not > sure how that's causing the issue though. It looks like all the newly > started processes run "LutrisApplication::do_command_line()" and then exit > before running the command they were spawned to run. Then the next attempt > is started, and so on... > > I was able to work around this by adding this code to "/usr/bin/lutris" to > force using "fork" again: > > import multiprocessing > multiprocessing.set_start_method('fork') tbh this sound like something that probably should be fixed upstream sadly upstream has locked their issue tracker down to only contributors. After all it shouldn't effect the lutris client with older python version to just set the methode to fork since thats the default there anyways.
(In reply to aspacegamer from comment #5) > (In reply to Sebastian Keller from comment #3) > > I think this is due to Fedora 43 shipping Python 3.14 and this now > > defaulting to "forkserver" instead of "fork". So this probably does not > > affect the Flatpak version that would use an older version of Python. Not > > sure how that's causing the issue though. It looks like all the newly > > started processes run "LutrisApplication::do_command_line()" and then exit > > before running the command they were spawned to run. Then the next attempt > > is started, and so on... > > > > I was able to work around this by adding this code to "/usr/bin/lutris" to > > force using "fork" again: > > > > import multiprocessing > > multiprocessing.set_start_method('fork') > > tbh this sound like something that probably should be fixed upstream sadly > upstream has locked their issue tracker down to only contributors. > After all it shouldn't effect the lutris client with older python version to > just set the methode to fork since thats the default there anyways. nevermind i was now able to open the issue https://github.com/lutris/lutris/issues/6213
(In reply to Sebastian Keller from comment #3) > I think this is due to Fedora 43 shipping Python 3.14 and this now > defaulting to "forkserver" instead of "fork". So this probably does not > affect the Flatpak version that would use an older version of Python. Not > sure how that's causing the issue though. It looks like all the newly > started processes run "LutrisApplication::do_command_line()" and then exit > before running the command they were spawned to run. Then the next attempt > is started, and so on... > > I was able to work around this by adding this code to "/usr/bin/lutris" to > force using "fork" again: > > import multiprocessing > multiprocessing.set_start_method('fork') Change has been merged in upstream https://github.com/lutris/lutris/commit/4cef2407288fd0219eba684c7b24451eeaf35fef
It would still be good to have a downstream backport of the fix.
I pushed the fix to rawhide, but it's super late for me. I'll push it to F43/F42 tomorrow and link this bug.