ASPENSMONSTER

August 23, 2013

nsa.gov is down (Friday August 23 2013 0330 CST 0930 GMT)

Filed under: Uncategorized — aspensmonster @ 2:32 am

flattr this!

Well that’s interesting:

$ dig nsa.gov

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> nsa.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16857
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;nsa.gov. IN A

;; Query time: 32 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Fri Aug 23 03:24:33 2013
;; MSG SIZE rcvd: 25

$ dig nsa.gov

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.5 <<>> nsa.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7136
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;nsa.gov. IN A

;; Query time: 0 msec
;; SERVER: 74.220.198.186#53(74.220.198.186)
;; WHEN: Fri Aug 23 03:21:57 2013
;; MSG SIZE rcvd: 25

Looks like the Akamai Edge network is resurrecting it. It's resolving to an IP at least. No webpage though.

$ dig www.nsa.gov

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.nsa.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12653
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.nsa.gov. IN A

;; ANSWER SECTION:
www.nsa.gov. 300 IN CNAME www.nsa.gov.edgekey.net.
www.nsa.gov.edgekey.net. 21600 IN CNAME e6655.dscna.akamaiedge.net.
e6655.dscna.akamaiedge.net. 20 IN A 23.77.68.226

;; Query time: 202 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Fri Aug 23 04:04:51 2013
;; MSG SIZE rcvd: 119

Got webpage now. And nsa.gov resolves, but no web there. Edge network still serving.

$ dig nsa.gov @8.8.8.8

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> nsa.gov @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37987
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;nsa.gov. IN A

;; ANSWER SECTION:
nsa.gov. 300 IN A 65.196.127.226
nsa.gov. 300 IN A 65.196.127.225

;; Query time: 100 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Aug 23 04:21:04 2013
;; MSG SIZE rcvd: 57

$ nmap -PN -p 80 65.196.127.225

Starting Nmap 6.25 ( http://nmap.org ) at 2013-08-23 04:24 CDT
Nmap scan report for 65.196.127.225
Host is up.
PORT STATE SERVICE
80/tcp filtered http

$ dig www.nsa.gov @8.8.8.8

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.nsa.gov @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18087
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.nsa.gov. IN A

;; ANSWER SECTION:
www.nsa.gov. 300 IN CNAME www.nsa.gov.edgekey.net.
www.nsa.gov.edgekey.net. 21600 IN CNAME e6655.dscna.akamaiedge.net.
e6655.dscna.akamaiedge.net. 20 IN A 23.77.68.226

;; Query time: 118 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Aug 23 04:20:59 2013
;; MSG SIZE rcvd: 119

$ nmap -PN -p 80 23.77.68.226

Starting Nmap 6.25 ( http://nmap.org ) at 2013-08-23 04:26 CDT
Nmap scan report for a23-77-68-226.deploy.static.akamaitechnologies.com (23.77.68.226)
Host is up (0.037s latency).
PORT STATE SERVICE
80/tcp open http

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 1.0.0.16 deb package. I first ran into these troubles with a fresh install of 1.0.0.20 on a separate machine that functioned with the previous guide, but had annoying update prompts complaining about missing packages. Curious, I checked my 1.0.0.16 install and tried upgrading. The 1.0.0.16 release gave me the impression that it updated –and I could still play Team Fortress 2– but comparing the file structure between 1.0.0.16 and 1.0.0.20 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 1.0.0.16 based installation to the current latest release of 1.0.0.22 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: http://wiki.debian.org/Multiarch/HOWTO

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
amd64

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
i386

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] http://ftp.us.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.us.debian.org/debian/ testing main contrib non-free

deb [arch=amd64,i386] http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ 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 steamui.so 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 1.0.0.16 to 1.0.0.22 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 1.0.0.20 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/steam.pid

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 1.0.0.16, 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:

http://repo.steampowered.com/steam/archive/precise/steam_latest.deb

# 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:
 steam

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 1.0.0.22 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
libpulse0:i386:
  Installed: 2.0-6
  Candidate: 2.0-6
  Version table:
 *** 2.0-6 0
        500 http://ftp.us.debian.org/debian/ 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
libc6:i386:
  Installed: 2.13-37
  Candidate: 2.13-37
  Version table:
 *** 2.13-37 0
        500 http://ftp.us.debian.org/debian/ 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 1.0.0.22 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:

STEAMLIBS=${HOME}/steam-beta/lib

You’ll also want to append this to LD_LIBRARY_PATH:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib64:/usr/lib/jvm/jdk1.7.0_05/jre/lib/amd64:/usr/lib/jvm/jdk1.7.0_05/jre/lib/i386:/usr/lib32:${STEAMLIBS}

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:

export STEAMLIBS
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 http://security.ubuntu.com/ubuntu/pool/main/e/eglibc/libc6_2.15-0ubuntu10.2_i386.deb
$ 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 http://mirror.ovh.net/ubuntu//pool/main/j/jockey/jockey-common_0.9.7-0ubuntu7_all.deb
$ wget http://mirror.ovh.net/ubuntu//pool/main/x/x-kit/python-xkit_0.4.2.3build1_all.deb
# 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 1.0.0.22 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
$ cd DEBIAN
$ tar -xvzf ../control.tar.gz
$ rm ../control.tar.gz
$ vim control

This is my before:

Package: steam
Version: 1.0.0.22
Architecture: i386
Maintainer: Valve Corporation <linux@steampowered.com>
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 (>= 1.8.0.10), 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:1.4.99.1), libxext6, libxfixes3, libxi6 (>= 2:1.2.99.4), libxinerama1, libxrandr2 (>= 2:1.2.99.3), libxrender1, zlib1g (>= 1:1.2.3.3.dfsg)

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

Package: steam
Version: 1.0.0.22-custom
Architecture: i386
Maintainer: Valve Corporation <linux@steampowered.com>
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 (>= 1.8.0.10), 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:1.4.99.1), libxext6, libxfixes3, libxi6 (>= 2:1.2.99.4), libxinerama1, libxrandr2 (>= 2:1.2.99.3), libxrender1, zlib1g (>= 1:1.2.3.3.dfsg)

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 (1.0.0.22-custom) ...
OK
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:

update-progress-bar

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:

list-of-linux-games-in-steam-showing-tf2-uninstalled

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:

steam-library-listing-shows-tf2-installed

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:

image-of-online-play

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
bin_steamdeps.py
steamdeps.txt

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
#
STEAM_RUNTIME=1
 
# 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:
#   http://www.debian.org/doc/debian-policy/ch-relationships.html
#
STEAM_DEPENDENCY_VERSION=1

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

# These are i386 dependencies for Steam itself
libcurl3-gnutls:i386
libgl1-mesa-dri:i386
libgl1-mesa-glx:i386
libjpeg-turbo8:i386
libogg0:i386
libpixman-1-0:i386
libtheora0:i386
libudev0:i386
libvorbis0a:i386
libvorbisenc2:i386
libvorbisfile3:i386
libasound2:i386
libc6:i386
libcairo2:i386
libcups2:i386
libdbus-1-3:i386
libfontconfig1:i386
libfreetype6:i386
libgcc1:i386
libgcrypt11:i386
libgdk-pixbuf2.0-0:i386
libglib2.0-0:i386
libgtk2.0-0:i386
libnspr4:i386
libnss3:i386
libopenal1:i386
libpango1.0-0:i386
libpng12-0:i386
libpulse0:i386
libstdc++6:i386
libx11-6:i386
libxext6:i386
libxfixes3:i386
libxi6:i386
libxinerama1:i386
libxrandr2:i386
libxrender1:i386
zlib1g:i386

# These are dependencies that are commonly required for games
libsdl1.2debian:i386

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

The python script has this notice:

#!/usr/bin/python
"""
	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 :D

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 :D And that was with all settings at HIGH, 4x on both AA and AF. Yeah… Valve is awesome :D

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.

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 http://aspensmonster.com/2013/01/19/updated-procedures-for-installing-steam-for-linux-beta-on-debian-gnulinux-testingwheezy/

Update January 17 2013: I’ve replicated the steps of this guide with 1.0.0.20 version of the steam.deb package (looks like latest is 1.0.0.21). 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 :D

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 http://repo.steampowered.com/steam 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 1.0.0.21 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: http://wiki.debian.org/Multiarch/HOWTO

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
amd64

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
i386

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] http://ftp.us.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.us.debian.org/debian/ testing main contrib non-free

deb [arch=amd64,i386] http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ 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 steamui.so 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:

http://media.steampowered.com/client/installer/steam.deb

# 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:
 steam

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 1.0.0.0– 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 “steam.sh” 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 :D

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
libpulse0:i386:
  Installed: 2.0-6
  Candidate: 2.0-6
  Version table:
 *** 2.0-6 0
        500 http://ftp.us.debian.org/debian/ 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
libc6:i386:
  Installed: 2.13-37
  Candidate: 2.13-37
  Version table:
 *** 2.13-37 0
        500 http://ftp.us.debian.org/debian/ 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:

STEAMLIBS=${HOME}/steam-beta/lib

You’ll also want to append this to LD_LIBRARY_PATH:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib64:/usr/lib/jvm/jdk1.7.0_05/jre/lib/amd64:/usr/lib/jvm/jdk1.7.0_05/jre/lib/i386:/usr/lib32:${STEAMLIBS}

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

export STEAMLIBS
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 http://security.ubuntu.com/ubuntu/pool/main/e/eglibc/libc6_2.15-0ubuntu10.2_i386.deb
$ 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 http://mirror.ovh.net/ubuntu//pool/main/j/jockey/jockey-common_0.9.7-0ubuntu7_all.deb
$ wget http://mirror.ovh.net/ubuntu//pool/main/x/x-kit/python-xkit_0.4.2.3build1_all.deb
# 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
$ cd DEBIAN
$ tar xvzf ../control.tar.gz
$ rm ../control.tar.gz
$ vim control

This is my before:

Package: steam
Version: 1.0.0.16
Architecture: i386
Maintainer: Valve Software LLC <ubuntu-support@valvesoftware.com>
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 (>= 1.8.0.10), 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:1.4.99.1), libxext6, libxfixes3, libxi6 (>= 2:1.2.99.4), libxrandr2 (>= 2:1.2.99.3), libxrender1, zlib1g (>= 1:1.2.3.3.dfsg)

And this is my after:

Package: steam
Version: 1.0.0.16-custom
Architecture: i386
Maintainer: Valve Software LLC <ubuntu-support@valvesoftware.com>
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 (>= 1.8.0.10), 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:1.4.99.1), libxext6, libxfixes3, libxi6 (>= 2:1.2.99.4), libxrandr2 (>= 2:1.2.99.3), libxrender1, zlib1g (>= 1:1.2.3.3.dfsg)

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 (1.0.0.16-custom) ...
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 :D

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 :D And that was with all settings at HIGH, 4x on both AA and AF. Yeah… Valve is awesome :D

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.

Older Posts »