ASPENSMONSTER Just another WordPress site

January 19, 2013

Updated Procedures for Installing Steam for Linux Beta on Debian GNU/Linux (Testing/Wheezy)

Filed under: Uncategorized — aspensmonster @ 10:24 pm

Flattr this!

The steam beta’s packaging scheme appears to have been shifting quite a bit since my guide to installing the deb package. I first ran into these troubles with a fresh install of on a separate machine that functioned with the previous guide, but had annoying update prompts complaining about missing packages. Curious, I checked my install and tried upgrading. The release gave me the impression that it updated –and I could still play Team Fortress 2– but comparing the file structure between and showed a few differences and some additional python scripts among other things.

Consequently, I decided to document how to perform a clean install from a based installation to the current latest release of by completely uninstalling the old version. What follows borrows heavily from my previous guide where appropriate, but documents some of the changes that have occurred since then. I summarize any relevant changes to each section from the previous guide with bold blue text.

0: Prerequisites

This section has not changed from the previous guide. Multiarch is still needed as well as 32-bit GL libraries.

Multiarch Support

Debian guide to multiarch here:

Multiarch is a necessity to install steam on a 64 bit system. This is my own drunk history of sorts on the matter as understood from someone on the sidelines.

Over the years, the multiarch implementation has grown and evolved. For the longest time, a 64 bit user’s only hope of running 32 bit binaries was that all of necessary compiled 32 bit libraries happened to reside in the ia32-libs meta package, a collection that grew ever more monstrous. If you wanted to compile 32 bit software yourself your options were to do a fully isolated chroot or wrestle with one of many paths like /lib, /lib64, /lib32, and a host of other annoying issues from a lack of standardization across static and dynamic linkers. As of Wheezy, this monster was deprecated. A decision was made –I believe– to settle on “/lib/i386-linux-gnu/” for a unified path for all i386 libraries and headers when i386 is the “foreign” architecture to the host. But that’s not the best part.

As well, one can have libraries and headers for multiple architectures (though the guide referenced above is careful to point out that you are really targeting the ABI of various architectures, not the actual instruction set). The idea is that you could have the 64-bit-based amd64 library for libcurl3-gnutls AND the 32-bit-based i386 library for libcurl3-gnutls installed at the same time. This way, your 32 bit binaries can access the 32 bit libraries, and your 64-bit binaries the 64-bit libraries. Support is not yet implmented for having multiple architectures for the same binary however. That is, you couldn’t install both steam 32 bit AND steam 64 bit. You need to pick on or the other, as the standard path for binaries is –iirc– /usr/bin, with no indication or allowance made to have /usr/bin/steam (32 bit) be recognizable from /usr/bin/steam (64 bit).

If you haven’t already, you’ll need to make the plunge.

First, verify that you are indeed running on a 64 bit architecture:

$ dpkg --print-architecture

Here, amd64 is the default architecture. If you’re on a 32 bit architecture already, then you’ve got nothing to worry about regarding multiarch! Next, see if you’ve already got multiarch enabled for i386 (32 bit) assuming it’s not your primary architecture:

$ dpkg --print-foreign-architectures

Assuming you don’t, add it and update.

# dpkg --add-architecture i386
# apt-get update

I believe this automatically updates sources.list. But double check. If it doesn’t, then you need to modify your sources.list as well. Not much has changed. Just syntax differences to show the different architectures you want to install from.

deb [arch=amd64,i386] testing main contrib non-free
deb-src testing main contrib non-free

deb [arch=amd64,i386] testing/updates main contrib non-free
deb-src testing/updates main contrib non-free

At this point, you can install –or a package could theoretically grab– a 32-bit dependency. It is done with this syntax:

apt-get install package:architecture

An example would be

apt-get install libcurl3-gnutls:i386

32-bit OpenGL libraries

I am not familiar with Debian’s package management for the proprietary drivers for Nvidia or ATI. I choose to reinstall based off of nvidia’s *.run script every time I need to upgrade. A slight hassle, sure, but it’s NEVER given me problems after an upgrade. I can’t say the same for package management of Nvidia’s drivers.

Regardless, the important part of your installation is that, when prompted whether you wish to install the OpenGL 32 bit compatibility libraries, say YES. Otherwise, I don’t think you’ll be able to run the Steam client. You’ll probably get some error regarding relating to the OpenGL libraries.

0.5: Completely Uninstalling a Previous Installation of Steam

This is a NEW section. If you have never previously had a successful installation of the steam package, then you can (probably) ignore this section. If you’re upgrading… as stated in the intro, I distrusted whether I had a clean upgrade from to and as such performed a completely clean install for writing this guide. If you don’t want to do a clean install, you’re on your own. But don’t worry, I did back up the textures so you shouldn’t have to wait forever to redownload them.

First things first is to remove and purge the package:

# apt-get --purge remove steam

However, this typically does not remove all of the relevant files. My initial attempts at reinstalling a newer steam package after purging the old left me with doubts as to whether I genuinely had the latest steam files; a clean install of on a laptop of mine had several different files then the supposed “upgrade” I performed on my desktop. Consequently, I went through the process of manually purging old files.

Back up game textures

Game textures take up most of the space from an installation of steam. As you install games, gigabytes of textures get downloaded as well. I didn’t want to have to do that again, and so backed up my SteamApps directory so that I could replace the textures without waiting all day for them to download again:

$ cd ~/
$ mkdir steamapps-backup
$ cd ~/.local/share/Steam
$ mv SteamApps/ ~/steamapps-backup/

Purge all installed files

At this point I needed to find the various places that steam had installed files. Indeed, the whole point of a package manager is that we shouldn’t have to do this, but it IS still a beta release. I did the following to find stuff relevant to steam in my home directory:

$ cd ~/
$ ls -la | grep -i steam
drwxr-xr-x   2 preston preston         4096 Jan 18 15:41 .steam
-rw-r--r--   1 preston preston         2854 Oct 12  2010 steam2
drwxr-xr-x   3 preston preston         4096 Jan 19 20:01 steamapps-bup
drwxr-xr-x   5 preston preston         4096 Jan 18 15:37 steam-beta
-rw-r--r--   1 preston preston      1484458 Nov 28 17:50 steam.deb
lrwxrwxrwx   1 preston preston           32 Jan 18 15:39 .steampath -> /home/preston/.steam/bin32/steam
lrwxrwxrwx   1 preston preston           30 Jan 18 15:39 .steampid -> /home/preston/.steam/

Not everything up there is from steam. Some of it was just me derping around. However, remove the following like so:

$ cd ~/.steam
$ rm -rf *
$ cd ~/
$ rm -r .steam
$ rm .steampath
$ rm .steampid

As well, we need to remove all of the user files steam installed. As of, steam was following the XDG base directory specification. By default, the files should have ended up at ~/.local/share/Steam . If you had a different default base directory (doubtful, but possible), then go to it. We need to delete the Steam/ folder inside there.

$ cd ~/.local/share/
$ rm -rf Steam/

OK. We have now completely uninstalled steam (so far as I can tell).

1: First exposure to steam_latest.deb

This section has some minimal changes. Namely, I don’t have any real details on how this latest package operates “under the hood.”

First run:

So… let’s attempt to install the steam_latest.deb package you get from:

# dpkg -i steam.deb 
Selecting previously unselected package steam.
(Reading database ... 515397 files and directories currently installed.)
Unpacking steam (from steam_latest.deb) ...
dpkg: dependency problems prevent configuration of steam:
 steam depends on multiarch-support (>= 2.15-0ubuntu10.2); however:
  Version of multiarch-support on system is 2.13-37.
 steam depends on libc6 (>= 2.15); however:
  Version of libc6:i386 on system is 2.13-37.
 steam depends on libpulse0 (>= 1:0.99.1); however:
  Version of libpulse0:i386 on system is 2.0-6.

dpkg: error processing steam (--install):
 dependency problems - leaving unconfigured
Processing triggers for man-db ...
Processing triggers for hicolor-icon-theme ...
Processing triggers for gnome-menus ...
Processing triggers for desktop-file-utils ...
Errors were encountered while processing:

Now you have a broken package. Remove the broken steam package like so:

# apt-get -f install

This should prompt you to uninstall the steam package. Say yes assuming that’s all it’s asking. If it’s asking you all sorts of other stuff… well, it’s your system and presumably there’s other packaging issues that can’t be addressed here.

At this point, everyone might be getting all kinds of different errors. Given how long steam has been out in the open, I don’t have any practical way of checking for all the ways the packager might break or look different in a different use case.

A basic explanation of what steam.deb does

I haven’t had time to take a look at what the latest version does. Might check it out later.

2: Types of “Bugs” in Debian Packages

This section has not changed appreciably from the previous guide (minor wording and incorporation of comments from previous post). It serves as a guidepost for the types of bugs one might run into in their quest to satisfy all dependencies.

There are three basic problems you’ll run into when attempting to install this package like so:

# dpkg -i steam.deb

(Potential) False Positive

I was curious as to some of the dependencies that this steam.deb claimed were unsatisfied. Debian is upstream to Ubuntu, so I was surprised to find any “outdated” dependencies. Turns out, there are some false positives in Valve’s package, as the package is geared toward Ubuntu specifically. Not surprising, but that’s what the community is here for! They can look like this:

 steam depends on libpulse0 (>= 1:0.99.1); however:
  Version of libpulse0:i386 on system is 2.0-6.

Commenter Stefan explained in the previous guide that the reason the package manager is marking this as a failed dependency is due to Ubuntu’s repositories increasing the epoch on the package from 0 to 1 (ubuntu has “1:0.99.1” where debian is “0:2.0-6”). So strictly speaking, this can be considered a “true” positive. The package manager is correctly noticing the difference in epochs. Regardless, I haven’t had any issues with the beta that I can trace back to Debian’s epoch 0 version of libpulse0.

(Potential) Package not automatically installed for whatever reason

The whole idea behind a package manager is that it tackles all dependencies that it can, before quitting and spitting out an error. All other packages should be installed automatically on your first attempt to install steam.deb. If any other packages are mentioned as uninstalled, install them yourself. For example, my first run had the following:

 steam depends on libtheora0 (>= 1.0~beta1); however:
  Package libtheora0:i386 is not installed.

Package not available
libjpeg-turbo8 is no longer listed as a dependency in the package, but the steam binary still seems to think it’s necessary. Be sure to install “libjpeg8” package.

The last problem is a package that dpkg simply doesn’t recognize at all. I.e., it can’t find a source either locally or in any repo given in /etc/apt/sources.list (or in /etc/apt/sources.list.d/*.list). It looks like this:

 steam depends on libjpeg-turbo8; however:

Just a single line. Nothing else to it.

3: Finding all the Bugs

Seeing as I’m updating this guide from the previous one, I don’t actually encounter most of these errors anymore. They’re left here more for posterity’s sake and that of other web surfers 🙂 See the bolded section “Upgrade from Previous Install” for the errors I first encountered after purging my old installation.

At this point, you attempted to install steam.deb, and made note of the various forms of errors you found. I’m assuming you also removed the broken package by performing “apt-get -f install” as root. This is the list of errors I ran into, though it could be different for you. (That was the point of showing you what the errors looked like).

My (potential) false positives were as follows:

  • multiarch-support
  • libpulse0:i386
  • libc6:i386

My (potential) uninstalled packages that I needed to install manually:

  • libtheora0

The packages that weren’t unavailable were:

  • libjpeg-turbo8

Upgrade from previous install

The only additional package that I can recall needing to install was “libudev0:i386”.

4: Squashing all the Bugs

This section has not changed from the old guide appreciably. Minor wording changes.

Google may be your friend here, along with practice and experience.

(Potential) False positives:

  • multiarch-support : I thought that Debian was the driving force behind multiarch and it was surprising to me that even debian unstable (sid) would not have 2.15. I chose to cross my fingers and hope this wasn’t a critical package.
  • libpulse0:i386 : Performing a “apt-cache policy libpulse0:i386” confirms this to be a “false” positive (in a sense. Ubuntu just uses a different epoch than Debian).
  • libc6:i386 : Performing a “apt-cache policy libc6:i386” confirms this to be a true positive. This will need upgrading, which sucks, because “libc6” (better known as eglibc) is a crucial component that you’ll have a hard time upgrading your system with. Never fear though. There are tricks. See section five for how we do this.

A quick explanation of “apt-cache policy”: I decided to cross-reference each dependency with what I had on my system, and what was available upstream in the repos. This is what I did for each package:

$ apt-cache policy libpulse0:i386
  Installed: 2.0-6
  Candidate: 2.0-6
  Version table:
 *** 2.0-6 0
        500 testing/main i386 Packages
        100 /var/lib/dpkg/status

As you can see, I DO have libpulse0:i386 installed, and at a greater version than requested. This is a false positive. (Well, technically not, but Debian and Ubuntu are on different epochs for this package for some reason).

However, look at libc6:

$ apt-cache policy libc6:i386
  Installed: 2.13-37
  Candidate: 2.13-37
  Version table:
 *** 2.13-37 0
        500 testing/main i386 Packages
        100 /var/lib/dpkg/status

Eek. Looks like that might actually need to be upgraded or otherwise attained.

(Potential) Uninstalled packages:

  • libtheora0 : “apt-get install libtheora0:i386” is all you should need to do to clear up something like this.

As well, sometimes, performing:

# apt-get -f install

will install additional packages in the process of attempting to fix a broken package. If apt doesn’t attempt to install the missing dependencies itself, then be sure to manually install them a la “apt-get install somepackage”

Unavailable packages:
libjpeg-turbo8 is no longer listed as a dependency in the package, but the steam binary still seems to think it’s necessary. Be sure to install “libjpeg8” package.

  • libjpeg-turbo8 : Apparently a potential licensing issue is keeping this out of debian repos at the moment. “libjpeg8” is the equivalent (and from what I read, they are binary compatible; don’t take my word for it though). “apt-get install libjpeg8” takes care of this.

5: Grabbing eglibc 2.15 and Some Other Dependencies not Listed

This section has not changed from the old guide appreciably. Minor wording changes. We’re still grabbing precompiled binaries for eglibc and setting up our .bashrc such that LD_LIBRARY_PATH looks in the directory we place these binaries.

eglibc 2.15

As stated before, upgrading your version of eglibc is not typically a pleasant experience. It can break lots of other packages and even totally bork your system. So, rather than attempt to upgrade ourselves –either by compiling from source or by installing someone else’s debian package along with all its dependencies– we will do something inbetween: grab the compiled libraries (*.so files, basically) from someone else’s eglibc 2.15 package. We will have to tell steam where to look for them, but this prevents us from borking our system or otherwise breaking things.

I decided at this point to keep all custom stuff for steam in a single folder. Specifically:

$ mkdir ~/steam-beta
$ mv steam.deb ~/steam-beta
$ cd ~/steam-beta
$ mkdir lib

We will throw all our custom eglibc 2.15 i386 compiled libraries in there. But steam still needs to able to find them. So, add the following environment variable to your .bashrc:


You’ll also want to append this to LD_LIBRARY_PATH:


Your LD_LIBRARY_PATH will probably be different. DO NOT change it to look like mine. Just add “:${STEAMLIBS}” to the end. Make sure you export them at the end of your .bashrc:


You’ll need to reload your terminal (close and reopen) before this takes effect.

We now have a spot to put our eglibc 2.15 i386 compiled libraries where steam will know where to look. So let’s get them and put them there:

$ wget
$ dpkg -x libc6_2.15-0ubuntu10.2_i386.deb /tmp/libc/
$ mv /tmp/libc/lib/i386-linux-gnu/* ${STEAMLIBS}

Congratulations. The hard part is done!

jockey-common and python-xkit

I don’t know how these play into steam. I think they are intended to help with desktop integration. Regardless, others have recommended they be installed, so that’s what I’m doing.

$ cd ~/steam-beta/
$ wget
$ wget
# dpkg -i jockey-common_0.9.7-0ubuntu7_all.deb python-xkit_0.4.2.3build1_all.deb

6: Rebuilding the steam.deb Package

libjpeg-turbo8 is no longer listed as a dependency in the package, but the steam binary still seems to think it’s necessary. Be sure to install “libjpeg8” package.

Recall from section 4 the problem packages. We’ve taken care of eglibc. But we have these to contend with:

  • multiarch-support
  • libpulse0:i386

Recall that we’re regarding multiarch-support and libpulse0:i386 as false positives, and libjpeg-turbo8 has a different name, “libjpeg8”. We’ve installed libjpeg8 and of course eglibc. This won’t stop the package as-is from complaining though! We need to remove these as dependencies so that the package installation goes through and you can log in.

We do that like so. This is essentially unpacking the steam.deb package and tweaking it. Specifically, we will edit the “control” file to get rid of the false positives (multiarch-support, libpulse0) and the package we are manually having steam link to (libc6).

$ cd ~/steam-beta
$ mkdir deb-package
$ cd deb-package
$ ar -x ../steam_latest.deb
$ rm debian-binary
$ tar -xvzf data.tar.gz
$ rm data.tar.gz
$ mkdir DEBIAN
$ tar -xvzf ../control.tar.gz
$ rm ../control.tar.gz
$ vim control

This is my before:

Package: steam
Architecture: i386
Maintainer: Valve Corporation <>
Installed-Size: 323836
Depends: libcurl3-gnutls (>= 7.16.2-1), libgl1-mesa-dri, libgl1-mesa-glx, libogg0 (>= 1.0rc3), libpixman-1-0 (>= 0.24.4-1), libsdl1.2debian (>= 1.2.10-1), libtheora0 (>= 1.0~beta1), libudev0 (>= 175-0ubuntu9.2), libvorbis0a (>= 1.1.2), libvorbisenc2 (>= 1.1.2), libvorbisfile3 (>= 1.1.2), multiarch-support (>= 2.15-0ubuntu10.2), zenity, xterm | gnome-terminal, libasound2 (>= 1.0.23), libc6 (>= 2.15), libcairo2 (>= 1.6.0), libcups2 (>= 1.4.0), libdbus-1-3 (>= 1.2.14), libfontconfig1 (>= 2.8.0), libfreetype6 (>= 2.3.9), libgcc1 (>= 1:4.1.1), libgcrypt11 (>= 1.4.5), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.14.0), libgtk2.0-0 (>= 2.24.0), libnspr4 (>=, libnss3 (>= 3.12.3), libopenal1 (>= 1:1.13), libpango1.0-0 (>= 1.22.0), libpng12-0 (>= 1.2.13-4), libpulse0 (>= 1:0.99.1), libstdc++6 (>= 4.6), libx11-6 (>= 2:, libxext6, libxfixes3, libxi6 (>= 2:, libxinerama1, libxrandr2 (>= 2:, libxrender1, zlib1g (>= 1:

And this is my after, where I removed “multiarch-support”, “libc6”, and “libpulse0”.

Package: steam
Architecture: i386
Maintainer: Valve Corporation <>
Installed-Size: 323836
Depends: libcurl3-gnutls (>= 7.16.2-1), libgl1-mesa-dri, libgl1-mesa-glx, libogg0 (>= 1.0rc3), libpixman-1-0 (>= 0.24.4-1), libsdl1.2debian (>= 1.2.10-1), libtheora0 (>= 1.0~beta1), libudev0 (>= 175-0ubuntu9.2), libvorbis0a (>= 1.1.2), libvorbisenc2 (>= 1.1.2), libvorbisfile3 (>= 1.1.2), zenity, xterm | gnome-terminal, libasound2 (>= 1.0.23), libcairo2 (>= 1.6.0), libcups2 (>= 1.4.0), libdbus-1-3 (>= 1.2.14), libfontconfig1 (>= 2.8.0), libfreetype6 (>= 2.3.9), libgcc1 (>= 1:4.1.1), libgcrypt11 (>= 1.4.5), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.14.0), libgtk2.0-0 (>= 2.24.0), libnspr4 (>=, libnss3 (>= 3.12.3), libopenal1 (>= 1:1.13), libpango1.0-0 (>= 1.22.0), libpng12-0 (>= 1.2.13-4), libstdc++6 (>= 4.6), libx11-6 (>= 2:, libxext6, libxfixes3, libxi6 (>= 2:, libxinerama1, libxrandr2 (>= 2:, libxrender1, zlib1g (>= 1:

I HIGHLY recommend changing the version to something customized, so you know this a tweaked package, and not vanilla steam.deb from Valve.

Now recompile that package!

$ cd ~/steam-beta
$ fakeroot dpkg-deb -b deb-package steam_1.0.0.22-custom_i386.deb

And try to install it:

# dpkg -i steam_1.0.0.22-custom_i386.deb
Selecting previously unselected package steam.
(Reading database ... 515398 files and directories currently installed.)
Unpacking steam (from steam_1.0.0.22-custom_i386.deb) ...
Setting up steam ( ...
Processing triggers for gnome-menus ...
Processing triggers for desktop-file-utils ...
Processing triggers for man-db ...
Processing triggers for hicolor-icon-theme ...

SHINY! It installed! But sadly, that’s not all we have to do these days.

7: Getting Steam to Start

NEW section.

Start steam so it does its bootstrapping thing:

$ steam

You should see something like this:


However, once that finishes, the terminal you started steam in will look like this:

$ steam
ILocalize::AddFile() failed to load file "public/steambootstrapper_english.txt".
Installing breakpad exception handler for appid(steam)/version(0_client)
Installing breakpad exception handler for appid(steam)/version(1.0_client)
Installing breakpad exception handler for appid(steam)/version(1.0_client)
Installing breakpad exception handler for appid(steam)/version(1.0_client)
Package multiarch-support is installed with version '2.13-37' but doesn't match requirements: multiarch-support (>= 2.15-0ubuntu10.2)
Package libjpeg-turbo8:i386 needs to be installed

and shortly after another terminal will probably pop up that wants your sudo password:

Steam needs to install these additional packages: 
	multiarch-support, libjpeg-turbo8:i386
[sudo] password for preston: 

That’s interesting. Valve has removed libjpeg-turbo8:i386 from the list of dependencies, but its steam binary still says they’re necessary.

Dismiss each pop-up. You should then be able to log-in. I then checked my list of applications:


Now, let’s close steam and move our textures back over so we aren’t stuck redownloading them all night.

8: Move our textures back

NEW section.

Remember when you backed up your SteamApps/ directory to ~/steamapps-backup/ ? Good. Let’s move it back into place. We’ll delete the new SteamApps folder in the process (don’t worry, it’s empty on a fresh install, at least for me).

$ cd ~/.local/share/Steam
$ rm -rf SteamApps/
$ mv ~/steamapps-backup/SteamApps/ .
$ cd SteamApps
$ ls
aggroskater                        Source Models.gcf
Multiplayer OB Linux Binaries.gcf  sourcemods
Source 2007 Shared Materials.gcf   Source Sounds.gcf
Source 2007 Shared Models.gcf      Team Fortress 2 Client Content.gcf
Source 2007 Shared Sounds.gcf      Team Fortress 2 Content.gcf
SourceInit.gcf                     Team Fortress 2 Linux.gcf
Source Materials.gcf               Team Fortress 2 Materials.gcf

Shiny. Our textures are back. But does steam recognize this when we try to reinstall TF2? Start up steam again:

$ steam

Dismiss the sudo prompts. Check your steam library:


Yep. Steam shows it as installed. Nice. I right-clicked Team Fortress 2, told it to resume updating, and it took a few minutes downloading some more files before it showed the game as installed again. I was then able to play, as evidenced by this screenshot of me getting stomped by a heavy:


I believe the tearing is from the screenshot utility, as I don’t experience tearing during regular play.

9: Convincing Steam That It Really Isn’t The Package Manager

NEW section.

The new prompts are an annoying addition. They’re not entirely unexpected though, coming from a company that has been developing games for well over a decade for a platform that has never had a genuine package manager (Windows). I ran an strace of steam as I started it up and it looks like steam uses a binary called “steamdeps” for dependency checking:

$ steamdeps
Usage: /usr/bin/steamdeps dependencies.txt

I’m guessing this has something to do with the python script in the Steam directory:

$ cd ~/.local/share/Steam
$ ls | grep dep

Indeed, steamdeps.txt has the following contents:

# This is a package dependency manifest used by steamdep

# This should be set to the version of the Steam runtime that this program
# is built with.
# Available values are:
#	1	- Ubuntu 12.04 LTS
# This should be set to the version of the dependency file format
# The file can contain lines starting with #, blank lines and dependencies
# A dependency line consists of a package name for the current runtime,
# along with optional architecture or version requirements using the 
# Debian package syntax:

# These are non-arch specific dependencies
xterm | gnome-terminal
multiarch-support (>= 2.15-0ubuntu10.2)

# These are i386 dependencies for Steam itself

# These are dependencies that are commonly required for games

As you can see, this listing still has libjpeg-turbo8:i386 as a dependency.

The python script has this notice:

	This script handles installing system dependencies for games using the
	Steam runtime.  It is intended to be customized by other distributions
	to "do the right thing"

	Usage: steamdeps dependencies.txt

I’d say that “the right thing” is to actually work with the package manager and not second-guess it… but I’m not a maintainer nor a developer. So perhaps I’m just being an asshat 😀

Looking through the python script, I could see a number of ways to at least get it to stop throwing up the prompts, but that’s not really a solution. If you want to mess around with it, then I’d suggest removing the steam package (“apt-get remove steam”), tweaking the script as needed (It’s in the steam_latest.deb package at usr/bin) and then reinstalling the package. I’m pressed for time though, and I’m sure there are plenty of people way more proficient with python and proper package management than I. As for me, I’ll live with dismissing the pop-up whenever I start steam for now.

10: Sidenotes

This section hasn’t changed much. Just notes on usability and performance.

The gameplay is AWESOME so far. Very clean, smooth. It even handled my dual monitor setup flawlessly, putting the game in the correct monitor at the correct resolution. Framerate was excellent! Average of 150 FPS without Vsync on. With Vsync, it’s a solid 60 FPS damn near all the time. Starting the game up took 2-3 minutes (thought something was wrong at first), but once it gets started, it’s all gravy 😀 And that was with all settings at HIGH, 4x on both AA and AF. Yeah… Valve is awesome 😀

Some specs:

Processor: Intel quad core 2.5 GHz
Graphics: Nvidia GTX 280 with proprietary 310.x drivers
Desktop environment: Gnome 3 fallback mode
Window Decorator: Emerald (old I know. Don’t judge me!)
Window Compositor: Compiz

I’m truly shocked that everything worked as well as it does, given compiz’ reputation for problems with full-screen anything, much less gaming. Granted, I do have the “Unredirect full screen windows” option selected for compiz. But I thought it had no effect when you had multiple monitors being handled by X at once… Whatever. I’m not complaining. This is fucking AWESOME.


  1. ok got it :). Thanks again.

    I had to excise four packages from the control metadata, multiarch, zenity, libc6, and libpulse (all :i386 ofc). But now it’s running alright. Hopefully Valve will directly support debian soon so this hackery is not required. I believe that fixing the current situation “the right way” ™ will involve a three way dialogue between the package maintainers for ubuntu and debian, and the Steam devs. I don’t fully understand the motivation behind these versioning incompatibilities but they don’t seem to difficult fix.

    This is so exciting for me, as a Linux user! Big $$$ is about to be spent making gnu/linux a commercially viable platform for gaming software. Up until this point, we really only had Amnesia, Xonotic, and precious few other projects (I’m sure there are more that I didn’t know about – but not many). Or we could resort to wine as a fairly ugly (but beautifully implemented) option. Gaben!! You’re the man!

    Comment by Max DeLiso — January 24, 2013 @ 10:45 pm

  2. I have one Q, where did you find the css for your code snippits
    it is awesome

    Comment by Dick Thomas — January 26, 2013 @ 11:47 am

  3. Libc6 and multiarch from debian experimental are version 2.16, you can install libjpeg-turbo8 with –force overwrite and exclude only libpulse from debian/control. It works great but of course you have to be careful when messing with libc6. No more prompts for installing multiarch/libjpeg-turbo8.

    Comment by Slavko Igric — January 28, 2013 @ 8:57 am

  4. I did exactly as the same above and all job was done sucessfully but when I try to run:
    $ steam
    I get this error message:

    $ steam
    Setting up Steam content in /home/lucianomarinho/.local/share/Steam
    ILocalize::AddFile() failed to load file “public/steambootstrapper_english.txt”.
    Installing breakpad exception handler for appid(steam)/version(0_client)
    /home/lucianomarinho/.local/share/Steam/ line 337: 15133 Segmentation fault $STEAM_DEBUGGER “$STEAMROOT/$PLATFORM/$STEAMEXE” “$@”
    Installing bootstrap /home/lucianomarinho/.local/share/Steam/bootstrap.tar.xz
    ILocalize::AddFile() failed to load file “public/steambootstrapper_english.txt”.
    Installing breakpad exception handler for appid(steam)/version(0_client)
    /home/lucianomarinho/.local/share/Steam/ line 337: 15179 Segmentation fault $STEAM_DEBUGGER “$STEAMROOT/$PLATFORM/$STEAMEXE” “$@”

    Comment by Luciano Marinho — January 29, 2013 @ 10:26 am

  5. Hi,

    thanks for the guide, even though I ended up doing it a bit differently.

    As for getting the right nvidia openGL driver through the Debian package management system:
    Install libgl1-nvidia-glx:i386

    Comment by A. Donda — January 30, 2013 @ 3:08 pm

  6. Hi!
    First of all: thanks for all your work!
    Everything was working fine, but today I got following error (and some variations of it):
    /bin/bash: /lib/x86_64-linux-gnu/ version `GLIBC_2.14′ not found (required by /home/andi/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/
    For some reason (update of the system or steam?) the linking doesn’t work anymore. Of course I edited my .bashrc as you described and the 2.15 versions exists in steam-beta/lib.
    I googled hard for it, but I just have to little knowledge of how this really all works.
    Any help would be greatly appreciated!

    Comment by Andi W. — February 2, 2013 @ 8:37 pm

  7. Huh. I didn’t have that directory in my own steam installation. I just updated though and now I’m getting that directory structure as well. Granted, the steam client is still functional but it’s thrown those errors at me as well. The name seems to indicate it’s trying to use 64 bit libraries. I didn’t think Valve would jump into multiple architectures so quickly, but that seems to be what it’s doing. Hell, I can’t even ls the ~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64 directory. However, reading ~/.local/share/Steam/ubuntu12_32/steam-runtime/ shows that it’s modifying LD_LIBRARY_PATH. I tried fiddling with this, even removing all references to the amd64 directory, but some other aspect of steam is still checking there. And of course there’s this bit of info in the terminal from steam:

    preston@PRESTON:~/.local/share/Steam/ubuntu12_32/steam-runtime$ steam
    Running Steam on debian 7.0
    STEAM_RUNTIME is enabled automatically on debian

    So I grepped around and noticed that STEAM_RUNTIME had lots of instances in I took a look at the script to see where STEAM_RUNTIME was coming into it:

            # Show what we detect for distribution and release
            echo "Running Steam on `detect_distro` `detect_release`"
            # prepend our lib path to LD_LIBRARY_PATH
            if [ "$STEAM_RUNTIME" = "1" ]; then
                    echo "STEAM_RUNTIME is enabled by the user"
            elif [ "$STEAM_RUNTIME" = "0" ]; then
                    echo "STEAM_RUNTIME is disabled by the user"
            elif [ -z "$STEAM_RUNTIME" ]; then
                    if runtime_supported; then
                            echo "STEAM_RUNTIME is enabled automatically on `detect_distro`"
                            echo "STEAM_RUNTIME is disabled automatically on `detect_distro`"
                    echo "STEAM_RUNTIME has been set by the user to: $STEAM_RUNTIME" 
            if [ "$STEAM_RUNTIME" ]; then
                    # Unpack the runtime if necessary
                    if unpack_runtime; then
                            export LD_LIBRARY_PATH="$STEAM_RUNTIME/i386/lib/i386-linux-gnu:$STEAM_RUNTIME/i386/lib:$STEAM_RUNTIME/i386/usr/lib/i386-linux-gnu:$STEAM_RUNTIME/i386/usr/lib:$STEAM_RUNTIME/amd64/lib/x86_64-linux-gnu:$STEAM_RUNTIME/amd64/lib:$STEAM_RUNTIME/amd64/usr/lib/x86_64-linux-gnu:$STEAM_RUNTIME/amd64/usr/lib:$LD_LIBRARY_PATH"
    and so on and so forth and so on and so forth 


    It looks like Valve is doubling down on their “don’t trust the package manager” mantra. Looks like even more safeguards and the like are being put into place, and it’s rapidly growing into something I don’t have time to keep track of between school and internship-searching 😛 I feel like I’m back with Microsoft Windows, hunting down DLLs and updated graphics drivers just to get games to run. Though it is interesting to me that they seem to be working toward 64 bit support.

    A fix for now is to add the following to your .bashrc:

    export STEAM_RUNTIME

    This stopped the errors from popping up on me. I was able to run the client and play some Team Fortress 2 online with other players. Haven’t tested anything else like Half-Life or Counter-Strike 1.6 or any of the other Linux offerings.

    Comment by aspensmonster — February 2, 2013 @ 10:09 pm

  8. Yeah! This works (also with Half-Life and Solar 2)!

    …Internship? Don’t you like the job on Valve’s fix staff that they are obviously offering – next to your share of all the money gamers can spend thanks to you? 😉

    Comment by Andi W. — February 3, 2013 @ 2:06 am

  9. This doesn’t work either. Because at the first run of Steam it untars /usr/lib/steam/bootstraplinux_ubuntu12_32.tar.xz. I needed to extract bootstraplinux_ubuntu12_32.tar.xz, modifing and tar it again.

    Thanks for that very useful article.

    Comment by Leandro Toledo — February 3, 2013 @ 7:45 am

  10. Hi,
    I’m one of the annoying guys who follow instructions partially, and later wonder why it does not work.

    So, I decided not to mess too much with .bashrc (although at last I did it anyway but still it did not work).

    I’ve created custom deb with no dependancies on libc (and other), as in instructions above, and installed it.

    After running steam bootstrap is unpacked, and GLIBC error is in the console
    boskar@pauper:~$ steam
    Setting up Steam content in /home/boskar/.local/share/Steam
    /home/boskar/.local/share/Steam/ubuntu12_32/steam: /lib/i386-linux-gnu/i686/cmov/ version `GLIBC_2.15' not found (required by /home/boskar/.local/share/Steam/ubuntu12_32/steam)
    Installing bootstrap /home/boskar/.local/share/Steam/bootstrap.tar.xz
    /home/boskar/.local/share/Steam/ubuntu12_32/steam: /lib/i386-linux-gnu/i686/cmov/ version `GLIBC_2.15' not found (required by /home/boskar/.local/share/Steam/ubuntu12_32/steam)

    But that’s not the problem. I decided to fix it my way – ie. running steam this way
    boskar@pauper:~$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/boskar/steam/libs/lib/i386-linux-gnu/ steam

    It DID work.
    But then I came accross an popup: Steam – Fatal error: Failed to load

    I tried to run steam ($ steam in console) without LD_LIBRARY_PATH before – GLIBC errors in the console – so it looks like that’s not the problem here. Running it again with LD_LIBRARY_PATH – the same error.

    So, stage 2. Investigation.
    I’ve got a nice steam setup in ~/.local/Steam. What’s especially interesting is ~/.local/share/Steam/ubuntu12_32/steam-runtime – with i386/libs and amd64/libs directories.

    I tried to get rid of LD_LIBRARY_PATH by simply coping the libs logically to i386/libs and i386/usr/libs – it did work. Now I reach the same error without LD_LIBRARY_PATH before steam in console.

    I tried running steam with STEAM_RUNTIME=0 – Running Steam on debian 7.0
    STEAM_RUNTIME is enabled automatically on debian
    Installing breakpad exception handler for appid(steam)/version(1359765526_client)
    Installing breakpad exception handler for appid(steam)/version(1359765526_client)
    boskar@pauper:~$ STEAM_RUNTIME=0 steam
    Running Steam on debian 7.0
    STEAM_RUNTIME is disabled by the user
    Installing breakpad exception handler for appid(steam)/version(1359765526_client)
    Installing breakpad exception handler for appid(steam)/version(1359765526_client)

    Now, I suppose the problem is caused by something libc unrelated. (I tried to mess with amd64 libc libraries the same way as described above).
    Any ideas what could I do with “Failed to load ” error?

    Comment by boskar — February 3, 2013 @ 7:00 am

  11. My first step would be to run

    $ cd ~/.local/share/Steam/ubuntu12_32
    $ ldd | grep -i "not found"

    If any libraries are missing that depends on, that should tell you. At that point it’s a matter of installing the libraries, either through a package manager or by manually obtaining those libraries and placing them wherever LD_LIBRARY_PATH is looking (/home/boskar/steam/libs/lib/i386-linux-gnu/ if I understand your setup correctly).

    Failing that, strace is a great tool for getting a grip on a problem that isn’t presenting any obvious symptoms:

    $ export STEAM_RUNTIME=0
    $ strace -o some_output_file_name steam

    There will be plenty of file not found errors as the binary searches in various spots for libraries it needs, but typically, somewhere within the mess of strace’s output is a useful hint at where to look.

    Comment by aspensmonster — February 5, 2013 @ 9:32 pm

  12. FWIW, I was having this issue and it was due to me haivng left a rogue $ in when definint STEAMLIB in my bash.rc so LD_LIBRARY_PATH was also not correct and not being included.

    Comment by DevAnubis — February 16, 2013 @ 11:53 am

  13. I’m going to try this out on my new Sid box later today. Hopefully it should work a bit better than Wheezy, considering the newer dependencies that Sid comes with.

    Comment by Erik — February 5, 2013 @ 10:02 am

  14. Rather than mucking around with the .deb, you can just use dpkg -i --force-depends-version steam_latest.deb

    Comment by Pauan — February 12, 2013 @ 5:53 pm

  15. Awesome tutorial man. Thanks for your help.

    Comment by Burak — March 21, 2013 @ 4:04 am

  16. nice post, let’s have a beer

    Comment by clintdub — July 22, 2014 @ 5:24 pm

RSS feed for comments on this post.

Leave a comment