ASPENSMONSTER Just another WordPress site

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.


  1. Dude, awesome tut!

    Comment by Rower — December 7, 2012 @ 12:42 pm

  2. Hi,

    Great post because:
    – You explain each step &
    – it works !

    2 things:
    – I used steam-beta instead of steam-libs
    “Now recompile that package!
    $ cd ~/steam-beta”
    – I had to install the proprietary driver 🙁

    and now let’s have a look at this beta. tanx

    Comment by XYU — December 7, 2012 @ 11:20 pm

  3. The libpulse issue is because Ubuntu increased the epoch for the package for some reason. Therefore the version in Debian is 0:2.0-6 and the requested one is 1:0.99.1, so the package manager is actually right for saying the dependency is not satisfied. The wording could be improved, though.

    I’m not sure if omitting the epoch in the .deb file would allow it to install on Debian nicely while still working as expected. Of course, there are other issues, but every manual step removed is a step in the right direction 🙂

    See for details.

    Comment by Stefan — December 8, 2012 @ 7:57 am

  4. glibc 2.16 is in experimental

    Comment by sir_sigurd — December 8, 2012 @ 3:06 pm

  5. Dude, great job, thank you so much! 🙂

    Comment by Anonymous — December 9, 2012 @ 6:20 am

  6. Hi,
    I have a great problem here in Mint Debian.
    The problem is with libpulse0:i386

    $ apt-get -s install libpulse0:i386

    and it says about dependency problem. libpulse0:i386 : Require: libcap2:i386 (>= 2.10) but will not be installed

    So I tried this:

    $ apt-get -s install libcap2:i386

    And i looks like that packet want to delete about half of my system…:

    0 updated, 19 new installed, 263 removed and 0 not updated.

    I dont want to paste these 263 packages here but there is entire gnome, mate, cinnamon and pulseaudio to be removed and a lot of libs and apps.

    Can you help?

    Comment by Jack — December 9, 2012 @ 2:33 pm

  7. Very nice post! Too bad Steam doesn’t seem to like the video card on my desktop box. I’ll have to give it a try on my laptop over the break.

    Comment by Zaki Mughal — December 9, 2012 @ 8:32 pm

  8. Thanks all!

    In reply to Jack:

    I don’t know if Mint’s repositories are different. However, I ran into issues with the steam.deb package listing a different epoch for the libpulse0:i386 package (epoch “1”) than Debian’s repositories (epoch “0”). Regardless, I _did_ have libpulse0:i386 installed. When I modified the steam.deb package, I removed libpulse0 as a dependency. I haven’t had any problems with sound in steam or TF2 so far.

    However, your simulation from apt-get implies that libpulse0:i386 is not installed at all; I would assume something like “already installed and latest version” if it was installed. And it looks like “” does list it as a shared library:

    $ pwd
    $ ldd | grep pulse => /usr/lib/i386-linux-gnu/ (0xf676a000) => /usr/lib/i386-linux-gnu/pulseaudio/ (0xf6415000)

    Typically, when I’ve run into this, it means that the repositories being used have no way to satisfy the dependencies. Essentially, apt-get will say that it can’t be installed. In your case, it’s saying this by way of saying it can’t find a way to install libcap2:i386.

    My suggestion would be to grab the libpulse0:i386 package from your repository directly, and add the shared libraries into ~/steam-beta/lib. Basically, this is doing the same trick as with eglibc 2.15. I didn’t want to bork my system by trying to upgrade everything, so I just grabbed some precompiled *.so files instead and told steam where to look for them.

    So something like this:

    $ wget

    $ dpkg -x libpulse0_2.0-6_i386.deb /tmp/libpulse0
    $ mv /tmp/libpulse0/usr/lib/i386-linux-gnu/* ${STEAMLIBS}

    Might work. In this case I’m pulling from Debian testing repositories. If Mint has its own version of the package you might grab it from there instead. This set of commands is putting the libpulse0 libraries into ${STEAMLIBS}, which my guide defines as ~/steam-beta/lib , though you can put the custom libraries wherever you wish, so long as you are consistent and include that location in the LD_LIBRARY_PATH environment variable. At that point, just remove libpulse0 as a dependency in the control file (as detailed in the post) and give it a go. I can’t guarantee it will work, but it’s always worth a shot.

    Comment by aspensmonster — December 9, 2012 @ 9:09 pm

  9. I Can’t seem to locate the LD_LIBRARY_PATH environment variables on .bashrc
    I’m running CrunchBang 11 Waldorf (Wheezy based)
    Also i have installed most of the installable dependences expect the ones listed
    Is there is any Alt way to place the compiled libraries on the folder

    Comment by Papa Smurf — December 16, 2012 @ 12:09 am

  10. If LD_LIBRARY_PATH isn’t defined in your .bashrc file, then you can define it like so:

    export LD_LIBRARY_PATH

    The full additions to your .bashrc would look something like this in that case:

    #for steam beta
    export STEAMLIBS
    export LD_LIBRARY_PATH

    I’m not sure what you mean by “Alt way to place the compiled binaries in the folder” though. You can put them in another folder if you wish, so long as you’re consistent. If you’re referring to a different way to tell steam’s binaries to find them, I’m not aware of another manner of doing that. I’m sure there is a way though; it seems there’s always another way when it comes to these things. If I were to hazard a guess, I’d say there’s a good chance most binaries will search the directory –and maybe subdirectories– they reside in for .so’s. For example, Team Fortress 2’s directory structure appears like so (your steam username is going to be different):

    $ cd ~/.local/share/Steam/SteamApps/aggroskater/Team\ Fortress\ 2/
    $ ls 
    bin  config  hl2  hl2_linux  platform  tf
    $ cd bin
    $ ls

    Placing the binaries in either the Team Fortress 2 directory or its bin/ subdirectory might work. But then you have to do that for every game. The idea behind using LD_LIBRARY_PATH is that all binaries _should_ check there for shared libraries. This way, you only need to put the shared libaries in one spot. I would advise you to simply define LD_LIBRARY_PATH in your .bashrc. It’s fine if it’s not already defined.

    Comment by aspensmonster — December 18, 2012 @ 7:59 pm

  11. Two things to add. One, the box on exporting LD_LIBRARY_PATH is missing the ‘B’

    Also, if you have Debian Wheezy 64 bit with Nvidia drivers, you are going to need to add patched libraries for libxvmc1. The change is simple, but it seems like the devs are preventing an easy solution from being applied. Without this fix, you can’t install 32 bit nvidia libraries required for steam. To fix the issue, manually install the patched libraries from (both i386 and amd64) and then install libgl1-nvidia-glx:i386.

    Everything else worked great and thank you for the article!

    Comment by Ryan — December 16, 2012 @ 12:44 pm

  12. It works for me for a few days now.
    I’ve changed my sources list from mint one to testing one. Everything was easier after that and after system-upgrade.
    @Ryan, I’m running now 64 bit testing and I don’t have libgl1-nvidia-glx:i386 installed. Also I don’t have patched libraries for libxvmc1. And Stem is working for me just fine. I have nvidia drivers installed by smxi script and it’s not the Debian way (not from deb package but from nvidia website). Maybe that’s the difference.
    Regards and thanks to aspensmonster for the help 🙂

    Comment by Jack — December 18, 2012 @ 5:14 pm

  13. Wow, thank you, this helped a lot and I was already giving up my hopes of running steam natively on debian.

    Comment by Morgawr — December 20, 2012 @ 4:42 am

  14. multiarch-support 2.16-0experimental1 is available in experimental.

    To install it:
    Add ‘APT::Default-Release “testing”;’ to your /etc/apt/apt.conf (if you use stable or unstable, replace testing with what you use).
    Add an experimental repository to your /etc/apt/sources.list.
    Perform “apt-get update”.
    Then it can be installed with “apt-get install multiarch-support/experimental”.

    Comment by michan — December 25, 2012 @ 6:48 am

  15. sudo dpkg -i steam_1.0.0.18-custom_i386.deb 
    (Reading database ... 133349 files and directories currently installed.)
    Preparing to replace steam (using steam_1.0.0.18-custom_i386.deb) ...
    Unpacking replacement steam ...
    dpkg: dependency problems prevent configuration of steam:
     steam depends on libpixman-1-0 (>= 0.24.4-1).
     steam depends on libsdl1.2debian (>= 1.2.10-1).
     steam depends on libvorbisfile3 (>= 1.1.2); however:
      Package libvorbisfile3:i386 is not installed.
     steam depends on libcairo2 (>= 1.6.0); however:
     steam depends on libcups2 (>= 1.4.0); however:
     steam depends on libgdk-pixbuf2.0-0 (>= 2.22.0); however:
     steam depends on libglib2.0-0 (>= 2.14.0); however:
     steam depends on libgtk2.0-0 (>= 2.24.0); however:
     steam depends on libnspr4 (>=; however:
     steam depends on libnss3 (>= 3.12.3); however:
     steam depends on libopenal1 (>= 1:1.13); however:
     steam depends on libpango1.0-0 (>= 1.22.0); however:
    dpkg: error processing steam (--install):
     dependency problems - leaving unconfigured
    Processing triggers for man-db ...
    Processing triggers for desktop-file-utils ...
    Processing triggers for hicolor-icon-theme ...
    Errors were encountered while processing:

    Comment by MarioMaster100 — January 5, 2013 @ 9:54 pm

  16. Sorry for the delay. It looks like libvorbisfile3:i386 isn’t installed. If you run

    # apt-get -f install

    There’s a good chance apt will install the missing dependency for you in the process of trying to fix the installation.

    Comment by aspensmonster — January 12, 2013 @ 9:21 pm

  17. Nah it didn’t :/

    Comment by MarioMaster100 — January 19, 2013 @ 8:01 pm

  18. I’ve got a new guide up here:

    Regardless, I suspect you’d be able to install the package manually. According to the policy on my machine, the package is in the main debian repos:

    $ apt-cache policy libvorbisfile3
      Installed: 1.3.2-1.3
      Candidate: 1.3.2-1.3
      Version table:
     *** 1.3.2-1.3 0
            500 testing/main amd64 Packages
            100 /var/lib/dpkg/status

    “apt-get install libvorbisfile3” should do the trick to install it.

    Comment by aspensmonster — January 19, 2013 @ 10:30 pm

  19. Ah well I found something that works before I checked back here

    Comment by MarioMaster100 — January 26, 2013 @ 5:59 pm

  20. Hello,

    looks like is the last version where this patch is possible. All later versions check their dependencies also at program-start and fail to install the “needed” packages.
    The good news is that is still working at the moment (even as steam complains at the start about an outdated version).

    Thanks for the howto!

    Comment by DaB. — January 16, 2013 @ 9:48 am

  21. I’ve noticed that. I installed steam using the package on a different machine. The process still worked, along with steam and team fortress 2. It’s annoying that the steam binary is now force-checking the dependencies, but dismissing the shell prompt (the one that keeps asking for sudo password) two or three times gets rid of the prompts and permits me to log in and play TF2.

    Comment by aspensmonster — January 17, 2013 @ 2:01 pm

  22. I keep getting this error everytime I run apt-get update:

    Failed to fetch Unable to find expected entry ‘main/binary-armhf/Packages’ in Release file (Wrong sources.list entry or malformed file)

    I am running cruchbang waldorf which is debian wheezy

    Comment by felix — January 16, 2013 @ 3:07 pm

  23. Crunchbang bases itself off Debian, but their repositories are different from the Debian project’s repositories. The message you’re getting seems to indicate you have armhf as an architecture, which isn’t provided by the repo you linked. It does look like it has binary i386 and amd64 releases though, which is all you’d need for steam. You could show all architectures you use like so:

    $ dpkg --print-architecture
    $ dpkg --print-foreign-architectures

    That would spit out your main architecture and any others you have listed. I’d assume armhf made its way in there. I’m no repo whizz though, so I suppose it could be possible that your /etc/apt/sources.list has the debian repository URLs in it. If this is the case, then I’d suggest swapping them with the appropriate crunchbang repositories (like the one you linked to). Having different repositories for apt can get messy.

    Comment by aspensmonster — January 17, 2013 @ 2:13 pm

  24. Selecting previously unselected package steam.
    (Reading database … 105716 files and directories currently installed.)
    Unpacking steam (from …/steam_1.0.0.21-custom_i386.deb) …
    dpkg: dependency problems prevent configuration of steam:
    steam depends on libjpeg-turbo8; however:
    Package libjpeg-turbo8 is not installed.
    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 desktop-file-utils …
    Processing triggers for hicolor-icon-theme …
    Processing triggers for man-db …
    Errors were encountered while processing:

    I get this error, and “sudo apt-get -f install” dosen’t seen to help.

    Comment by Pailey — January 17, 2013 @ 11:52 pm

  25. I have an updated guide available here:

    However, according to those error messages, it looks like the appropriate packages weren’t removed from the “control” file of the package Valve releases. I.e., you rebuilt the package and named it “steam_1.0.0.21-custom_i386.deb” but forgot to edit the control file to get rid of the dependencies it’s complaining about (libjpeg-turbo8, multiarch-support, libc6:i386, libpulse0:i386).

    “apt-get -f install” should have removed the broken steam package. At which point you can modify the control file and rebuild the custom package and install it.

    Comment by aspensmonster — January 19, 2013 @ 10:33 pm

  26. excellent tutorial thanks so much for writing! almost working on debian unstable x64; will post again once I get the job done (later)

    Comment by Max DeLiso — January 24, 2013 @ 8:08 pm

  27. Thanks for the tutorial. I got everything installed, but now I have an issue whenever I run steam. It says “Fatal Error: Failed to load”.

    I use Debian Wheezy DI Beta 4 amd86_64; any clue on how to fix this?

    Comment by Moose — February 7, 2013 @ 3:21 pm

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

    That will let you know if any libraries are missing that needs.


    $ STEAM_RUNTIME=0 strace -o steamdebug.txt steam

    This just runs strace and dumps output to steamdebug.txt. Sometimes meaningful information can be found as to why a program isn’t operating as expected.

    Comment by aspensmonster — February 8, 2013 @ 1:07 pm

  29. I really appreciate your effort but it’s too hacky to me. I’ll wait official support. For now, Wine is enough to me (I’m always playing L4D2)
    Thanks and keep doing this great job 🙂

    Comment by Willian — February 14, 2013 @ 5:17 pm

RSS feed for comments on this post.

Leave a comment