Alien Pastures

My thoughts on Slackware, life and everything

Tag: steam (Page 1 of 3)

Steam Client for Slackware updated to 1.0.0.76

March 19, 2023 / / 10 Comments

steam

A few weeks ago, Valve‘s official Linux binaries for its steamclient got an update. The 1.0.0.76 version is built using an updated Steam client:

  • Client timestamp 1676336721 (2023-02-14)
  • Steam Runtime version 0.20221019.0

The steamclient package which I create from this release tarball is meant to bootstrap the installation of Valve’s Steam gaming platform on your Slackware computer. The package installs a couple of scripts and a 32-bit Linux runtime based on Ubuntu, and adds a desktop menu entry so that you can easily start Steam.
When you first start ‘steam’ from the menu or from the X terminal command-line, the client scripts will download a larger set of runtime libraries, including 64-bit support. From then on, the steamclient will keep its runtime libraries up-to-date automatically, every time it starts up and connects to the Steam servers.
The Slackware package has a couple of tweaks because we obviously do not have all the expected Ubuntu tools on board. With the help of these tweaks, Steam works out of the box on Slackware – both 32bit and 64-bit with multilib!

If you are using Steam for gaming, be sure to check out its Slackware community. It’s not really chatty in there but last time I checked, the group listed over 400 Slackware users and there’s always a few online and playing.

Enjoy!
Eric

Steam client update, also fresh Wine, QEMU, MinGW-w64

December 28, 2021 / / 18 Comments

It was already a while ago that I refreshed my ‘steamclient‘ package for Slackware.

The steamclient package is meant to bootstrap the installation of Valve’s Steam gaming platform on your Slackware computer. The package installs a couple of scripts and a 32-bit Linux runtime based on Ubuntu. When you first start ‘steam’ from the menu or from the X terminal commandline, the client will download a larger set of runtime libraries, including 64-bit support. Onwards, the client will keep its runtime libraries up-to-date automatically, every time it starts up and connects to the Steam servers.
The Slackware package has a couple of tweaks because we obviously do not have Ubuntu tools on board. As a result, on Slackware-current (32bit and 64-bit with multilib) Steam works out of the box.

The reason for a package refresh is a recent bug report on Valve’s github, about an ALSA related crash on Slackware. The root cause was eventually found and it was part of the customization I added to the steam launcher 6 years ago when we were still on release 14.1 and we did not have pulseaudio as part of the Operating System.

So I removed (actually, commented-out) these lines, and that should fix the root cause for that bug. If you do not use Pulseaudio or want to enforce ALSA sound regardless, just un-comment the relevant lines at the top of the ‘/usr/bin/steam’ script again – it’s self-explanatory.
I have also refreshed the READMEs for Slackware and additionally removed support for all Slackware versions older than 14.2. To be realistic, I assume that gamers are all on the -current platform already.

NOTE:
If you have an older ‘steamclient’ package installed on 64bit Slackware and use the slackpkg+ extension to manage 3rd-party repositories, you need to un-install the old steamclient package first. The old packages have a ‘i386’ architecture tag whereas the new one has a ‘i386’ architecture tag for the 32bit Slackware, and a x86_64 tag for use on 64bit Slackware.
They are the same package actually but I was asked to make ‘steamclient’ installable via slackpkg/slackpkg+ also on 64bit Slackware. So:

# removepkg steamclient
# slackpkg update
# slackpkg install steamclient

Have fun playing games on Steam!

Some other recent package updates in my Slackware-current repository are:

Wine: we’re up to version 6.23 now. The 32bit wine package is just that – 32bit Wine. My 64bit wine package contains both 64bit Wine and the 32bit WoW64 (Wine on Wine64). Both have the ‘staging‘ patches applied.
The external dependencies for this package remain the same: FAudio and vkd3d are required. On 64bit Slackware you need to have multilib installed. In addition to multilib, you need to convert the 32bit versions of the FAudio and vkd3d packages to ‘compat32’ packages and install those.

MinGW-w64: I have updated this package to v9.0.0_gcc11.2.0. Mingw-w64 is based on the original mingw.org project (which was created to support the GCC compiler on Windows systems), particularly adding 64-bit support.

The MinGW compiler suite is used to generate the native Windows DLLs in the wine package.

The QEMU machine emulator and virtualizer got a refresh because I am preparing (fingers crossed!) for a release of Slackware 15.0 which according to an online statement could happen soon after New Year 2022.
I run Slackware Virtual Machines (VMs) in QEMU and I wanted to take advantage of the newest QEMU features. At the moment my VM host is Slackware 14.2 and that has a fairly old QEMU package installed. The VM host will get an upgrade to Slackware 15.0 as soon as the new release is made available.
Dependencies for my qemu package are: vde (historically for non-root network bridge support) and as of now also: device-tree-compiler, jack2 (note that jack2 has its own sub-dependencies!) and virglrenderer.

Have fun with these during the holiday break, and I wish you all a Happy New Year.

MS Windows on Linux: wine and MinGW-w64

September 28, 2020 / / 48 Comments

 

I came across two separate discussions on LinuxQuestions.org that had a common root cause; a lack of Windows VST support in Carla and missing PE binary support in Wine causing Windows games to fail on Slackware.
They made me think about how I could help fix the core issue, which is that both SlackBuilds.org and Slackware 3rd party repositories (like mine) do not offer MinGW packages or scripts. To address the issue I needed to create a MinGW-w64 package, which is what I did. More on that, further down.

Back to the issue at hand and their common root cause.

Starting with Wine 5.x, the developers added support for compiling wine’s Windows programs and DLLs into Microsoft PE (portable executable) format instead of building them as Linux ELF binaries. This has advantages, one of the more obvious ones adding compatibility with some copy protection schemes in Windows games.
However with wine-5.12 and newer, it appears that the PE binary format is now a requirement for some modern Windows-based games that you can play in Wine on Linux. Diablo III, World of Warcraft and others are mentioned in the relevant bug report.

This meant that I needed to do something if I ever wanted to update my own Slackware package for wine to a newer version than the 5.6 I had in my repository. Apparently to compile binaries into native MS Windows PE format, you need MinGW, the “Minimalist GNU for Windows“. In fact, I needed MinGW-w64 whichs is a fork made in 2007 of the original MinGW which adds 64bit Windows support and a lot of other enhancements, and is actively developed. Since this is not available for Slackware as a package or SlackBuild yet, I needed to come up with my own version.

The LQ thread mentions an OS-agnostic project from developer ‘Tk-Glitch’ called  “(Mostly) Portable GCC/MinGW” which people used successfully to obtain a working MinGW compiler on Slackware. Since I was completely clueless about MinGW I started with that script, and for me indeed it built a MinGW compiler suite with support tools. Alas, the script was only meant for 64bit OS-es and of course it was not a proper SlackBuild script. So I used the project as inspiration (like, I used the script’s flow and logic) to write a SlackBuild script that would also work on 32bit Slackware.
The result is that I now have MinGW-w64 packages in my repository for Slackware-current as well as 14.2 (32bit and 64bit). The package installs a profile script to “/etc/profile.d/” which adds the MinGW binaries to your $PATH environment variable. On 64bit Slackware you will get both the MinGW programs that create 64bit Windows PE binaries (x64_64-w64-ming32-*) and those that create 32bit Windows PE binaries (i686-w64-mingw32-*). While on 32bit Slackware you will get programs that create 32bit Windows PE binaries (i586-w64-mingw32-*).

Having a MinGW-w64 package finally enabled me to compile the newest wine (enhanced with the wine-staging patch set) properly.
Since the MinGW compilers are in the $PATH, the wine-build will automatically use those where needed, no change to the SlackBuild was required. The result is a wine-5.17wine-5.18 package which has grown considerably in size due to the addition of PE binaries. I hope this package will enable you gamers to play your favorite game again.
Note that I have added new dependencies to the wine package for Slackware-current. In order to improve DirectX sound support you need FAudio.  For Direct3D 12 support, wine additionally depends on vkd3d. You’ll have to install those from my repository as well.
Both FAudio and vkd3d fail to compile on Slackware 14.2, due to a lack of Vulkan library support and outdated other libraries such as Gstreamer, so the wine package for Slackware 14.2 was built without them (but it does need OpenAL as a dependency there. This got added to slackware-current as ‘openal-soft’).

And then there was Carla, the subject of that other LQ thread.
Carla is an audio plugin host; it is contained in my Slackware Live DAW project. It supports a lot of plugin formats, like LADSPA, DSSI, LV2, VST2, VST3 and more. It turned out that my Slackware package for Carla did not support Windows VST plugins. VST is mostly used on Windows, VST is a proprietary format from Steinberg which requires a licence from them to create or host a plugin. The VST3 source code is placed under a GPL3 license; however you still need written agreement from Steinberg if you want to distribute a plugin. Nevertheless, if you are a mucisian and purchased a VST plugin then Carla needs some additional work to use that Windows VST plugin.
Again, MinGW-w64 (and wine) were needed to expand the capabilities of my carla package. Luckily, a new version of Carla was released yesterday so I could apply my newfound knowledge immediately. The new carla-2.2.0 package supports Windows VST’s. Go get it.

For the techies:
Note the different architecture used in the names of the MinGW 32bit binary compilers: “i686” on Slackware64 and “i586” on Slackware. On 64bit Slackware I compile a new gcc, binutils and all the libraries they need first, and use them as a bootstrap for compiling MinGW-w64. That is why I could switch away from Slackware’s “i586” to a new “i686” architecture target, and in principle I can use a different version of GCC than the one shipped with Slackware. On the Slackware 32bit OS I was unable to compile this “bootstrap GCC” so I needed to stick to the version of GCC which is present on Slackware and use that to compile MinGW-w64.
If someone feels adventurous and has a lot of free time, the issue on 32bit Slackware is that after I compile various support libraries, then binutils and then gcc, I can not complete the gcc compilation because it ends prematurely with an error “/tmp/build/mingw_gcc_bootstrap/bin/ld: cannot find -lc“. Apparently the linker does not search /lib or /usr/lib for whatever reason. If I add symlinks for libc into “/tmp/build/mingw_gcc_bootstrap/lib/” then I get a little further in the process, but then the same happens for -lm”. Etcetera. I do not have this issue on 64bit Slackware where I use my multilib version of gcc packages… no idea whether that makes the difference. So in 32bit Slackware I just skip compiling my own GCC and move immediately to compiling MinGW. Suggestions are welcome and appreciated.

Have fun with this! Eric

Note: I used one of Dave Gauer’s logos for MinGW-w64 to decorate this blog page.

LibreOffice 5.0.3 and new steamclient

November 20, 2015 / / 20 Comments

libreoffce_logoTwo weeks ago, a new version of LibreOffice 5 became available. On their blog the Document Foundation mentioned that apart from version 5.0.3 there has been a (final?) release in the 4.x series: 4.4.6 sources were made available as well. I will find time to compile 4.4.6 for Slackware 14.1 soon, since there are security fixes too, but there were more pressing matters to attend to, and therefore I limited myself to the new 5.x release for the moment.

This is what the Document Foundation wrote about the two versions: “LibreOffice 5.0.3 is more feature-rich, and as such is targeted to tech enthusiasts and power users, and LibreOffice 4.4.6 is targeted to more conservative users and enterprise deployments as it has been in widespread use for a longer time, and as such offers a better experience for document production”

The new LibreOffice 5.0.3 packages have been compiled for users of Slackware-current only. The 4.4.5 packages that I have for Slackware 14.1 should also work on -current, but I have not tested that. I hope that this package for LibreOffice 5.0.3 survives the day… Pat is planning another (possibly intrusive) update to slackware-current which may break the package.

LO_5.0.3

The package was yet again compiled against gstreamer-1.x, so I would like to hear if the issues that were reported about embedded multimedia files are still there.

steam

Then there was a new release of Valve‘s steamclient. The changes are minor – adding udev support for new controllers. And anyway, your Steam run-time gets updated automatically anyway when you go online. The package is useful when installing the Slackware OS from scratch so I provide the updated package in my repository. Remember people, there is a Slackware community on Steam too! And no, I do not want to hear the moaning about a closed-source platform. Valve does more for Open Source and Linux in general than many other game companies.

Get your packages from any of these sites (there are probably more mirrors than these but I am unaware of them):

Cheers! Eric

SteamOS is out – based on Debian, not Ubuntu

December 14, 2013 / / 7 Comments

steamos

The release of SteamOS was right on time, as promised by Valve. SteamOS is an Operating System designed to play your (Steam) games on a TV. The accompanying “Steam Box“, which will be running the SteamOS and which is supposed to be a hardware platform as open as the Operating System designed for it, is still in Beta but 300 prototype devices (running the SteamOS) have been sent to eager testers together with a purpose-built Steam Controller.

Apparently the Steam Box will also allow you to play your games on your regular (Windows?) computer and “stream” the game’s display to the TV connected to the Steam Box (or any homebrew computer running SteamOS). I don’t know if that will deliver a perfect gaming experience (PC and TV must be close to each other) but I guess that this is how Windows users can still profit from the Steam Box (since it runs a Linux OS, Windows games are out of the question).

You can already download the slightly less than one gigabyte large archive of the OS. It is still a beta release, so not advised for “inexperienced Linux users”. Well, we Slackers do not fall into that category.

From the SteamOS FAQ:

Q: What is SteamOS?
SteamOS is a fork (derivative) of Debian GNU/Linux. The first version (SteamOS 1.0) is called ‘alchemist’ and it is based on the Debian ‘wheezy’ (stable 7.1) distribution.

The major changes made in SteamOS are:

  • Backported eglibc 2.17 from Debian testing
  • Added various third-party drivers and updated graphics stack (Intel and AMD graphics support still being worked on)
  • Updated kernel tracking the 3.10 longterm branch (currently 3.10.11)
  • Custom graphics compositor designed to provide a seamless transition between Steam, its games and the SteamOS system overlay
  • Configured to auto-update from the Valve SteamOS repositories

I think it is a positive message to all Open Source fans that Debian has been chosen as the base for SteamOS and not Ubuntu, which was the initial target for the Linux Steam Client. I have been watching the threads discussing issues with Steam on Ubuntu and was always glad that running Steam on Slackware was so much easier 🙂

I downloaded the OS image and despite online warnings that the download server was overloaded, it arrived at  6.5 MB/sec which is the maximum bandwith of my own Internet link. I have not yet tried it, but somewhere this week I will certainly dress up a Virtual Machine to see what it looks like. I wonder what will happen, as SteamOS expects Nvidia graphics hardware to be present, although the FAQ mentions “(AMD and Intel graphics support coming soon)“.

Exciting times for Linux gamers.  Ever since Gabe Newell’s public statement at LinuxCon 2013 that the future of gaming was on Linux, not on Windows, his company has been porting Steam games to Linux at a frantic pace, with other Open Source software profiting from their efforts (LLVM, X.Org drivers are examples). A year before that speech, Gabe Newell already called Windows 8 “a catastrophe” at a videogame conference in Seattle. Valve, a big thumbs up!

Eric

« Older posts

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑