December 7, 2012

Steam for Linux Beta on 64 bit Debian Testing (Wheezy)

Filed under: Uncategorized — aspensmonster @ 6:48 am

Flattr this!

UPDATE JANUARY 19 2013: I have updated this guide. The new guide is available at

Update January 17 2013: I’ve replicated the steps of this guide with version of the steam.deb package (looks like latest is It works to get steam installed, but now the steam binary will also force-check for missing packages like “libjpeg-turbo8″ which this guide removed from the control file of the package. Steam will throw up a shell, prompting you to provide sudo access. This pop-up is annoying, but dismissing it 2 to 3 times permits me to log in and play TF2. It looks like Valve is now hosting its own repository for steam (at least according to my /etc/apt/sources.list.d/steam.list) and a better solution is probably to tweak something about the new repo, but I’m short on time atm. The joys of senior year at uni 😀

Update January 17 2013 edit 2: Fuck it. Lab can wait. Looks like there’s a binary at /usr/bin/steamdeps that /usr/bin/steam uses. steamdeps checks ~/.local/share/Steam/steamdeps.txt . You can comment out the offending packages that steam throws at you on startup and the binary won’t prompt you for them anymore. For me, it’s started updating steam. And then threw this at me:

“Your steam package is out of date. Please get an updated version from your package provider or directly from for supported distributions.”

At which point I click OK, and I can still get to steam by dismissing prompts. However, whenever I comment out the offending packages in steamdeps.txt, the binary will then check your steam package to see if it’s up-to-date, and revert your changes to steamdeps.txt.

And now lab is 20 minutes away. Maybe I’ll tackle getting a clean install with steam over the weekend.

I just got an invite to the Steam for Linux Beta this afternoon. Of course, I had already fiddled with a hacked steam client, but I figured since I now had full access I could write a guide on how to get this up and running on 64 bit Debian testing. Of course, this should work on any Debian derived distro with multiarch support (ability to have binaries compiled for foreign architectures run on your machine). There are some scripts floating around that try to automate some of this work. I prefer to dive head in, and explain everything that’s going on, so that in the event that things change, this guide might still be of use. Scripts are nice, but if you don’t know what’s going on then you’re helpless when the script fails.

The main sources I found that assisted me:

Moving on.

0: Prerequisites

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.

1: First exposure to steam.deb

First run:

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

# dpkg -i steam.deb 
Selecting previously unselected package steam.
(Reading database ... 511879 files and directories currently installed.)
Unpacking steam (from steam.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 libjpeg-turbo8; however:
 steam depends on libtheora0 (>= 1.0~beta1); however:
  Package libtheora0:i386 is not installed.
 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:

At this point, you have a broken package. It tried its best to grab all of those dependencies, but it didn’t get all of them and now it’s crying. Get rid of that sucker:

# 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.

A basic explanation of what steam.deb does

Valve’s steam.deb package appears to function merely as a wrapper for the “actual” installer. The package will attempt to detect all dependencies –and if one looks at the changelog for the package, one can see how they’ve added to it since– but once the package is “installed” (dependency check passes) the postinst instantiates the update notifier, asking the user to run /usr/bin/steam to complete the installation. I’m guessing that upon successful login, this detects what “STEAMUNIVERSE” you’re in (“Beta” or “Public”) and extracts bootstraplinux_ubuntu12_32.tar, at which point there is a “” script that then attempts to detect various aspects of the system and then goes about setting up shop in your home directory, populating ~/.steam with symlinks that thankfully appear to be following the XDG base directory specification now. Afterwards, I’m guessing it starts to populate all of your information and the various games/configs/data/etc into ~/.steam/root, which is ~/.local/share/Steam for me.

I don’t understand why they’ve got a separate script doing double duty on the dependency and environment checking –and what appears to be some python helper scripts to do even more double checking about hardware availability– but then again, I’m not 100% sure of what I’m looking at. And it is a beta after all 😀

Regardless, we want to modify this steam.deb file so that we can get the package to “install” cleanly. Broken packages prevent us from installing other packages that come from regular updates.

2: Types of Bugs in steam.deb Package

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.

The problem of course is that the package manager could be right too. But I’m pretty sure 2.0 is bigger than 0.99.1. Perhaps there’s some significance here I’m missing, but my libpulse0 works fine on my install of steam (that I can tell).

Update Sat Dec 8 2012: In the comments, Stefan explained 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

The last problem is a package that dpkg simply doesn’t recognize at all, either available locally or in any repo given in /etc/apt/sources.list. It looks like this:

 steam depends on libjpeg-turbo8; however:

Just a single line. Nothing else to it.

3: Finding all the Bugs

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

4: Squashing all the Bugs

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.
  • 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, read the update note above in section 2). 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.

Unavailable packages:

  • 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

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:

Update from comment: fixed typo. used to read “export LD_LIRARY_PATH” when it should have read “export LD_LIBRARY_PATH”.


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

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

  • multiarch-support
  • libpulse0:i386
  • libjpeg-turbo8

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), the packages we’ve already installed under a different name(libjpeg-turbo8), and the package we are manually having steam link to (libc6).

$ cd ~/steam-beta
$ mkdir deb-package
$ cd deb-package
$ ar -x ../steam.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 Software LLC <>
Installed-Size: 323836
Depends: multiarch-support (>= 2.15-0ubuntu10.2), libgl1-mesa-glx, libgl1-mesa-dri, libjpeg-turbo8, libcurl3-gnutls (>= 7.16.2-1), libogg0 (>= 1.0rc3), libpixman-1-0 (>= 0.24.4-1), libsdl1.2debian (>= 1.2.10-1), libtheora0 (>= 1.0~beta1), libvorbis0a (>= 1.1.2), libvorbisenc2 (>= 1.1.2), libvorbisfile3 (>= 1.1.2), zenity (>= 3.4.0-0ubuntu4), 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:, libxrandr2 (>= 2:, libxrender1, zlib1g (>= 1:

And this is my after:

Package: steam
Architecture: i386
Maintainer: Valve Software LLC <>
Installed-Size: 323836
Depends: libgl1-mesa-glx, libgl1-mesa-dri, libjpeg8, libcurl3-gnutls (>= 7.16.2-1), libogg0 (>= 1.0rc3), libpixman-1-0 (>= 0.24.4-1), libsdl1.2debian (>= 1.2.10-1), libtheora0 (>= 1.0~beta1), libvorbis0a (>= 1.1.2), libvorbisenc2 (>= 1.1.2), libvorbisfile3 (>= 1.1.2), zenity (>= 3.4.0-0ubuntu4), 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:, 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. Notice how I REMOVED multiarch-support completely. I renamed libjpeg-turbo8 to libjpeg8, though you can also just remove libjpeg-turbo8. I also removed libc6:i386, as well as libpulse0. You can try renaming or removing as you see fit. They’re all equally hacky ways of dealing with a hacky package file :)

Now recompile that package!

Update Sat Dec 8 2012: Fixed typo below. It used to read “cd ~/steam-libs”. This was incorrect. It’s updated now. Thanks XYU!

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

And try to install it:

# dpkg -i steam_1.0.0.16-custom_i386.deb
Selecting previously unselected package steam.
(Reading database ... 511885 files and directories currently installed.)
Unpacking steam (from steam_1.0.0.16-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!

7: Running steam

At this point, all you have to do is run the “steam” command in a terminal. It might have even added a menu item or desktop shortcut for you. If you’ve followed all the steps –most importantly, getting eglibc 2.15 and repackaging steam.deb– you should be all set.

If not? Bring it up with the folks in the support forum:

Main “Debian” thread in the Steam for Linux beta support forum.

I’ve got finals to study for, but I’ll do my best to help out.

8: Sidenotes

I first installed steam with the broken package, using “–force-depends” after taking care of the eglibc 2.15 business. I hoped that I wouldn’t need to redownload team fortress 2 upon reinstalling a “cleaner” package for debian wheezy. Looks like I didn’t have to 😀

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.