-
-
Notifications
You must be signed in to change notification settings - Fork 473
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Games won't run (seems to hang) but launch command works directly in shell #4273
Comments
Continuing to look, the hanging process is via |
I built my own umu-launcher and had the one Heroic downloads point to that instead. Same result (hanging Unfortunately I don't know JS/TS to really dig into what is happening here, but my guess is something about how the game run command is launched has some subtle issue in a container. Not very useful, but I don't have anything else to go on and have run out of idea on how to debug this without some more expertise from someone here. |
Success! Emerging from that deep debug/trial and error hole with a relatively simple change, though the "why" I'm not quite sure on. The punchline: what worked for me was to add But this is confusing: as far as I can see My guess is that perhaps this path is handled specially by |
TL;DR: Not a (direct) Heroic issues; keep The real issue was sort of the opposite I was saying above: it is that We (nonguix) were overriding The fix is to keep Pretty simple in the end! And I guess nothing particular to Heroic, at least nothing outside of what seems to be typical for Electron/Chromium apps. However, let me note that this is a real issue for source packaging with things like node/electron that want to download or bundle libraries and make it hard/impossible to properly build from bootstrapped sources (and they are not alone, other ecosystems too). I'll leave this open for a bit in case this is useful to anyone (things like |
To close this out, and for future reference in case it helps anyone (or myself again): tracked this one also in nonguix at https://gitlab.com/nonguix/nonguix/-/issues/369 with the fix being in https://gitlab.com/nonguix/nonguix/-/merge_requests/617 |
Describe the bug
Something is different between running a game from within the Heroic GUI and using the same command in the shell. The first doesn't work while the second does. This is likely peculiar to my (rare) setup of running on GNU Guix where Heroic runs in a container so that it has a more "typical" Linux environment (in brief, in Guix
/lib, /bin
etc. doesn't exist, like NixOS). Things seem fine in Flatpak on the same system.I've been beating my head against the wall trying all sorts of different stuff, having managed to find the original regression (games with Proton and Steam Runtime worked before) from commits after 2.12.2, namely I think 4770278 (part of #3020). I do have a local setup to build Heroic to test. However, I think that was a red herring, as what worked was for using the old (I presume)
run
entry for the Steam Runtime and I see Heroic now will default to umu. There is some difference betweenrun
and_v2-entry-point
which is non-obvious and I couldn't figure it out and seems to be outdated for upcoming Heroic versions.Some notes:
PRESSURE_VESSEL_SHELL=instead
to get an xterm didn't help either (same seeming hang as in Heroic, environment variables all look the same)So...what could possibly be different in how Heroic executes the launch command? I know this is tricky as the multiple layers with having Heroic in a container make it difficult to see exactly what is happening (I spent a long time debugging and trying to understand this for Steam, which I'm happy to say works great in Guix now).
Sorry if this is hard to follow, but really looking for any insights from the experts here...any ideas?
Add logs
(apologies for the formatting, looks like enabling umu log adds console color codes)
Steps to reproduce
Expected behavior
Game should run from the GUI
Screenshots
No response
Heroic Version
main branch from GitHub
System Information
GNU Guix
Heroic runs in a container, like our Steam package (and as in Flatpak or NixOS) which does complicate things...
Additional information
No response
The text was updated successfully, but these errors were encountered: