Bug 244207
| Summary: | [NEW PORT] games/linux-steam-utils: Linux Steam scripts/workarounds | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Alex S <iwtcex> | ||||||||||||||
| Component: | Individual Port(s) | Assignee: | Dave Cottlehuber <dch> | ||||||||||||||
| Status: | Closed FIXED | ||||||||||||||||
| Severity: | Affects Only Me | CC: | darkfiberiru, dch, dmenelkir, monwarez, pi, rhurlin, salvadore, shadow53+freebsd | ||||||||||||||
| Priority: | --- | ||||||||||||||||
| Version: | Latest | ||||||||||||||||
| Hardware: | Any | ||||||||||||||||
| OS: | Any | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
Created attachment 211734 [details]
steam-utils.log
`synth test` log
By the way, it would be nice to state somewhere this is not an official Valve script, but I really can't decide where to put that. On the other hand, it should be quite obvious anyway, so maybe not. Any suggestions are appreciated. Thanks Alex. I would say the install message would be a good place for a disclaimer that this is an unofficial utility incase someone doesn't read the package description. Created attachment 211757 [details]
steam-utils.patch v2
+ disclaimer
- symlink warning
(In reply to Nick Wolff from comment #3) > I would say the install message would be a good place for a disclaimer I'm quite convinced the target audience for this port doesn't habitually read those messages... We'll see how it goes. Created attachment 211855 [details]
steam-utils.patch v3
steam-utils -> linux-steam-utils, USES=linux
Created attachment 211856 [details]
linux-steam-utils.log
`synth test` log
testbuilds@work testbuilds look fine. Can someone report if run-tests are fine ? Created attachment 212080 [details]
steam-utils.patch v4
Fixed a few mildly embarrassing things.
Regarding the mailing list question: > can someone do some run-tests That would be nice indeed. I think vaguely remember CC'ing someone... FWIW, there is a corresponding forum thread @ https://forums.freebsd.org/threads/steamuxulation-redux.72140/. No, there is practically zero chance somebody there could be convinced to specifically test the port. That's just the way it is. > and explain how to use that port ? It's precisely what the readme/pkg-message says: run `steam-install` script (to download and install Steam into a user home directory), run `steam` script. After that you should be able to log in and use the game library UI. It's assumed, but not explicitly mentioned, that you already have a Steam account and that OpenGL under Linuxulator is properly set up. (In reply to Alex S from comment #11) I'm coming up onto finals week at the moment, but once that is over I can take a look at testing this port. I've got 114 games in my library, most of which have Linux versions I can test. Are there any that I should specifically check? (My games list is at https://steamcommunity.com/id/shad0w0710/games/?tab=all if that helps with suggestions) (In reply to shadow53+freebsd from comment #12) > I've got 114 games in my library, most of which have Linux versions I can test. > Are there any that I should specifically check? Whatever you want to check. Let me know if anything actually runs (or not). So, is there anything I *personally* can do to move this forward? That is, something not involving waiting indefinitely for other people. Ok, enough is enough. This certainly was quite enlightening. taking this taking this as frankly its amazing. Rumours of netflix working in the game browser should be enough to pique more peoples' interest... Kurt are you ok with the patch as is, or do you see the need for further tweaks and changes? I can test this later in the weekend with steam. I'm very fine with the patch, we just need run-tests. (In reply to Dave Cottlehuber from comment #17) > taking this Don't miss the latest commit. > Rumours of netflix working in the game browser should be enough to pique more peoples' interest... Nah, existing FreeBSD users has been self-selecting for years to the point most of them consider the absence of those things a part of their identity. Steam/Widevine/CUDA would be valuable for getting attention of people with some interest in FreeBSD, who are currently using a Linux/Windows desktop. (Which is precisely the crowd who won't test this port.) I'm not particularly optimistic, but at least it's worth a try. The port build fine, steam is launching, the store is loading. One feature that I miss is the possibility to run steam with optirun (the port https://reviews.freebsd.org/D22521 ). (In reply to Thibault Payet from comment #20) > One feature that I miss is the possibility to run steam with optirun (the port https://reviews.freebsd.org/D22521). You would have to ask Theron for Linux executable support. (In reply to Alex S from comment #21) It is steam that I cannot run with nvrun-vgl, I can run outside steam a linux game with the nvidia driver via a linux VirtualGL wrapper. The steam wrapper seems to clear the LD_LIBRARY_PATH in some ways. (In reply to Thibault Payet from comment #22) > I can run outside steam a linux game > with the nvidia driver via a linux VirtualGL wrapper. Is this actually available somewhere? > The steam wrapper seems to clear the LD_LIBRARY_PATH in some ways. Yes, quite intentionally so. We have to account for the three separate LD_LIBRARY_PATH environment variables: one for the native FreeBSD environment, one for the Steam client and another one for games. There is no way to make this arbitrary stackable with other wrapper scripts. (In reply to Alex S from comment #23) >> I can run outside steam a linux game >> with the nvidia driver via a linux VirtualGL wrapper. >Is this actually available somewhere? There is no place where this is documented, what I do is simply to download virtualgl (and turbojpeg) for centos7, extract it in a directory and then running my linux executable with : env LD_LIBRARY_PATH=path_to_linux_virtualgl_lib64 path_to_linux_virtualgl_bin/vglrun -gl -d :8 some_linux_program using the nvidia-hybrid-graphics port . >Yes, quite intentionally so. We have to account for the three separate >LD_LIBRARY_PATH environment variables: one for the native FreeBSD environment, >one for the Steam client and another one for games. There is no way to make this >arbitrary stackable with other wrapper scripts. Wouldn't it be possible to have a special environment variable that will be append to each LD_LIBRARY_PATH ? (In reply to Thibault Payet from comment #24) > Wouldn't it be possible to have a special environment variable that will be append to each LD_LIBRARY_PATH? It is possible, but since I don't have a compelling use case for that, I didn't bother. Try it and see how it goes. this works very nicely; there are of course many warnings and errors spat out during run time but it's a fantastic piece of hackery :-) tested with XCOM2 as it's the only thing I have in steam. Many thanks Alex! Kurt are you ok if I commit this? I would appreciate a version bump to 20200404. It has one trivial change (a workaround for inaccessible /compat/linux/proc/self/fd which is an issue with at least NomadBSD), it doesn't need retesting in my opinion. (In reply to Dave Cottlehuber from comment #26) Of course I'm absolutly fine with you committing it 8-} A commit references this bug: Author: dch Date: Sun Apr 19 10:57:33 UTC 2020 New revision: 532102 URL: https://svnweb.freebsd.org/changeset/ports/532102 Log: games/linux-steam-utils: new port PR: 244207 Submitted by: Alex S <iwtcex@gmail.com> Reviewed by: pi Differential Revision: https://reviews.freebsd.org/D24501 Changes: head/games/Makefile head/games/linux-steam-utils/ head/games/linux-steam-utils/Makefile head/games/linux-steam-utils/distinfo head/games/linux-steam-utils/pkg-descr head/games/linux-steam-utils/pkg-message head/games/linux-steam-utils/pkg-plist updated to 202020404 as requested, poudriere build passes on x86_64 for 12.1R and 13-0.CURRENT. |
Created attachment 211733 [details] steam-utils.port I've been asked about it twice, so here is a port for my Linux Steam scripts/workarounds. These scripts make installing Steam on FreeBSD considerably less difficult. To be honest, the result is still kind of underwhelming, especially for people expecting to run actual games and not just stare at the game library UI. Still, this is a considerable improvement upon previous attempts.