Yeah don't use Steam on Gentoo until SDL team has officially released 2.0 and it is included in the one and only main tree in ... some weeks!
As overlays are evil, you can use Ubuntu or ArchLinux until then!

Yeah don't use Steam on Gentoo until SDL team has officially released 2.0 and it is included in the one and only main tree in ... some weeks!
As overlays are evil, you can use Ubuntu or ArchLinux until then!

I deal with it, step by step. And I invest quite some spare time in the overlay to make steam work and convenient for people. What annoys me is when people call our work here broken or unrecommended as if this couldn't have happen with an ebuild in main tree as well. Of course people should be careful with overlays but that should be clear to everyone.

I deal with it, step by step. And I invest quite some spare time in the overlay to make steam work and convenient for people. What annoys me is when people call our work here broken or unrecommended as if this couldn't have happen with an ebuild in main tree as well. Of course people should be careful with overlays but that should be clear to everyone.

Seems no one considered to add any of that to sunrise where it gets a review. (steam-installer, not SDL-2)
And even if you can't add ebuilds to sunrise (SDL-2 would not be allowed since it would overwrite an in-tree ebuild), you can still get a review.

Minimum testing would be to
1) enable all ABIs and enable all useflags
2) enable all ABIs and disable all useflags.
4) only enable default ABI, leave useflags to default

But people seem to rather do things on their own. Guess why we have "herds". Because many people look at the same ebuilds then, maybe even review one another before comitting non-trivial changes. A new major version of a widely used library is a good example for that and is delicate to handle, because it has many consumers and can break many things.

As for "broken overlay"... I have never used the steam overlay, I rather had gamerlay in mind which I tinker with from time to time, or rework totally broken ebuilds. Most of them would not be that broken if they got a review.

I appreciate if people work on gentoo, not on overlays (except sunrise, which is our user overlay). But most don't have patience, but DO have time (e.g. people comitting to science overlay for over 4 years and still no dev, wtf??). That is partly our fault, because we don't force those people into recruitment early enough, but also a bad side-effect of the easiness of overlays.

At best, overlays should _only_ be used as a testing ground, e.g. when introducing non-trivial eclasses or major changes. That said... the multilib-conversion stuff was not done properly. Blame us.

empanyc wrote:

Do you really blame me for disabling steam runtime?

Not necessarily, but you are ranting about gentoo devs not importing an unstable library. I can just say... well.

I add it to gamerlay in regular terms and it creates problems as people can't find ebuilds for some additional libraries that are only available in steam-overlay because I don't want to disturb non-steam users. I admit that my primary objective is to get things working, so people can use their spare time for playing instead of searching the web for workarounds.

hasufell wrote:

Not necessarily, but you are ranting about gentoo devs not importing an unstable library. I can just say... well.

What I meant was, by that time, using a "broken" overlay/ebuild was the only chance to get steam running again.

so people can use their spare time for playing instead of searching the web for workarounds.

That assumes that those ebuilds are working and cause no breakage.

And that is exactly what we are trying to do and is also the reason that the tree policy is a bit more strict. Especially when adding libraries to overlays it is a _very_ delicate situation, because you don't have any access to the main tree "profiles/" folder and will not be able to contain breakage the way we are able. That is even more delicate when it's a new slot/major version of an already existing library. Do you know that most ebuilds don't depend on a SLOT of libsdl which means that libsdl-1.2 could even be unmerged by portage because libsdl-2 satisfies all those ebuilds? Are you able to fix those ebuilds? That would require a mass commit.

Regarding irrlicht in gamerlay I also received a bugreport and had to explain the user not to use that version, but only the in-tree one. That was because I discovered a fatal bug in the tree ebuild which was not a build-time bug and would only show up on particular library consumers under particular circumstances. I can't have an eye on overlays to fix such things too.

I never got a single word from any of you in #gentoo-dev-help, #gentoo-sunrise or even #gentoo-games that you plan to add libSDL-2 to an overlay and want to know how to do that properly.
My answer would have been: do NOT slot it, but rename it to libsdl2. That way it is completely out-of-tree, does not mess with libsdl dependency resolution etc.

So: communicate, ask, contribute. Not everyone is easy to work with, but rather take that annoyance than not contributing at all.

empanyc wrote:

hasufell wrote:

Not necessarily, but you are ranting about gentoo devs not importing an unstable library. I can just say... well.

What I meant was, by that time, using a "broken" overlay/ebuild was the only chance to get steam running again.

I start to agree with you on this one. I think it would be ok to add it masked and fix all ebuilds to use the appropriate slot.
But the maintainer of libSDL disagrees and he has the last word and usually knows the situation best.

On another note: hard-masking was never actually meant as another level of unstable ~arch. That is common practice today in the tree, but not everyone agrees with it and not everyone does it.

Hm, okay, I see your point. Although, in this case, it would be more correct to say that the ebuilds in main tree that do not depend on a slotted version are broken, not our libSDL ebuild or not?
Sorry for the noise and thanks for the explanation!

I tried steam at the beginning using gamer-overlay and I remember being able to play TF2, even if with poor performances.
Today I had some spare time to try it again.

Upgrading steam was unsuccessful so I decided to reset my steam installation, remove the overlay and do it manually (I had more time to spend then the last occasion) following the wiki page.

What I did was

did steam --reset

unmerging the steam ebuilds

creating the @steam sets

downloading latest steam and script (linked in wiki page)

copied the bootstrap, .desktop and script in a temporary folder

executed the script

(made sure I had unmasked and installed the last nvidia drivers)

I think that this didn't actually executed the script because I didn't removed the .steam directory (I didn't want to re-download the games)

Steam started without issues and I was able to download Portal Beta (which I already owned on Windows from a long time).

Here comes the issues:
Portal:

sometimes when I launch it the screen goes black, I can here the game sounds but can't see anything. ALT+TAB switch me back to the desktop while the game crash. (happen often but without an apparent logic)

sometime the game is fluid as it is in windows, sometime it become sluggish / unplayable and crash to desktop

TF2:

I can't play TF2 anymore: when I execute it it loads up, I can see my mouse cursor but clicking or moving around produce no effect

as Portal sometimes it is black when I execute it

I do not know exactly which kind of informations can help you.

My system is an old laptop (~6 years old) with NVidia (2 core with SLI) 8600.

I execute steam using ~/.local/share/Steam/steam.sh
on the command line see many warning / errors while it runs

do you suggest to get rid completely of steam and retry with the wiki page?
what kind of information can help you debug my issues?

I just tried to do a world update after probably about a month (I know, tsk, tsk. I was busy.) After some tedium that I think was related to the multilib transition, I eventually got things to install, except that I got this:

Code:

WARNING: One or more updates have been skipped due to a dependency conflict:

Looks like some substitute libraries from steam-overlay are blocking an upgrade from the main tree. Except it seems to me gobject-introspection-1.34.2-r1 should meet the requirement it claims to conflict with: At least version 1, abi_x86_32 enabled, abi_x86_64 enabled for good measure. I don't know much about how dependencies are specified.

I'll also admit to not being the most informed on how overlays interact with the main tree. Does anyone have any guidance on how to fix this?

After updating my laptop last week I can no longer play games based on the source engine. The error I get is "Could not find required OpenGL entry point 'glGetError'! Either your video card is unsupported, or your OpenGL driver needs to be updated." This appears to be quite a common error but none of the suggestions I'm getting through Google help (such as recompiling mesa/nvidia-drivers). Other games and OpenGL applications work.

My laptop is a Lenovo W530 with Intel i915 and nVidia Quadro K2000M GPUs using Optimus. I have installed bumblebee with virtualGL to control the nVidia card.

## Server options. Any change made in this section will need a server restart
# to take effect.
[bumblebeed]
# The secondary Xorg server DISPLAY number
VirtualDisplay=:8
# Should the unused Xorg server be kept running? Set this to true if waiting
# for X to be ready is too long and don't need power management at all.
KeepUnusedXServer=false
# The name of the Bumbleblee server group name (GID name)
ServerGroup=bumblebee
# Card power state at exit. Set to false if the card shoud be ON when Bumblebee
# server exits.
TurnCardOffAtExit=false
# The default behavior of '-f' option on optirun. If set to "true", '-f' will
# be ignored.
NoEcoModeOverride=false
# The Driver used by Bumblebee server. If this value is not set (or empty),
# auto-detection is performed. The available drivers are nvidia and nouveau
# (See also the driver-specific sections below)
Driver=nvidia
# Directory with a dummy config file to pass as a -configdir to secondary X
XorgConfDir=/etc/bumblebee/xorg.conf.d

## Client options. Will take effect on the next optirun executed.
[optirun]
# Acceleration/ rendering bridge, possible values are auto, virtualgl and
# primus.
Bridge=auto
# The method used for VirtualGL to transport frames between X servers.
# Possible values are proxy, jpeg, rgb, xv and yuv.
VGLTransport=proxy
# List of paths which are searched for the primus libGL.so.1 when using
# the primus bridge
PrimusLibraryPath=/usr/lib/primus:/usr/lib32/primus
# Should the program run under optirun even if Bumblebee server or nvidia card
# is not available?
AllowFallbackToIGC=false

# Driver-specific settings are grouped under [driver-NAME]. The sections are
# parsed if the Driver setting in [bumblebeed] is set to NAME (or if auto-
# detection resolves to NAME).
# PMMethod: method to use for saving power by disabling the nvidia card, valid
# values are: auto - automatically detect which PM method to use
# bbswitch - new in BB 3, recommended if available
# switcheroo - vga_switcheroo method, use at your own risk
# none - disable PM completely
# https://github.com/Bumblebee-Project/Bumblebee/wiki/Comparison-of-PM-methods

# If the X server does not automatically detect your VGA device,
# you can manually set it here.
# To get the BusID prop, run `lspci | egrep 'VGA|3D'` and input the data
# as you see in the commented example.
# This Setting may be needed in some platforms with more than one
# nvidia card, which may confuse the proprietary driver (e.g.,
# trying to take ownership of the wrong device). Also needed on Ubuntu 13.04.
# BusID "PCI:01:00:0"

# Setting ProbeAllGpus to false prevents the new proprietary driver
# instance spawned to try to control the integrated graphics card,
# which is already being managed outside bumblebee.
# This option doesn't hurt and it is required on platforms running
# more than one nvidia graphics card with the proprietary driver.
# (E.g. Macbook Pro pre-2010 with nVidia 9400M + 9600M GT).
# If this option is not set, the new Xorg may blacken the screen and
# render it unusable (unless you have some way to run killall Xorg).
Option "ProbeAllGpus" "false"

After updating my laptop last week I can no longer play games based on the source engine. The error I get is "Could not find required OpenGL entry point 'glGetError'! Either your video card is unsupported, or your OpenGL driver needs to be updated." This appears to be quite a common error but none of the suggestions I'm getting through Google help (such as recompiling mesa/nvidia-drivers). Other games and OpenGL applications work.

My laptop is a Lenovo W530 with Intel i915 and nVidia Quadro K2000M GPUs using Optimus. I have installed bumblebee with virtualGL to control the nVidia card.

## Server options. Any change made in this section will need a server restart
# to take effect.
[bumblebeed]
# The secondary Xorg server DISPLAY number
VirtualDisplay=:8
# Should the unused Xorg server be kept running? Set this to true if waiting
# for X to be ready is too long and don't need power management at all.
KeepUnusedXServer=false
# The name of the Bumbleblee server group name (GID name)
ServerGroup=bumblebee
# Card power state at exit. Set to false if the card shoud be ON when Bumblebee
# server exits.
TurnCardOffAtExit=false
# The default behavior of '-f' option on optirun. If set to "true", '-f' will
# be ignored.
NoEcoModeOverride=false
# The Driver used by Bumblebee server. If this value is not set (or empty),
# auto-detection is performed. The available drivers are nvidia and nouveau
# (See also the driver-specific sections below)
Driver=nvidia
# Directory with a dummy config file to pass as a -configdir to secondary X
XorgConfDir=/etc/bumblebee/xorg.conf.d

## Client options. Will take effect on the next optirun executed.
[optirun]
# Acceleration/ rendering bridge, possible values are auto, virtualgl and
# primus.
Bridge=auto
# The method used for VirtualGL to transport frames between X servers.
# Possible values are proxy, jpeg, rgb, xv and yuv.
VGLTransport=proxy
# List of paths which are searched for the primus libGL.so.1 when using
# the primus bridge
PrimusLibraryPath=/usr/lib/primus:/usr/lib32/primus
# Should the program run under optirun even if Bumblebee server or nvidia card
# is not available?
AllowFallbackToIGC=false

# Driver-specific settings are grouped under [driver-NAME]. The sections are
# parsed if the Driver setting in [bumblebeed] is set to NAME (or if auto-
# detection resolves to NAME).
# PMMethod: method to use for saving power by disabling the nvidia card, valid
# values are: auto - automatically detect which PM method to use
# bbswitch - new in BB 3, recommended if available
# switcheroo - vga_switcheroo method, use at your own risk
# none - disable PM completely
# https://github.com/Bumblebee-Project/Bumblebee/wiki/Comparison-of-PM-methods

# If the X server does not automatically detect your VGA device,
# you can manually set it here.
# To get the BusID prop, run `lspci | egrep 'VGA|3D'` and input the data
# as you see in the commented example.
# This Setting may be needed in some platforms with more than one
# nvidia card, which may confuse the proprietary driver (e.g.,
# trying to take ownership of the wrong device). Also needed on Ubuntu 13.04.
# BusID "PCI:01:00:0"

# Setting ProbeAllGpus to false prevents the new proprietary driver
# instance spawned to try to control the integrated graphics card,
# which is already being managed outside bumblebee.
# This option doesn't hurt and it is required on platforms running
# more than one nvidia graphics card with the proprietary driver.
# (E.g. Macbook Pro pre-2010 with nVidia 9400M + 9600M GT).
# If this option is not set, the new Xorg may blacken the screen and
# render it unusable (unless you have some way to run killall Xorg).
Option "ProbeAllGpus" "false"

anyway... sdl2 is nearing official release. Once it is it shall be in the tree and then we can have an emul update and this will fix this issue_________________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

thats kinda why I hate overlays and rather layman -a, copy out the ebuilds I want to my local_________________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

thats kinda why I hate overlays and rather layman -a, copy out the ebuilds I want to my local

my post in the other thread disappeared so I'm gonna post it here again

a) don't use steam-overlay unless you really need to. You can install and run steam without it
b) if you use steam-overlay, then mask all packages by default via package.mask: */*::steam-overlay
and only put those packages in package.unmask that you really want
c) do the same with gamerlay if you happen to use it
d) do NOT set STEAM_RUNTIME=0