tried to run steam using the chroot installation as described in the wiki. While I am able to install steam the wrapper script from the wiki does not work. I end up getting a "no protocol specified" error message. Does this mean, that dbus-launcher cannot connect to my display? Any idea how to fix this?

I started getting this as well.
That bug report seems to imply it is related to xorg.conf and a FILES section, but I don't have an xorg.conf file, just xorg.conf.d & there is a new 20opengl.conf

Mon Nov 4 00:06:06 2013 >>> app-admin/eselect-opengl-1.2.7
Sat Jan 3 17:31:34 2015 >>> app-admin/eselect-opengl-1.3.1_________________The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king

I might have a cleaner solution. the libGL is being dropped in different directories to where STEAM cannot find them ... (and for some reason the LDPATH data from 000opengl & ld.so isn't being used/valid)
STEAM is 32bit & if it cannot find the 32bit 3D accel libGL it will fall back to raster (ie sw/mesa)

and it starts fine_________________The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king

Last edited by Naib on Sun Jan 04, 2015 6:34 pm; edited 2 times in total

took me half the day to figure this out, downgraded from xorg 1.16.2-r1 back to 1.15, suspected the xorg update to be the problem._________________I do not have a Superman complex, for I am God not Superman

The issue is that eselect opengl uses ldconfig priorities to determine which libGL libraries get loaded by apps trying to use GL. Normally this works fine; /usr/lib??/opengl/{ati,nvidia}/lib is listed before /usr/lib??, and so the vendor-specific GL gets loaded at runtime.

However, the Steam client messes this up; the loader shell script, located at ~/.local/share/Steam/steam.sh, manually adds "/usr/lib32" to the end of the LD_LIBRARY_PATH environment variable for, according to the comment, compatibility with Ubuntu 12.04. Since LD_LIBRARY_PATH takes precedence over ldconfig, this jumps the Mesa implementation in /usr/lib32 to the top of the list, breaking the priorities set by eselect. That's why Naib's solution, adding the vendor-specific GL library path to LD_LIBRARY_PATH, works and is the right one.

On my system I just have a simple "steam" shell script that sets the variable and then executes the Steam loader.

For anyone that wants a simple, standalone solution that works for any video card, use this shell script to run steam:

I only ask because I have just done it and so far, for the few free demos I have tried, it seems like it is just working. This is under a separate user account on a gentoo based system with open source radeon drivers.

So did I do it right or just get lucky so far? Haven't seen much posted about steam and abi_x86_32 maybe because it's not in stable yet, but it just seems like such a great way to avoid the whole emul-linux/old mesa version mess.

I only ask because I have just done it and so far, for the few free demos I have tried, it seems like it is just working. This is under a separate user account on a gentoo based system with open source radeon drivers.

So did I do it right or just get lucky so far? Haven't seen much posted about steam and abi_x86_32 maybe because it's not in stable yet, but it just seems like such a great way to avoid the whole emul-linux/old mesa version mess.

Oh and Dota 2, it looks great so far.

After researching my Steam options, this is the method I chose. I'm playing TF2 again (cause like everything, it's better on linux), Have just finished Metro 2033 Redux and am starting Metro Last Light Redux (both metro titles were heavily discounted on Steam). All 3 games are working very very well and I am enjoyin linux gaming more than ever. Also played the free-to-play, Fistfull of Frags, which worked as advertised._________________Asus z97-a
Intel i7 4790k
16Gb Mushkin DDR3
Geforce GTX 970
Samsung Evo 840 500Gb +Seagate 1TB HDD
Etc....

I only ask because I have just done it and so far, for the few free demos I have tried, it seems like it is just working. This is under a separate user account on a gentoo based system with open source radeon drivers.

So did I do it right or just get lucky so far? Haven't seen much posted about steam and abi_x86_32 maybe because it's not in stable yet, but it just seems like such a great way to avoid the whole emul-linux/old mesa version mess.

Oh and Dota 2, it looks great so far.

That's exactly what I've been doing ever since I installed steam on my system. Works like a charm

since abi_32 changes past week, i have no sound in steam anymore. which package do i need for 32 bit apps to have sound again. all emul-linux packages are masked here.

i am pretty much helpless

edit: recompiling pulseaudio after kernel update is mandatory

edit2: i think 3.19.3 with xorg 1.17 and ati-drivers-15.1 gives better performance so it was worth fiddling with all that in order to achive performance update _________________I do not have a Superman complex, for I am God not Superman

I only ask because I have just done it and so far, for the few free demos I have tried, it seems like it is just working. This is under a separate user account on a gentoo based system with open source radeon drivers.

So did I do it right or just get lucky so far? Haven't seen much posted about steam and abi_x86_32 maybe because it's not in stable yet, but it just seems like such a great way to avoid the whole emul-linux/old mesa version mess.

Oh and Dota 2, it looks great so far.[/quote]

After researching my Steam options, this is the method I chose. I'm playing TF2 again (cause like everything, it's better on linux), Have just finished Metro 2033 Redux and am starting Metro Last Light Redux (both metro titles were heavily discounted on Steam). All 3 games are working very very well and I am enjoyin linux gaming more than ever. Also played the free-to-play, Fistfull of Frags, which worked as advertised.[/quote]

Since the chroot is giving an issue, I tried the Multilib System without emul-linux but still get the standard error: You are missing the following 32-bit libraries, and Steam may not run:
libc.so.6

My system is default/linux/amd64/13.0/no-multilib Is there something obvious and specific to Steam, etc I am likely missing?

tried to run steam using the chroot installation as described in the wiki. While I am able to install steam the wrapper script from the wiki does not work. I end up getting a "no protocol specified" error message. Does this mean, that dbus-launcher cannot connect to my display? Any idea how to fix this?

thanks
Christian

Quote:

Same issue, I'm trying to see if emerging xorg-x11 in the chroot will work.

Okay I figured out the chroot no protocol issue. What I did was I emerged xorg-x11 in my chroot.

I installed steam from the overlay and I cannot get steam to start again once closing it for the first time. I reinstalled it but the same thing happened where everything would work then it would just not start up again.

Ok I have new install here running true multilib on amd64 and I'm not getting a Steam icon (just a paper icon with a question mark) in the kde tray. KDE is 4.14.3
Steam was installed manually as per the gentoo wiki.

I installed steam from the overlay and I cannot get steam to start again once closing it for the first time. I reinstalled it but the same thing happened where everything would work then it would just not start up again.

I ran into the exact same problem yesterday! It<s super easy to fix. Just uninstall both steam and fglrx, reboot, install steam FIRST, then ati-drivers then it should work easy peasy.

One good example of Steam's bad /tmp use is that it tends to leave a certain file (starting with steam_chrome_shmem...) that will make Steam run very slow if another user runs it and the file is still around from the other. I did just now look at it though to confirm the name of it, and I see my user name is now there, too, so they might have finally fixed this!

I have a problem that sounds like this. Steam is extremely slow. Sometimes it might answer to clicks, but mostly no. I've tried removing it, created a new user to test it (so there's absolutely nothing in homedir) but nothing helps.

Seeing this got me excited that finally I don't have to boot to Ubuntu for games, but no. There's no such file in my /tmp left behind. Steam creates one when it's running.

Problem started when I got rid of emul-linux-x86* packages so I've been quite sure this is about some missing or wrong dependency. I have emerge -e @world after the change so everything should be compiled.

Any ideas?_________________"If I could remember the names of all these particles, I'd be a botanist." - Enrico Fermi
micko@IrcNet, micko_@FreeNode

Assert( Assertion Failed: ClientAPI_InitGlobalInstance: InternalAPI_Init_Internal failed, most likely because you are missing a 32-bit dependency of steamclient.so (the Steam client is a 32-bit app).
):/home/buildbot/buildslave_steam/steam_rel_client_ubuntu12_linux/build/src/steamUI/../common/steam/client_api.cpp:320

~/.steam/bin32 $ LD_LIBRARY_PATH=. ldd steamclient.so | grep not
libnm-glib.so.4 => not found
libnm-util.so.2 => not found
libudev.so.0 => not found

The wiki says networkmanager is optional, and I hope it is because this runaway dependency train has already gone too far at this point. And if it does require libudev.so.0 I'm screwed, because I don't think there's a version of udev in the tree any more that provides that obsolete soname._________________*.ebuild // /etc/service/*

Interestingly enough, I've encountered some similar issues. (Steam games being sluggish to impossibly slow for 3D)
Running Gentoo x64 4.0.5, mesa 10.5.6, llvm 3.6.1, with i5-4590S and a Radeon 270X.

At first I tried the methods listed above, but nothing worked, Steam still identified Intel hardware only, and games still ran horribly. (Presumably in software mode since many OpenGL features were marked disabled)

I then looked into /usr/lib32/ along with /usr/lib64/, and, shock of all shocks, the opengl folder is nowhere to be found! Checking "Show Hidden Files" along with viewing the folder in console as root did nothing. The folder's just... not there. eselect opengl works fine, but the folders are just nonexistant, and it seems Steam can't load ati no matter the command/script.

Am I the only one with this issue right now?

Last edited by Dylanlip on Tue Jun 09, 2015 4:43 pm; edited 1 time in total

The issue micko was having seems to have been related to the issue mentioned in the other thread, and solved here.

I have no idea if (and how) it affects ATI/AMD.

Also, here I get the same (with added libpulse.so.0):

Code:

~/.steam/bin32 $ LD_LIBRARY_PATH=. ldd steamclient.so | grep not
libpulse.so.0 => not found
libnm-glib.so.4 => not found
libnm-util.so.2 => not found
libudev.so.0 => not found

However, my Steam installation is a bit... “different” (or broken, even). I can't start it directly by doing

Code:

~ $ .steam/bin32/steam
You are in the 'publicbeta' client beta.

Aside from that, the only thing it does is run a message box stating “Fatal Error: Failed to load steamui.so”.

Instead, I cd to the Steam directory (which is under home, though I have a symlink there instead so as to have the main stuff elsewhere, too), and run the steam.sh script found there (the same one I originally used to install the client when it was first released).

Interestingly (or not), Naib seems to be using steam.sh as well. I'm getting more and more curious about the differences (which might end up to a total of nothing in terms of what they do)._________________Kind Regards,
~ The Noob Unlimited ~

The "steam" script found in steam_latest.tar.gz should be the same as "~/.local/share/Steam/bin_steam.sh". It is also the same script that the steam-launcher ebuild and Debian package copy to "/usr/bin/steam", although the steam-launcher ebuild patches it slightly for joystick detection.

Attempting to start Steam with "~/.local/share/Steam/bin_steam.sh" will fail with the error "Unknown Steam package 'bin_steam.sh'". This can be fixed by coping "~/.local/share/Steam/bin_steam.sh" to "/usr/local/bin/steam". You can then start Steam by running "steam" in a terminal.

It is (from my experience) probably safe to start Steam with "~/.local/share/Steam/steam.sh" after the Steam bootstrap has been created, which is done when "~/.local/share/Steam/bin_steam.sh" is run at least once. It should also be noted that "~/.local/share/Steam/bin_steam.sh" executes "~/.local/share/Steam/steam.sh". Because of this, starting Steam with "~/.local/share/Steam/bin_steam.sh" is recommended.