Solved Steam on FreeBSD

Trying to get Steam running on FreeBSD 14-Current I have tried linuxulator to no success loads to a black screen as well as wine. wine-devel doesn't work for me at all and complains about CPU Architecture is unkown which is strange cause the regular wine package which is much older doesn't complain. I have a 7950x for context. I was thinking of trying to build the wine repo from source however I'm wondering if I'm just wasting my time as FreeBSD also requires pkg32 script to have the same version installed. Do any of you guys have steam working at the moment? I like to play this one game Hearts of Iron with mods from the Steam workshop so downloading the game itself doesn't work in this case sadly as I won't have the mods selection.
 
Getting steam to run under FreeBSD is still something on my todo list. As such, I can't provide anything related to experience.

shkhln is our steam guy. He made games/linux-steam-utils. Did you try that?
Thanks I did try this earlier a few weeks back I just tried it again right now and no more black screen! Strange when run in wine its a black screen for login for me though. Thanks for the help!
 
Trying to get Steam running on FreeBSD 14-Current I have tried linuxulator to no success loads to a black screen as well as wine. wine-devel doesn't work for me at all and complains about CPU Architecture is unkown which is strange cause the regular wine package which is much older doesn't complain. I have a 7950x for context. I was thinking of trying to build the wine repo from source however I'm wondering if I'm just wasting my time as FreeBSD also requires pkg32 script to have the same version installed. Do any of you guys have steam working at the moment? I like to play this one game Hearts of Iron with mods from the Steam workshop so downloading the game itself doesn't work in this case sadly as I won't have the mods selection.
Did you tried with a supported release instead of 14-CURRENT?
 
That may be best answered by the OP however, wouldn't tracking -CURRENT with quarterly packages (instead of ports) be a bit "dearing"?
CURRENT doesn't have quarterly packages, I assumed OP upgraded after testing Linux Steam. If that's not true, then configured misconfigured dbus is the most likely reason for this.
 
Precisely! I hope this is as clear to the OP considering Best way to manage ports?

TheDantee, have you tried 13-STABLE with your specific hardware (intel 2.5GB, AMD RX6600 & 7950x)?
My responses have to await approval for some reason so I apologize for the delayed responses. Yes I have tried my hardware on 13-STABLE The hardware works on OpenBSD's stable out of the box I figured BSD worked together more on driver support but I guess not.
 
Shouldn't current be on the most up to date versions of the packages?
No. Ports are the same to all versions, -CURRENT is a (unsupported) development branch, very unstable and filled with debug options that will be way slower than any release or stable available.
 
I'd imagine this has more to do with OP using quarterly packages. Those tend to be broken more often due to "only security patches" maintenance focus clashing with Steam's frequent updates. I actually expect another quarterly breakage very soon: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269089.
Proton doesn't launch any games crashes instantly for me same with native linux games any ideas? The console just shows cannot run pv-bwrap as well as LD_PRELOAD cannot be preloaded but it says this is ignored so I assume this isn't my issue.
 
That's simply not true.
And you simply don't know what you're talking about. It's the nature of CURRENT being unstable, because it's a development branch, and some things can be untested and slower of any release because the debug facilities such as WITNESS. CURRENT is only supposed to be used by people helping the development because it's pretty much a test environment.
 
And you simply don't know what you're talking about.
Wrong.
It's the nature of CURRENT being unstable
Again wrong (if we are not talking about API stability).
slower of any release because the debug facilities such as WITNESS
Wasn't arguing with that, but it can be turned using single sysctl command.
CURRENT is only supposed to be used by people helping the development because it's pretty much a test environment.
This has nothing to do with "very unstable" assertion.
 
Wrong.

Again wrong (if we are not talking about API stability).

Wasn't arguing with that, but it can be turned using single sysctl command.

This has nothing to do with "very unstable" assertion.
 
Guys, let's not get sidetracked from the threads topic.
Feel free to discuss your disagreements elsewhere, of course.
 
It is irrelevant how stable -CURRENT is right now. It's an unsupported version here on the forums.

  • All communication about -CURRENT should take place on the freebsd-current mailing list, not on the forums. There are very few developers on the forums, and the amount of 'regular users' routinely running -CURRENT who are willing and able to lend support is likely in the single digits. If you want support on these forums, run either a supported version of the -RELEASE branch (for proven, stable, solid installations) or of the -STABLE branch (a slightly more experimental, but still very stable version that incorporates some of the newer developments of the -CURRENT branch).
  • You should really only install -CURRENT if you're prepared to participate in fact-finding and troubleshooting sessions with the FreeBSD developers on the freebsd-current mailing list. The forums lack the knowledge and resources to answer in-depth questions about new developments and their ramifications.
 
It's probably not a Steam issue, games/linux-steam-utils runs well enough on my 13-STABLE to install and play Alien: Isolation (the only game I tested so far). I use x11/nvidia-driver for my RTX-3080 though.

Shouldn't current be on the most up to date versions of the packages?
There is only one ports tree. All versions and all architectures use one and the same ports tree. So there is no difference in port/package versions. This is quite different from various Linux distributions where third party software versions depend on the version of the distribution.
 
There is only one ports tree. All versions and all architectures use one and the same ports tree. So there is no difference in port/package versions.
When a port has "package support" in the sense that package builds are generated for that port, how are builds triggered?

Is that solely based on an update of a port in the ports source tree or is there also a deliberate scheduled time delay involved (in addition to just the time to churn through the build servers)? Is there a difference between tier-1 supported architectures and others? For example for amd64 as a tier-1 supported architecture, what could one expect in practical terms of time delay between an update of a port at the tip of the ports source tree and its availability as a package?
 
Back
Top