The first Steam for Linux Beta has been released, it is available at http://media.steampowered.com/client/installer/steam.deb Reproducible: Always
Created attachment 328652 [details] steam-9999.ebuild First attempt for an ebuild. It basically unpacks the deb and moves stuff into position. The installed binary is basically an shell script installer that downloads stuff into ${HOME}/Steam and tries to start the actual client from there. Which fails for me currently with the message: Installing breakpad exception handler for appid(steam)/version(1352224866_client)
Created attachment 328660 [details] Ebuild with dependencies This adds the dependencies from the deb control file. A crucial one is the gcc-4.6 dependency, as some libraries (not all …) want version GLIBCXX_3.4.15 in the libstdc++, which seems to be provided by gcc-4.6. Testing now :)
Created attachment 328662 [details] License License provided in the deb-file.
I have unpacked the .deb by hand and have the same message. But the message is normal, the same message appears also on Ubuntu 12.04 32bit where steam works. I think there are some missing 32bit libraries.
The problem seems to be that crashreporter.so (which is the file that the "breakpad"-message originates from) seems to swallow all linking failures. You will most certainly need to install the emul packages on amd64 (i.e. http://forums.gentoo.org/viewtopic-p-7179336.html#7179336).
Created attachment 328664 [details] steam-9999.ebuild ; merged x86 and amd64 I merged the x86 and amd64 ebuild
Created attachment 328670 [details] steam-9999.ebuild; merged x86 and amd64 Fixed QA notice for steam.desktop file
Created attachment 328678 [details] steam-9999.ebuild Improved dependency list. I only added dependencies that I verified to be necessary. Maybe other emul-linux-* packages are necessary that I had already preinstalled. Steam starts, but segfaults shortly after. See http://forums.gentoo.org/viewtopic-p-7179406.html#7179406 .
Created attachment 328682 [details] steam-9999.ebuild Fixes bash error messages but for the current steam version they have no impact on the success/failure of the installation. I'm still getting a segfault after launch of steam.
The ebuild might help to figure out dependencies, but it's probably better to start a gentoo wiki page for this. There is not much point in creating an ebuild, because this is just an installer, nothing more. The real games files and data get placed somewhere in $HOME and are meant to be controlled by steam/auto-updater, not the package manager. Please consider to start a wiki page. https://wiki.gentoo.org
Imho, it might be better to call it steam-installer and use it to pull in the dependencies required to start the later installed steam executable. Maybe it is also useful to add additional game dependencies as use-conditional deps in the installer ebuilds? Wiki is a good idea.
I agree with Mario, renaming to steam-installer is a good idea. Maybe Valve will provide proper versioned packages with all program files in the future which can be used with package managers. Until then it is nice to have an installer ebuild.
Created attachment 328704 [details] steam-installer-9999.ebuild Renamed ebuild, added info output for user and made client dependencies optional through use-flags. I'm not sure if the use-flag name is appropriate.
On 64bit, steam is making calls for libraries in emul-linux-x86-gtklibs, and it looks like emul-linux-x86-compat can also resolve the need for GLIBCXX_3.4.15. libappindicator is unresolved.
Please ignore/delete my last comment, seems I'm behind and need to do some research.
Created attachment 328742 [details] steam-installer-9999.ebuild Updated amd64 dependencies
Created attachment 328754 [details] steam-installer-9999.ebuild Updated dependencies, again. Somehow emul-*-sdl first created a segfault, now it's only working with it. If you find/solve issues, please also see/edit http://wiki.gentoo.org/wiki/Steam
(In reply to comment #17) > Updated dependencies, again. Somehow emul-*-sdl first created a segfault, > now it's only working with it. Thanks, the `!...sdl` line of the old ebuild caused a block with wine so that's fixed as well.
Comment on attachment 328754 [details] steam-installer-9999.ebuild >inherit eutils unpacker you don't use eutils so drop it >KEYWORDS="~x86 ~amd64" add -* to the start of this and keep it sorted >IUSE="+client-deps" i don't see the point in making this a USE flag >S="${WORKDIR}/" drop the trailing slash and quotes > # fix QA notice sed/patches belong in src_prepare, not src_unpack > sed -r -i "s/^(MimeType=.*)/\1;/" usr/share/applications/steam.desktop > sed -r -i "s/^(Actions=.*)/\1;/" usr/share/applications/steam.desktop use the -e option and merge into a single `sed` command also, use line matching instead of whole line replacing '/^(MimeType|Actions)=.*[^;]$/s:^:;:' > # fix bash error and replace apt-get command with user info > # not important for current steam version these should be a patch instead of a sed >src_install() { > exeinto "/usr/bin" > doexe "usr/bin/steam" dobin > insinto "/usr/lib/" > doins -r usr/lib/steam those most likely should be executable (i haven't looked), and should be into /usr/$(get_libdir) > dodoc usr/share/doc/steam/{changelog.gz,copyright} do not install copyright/license files with dodoc
Created attachment 328782 [details] steam-installer-9999.ebuild (In reply to comment #19) > you don't use eutils so drop it Looks like it is required for "doicon". > >IUSE="+client-deps" > > i don't see the point in making this a USE flag This ebuild installs an installer that is actually a shell script. These dependencies are required for the client that the installer fetches from Valve's servers. As the dependencies are not actually required for the installed files of this ebuild I was unsure how to handle it. > >S="${WORKDIR}/" > > drop the trailing slash and quotes Okay, thought quotes are safer, e.g., for directories with spaces. > > # fix QA notice > > sed/patches belong in src_prepare, not src_unpack > > > sed -r -i "s/^(MimeType=.*)/\1;/" usr/share/applications/steam.desktop > > sed -r -i "s/^(Actions=.*)/\1;/" usr/share/applications/steam.desktop > > use the -e option and merge into a single `sed` command > > also, use line matching instead of whole line replacing > '/^(MimeType|Actions)=.*[^;]$/s:^:;:' My sed skills are currently to low to get this work. I will read the manual. > > insinto "/usr/lib/" > > doins -r usr/lib/steam > > those most likely should be executable (i haven't looked), and should be > into /usr/$(get_libdir) They install an archive and a unused file. I guess they should go somewhere else. I applied the quick fixes based on your comments, thanks for that, but I'm not sure if it's worth putting too much time in this ebuild. I think many things will change anyway during this closed beta.
Created attachment 328784 [details] fixed deps and patch
Created attachment 328786 [details, diff] patch to strip unwanted functions from the steam installer
Added a new version aif the installer ebuild, with fixed deps and a patch to remove the extra-package check, at it is ubuntu specific.
The ebuild does not work for me on amd64, the client crashes: fabian@fabian-thinkpad ~ $ LANG=C steam Setting up steam platform in /home/fabian/Steam ILocalize::AddFile() failed to load file "public/steambootstrapper_english.txt". Installing breakpad exception handler for appid(steam)/version(1352224866_client) unlinked 1 orphaned pipes removing stale semaphore last operated on by process 11784 with name 0eBlobRegistryMutex_669BEA2EC606024B49B05E1F0BB0E38B removing stale semaphore last operated on by process 11784 with name 0eBlobRegistrySignal_669BEA2EC606024B49B05E1F0BB0E38B removing stale semaphore last operated on by process 11784 with name 0emSteamEngineInstance removing stale semaphore last operated on by process 11784 with name 0eSteamEngineLock [1108/143418:WARNING:proxy_service.cc(646)] PAC support disabled because there is no system implementation Uploading dump (in-process) [proxy ''] /tmp/dumps/crash_20121108143420_1.dmp success = yes response: CrashID=bp-ecb450ae-cd79-4308-b20d-9b51c2121108 /home/fabian/Steam/steam.sh: line 113: 11830 Segmentation fault ${DEBUGGER} "${STEAMROOT}"/${PLATFORM}/${STEAMEXE} "$@" I could attach the dump if it helps.
where did the pulse audio dependency come from? works fine without it from what I can tell.
Which one are you using? The one from Thomas is not based on the latest previous version in this bug.
the most recent ebuild with the tabbing cleaned up and less the pulseaudio dependency works here on amd64.
(In reply to comment #26) > Which one are you using? > The one from Thomas is not based on the latest previous version in this bug. I now tried both (and removed ~/Steam in between). Both crash with the same message.
Pulse audio is not required. I have it working without, its optional. more importantly, emul-linux-x86-opengl-20121028 contains mesa 8 but steam needs mesa9. I had to build mesa 9 in a chroot and copy the libGL.so over to /usr/lib32 on my main system to get steam working. Once I did that it worked flawlessly. I believe this only applies to intel video cards (I have sandybridge). Nvidia and ATi provide their own opengl which is used instead.
Florian: I only added additional emul-* packages as dependencies, as Steam did not work without them on my laptop. Other changes are only ebuild improvements and should not interfere with the client. Maybe Valve made changes in the meantime, we'll never know. I'm also not sure if the arch-independent deps of Thomas are really necessary. Afaik, the required fontconfig libs are provided by the emul-packages, for example.
Created attachment 328812 [details] ebuild with fixed deps and patch replaced tabs with spaces and made the pulseaudio dep useflag dependent, fixed binary name
(In reply to comment #30) > I'm also not sure if the arch-independent deps of Thomas are really > necessary. Afaik, the required fontconfig libs are provided by the > emul-packages, for example. I had checked the usage of the most dependencies via strace at runtime. The fontconfig is used from the 64bit package, so i added it. I have no clean install at the moment to verify if it is realy needed.
1) Works for me without GCC 4.6 (I have GCC 4.7.2 installed) on amd64 2) Please provide use flags for different games. For example, SpaceChem has Ubuntu-specific laucher that resolves dependencies, Trackmania Nations Forever is in list of linux games, but requires wine, etc.
(In reply to comment #33) > 1) Works for me without GCC 4.6 (I have GCC 4.7.2 installed) on amd64 Ok, maybe >=gcc4.6 would be the better choise > 2) Please provide use flags for different games. For example, SpaceChem has > Ubuntu-specific laucher that resolves dependencies, Trackmania Nations > Forever is in list of linux games, but requires wine, etc. That is another problem and could solved by meta-packages. But this is not a usecase for an ebuild i think. You would have to maintain the ebuild for every single game that comes out. In a year you would have hundrets of useflags.
> But this is not a usecase for an ebuild i think. so you think it is need to emerge steam + all the games I have and then download those games by the steam client?
(In reply to comment #35) > > But this is not a usecase for an ebuild i think. > so you think it is need to emerge steam + all the games I have and then > download those games by the steam client? You would have to: - emerge steam-installer - install steam - emerge game dependencies - install game via steam I think it would be possible to provide an overlay with sets for the dependencies of specific games. But i don't see a proper way to handle the dependencies for games via useflags. The games are not handeld by the package manager. Also to keep the ebuild up2date the maintainer would have to buy every single game that comes for linux, to verify the deps.
Getting an error when launching steam: $ steam Installing breakpad exception handler for appid(steam)/version(1352224866_client) any ideas?
(In reply to comment #37) > Getting an error when launching steam: > $ steam > Installing breakpad exception handler for > appid(steam)/version(1352224866_client) > > any ideas? https://forums.gentoo.org/viewtopic-t-930354.html https://wiki.gentoo.org/wiki/Steam
In conclusion the best solution I think is to have metapackages (maybe in gamerlay): games-sports/trackmania-nations-steamdeps(depends on app-emulation/wine and binfmt-support) games-rpg/amnesia-tdd-steamdeps (depends on something) Of course, it is need to print a message about these packages in postinst of steam-installer's ebuild.
or by sets, no matter
Yeah, I do not think it is a good idea to try to create an ebuild for every single game. This is not in the scope of ebuilds anymore. I think it is a good idea to package the steam-installer so interested people can easily install the Steam client on their machines, with all basic dependencies installed. The ebuild should elog a reference to the wiki where game-specific documentation (e.g. their dependencies, driver requirements etc) could be documented. Regarding the ebuild: It seems like media-libs/mesa-9.x is needed if no proprietary graphic drivers are installed, otherwise it complains about missing symbols: fabian@fabian-thinkpad ~ $ LD_DEBUG="libs" steam 2>&1 | grep error: 17496: /home/fabian/Steam/ubuntu12_32/steam: error: symbol lookup error: undefined symbol: gtk_widget_device_is_shadowed (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glBindFragDataLocationIndexed (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glBlitFramebufferEXT (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glBlitFramebufferANGLE (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glGetQueryObjecti64v (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glGetQueryObjectui64v (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glGetTranslatedShaderSourceANGLE (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glQueryCounter (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glRenderbufferStorageMultisampleANGLE (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glTexStorage2DEXT (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glGenFencesNV (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glDeleteFencesNV (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glSetFenceNV (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glTestFenceNV (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glFinishFenceNV (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glIsFenceNV (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glGetFenceivNV (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glXCopySubBufferMESA (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glXBindTexImageEXT (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glXReleaseTexImageEXT (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glXSwapIntervalEXT (fatal) 17496: /usr/lib32/libGL.so.1: error: symbol lookup error: undefined symbol: glXCreateContextAttribsARB (fatal) On amd64 mesa-9 is not provided app-emulation/emul-linux-x86-xlibs yet. I have only nouveau and intel drivers installed.
Sorry, libGL.so is part of app-emulation/emul-linux-x86-opengl, not -xlibs.
(In reply to comment #38) > (In reply to comment #37) > > Getting an error when launching steam: > > $ steam > > Installing breakpad exception handler for > > appid(steam)/version(1352224866_client) > > > > any ideas? > > https://forums.gentoo.org/viewtopic-t-930354.html > https://wiki.gentoo.org/wiki/Steam works for me after manually merge app-emulation/emul-linux-x86-gtklibs-20121028 app-emulation/emul-linux-x86-compat-20121028 and app-emulation/emul-linux-x86-sdl-20121028 thanks
Fabian: I have amd64 + intel HD graphics and I had to build mesa-9 in a chroot and copy over to get it working. the emul-opengl package does not work for intel cards. Does anyone know the correct way to make a new emul-package? I did it hackily and just cp'd the files into /usr/lib32. but there is definitely a dependency for mesa-9.
Thanks for the hint, Jason. I think I'll wait for a proper version of the emul package, though.
Opened a bug for (In reply to comment #45) > Thanks for the hint, Jason. I think I'll wait for a proper version of the > emul package, though. I have opened a bug for this and set it as blocker.
Hi all. Using attached ebuilds in a fresh x86 chrooted environment it is clear that "net-print/cups" is a missing dependency: it is needed by the bundled "libcef.so".
Created attachment 328988 [details] ebuild with fixed deps and patch - changed dep to gcc from slot to version >=4.6 - added cups as dep for x86
(In reply to comment #47) > Using attached ebuilds in a fresh x86 chrooted environment it is clear that > "net-print/cups" is a missing dependency: it is needed by the bundled > "libcef.so". I don't see why a Common Unix Printing System would be a dependency. `e-file libcef.so` doesn't give a match and `equery f cups | grep -i cef` doesn't give a match either. Doing some research this appears to be from https://code.google.com/p/chromiumembedded/ which doesn't have an ebuild yet. But one might wonder, is this even necessary as a dependency? I didn't install any such thing and have /home/tomwij/Steam/ubuntu12_32/libcef.so (In reply to comment #48) > - added cups as dep for x86 Please verify whether it makes sense before adding a dependency like this one.
> it is _needed by_ the bundled "libcef.so". I think I need to read better, ignore my previous comment. >_<
Hmm, to avoid problems like the above missing dependency in comment 47; perhaps it might be handy to run `ldd` over all the .so files from a chroot to see what else misses. This is probably a handy technique to apply to each game as well...
ubuntu12_32 % ldd libcef.so | grep cups [1:06:08] libcups.so.2 => /usr/lib32/libcups.so.2 (0xf40d1000) Yes, it should have cups dependency.
and should not have dependency on chromium embedded framework
(In reply to comment #53) > and should not have dependency on chromium embedded framework Yeah, as I said the comment after, that one can be ignored. Misread the last words. Though I'd wonder if this perhaps can be made optional by adding the cups USE flag... If you don't have a printer or don't want to print, it doesn't make much sense to pull in cups to use Steam. Which is why I was so surprised to see that dependency pop up at first.
(In reply to comment #54) > (In reply to comment #53) > > and should not have dependency on chromium embedded framework > > Yeah, as I said the comment after, that one can be ignored. Misread the last > words. > > Though I'd wonder if this perhaps can be made optional by adding the cups > USE flag... > > If you don't have a printer or don't want to print, it doesn't make much > sense to pull in cups to use Steam. Which is why I was so surprised to see > that dependency pop up at first. Maybe we could replace the internal chrome lib. But this would need some "hacking" at the client. Also the searchpath does containt the installation directory in the userdir first, so it would be not easy at all i think.
(In reply to comment #55) > Maybe we could replace the internal chrome lib. But this would need some > "hacking" at the client. Also the searchpath does containt the installation > directory in the userdir first, so it would be not easy at all i think. Perhaps it would be easier to try to push through the red tape and ask upstream to add a check for an external library. I don't know how receptive they would be to us at present. On a side note, I wish that steam had a generic command line output that read xx game died due to missing libyy.so so that the community could easily find relevent help what needs to be fixed.
(In reply to comment #56) > Perhaps it would be easier to try to push through the red tape and ask > upstream to add a check for an external library. I don't know how receptive > they would be to us at present. Opened a topic in the steam community. Don't know if we would get an answer on this, but it could not harm. http://steamcommunity.com/app/221410/discussions/0/882965239739687747/
After a deeper look, if have seen thet the installer is not versionless. It contains the "beta" package at the moment. Also the startup script does not be downloaded from upstream. So we should not use -9999 as version i think.
It doesn't matter if you plan to print something or not. If the lib wants libcups, it has to get it. And I guess that there is a reason why they provide some own libraries and don't use the ones installed by the OS like they do with X/cups/etc. Maybe they hacked stuff into them themselves or they want an exactly predictable behavior. As it's always the same URL we use to download the installer, there is currently no point in using something else as -9999 as we can't move back or forward on the versions. We can only use the one steam.deb provided by Valve and people should use the latest -9999 when they want to install it. Maybe if they start distributing a buggy version that requires a modified ebuild, we could add something like steam-installer-0.0.1beta-r$date_of_last_correct_deb.ebuild in order to use it with a backup of the old .deb.
(In reply to comment #59) > It doesn't matter if you plan to print something or not. If the lib wants > libcups, it has to get it. As there is no printing option within the steam client, i think this dependency is not really necessary. If they have hacked the library, the could state so and we would forget the plan. So, lets see if we get a response. Also i will try to replace the library for testing purposes at the weekend.
Created attachment 328996 [details] steam-installer-9999.ebuild (In reply to comment #60) > As there is no printing option within the steam client, i think this > dependency is not really necessary. Hm, maybe it's hidden somewhere. Print a bill after buying a game or something like this. But if the lib is listed in ldd, we have no choice. If a lib only shows up with LD_DEBUG or strace, it might get loaded using dl* functions and then there might exist fallback code making the lib only nice-to-have. I tried to merge the 3 sources - the ebuild from Thomas, the Wiki and mine - in one ebuild. Mine mostly contains improvements in terms of ebuild writing. I took the dependencies from the Wiki. As we saw, it is getting confusing what is really required and what is only nice to have. I would suggest we discuss the dependencies in the forums and add new ones _after confirmation_, that it is _really_ necessary, to the wiki and then to the ebuild. I think this bug is getting to long if we discuss and vote for everything here.
Or create own bugs to discuss dependencies. But I don't know if this is recommended by the officials.
(In reply to comment #61) > Created attachment 328996 [details] > steam-installer-9999.ebuild > > I tried to merge the 3 sources - the ebuild from Thomas, the Wiki and mine - > in one ebuild. Mine mostly contains improvements in terms of ebuild writing. > I took the dependencies from the Wiki. As we saw, it is getting confusing > what is really required and what is only nice to have. I would suggest we > discuss the dependencies in the forums and add new ones _after > confirmation_, that it is _really_ necessary, to the wiki and then to the > ebuild. I think this bug is getting to long if we discuss and vote for > everything here. Just one thought: The whole X* libraries are already RDEPS for the libX11.
I assume, removing them from this ebuild depends on whether the client uses the functions in these libs directly or they are only listed by ldd because libX11 is using them. I'm not sure on this, therefore I asked in #gentoo-dev-help but I didn't get an answer so far.
(In reply to comment #41) > Yeah, I do not think it is a good idea to try to create an ebuild for every > single game. This is not in the scope of ebuilds anymore. > > I think it is a good idea to package the steam-installer so interested > people can easily install the Steam client on their machines, with all basic > dependencies installed. The ebuild should elog a reference to the wiki where > game-specific documentation (e.g. their dependencies, driver requirements > etc) could be documented. I think there will be ~100 games before new year. Anyway, it will be VERY VERY LONG wiki page. Steam overlay with metapackages at o.g.o will be much better.
(In reply to comment #61) > Created attachment 328996 [details] > steam-installer-9999.ebuild > > (In reply to comment #60) > > As there is no printing option within the steam client, i think this > > dependency is not really necessary. > > Hm, maybe it's hidden somewhere. Print a bill after buying a game or > something like this. But if the lib is listed in ldd, we have no choice. If > a lib only shows up with LD_DEBUG or strace, it might get loaded using dl* > functions and then there might exist fallback code making the lib only > nice-to-have. Just a quick comment on this: I do believe there indeed is an option to print information of a purchase, at least on the Windows client, so that would be my guess. I also do think it is a silly dependency to have, since indeed, I personally don't have a printer... As a side note, I mentioned this at the forum as well, but it does run with mesa-8 at least when using Intel. Guess it's specific to the drivers in use, as I saw something mentioned towards that, but it was only regarding nVidia/ATi, I think.
Can't wait for nvidia-drivers-310
(In reply to comment #66) > As a side note, I mentioned this at the forum as well, but it does run with > mesa-8 at least when using Intel. Guess it's specific to the drivers in > use, as I saw something mentioned towards that, but it was only regarding > nVidia/ATi, I think. nVidia blob 304.51 on a 8xxx series works with mesa 8 here, If my understanding is correct the issue needing mesa 9 is with open source drivers that Valve is not targeting at this time due to the lesser performance. Personally, I don't consider this a blocker because upsteam does not want xf86-video-ati and nouveau feedback at this time and by the time they might be receptive, mesa will probably be 9.x in the emul-linux-x86 set. Can somebody confirm fglrx on 64 bit with mesa 8? We should consider doing these game dependancies as a steamdep useflag on the indie games we already have ebuilds. have the steamdep useflag skip downloading, unpacking, and installing while retaining the dependencies and have family style ebuilds for the new titles in an overlay (most likely gamerlay), for example games-misc/steam-source-based, games-misc/steam-unreal-based since these engines tend to be the major factor as to what dependencies are needed. If there are major deviatations from the the general sets of dependencies, then we can always have a game specific ebuild which depends on the ebuild for the game engine. Hopefully this mentality can reduce some overhead in the long run and reduce some of the duplicated effort.
(In reply to comment #68) > (In reply to comment #66) > > As a side note, I mentioned this at the forum as well, but it does run with > > mesa-8 at least when using Intel. Guess it's specific to the drivers in > > use, as I saw something mentioned towards that, but it was only regarding > > nVidia/ATi, I think. > > nVidia blob 304.51 on a 8xxx series works with mesa 8 here, If my > understanding is correct the issue needing mesa 9 is with open source > drivers that Valve is not targeting at this time due to the lesser > performance. Personally, I don't consider this a blocker because upsteam > does not want xf86-video-ati and nouveau feedback at this time and by the > time they might be receptive, mesa will probably be 9.x in the > emul-linux-x86 set. Yeah, I agree, or well, I see it the same way. I actually have mesa-8.0.4-r1 on this main machine of mine as well, that uses nvidia-drivers, and stuff works. I figured I'd mention my Intel testing as I saw now mention of it as of yet, but granted, I know very little of the intel-drivers and how they do things.
As far as I know, mesa has nothing to do with proprietary drivers from NVIDIA or AMD. They provide their own stack of libraries aside from mesa.
(In reply to comment #65) > (In reply to comment #41) > > Yeah, I do not think it is a good idea to try to create an ebuild for every > > single game. This is not in the scope of ebuilds anymore. > > > > I think it is a good idea to package the steam-installer so interested > > people can easily install the Steam client on their machines, with all basic > > dependencies installed. The ebuild should elog a reference to the wiki where > > game-specific documentation (e.g. their dependencies, driver requirements > > etc) could be documented. > > > I think there will be ~100 games before new year. Anyway, it will be VERY > VERY LONG wiki page. Steam overlay with metapackages at o.g.o will be much > better. It does not have to be one single wiki page but for example one page per game. But I think you are right, the steam overlay solution is probably better.
The mesa9 issue only applies to the intel drivers. Nvidia and ATI drivers provide their own opengl stacks so mesa is not used at all. The intel drivers use the mesa stack and only mesa9 provides the symbols needed. The ebuild should have something like" in the x86 section: video_cards_intel? ( >=media-libs/mesa-9 ) in the amd64 section: video_cards_intel? ( >=app-emulation/emul-linux-x86-opengl-2012XXXXX ) (XXXX == whatever the new version will be) Regarding deps for the games, I think we should not worry about that for now. I would not be surprised if, after the beta, valve will put something together that all distros can share with the list of deps for each game. Also if we do make ebuilds they should definitely be per engine as mentioned by someone else, not per game. Almost all games that use eg. the source engine will have the exact same deps so there is no reason to have different ebuilds for tf2/cs/portal etc. If this ends up going in an overlay i'd personally also prefer if the main steam installer would still go in the main portage tree for people that are okay with dealing with deps on their own instead of having to have tons of overlays around just for one package.
I actually took the liberty to create a overlay on github at https://github.com/anyc/steam-overlay I think github is a good place, as requests for dependencies and stuff can be handled using github's pull request where we easily start discussions per request and don't have to discuss everything in long bug reports. If I understand the manual correctly, it is also possible to grant write access to other github users, so does not only depend on me. If beta is over and we get something stable from Valve, we can think of something new. It currently contains the version from this bug report. What do you think?
(In reply to comment #73) > I actually took the liberty to create a overlay on github at > https://github.com/anyc/steam-overlay > > I think github is a good place, as requests for dependencies and stuff can > be handled using github's pull request where we easily start discussions per > request and don't have to discuss everything in long bug reports. If I > understand the manual correctly, it is also possible to grant write access > to other github users, so does not only depend on me. If beta is over and we > get something stable from Valve, we can think of something new. > > It currently contains the version from this bug report. > > What do you think? Maybe gamerlay will be a better place rather than dedicated steam overlay? CCing gamerlay's owner to this discussion, it would be nice to hear his opinion on that.
I would suggest adding the ebuild(s) to gamerlay if we got something mature. Currently, all is "in flux". Also, I think the pull requests and their discussion feature comes quite handy in this state.
+1 to github platform.. comments & pull requests are nice things that matter.
I just added a pull request for Jason's suggestion from https://bugs.gentoo.org/show_bug.cgi?id=442176#c72 as an example. You can see https://github.com/anyc/steam-overlay/pull/1 how this look like.
(In reply to comment #72) > The mesa9 issue only applies to the intel drivers. Nvidia and ATI drivers > provide their own opengl stacks so mesa is not used at all. The intel > drivers use the mesa stack and only mesa9 provides the symbols needed. That's what I figured, thanks for confirming it. Only now I'm confused as to why it works on a little laptop I have with mesa-8 (classic does not work at all with mesa-9, and gallium goes to software rasterizer). Oh well, this is probably not important regarding this bug.
Hey, guys! I've already added steam ebuild to gamerlay at 7th Nov, so, if anyone want to maintain it — I can ACK gamerlay push access.
(In reply to comment #79) > Hey, guys! > I've already added steam ebuild to gamerlay at 7th Nov, so, if anyone want > to maintain it — I can ACK gamerlay push access. If no one else likes to volunteer, I would offer to commit the ebuild we think of as stable from my github to gamerlay and do the testing and discussion on github. Shall we close this bug for now and move discussion to github?
(In reply to comment #80) > Shall we close this bug for now and move discussion to github? No, there is no resolution on this package yet(i mean, about it inclusion to main tree), so bug should not be closed.
(In reply to comment #80) > Shall we close this bug for now and move discussion to github? I think this should stay open until the beta is over and steam is released publicly at least.
Okay, I just thought it might be better to start a new bug after beta as much of the info in this bug might be outdated. FYI, split ebuilds are now in gamerlay overlay and development happens at https://github.com/anyc/steam-overlay If someone (e.g., who is part of the beta) would like to contribute I'm happy to grant write access to my github overlay.
2 font packages that are not listed in the ebuild but seem to be needed by steam are: media-fonts/corefonts media-fonts/dejavu Most people most likely already have those on their system but for a few that are missing one or both of those, it could make some things a bit hard to read :)
[offtop] now steam in arch community repos :) [/offtop]
(In reply to comment #85) > [offtop] > now steam in arch community repos :) > [/offtop] yeah, without proper permission from valve http://www.phoronix.com/scan.php?page=news_item&px=MTIyOTI and now it seems they removed it.
(In reply to comment #86) > (In reply to comment #85) > > [offtop] > > now steam in arch community repos :) > > [/offtop] > > yeah, without proper permission from valve > > http://www.phoronix.com/scan.php?page=news_item&px=MTIyOTI > > and now it seems they removed it. Am I right that this is no problem for Gentoo as we do not distribute a modified binary?
(In reply to comment #87) > (In reply to comment #86) > > (In reply to comment #85) > > > [offtop] > > > now steam in arch community repos :) > > > [/offtop] > > > > yeah, without proper permission from valve > > > > http://www.phoronix.com/scan.php?page=news_item&px=MTIyOTI > > > > and now it seems they removed it. > > Am I right that this is no problem for Gentoo as we do not distribute a > modified binary? you are wrong.
Ebuilds are just scripts with a GPL license. Since when is that illegal?
(In reply to comment #89) > Ebuilds are just scripts with a GPL license. Since when is that illegal? cause we would redistribute the bootstrap tarball which includes the steam binary.
(In reply to comment #90) > cause we would redistribute the bootstrap tarball which includes the steam > binary. RESTRICT="mirror"?
(In reply to comment #91) > (In reply to comment #90) > > cause we would redistribute the bootstrap tarball which includes the steam > > binary. > > RESTRICT="mirror"? not sure if that would suffice. CC'ed license team just out of interest. License is already attached and is from the officially published .deb archive.
(In reply to comment #92) > > RESTRICT="mirror"? > > not sure if that would suffice. CC'ed license team just out of interest. > > License is already attached and is from the officially published .deb > archive. Also "bindist" should be added to RESTRICT. Assuming that the license pertains to the installer itself. This is not entirely clear to me; the "Program" mentioned in the license could be the client as well.
1. The ebuild needs to have both RESTRICT='bindist mirror' 2. * QA Notice: This package installs one or more .desktop files that do not * pass validation. * * /usr/share/applications/steam.desktop: hint: value "Network;FileTransfer;Game;" for key "Categories" in group "Desktop Entry" contains more than one main category; application might appear more than once in the application menu * 3. The gentoo games install location /usr/games. Please use games.eclass, specifically dogamesbin. 4. If we do go with packages for games, we'll need to make large use of QA_* variables for precompiled binaries.
(In reply to comment #94) > 3. > The gentoo games install location /usr/games. Please use games.eclass, > specifically dogamesbin. The steam-installer is not much more than a shell script and a tar archive with the minimal steam client. The only usecase for the installer is to bootstrap the client within the home directory of the user. Maybe this will change later. To move the package to /usr/games the steam-script must be modified. > 4. > If we do go with packages for games, we'll need to make large use of QA_* > variables for precompiled binaries. The games could not be installed via ebuild, as they are managed by the client. The ebuilds or sets would be needed to provide the dependencies for the games.
(In reply to comment #95) > (In reply to comment #94) > > > 3. > > The gentoo games install location /usr/games. Please use games.eclass, > > specifically dogamesbin. > The steam-installer is not much more than a shell script and a tar archive > with the minimal steam client. The only usecase for the installer is to > bootstrap the client within the home directory of the user. Maybe this will > change later. > To move the package to /usr/games the steam-script must be modified. Only users in the games group should be able to run game things. You only need to change two things that I can see as a grep: 1. /usr/share/applications/steam.desktop:Exec=/usr/bin/steam %U /usr/lib/steam/steam-install-notify:Command: /usr/bin/steam I did move it, and it seems to work fine (I don't have a Linux enrollment, but up until that it works great). > > 4. > > If we do go with packages for games, we'll need to make large use of QA_* > > variables for precompiled binaries. > > The games could not be installed via ebuild, as they are managed by the > client. The ebuilds or sets would be needed to provide the dependencies for > the games. I'm just stating it as a warning.
(In reply to comment #94) > 2. > * QA Notice: This package installs one or more .desktop files that do not > * pass validation. > * > * /usr/share/applications/steam.desktop: hint: value > "Network;FileTransfer;Game;" for key "Categories" in group "Desktop Entry" > contains more than one main category; application might appear more than > once in the application menu Note that this is only a hint, and will is not shown in the latest portage.
(In reply to comment #93) > (In reply to comment #92) > > > RESTRICT="mirror"? > > > > not sure if that would suffice. CC'ed license team just out of interest. > > > > License is already attached and is from the officially published .deb > > archive. > > Also "bindist" should be added to RESTRICT. > > Assuming that the license pertains to the installer itself. This is not > entirely clear to me; the "Program" mentioned in the license could be the > client as well. Judging from the license attached it seems to me as "Program" here includes (at least) the client as well. Especially since it talks about "installing the Program", it woudl be a bit daft to refer that way to installing the installer of the client. Also note that: "By installing the Program, you agree that your future use of the Program will be subject to the terms of the Steam Agreement. A copy of the Steam Agreement is available at www.steampowered.com/agreement. The Steam Agreement will be displayed to you when you obtain an account with the Steam service." Since the license claims the you agree to the additional Steam Agreement (NB, not this license), we should definelty warn the user that on installation.
Don't related directly to the Steam, but Serious Sam 3 requires 32bit libpci.so.3 to work. It should be included to emul-linux-x86-xlibs in order to play this game on amd64.
I added ebuld and patch from this page https://github.com/anyc/steam-overlay/tree/master/games-util/steam-installer to local overlay and try to emerge "steam-installer" Currently steam-installer doesn't emerged as error of patching. It obviously there is a new "/usr/steam" file in "steam.deb" and old patch isn't applicable now. I tried to create new patch but got the same error: --------------------- # emerge steam-installer Calculating dependencies... done! >>> Verifying ebuild manifests >>> Emerging (1 of 1) games-util/steam-installer-9999 from x-portage * steam.deb SHA256 SHA512 WHIRLPOOL size ;-)... [ ok ] >>> Unpacking source... >>> Unpacking steam.deb to /var/tmp/portage/games-util/steam-installer-9999/work >>> Unpacking data.tar.gz to /var/tmp/portage/games-util/steam-installer-9999/work >>> Source unpacked in /var/tmp/portage/games-util/steam-installer-9999/work >>> Preparing source in /var/tmp/portage/games-util/steam-installer-9999/work ... * Applying remove-ubuntu-specifics.patch ... * Failed Patch: remove-ubuntu-specifics.patch ! * ( /usr/local/portage/games-util/steam-installer/files/remove-ubuntu-specifics.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/games-util/steam-installer-9999/temp/remove-ubuntu-specifics.patch.out * ERROR: games-util/steam-installer-9999 failed (prepare phase): * Failed Patch: remove-ubuntu-specifics.patch! --------------------- I attach the original downloaded patch and new 'steam.deb" [downloaded on 30 nov 2012] as "not_worked_patch.zip" file.
Created attachment 331072 [details] not_worked_patch.zip "remove-ubuntu-specifics.patch" is not aplicable to new "steam.deb" (i.e. to "/usr/steam" from this .deb)
Hello, for steam-overlay users, a day ago I've made manifest & patch bump, all is in the pull request: https://github.com/anyc/steam-overlay/pull/11 Patch is not pulled yet, I don't know how to contact the maintainer, you can apply it locally somehow. or, for lazy onese, you can clone my fork of steam overlay and add it as local repository.
I tried to create own patch (by creating a copy of steam and removing the blocks concerning ubuntu_extra) by command ($diff -u originalsteam updatedsteam > steam.patch) and then it was applied successfully manualy ($patch originalsteam -i steam.patch -o updatedsteam). But after updated of ebuild digest with new patch I receive the same error again during emerging. I'll try and check it again but It's strange that emerge did not apply new patch.
Created attachment 331120 [details] remove-ubuntu-specifics.patch.out remove-ubuntu-specifics.patch.out while trying emerge steam-installer from local overlay. ebuild was downloaded from https://github.com/anyc/steam-overlay/tree/master/games-util/steam-installer and identical the one from https://github.com/Cynede/steam-overlay/tree/master/games-util/steam-installer
hey, guys! Why don't you all use gamerlay?
Created attachment 331122 [details] remove-ubuntu-specifics.patch [date: 2012 December 1] Well I create the new "remove-ubuntu-specifics.patch" that removes "function install_extra_packages()" block and "install_extra_packages jockey-common python-apt". Now steam-installer-9999.ebuild emerge successfully. BUT!!! After emerging I had run "$steam" under my user and it install steam to local home directory (/home/%myusername%/.local/share/Steam/) after that ask in xterm window: "Please enter your password to update /usr/bin/steam [sudo] password for user:" It seems I don't has appropriate rules for sudo to rewrite /usr/bin/steam so after appears xterm window: "Unable to copy /home/%myusername%/.local/share/Steam/bin_steam.sh to /usr/bin/steam, please contact your system administrator." After closing this windows Steam starts. I manually copied this file after steam updated localy to /usr/bin/steam and after that Steam don't request sudo password again.
https://github.com/Cynede/steam-overlay has already have the same patch (https://github.com/Cynede/steam-overlay/blob/master/games-util/steam-installer/files/remove-ubuntu-specifics.patch) I don't notice that instantly as I clone today from https://github.com/anyc/steam-overlay :)
Same here. I just forced the switch to Cynede's pull.
(In reply to comment #108) > Same here. I just forced the switch to Cynede's pull. Guys, I jest repeat: as far as I tested, steam ebuild in gamerlay works just fine. Why don't you want to use it?
Seems feedback from the license team is still missing, although I suppose they are waiting for Steam to clarify the license wrt package managers. Also, are any of the ebuilds in the attachment list obsolete? (In reply to comment #106) > It seems I don't has appropriate rules for sudo to rewrite /usr/bin/steam > so after appears xterm window: > "Unable to copy /home/%myusername%/.local/share/Steam/bin_steam.sh to > /usr/bin/steam, please contact your system administrator." Shouldn't this be a symbolic link instead? (In reply to comment #109) > Guys, I jest repeat: as far as I tested, steam ebuild in gamerlay works just > fine. Why don't you want to use it? See the following comment: (Quoting comment #75) > I would suggest adding the ebuild(s) to gamerlay if we got something mature. > Currently, all is "in flux". Also, I think the pull requests and their > discussion feature comes quite handy in this state. Also; in an open-source world, forking exists, there's no control over that; although poking doesn't hurt unless you do it too much. anyc was interested, but has made his own overlay for now to speed up the progress (to get pull requests / out-of-bug discussion), you can try (through private e-mail) to set up push access for him; as most people follow him, if he goes gamerlay the rest follows. Cynede just forked from anyc, to contribute some patches.
From the manifest files in each repository: Gamerlay/anyc steam-overlay: DIST steam.deb 1327544 ... Cynede steam-overlay: DIST steam.deb 1484458 ... The latter works. I just forced-added that version of steam-overlay and I do not get any issues pulling the patches nor the installer.
(In reply to comment #110) > anyc was interested, but has made his own overlay for now to speed up the > progress (to get pull requests / out-of-bug discussion), you can try > (through private e-mail) to set up push access for him; as most people > follow him, if he goes gamerlay the rest follows. the case is in that fact, that anYc himself added steam-ebuilds in gamerlay and maintained them, but leaved repo on github due to github's issue system. > Cynede just forked from anyc, to contribute some patches. yes. He forked it after (AFAIK) anYc pushed working (I just tested few times) ebuilds to gamerlay.
(In reply to comment #111) > DIST steam.deb 1327544 ... > DIST steam.deb 1484458 ... > > The latter works. Uhm, okay, I just reemerged steam without refetching. Sorry. So, I try to poke anYc in IRC about it and just import Cynede's patch into overlay. Thanks.
I wouldn't be surprised if we have to keep on top of the client updates (as per here: http://steamcommunity.com/games/221410/announcements ). The new one was released Nov 29th and Cynene was right on-top of it.
> (In reply to comment #106) > > It seems I don't has appropriate rules for sudo to rewrite /usr/bin/steam > > so after appears xterm window: > > "Unable to copy /home/%myusername%/.local/share/Steam/bin_steam.sh to > > /usr/bin/steam, please contact your system administrator." > > Shouldn't this be a symbolic link instead? As I remember after emerging of steam-installer the executable "steam" is placed to "/usr/bin". When user make first run of "/usr/bin/steam" it initialize the downloading and installing the Steam client to home-user directory (/home/%myusername%/.local/share/Steam/) and after finishing of installation of Steam client it just want to overwrite initial steam script in /usr/bin/steam. Otherwise user always began installation process again to his home directory by starting steam via terminal ($steam ). So maybe it worth to add information message to ebuild that now user must run "steam" to install it to his home-dir and after that overwrite appropriate file, but without any prompt about "sudo" asking passwords. May it be realized by some postinstall-patching of /usr/bin/steam to remove such prompt before first run? Or just replace it with information message about necessity to replace this file by new one after installation to user home-directory? P.S. I don't know does it available to install steam by any other user of local machine after such final replacing?
> So, I try to poke anYc in IRC about it and just import Cynede's patch into > overlay. Thanks. Both things done. By the way, I can also ask for W-rights for Cynede.
Sorry guys, I was traveling the last days. I pulled the patch from cynede, thanks for that! Regarding the problem that steam tries to replace the /usr/bin/, we started a discussion some days ago here: https://github.com/anyc/steam-overlay/issues/9 Unfortunately, I didn't had the time to look further into it. Discussion is appreciated.
Thanks for the link. I added my own comments on that, and I'm following the thread. The TL;DR on the comment for here is: Because Valve is currently targeting Ubuntu 12.xx but knows of other distros, and promised to expand it out, /usr/bin/steam is going to be updated. Since it does use sudo (and rightfully so), two things are needed. The ebuild needs a dependency on sudo (and ether Gnome/KDE's sudo prompter if gnome/kde USE flag is present) and a few ewarn lines to let the user know that this happens for beta software. Outside that comment: If we go upstream (Valve) and see if the installer can be sequestered someplace other than /usr/bin (say, /opt/Valve), would there be a problem with telling sudo to let it auto-update if it stays in /opt/Valve?
(In reply to comment #118) > The TL;DR on the comment for here is: Because Valve is currently targeting > Ubuntu 12.xx but knows of other distros, and promised to expand it out, > /usr/bin/steam is going to be updated. Since it does use sudo (and > rightfully so), two things are needed. The ebuild needs a dependency on > sudo (and ether Gnome/KDE's sudo prompter if gnome/kde USE flag is present) > and a few ewarn lines to let the user know that this happens for beta > software. > We should in no way support Valve bypassing portage, this is an obvious security violation and must not be tolerated. Most of those devs are accustomed to full, unchecked access in Windows and Mac, they will need to find a proper solution for this tiny part of their project.
(In reply to comment #116) > > So, I try to poke anYc in IRC about it and just import Cynede's patch into > > overlay. Thanks. > > Both things done. > > By the way, I can also ask for W-rights for Cynede. Hello. Thank you. But I even don't know what is your irc channel :)
(In reply to comment #120) > I even don't know what is your irc channel :) #gentoo-gamerlay ;) And, if you want to get push-access to gamerlay you should create a bug like that: https://bugs.gentoo.org/show_bug.cgi?id=442710
(In reply to comment #121) > a bug like that: https://bugs.gentoo.org/show_bug.cgi?id=442710 (and don't forget to add me in CC)
Apparently the issue with updating /usr/bin/steam will be resolved upstream with properly updating the steam.deb: http://steamcommunity.com/app/221410/discussions/1/846938350907762743/#c846938350934704109
Will they be touching anything outside of /home/$user without the PMS being aware? I gather not from the post ( http://steamcommunity.com/app/221410/discussions/1/846938350907762743/#c846938350934704109 ), but it would be nice to be sure.
This currently won't work without media-sound/pulseaudio -- it'll just fail an assertion and exit with no good error message. It tries to use net-misc/networkmanager but if it isn't there it'll just give an error message and continue. It does use gnome-extra/zenity but this isn't in the attached ebuild's dependencies (I think I had it on my system already). I had the fonts mentioned in comment #84 installed already, media-fonts/dejavu and media-fonts/corefonts. You might want to add media-libs/libtxc_dxtn to the dependencies -- I discovered this is what was needed to get several of the 3d Humble Bundle games to load certain textures (they were drawing solid black polys), and some of the steam games seem to be copies of those ports. It might be due to my driver though, =x11-drivers/xf86-video-nouveau-1.0.4 But once the requirements are satisfied, it seems to Just Work.
I have no any Pulseaudio or Networkmanager installed on my system. It took error (in console) about absence of zenity, but I ignore it. But Steam Client installed successfully via steam-installer-9999.ebuild, and run under user ($steam) for me . First '$steam' run initiate downloading SteamClient and placing it to '~./local/share/Steam' with creating also '~/.steam' directory with symlinks. After I run $steam under my user and it ask to login or create new account. I alredy has invitation so I make login. Now client ask to take account in Hardware Survey and collect information about my system and hardware (I was agree). And now client successfully starts. I close it and remove Steam folder from '~./local/share/Steam' to another partition with more free space then my $HOME. And add my early downloading games from my Library (SteamApps directory) then try to run again $steam It try to download Steam Client again, I stop his. Go to 'NewSteamPlace/Steam' and run './steam.sh' It asl to login again (as I change paths) I see my early purchased games in Linux Games Category (Dark Descend, World of Goo, Jack Dynamite, Team Fortess 2, Team Fortress 2 beta, The Book of unwriten Tales demo). Displaying 'Limbo' is error - it has no linux native client. After closing ./steam.sh I can freely run $steam (from /usr/bin) without installing new SteamClient attempts (as symlinks in ~/.steam are now changed)
(In reply to comment #126) I try to start some games - sound works except of "Team Fortress 2" as it wants Pulseaudio but from this topic (http://steamcommunity.com/app/221410/discussions/1/882965737456862913/) it's need to excecute: export SDL_AUDIODRIVER=alsa or add this line to '/usr/bin/steam' then sound works in this game. And after that I also can test my webcam microphone.
(In reply to comment #126) > I have no any Pulseaudio or Networkmanager installed on my system. Huh. For me without pulseaudio installed it gives this error: client_api.cpp (273) : Assertion Failed: ClientAPI_InitGlobalInstance: InternalAPI_Init_Internal failed. and goes on to generate a crash dump. With pulseaudio it continues on and brings up the store. It's not json-c or libatomic_ops or any of pulseaudio's other dependencies; the only things that change are pulseaudio itself and the pulseaudio USE flag for alsa-plugins.
Same here, no pulseaudio. It just says > PulseAudio connect failed (used only for Mic Volume Control) with error: Access denied and goes on. When I open settings it also says > AL lib: pulseaudio.c:612: Context did not connect: Access denied but everything is still fine. I don't know what's happening with the mic though since I've never used it and as far as I can see it is not working in alsa right now. I might try to make it work one day.
I have no pulseaudio installed but I can successfully check my webcam mic.
I re-test and my mic also work without "export SDL_AUDIODRIVER=alsa" but it's still need to run Team Fortress 2 with working sound. But today I can't load Tf2 due to this issue : http://steamcommunity.com/app/221410/discussions/2/846939071092022675/ Last night it works.
Okay, I narrowed it down to just these files: /usr/lib/libpulse.so /usr/lib/libpulse.so.0 /usr/lib/libpulse.so.0.14.3 /usr/lib/pulseaudio/libpulsecommon-2.1.so I did emerge --nodeps pulseaudio (so it wouldn't force alsa-plugins to use it), copied those files out, then unmerged it and put them back. If you're on amd64 maybe they're included in emul-linux-x86-soundlibs? Good riddance to pulseaudio though, it was keeping sound from working in everything else
Comment on attachment 328996 [details] steam-installer-9999.ebuild Removed obsolete ebuild. Please take a look into the Wiki, gamerlay or steam-overlay for instructions, up-to-date ebuilds and discussion about deps.
(In reply to comment #132) > Okay, I narrowed it down to just these files: > > /usr/lib/libpulse.so > /usr/lib/libpulse.so.0 > /usr/lib/libpulse.so.0.14.3 > /usr/lib/pulseaudio/libpulsecommon-2.1.so > > I did emerge --nodeps pulseaudio (so it wouldn't force alsa-plugins to use > it), copied those files out, then unmerged it and put them back. If you're > on amd64 maybe they're included in emul-linux-x86-soundlibs? Good riddance > to pulseaudio though, it was keeping sound from working in everything else That is correct, the client needs to load the 32bit pulseaudio dependency, but does not need a running pulseaudio service. emul-linux-x86-soundlibs contains the pulseaudio dependency.
media-libs/libtxc_dxtn is needed for mesa driven gfx cards like intel. Maybe it should be pulled in the tree if VIDEO_CARDS contains intel.
(In reply to comment #135) > media-libs/libtxc_dxtn is needed for mesa driven gfx cards like intel. I can confirm this. Without this library, for exmaple, Cogs says > WARNING: Your OpenGL drivers lack S3TC support! Using inefficient fallback... Installing this library (which is multilib) solves this (but the game isn't running any faster which is a separate issue).
(In reply to comment #136) > (In reply to comment #135) > > media-libs/libtxc_dxtn is needed for mesa driven gfx cards like intel. We have this lib as "testing" dependency since 2 weeks in steam-overlay and since a few days, also in the gamerlay ebuilds. If you miss further deps, please also take a look at our ebuilds and the wiki.
(In reply to comment #137) > We have this lib as "testing" dependency since 2 weeks in steam-overlay and > since a few days, also in the gamerlay ebuilds. If you miss further deps, > please also take a look at our ebuilds and the wiki. That's right, I've missed this USE flag. And there is nothing about it and nothing about libtxc_dxtn dependency on the wiki (BTW, I'm using ebuild from gamerlay). Dependency on libtxc_dxtn clearly exists, why is it still hiding behind a USE flag? It should be enabled conditionally (depending on video driver in use) though.
(In reply to comment #138) > That's right, I've missed this USE flag. And there is nothing about it and > nothing about libtxc_dxtn dependency on the wiki (BTW, I'm using ebuild from > gamerlay). > Dependency on libtxc_dxtn clearly exists, why is it still hiding behind a > USE flag? It should be enabled conditionally (depending on video driver in > use) though. Yes, I only saw it in the Archwiki and added it to the optional list, as no one confirmed it yet. Since I'm in the beta, I didn't had the opportunity to test the games as I can only use a crappy hotel wifi for now. ;) Is this required for every game with Intel drivers or just for some games? In the latter case, I would add it with a distinguishable use-flag.
(In reply to comment #139) > Is this required for every game with Intel drivers or just for some games? > In the latter case, I would add it with a distinguishable use-flag. I have no idea. Cogs was the first game to tell me about this. I also played World of Goo, and it wasn't complaining about S3TC (and was running pretty smoothly)—either they don't need it at all or they fall back silently. As I understand it's just one of compression algorithms which games are free to use if they want, but it is not a necessity. Do you want to bother maintaining a comprehensive list of games using S3TC? IMHO, it should be a dependency without any USE-flags but only for mesa video cards. We can wait a bit to find out something about S3TC and other games, though. I've got a bunch of games I haven't even installed yet.
(In reply to comment #140) > Do you want to bother > maintaining a comprehensive list of games using S3TC? IMHO, it should be a > dependency without any USE-flags but only for mesa video cards. If it is not required by everyone then it should imho be conditional (gentoo ftw ;). I modified the steam-meta ebuild accordingly. I will also update gamerlay if no one reports a problem after some time or someone anticipates me. Thank you!
(In reply to comment #141) > If it is not required by everyone then it should imho be conditional (gentoo > ftw ;). This doesn't work sometimes =(. For example, I don't need OpenRC, but I can't just remove it… but, well, that's an offtopic. I guess you're right.
I don't khow is it offtopic, but some games needs libraries that are unavailable in arch=x86_64. For example I try to start Demo of "The Book of Unwritten Tales: The Critter Chronicles" and it wanted to install "ia-32libs" as it check via dpkg-status is it installed. I edit start script of game and remove this checking section and then try start again. From console output I saw that it wanted 32bit library of "media-libs/jasper" (jasper.so.1), so I had to find somewhere x86 binary package of it and place to appropriate directory of game. After this I encountered this bug (http://steamcommunity.com/app/221410/discussions/3/846939071081758230/) - "RenderSystem_GL.so" (32bit of course) delivered with game leads to crash while attempting to go Settings menu of game. This library can be obtained from "dev-games/ogre" package. I download and replace it in game directory with one of libogre-1.7.4-3 from "Precise" Ubuntu 12.04 repository for i386. It was strange that with the same lib from 1.7.4-5 and 1.8.0 versions the game don't work at all.
Right, media-libs/jasper is hidden behind testdeps. The bad news is that the ebuild is not multilib-enabled, and libjasper is not provided by emul-linux-*. So, I don't really know what to do now. I definitely don't want to setup a chroot. So, playing with multilib-portage is the only answer?
(In reply to comment #144) > So, I don't really know what to do now. I definitely don't want to setup a > chroot. So, playing with multilib-portage is the only answer? I have not tested it, but crossdev might be an option: "You need 32 bit library on a 64bit system and don't want to build a complete chroot environment." http://en.gentoo-wiki.com/wiki/Crossdev
I created a tracker bug #446682 where we can gather libraries not present in emul-linux-x86-* packages required for x86 steam games on AMD64 machines.
Just to state my criticism on the meta-ebuild for the Steam client also on the bugtracker: When uninstalling the installer this also removes the global launcher (/usr/bin/steam) which is needed for the steam://-URLs to work, so just keeping it installed does make sense. It is not a very good citizen at the moment (updating itself by writing stuff to /usr/bin and such), but this might get better over time, as a lot of people complained that in the Valve forums.
(In reply to comment #147) > It is not a very good citizen at the moment (updating itself by writing > stuff to /usr/bin and such), but this might get better over time, as a lot > of people complained that in the Valve forums. The steam client no longer attempts to update /usr/bin/steam by bypassing the package manager.
SpaceChem is awesome. It does > gksudo --description "apt-get install" "apt-get -y install $REQUIRED_PACKAGES" in ~/.local/share/Steam/SteamApps/common/SpaceChem/spacechem-launcher.sh BTW, here is the list of required packages: > REQUIRED_PACKAGES="libmono-i18n-west2.0-cil libmono-wcf3.0-cil libmono-winforms2.0-cil libmono2.0-cil libsdl-image1.2 libsdl-mixer1.2 libsdl1.2debian mono-runtime xclip"
First time (about 2 two weeks ago) then I run steam it ask for sudo password to update. But a week later I uninstall and delete all steam directories and "steam.deb". After I install steam again and during fist run it updated only localy for user without trying to rewrite "/usr/bin/steam" - It now seems is needed only to install steam client for new user.
(In reply to comment #149) > SpaceChem is awesome. > > It does > > > gksudo --description "apt-get install" "apt-get -y install $REQUIRED_PACKAGES" > > in ~/.local/share/Steam/SteamApps/common/SpaceChem/spacechem-launcher.sh > > BTW, here is the list of required packages: > > > REQUIRED_PACKAGES="libmono-i18n-west2.0-cil libmono-wcf3.0-cil libmono-winforms2.0-cil libmono2.0-cil libsdl-image1.2 libsdl-mixer1.2 libsdl1.2debian mono-runtime xclip" Wich means at least : dev-lang/mono x11-misc/xclip media-libs/sdl-image media-libs/sdl-mixer Moreover, the version distributed by steam doesn't work on 64bit. By simply replacing the files in ~/.local/share/Steam/SteamApps/common/SpaceChem/* by those from a official 64bit debian archive, the game works as expected. But this "workaround" is not sufficient as people can by the game on steam without having access to the .deb file.
What's the status of getting this ebuild in portage? Have any licensing issues been cleared up?
(In reply to comment #152) > What's the status of getting this ebuild in portage? Have any licensing > issues been cleared up? Since it seems it's GA at this point: http://www.phoronix.com/scan.php?page=news_item&px=MTI1ODg
Sorry, I'm not sure is this right place to report this issue. I'm using amd64 hardened. I've just installed steam from overlay gamerlay by emerging package steam-meta. Of course, it won't start because of hardened, I've expected that. But looks like it's impossible to just patch starting scripts by adding `paxctl -Cm` - when I do this steam reload/unpack itself again rewriting my changes. When I've patched it enough to protect against this - steam goes in endless loop reloading/unpacking. Finally, I've overcome this by running this in background: while :; do F=~/.local/share/Steam/ubuntu12_32/steam cp $F{,.new} paxctl -Cm $F.new mv $F{.new,} done This way steam started ok, but this solution may fail because of race condition and also I suppose steam become broken after next update. I'll report this issue to steam's bugtracker on github too, but keeping in mind how other vendors like skype spend years to fix something related to hardened I think we should find a way to patch it for hardened ourselves.
(In reply to comment #154) We are adding xattr pax flags soon, this will allow us to specify the pax flags without modifying the binary (and fix the self inspecting exec issue where it thinks it's been compromised).
heres what i did to get steam working fully. i dont seem to have anymajor bugs and system running as normal. sudo mkdir /etc/portage/sets sudo touch /etc/portage/sets/steam sudo nano /etc/portage/sets/steam add the following to /etc/portage/sets/steam >=app-emulation/emul-linux-x86-baselibs-20121028 >=app-emulation/emul-linux-x86-gtklibs-20121028 >=app-emulation/emul-linux-x86-opengl-20121028 >=app-emulation/emul-linux-x86-sdl-20121028 >=app-emulation/emul-linux-x86-soundlibs-20121028 >=app-emulation/emul-linux-x86-xlibs-20121028 >=sys-devel/gcc-4.6.0[multilib] >=sys-libs/glibc-2.15[multilib] virtual/opengl save that and run: sudo emerge --ask @steam once completed download the steam_latest.deb from steam official website. deb2targz steam_latest.deb tar xfv steam_latest.tar.gz then cd to steam_latest and cp these two files to another dir bootstraplinux_ubuntu12_32.tar.xz steam.desktop ok now cd to the new dir where you put those two files touch SteamInstall nano SteamInstall add this to the SteamInstall file #!/bin/sh # these variables can be overridden on commandline WORKDIR="$(pwd)" DESKTOPFILE="$WORKDIR/steam.desktop" LAUNCHSTEAMDIR=~/Steam LAUNCHSTEAMPLATFORM=ubuntu12_32 LAUNCHSTEAMBIN=$LAUNCHSTEAMDIR/$LAUNCHSTEAMPLATFORM LAUNCHSTEAMBOOTSTRAP=$LAUNCHSTEAMDIR/steam.sh LAUNCHSTEAMBOOTSTRAPFILE="$WORKDIR/bootstraplinux_$LAUNCHSTEAMPLATFORM.tar.xz" EXELINK=~/.steampath # full path of steam (~/Steam/ubuntu12_32/steam) STEAMROOTLINK=~/.steam/root # used by games to find the steam install directory (~/Steam) if ! [ -x "$LAUNCHSTEAMBOOTSTRAP" ]; then # user does not have steam set up yet, do some sanity checks and set it up echo "Setting up steam platform in $LAUNCHSTEAMDIR" mkdir -p "$LAUNCHSTEAMDIR" cd "$LAUNCHSTEAMDIR" tar -xvJf "$LAUNCHSTEAMBOOTSTRAPFILE" || { echo "Failed to extract $LAUNCHSTEAMBOOTSTRAPFILE, aborting installation." exit 1 ;} # create the symlinks in the user's home directory [ -e ~/.steam ] || mkdir ~/.steam rm -f ${EXELINK} && ln -s "${LAUNCHSTEAMBIN}"/steam ${EXELINK} rm -f ${STEAMROOTLINK} && ln -s "${LAUNCHSTEAMDIR}" ${STEAMROOTLINK} # put the Steam icon on the user's desktop # try to read ~/.config/user-dirs.dirs to get the current desktop directory # http://www.freedesktop.org/wiki/Software/xdg-user-dirs test -f ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs && . ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs DESKTOP_DIR=${XDG_DESKTOP_DIR:-$HOME/Desktop} cp "${DESKTOPFILE}" "${DESKTOP_DIR}" chmod +x "${DESKTOP_DIR}/steam.desktop" fi # go to the install directory and run the client LAUNCHSTEAMDIR=`readlink -e $STEAMROOTLINK` cd $LAUNCHSTEAMDIR exec "$LAUNCHSTEAMDIR/steam.sh" $* ####### sudo chmod +x SteamInstall ./SteamInstall sometimes it crashes or hangs so just restart it untill you can login fully (SAVE PASSWORD) then close steam ( file > exit ) cd touch steam echo sh ~/Steam/steam.sh chmod +x steam now everytime you want steam to run just run ./steam
(In reply to comment #156) > Here's what I did to get steam working fully Does this impose that all the other contributions in this bug aren't working? If so, which ones have you tried and why do you consider them to fail? It has worked for others as well; so, we don't need to start from scratch. > I don't seem to have any major bugs and the system is running as normal. The major bug is that you now have software on your computer that is not tracked by Portage in any way; you'll end up having problems in the long run like dependency issues, while you could not choose to upgrade to avoid that that would put you at a security risk. > sudo mkdir /etc/portage/sets > sudo touch /etc/portage/sets/steam > sudo nano /etc/portage/sets/steam > > add the following to /etc/portage/sets/steam > > >=app-emulation/emul-linux-x86-baselibs-20121028 > ... > >=app-emulation/emul-linux-x86-xlibs-20121028 > >=sys-devel/gcc-4.6.0[multilib] > >=sys-libs/glibc-2.15[multilib] > virtual/opengl Sets are not meant to be used for tracking dependencies, the ebuild of a package can do that on his own. The main goal of sets is to use them when you want to group packages, but are not to be used for the dependencies of a single package; while you can, you're making things more complex than necessary. > sudo emerge --ask @steam As a result, the problem here is that this doesn't really emerge steam. > once completed download the steam_latest.deb from steam official website. > ... > chmod +x steam That's a lot of manual work that takes quite some effort to repeat; package managers exist for that purpose, wouldn't it be easier to tell someone to add an overlay (which becomes unnecessary once it is in the Portage tree) and just emerge a package which does all the work? Ebuilds are simple Bash scripts which makes it easy to write an ebuild for a package, you can read more about them at http://devmanual.gentoo.org/index.html
(In reply to comment #157) > (In reply to comment #156) i understand there are overlays ect... (i tried gentoo-samuel / gamerlay as was suggested to me but they failed to work) i was just posting a method that allowed my steam to run, install games, have audio with pulseaudio. method people choose to use is optional. more options are better than one.
Is it me or steam* packages in gamerlay overlay have wrong/missing Manifest files? Please can you update them? Thanks
(In reply to comment #159) > Is it me or steam* packages in gamerlay overlay have wrong/missing Manifest > files? Please can you update them? Thanks Thank you for comment. Re-generated it just now: http://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=summary tested. Everything works fine for me =) sync overlay (layman -S) and try if it will work now.
The problem still exists and this is the self-explaining error message: * Missing digest for '/usr/local/portage/gamerlay/games-util/steam-base/steam-base-9999.ebuild' * Digest verification failed: * /usr/local/portage/gamerlay/games-util/steam-client-meta/steam-client-meta-9999.ebuild * Reason: Filesize does not match recorded size * Got: 2744 * Expected: 2315 * Digest verification failed: * /usr/local/portage/gamerlay/games-util/steam-meta/steam-meta-9999.ebuild * Reason: Filesize does not match recorded size * Got: 521 * Expected: 493 * Manifest not found for '/usr/local/portage/gamerlay/games-util/steam-games-meta/steam-games-meta-9999.ebuild' * Missing digest for '/usr/local/portage/gamerlay/games-util/steam-base/steam-base-1.0.0.20.ebuild' * Missing digest for '/usr/local/portage/gamerlay/games-util/steam-base/steam-base-1.0.0.18.ebuild' * Missing digest for '/usr/local/portage/gamerlay/games-util/steam-base/steam-base-1.0.0.17.ebuild' Thanks for your work.
(In reply to comment #161) > The problem still exists and this is the self-explaining error message: > > * Missing digest for > '/usr/local/portage/gamerlay/games-util/steam-base/steam-base-9999.ebuild' > * Digest verification failed: > * > /usr/local/portage/gamerlay/games-util/steam-client-meta/steam-client-meta- > 9999.ebuild > * Reason: Filesize does not match recorded size > * Got: 2744 > * Expected: 2315 > * Digest verification failed: > * /usr/local/portage/gamerlay/games-util/steam-meta/steam-meta-9999.ebuild > * Reason: Filesize does not match recorded size > * Got: 521 > * Expected: 493 > * Manifest not found for > '/usr/local/portage/gamerlay/games-util/steam-games-meta/steam-games-meta- > 9999.ebuild' > * Missing digest for > '/usr/local/portage/gamerlay/games-util/steam-base/steam-base-1.0.0.20. > ebuild' > * Missing digest for > '/usr/local/portage/gamerlay/games-util/steam-base/steam-base-1.0.0.18. > ebuild' > * Missing digest for > '/usr/local/portage/gamerlay/games-util/steam-base/steam-base-1.0.0.17. > ebuild' > > Thanks for your work. Don't use 9999 version... patches are different for different versions, check-sums are different so 9999 version must be just completely removed soon. I suggest to mask it back and use usual version.
Recently I uninstall december ebuild (of early December) of steam-installer from Cynede overlay and try to install Steam from "gamerlay" overlay. With "Cynede" Steam client the game Trine2 started without any warning-information message such as "Trine 2 Launcher script Unidentified Linux distribution. If you have problems running the game, please see the game support web site for more info and ensure you have the required libraries installed." It is a check within Trine2 game start script, there a check of ubuntu" " .... ### First, start by checking if some library requirements are met ### This automation is currently supported on Ubuntu 12.04 (or newer?) only. FB_DISTRIBUTION_IS_UBUNTU=0 .... check_for_ubuntu() { if [ -e /etc/lsb-release ]; then . /etc/lsb-release if [ $DISTRIB_ID = "Ubuntu" ]; then FB_DISTRIBUTION_IS_UBUNTU=1 # Note, for now, just assuming ubuntu 12+ fi fi } .... check_for_ubuntu if [ $FB_DISTRIBUTION_IS_UBUNTU -eq 1 ]; then ubuntu_library_check else POPUP_MSG="Trine 2 Launcher script\n\nUnidentified Linux distribution.\nIf you have problems running the game, please see the game support web site for more info and ensure you have the required libraries installed." popup_info fi .... " e.i. previously with early December's "Cynede" Steam installation the game Trine2 successfully pass such check. What could be reason for such difference of behaviour?
(In reply to comment #163) P.S. But the game start and run successfully after clicking OK button of warning-information message
(In reply to comment #163) > > e.i. previously with early December's "Cynede" Steam installation the game > Trine2 successfully pass such check. > > What could be reason for such difference of behaviour? I'm not sure about actual troulbe with Trine2, but I think that anyc is correct person to ask and overlay you are speaking about is his overlay: https://github.com/anyc/steam-overlay Cynede overlay is: https://github.com/Cynede/weirdo and there is no steam at all So please review this moments )
I'd rather guess that there was an automatic update from Valve, as the new behavior is actually "right": you're not using Ubuntu and Gentoo is not supported. Maybe you can create the lsb-release file on your own if you want to get rid of the message but I don't know if that might cause trouble. As this script is not controlled by portage we cannot patch it to accept Gentoo either.
The address for the steam installer is now http://repo.steampowered.com/steam/archive/precise/steam_latest.deb and Steam will alert you to the fact if your installer is downloaded from the wrong location. It doesn't seem to prevent Steam from updating or otherwise working, but it does produce and annoying error message. Note: I am using Gamerlay, not Steam-Overlay, but have had no problems thus far with not using Ubuntu, and was invited into the beta even after explicitly stating I do NOT use Ubuntu.
Just a heads up, Steam now contains a ${STEAMFOLDER}/bin_steamdeps.py (to be modified and put at '/usr/bin/steamdeps'). I can only find steamdeps.txt as an example of what it is ment to parse and I'm not sure how much it is worth to deal with translating the ubuntu naming scheme. That being said, this looks like the start of what we need to consider properly resolving dependencies.
Both files are present since a few versions. I played around with an own steamdeps script in the steam overlay as the steam version concentrates on dpkg. I did not include it in newer versions as the steamdeps.txt was always the same and the steamdeps script is called at every startup and increases start-up time. I'd say it only helps to keep the meta ebuilds up-to-date. But I will take another look if this has changed.
(In reply to comment #169) > Both files are present since a few versions. I played around with an own > steamdeps script in the steam overlay as the steam version concentrates on > dpkg. I did not include it in newer versions as the steamdeps.txt was always > the same and the steamdeps script is called at every startup and increases > start-up time. I'd say it only helps to keep the meta ebuilds up-to-date. > But I will take another look if this has changed. If this has already been evaluated, don't bother adding more effort for now. I do not believe it has changed suddenly, it is my impression that they want the game makers to start using it, but it is not very substantial right now. and I have not found an example of a game using it yet.
Would it be beneficial to add a +steam-runtime use flag that patches in a 'export STEAM_RUNTIME=0' line early in /usr/bin/steam if the use flag is disabled. All major dependencies should be resolved with steam-client-meta and steam-games-meta. This tells the client to not interfere with our libraries and for various reasons disabling the runtime gives me a better experience.
(In reply to comment #171) > Would it be beneficial to add a +steam-runtime use flag that patches in a > 'export STEAM_RUNTIME=0' line early in /usr/bin/steam if the use flag is > disabled. All major dependencies should be resolved with steam-client-meta > and steam-games-meta. This tells the client to not interfere with our > libraries and for various reasons disabling the runtime gives me a better > experience. I agree but the current version shows nagging dialogs when it's disabled and works flawlessly when enabled. Looks like they're working on this topic. I'd say we'll take another look after the next release.
It seems that valve started providing .tar.gz packages besides .deb files from version 1.0.0.23 onward. Might be usefull since latest steam-base ebuild(s) still uses http://repo.steampowered.com/steam/archive/precise/steam_${PV}_i386.deb to fetch sources.
(In reply to comment #173) > It seems that valve started providing .tar.gz packages besides .deb files > from version 1.0.0.23 onward. Might be usefull since latest steam-base > ebuild(s) still uses > http://repo.steampowered.com/steam/archive/precise/steam_${PV}_i386.deb to > fetch sources. I see that in 8th Feb. Beta update of steam write: "Added licence to allow repackaging for other Linux distribution"
Looks like it is considered "stable" now: http://repo.steampowered.com/steam/archive/precise/steam_1.0.0.26_i386.changes I will update the overlays soon.
Valve release stable version on Linux Steam client today: http://store.steampowered.com/news/9943/
P.S. Is it planing to add steam-installer to official portage tree due to stable release?
(In reply to comment #177) > P.S. > > Is it planing to add steam-installer to official portage tree due to stable > release? a) the tarball does not have any version scheme b) would we be allowed to have it on our mirrors? => c) broken manifest by design (much like googleearth) => c2) only a live-ebuild would make sense, but there is no repository. This will end up in dirty workarounds d) this is only an installer, motivation is very low to work on this e) managing game dependencies via meta-ebuilds seems wrong to me and slow and painful to maintain. The wiki is much quicker on that matter, because everyone can add stuff there. People can manage their dependencies via portage sets easily f) if we need special libraries that cannot be included in regular emul-linux libs we can simply add an app-emulation/emul-linux-x86-steam package, but I did not see a reason for that yet an overlay seems to be the right location for such an ebuild IMO. Portage tree means we {do,can,want to} officially support that stuff (which may include a whole lot of bug reports). I don't see a sane way to do this. We can't even patch the install scripts properly to be POSIX, cause they are being refetched.
(In reply to comment #178) > (In reply to comment #177) > > P.S. > > > > Is it planing to add steam-installer to official portage tree due to stable > > release? > > a) the tarball does not have any version scheme It does. http://repo.steampowered.com/steam/archive/precise/steam_1.0.0.28.tar.gz > b) would we be allowed to have it on our mirrors? Yes. http://repo.steampowered.com/steam/archive/precise/steam_1.0.0.24_i386.changes > * Added license to allow repackaging for other Linux distributions > d) this is only an installer, motivation is very low to work on this this is only an installer for the most popular game deploying utility > e) managing game dependencies via meta-ebuilds seems wrong to me and slow > and painful to maintain. The wiki is much quicker on that matter, because > everyone can add stuff there. People can manage their dependencies via > portage sets easily That's ok > f) if we need special libraries that cannot be included in regular > emul-linux libs we can simply add an app-emulation/emul-linux-x86-steam > package, but I did not see a reason for that yet Why? Steam is the only way we can buy games on gentoo (except humble bundle) > an overlay seems to be the right location for such an ebuild IMO. Portage > tree means we {do,can,want to} officially support that stuff (which may > include a whole lot of bug reports). I don't see a sane way to do this. We > can't even patch the install scripts properly to be POSIX, cause they are > being refetched. But we can attach a bug reports to valve's github repository
(In reply to comment #179) +1 — I was about to post the same answers to (a-e). Regarding (f): (In reply to comment #178) > f) if we need special libraries that cannot be included in regular > emul-linux libs we can simply add an app-emulation/emul-linux-x86-steam > package, but I did not see a reason for that yet I totally agree. > an overlay seems to be the right location for such an ebuild IMO. Portage > tree means we {do,can,want to} officially support that stuff (which may > include a whole lot of bug reports). I don't see a sane way to do this. At least you have quite a bunch of users who want you to support that stuff. And who would appreciate the convenience of not having to unpack the tarball themselves, and stick the bits in the right places. Regarding the number and quality of bugreports: I don't know. I had hoped Gentoo educated its users to come well prepared and with some common sense to Gentoo Bugzilla... > We can't even patch the install scripts properly to be POSIX, cause they are > being refetched. Seems to be a correct assertion. You have to hope that Valve packs Steam with sensible install scripts. If not: Blame them on their own bugtracker, and hopefully they will react upon it. But e.g. their change in license seems very promising that they will take you seriously. If you were talking about game install scripts: No need to patch them — they are not your concern, but the game creator's.
(In reply to comment #180) > You have to hope that Valve packs Steam > with sensible install scripts. If not: Blame them on their own bugtracker, > and hopefully they will react upon it. What puzzles me is, why do we need an ebuild for something which downloads and executes a script, and that's it? I mean, an ebuild would be good when someone wants to remove it, but would leave there files what steam itself downloaded after installation. Steam also upgrades itself which invalidates the installed checksums, so even removing the ebuild would leave files on the filesystem. But tell me, if I'm wrong. This is the exact same reason why I don't use the firefox-bin and thunderbird-bin packages. I don't want to compile those, and I'm happy with their own upgrading mechanisms (the ebuilds are always behind anyway). Opera and google-chrome ebuilds are making sense as they're not upgrading themselves on Gentoo.
> Steam also upgrades itself which invalidates the installed checksums Wrong. Steam does not upgrade himself since the beta times. When Valve needs to upgrade /usr/bin/steam, they just update deb and tar.gz files in repo.steampowered.com by increasing the minor version. > so even removing the ebuild would leave files on the filesystem. when you unmerge ANY program, the files in home folder _aren't_ unmerging. This is by design.
e.g. I have some audacity files from times I have that installed (just removed those).
Created attachment 339166 [details] License
So, from what I can tell so far about what is keeping this from be added to tree is that it needs meta-ebuilds for games?
(In reply to comment #185) > So, from what I can tell so far about what is keeping this from be added to > tree is that it needs meta-ebuilds for games? That this is completely optional, wiki page is enough. Nothing keeping this from addition to tree (at least, in arch it's already added to official repository :))
(In reply to comment #186) > (In reply to comment #185) > > So, from what I can tell so far about what is keeping this from be added to > > tree is that it needs meta-ebuilds for games? > > That this is completely optional, wiki page is enough. Nothing keeping this > from addition to tree (at least, in arch it's already added to official > repository :)) well, we have different priorities then arch :P this might be something to bring up on the dev list though.
Another thing is that some games (e.g. Dwarfs?!) will not work without some 32bit libraries on 64-bit systems as there is no way install these libs with portage.
and, of course, before adding steam to tree, someone should port steamdeps script to Gentoo.
(In reply to comment #189) > and, of course, before adding steam to tree, someone should port steamdeps > script to Gentoo. Please do NOT add arch teams yourself next time
ah, ok.
(In reply to comment #189) > and, of course, before adding steam to tree, someone should port steamdeps > script to Gentoo. Last time I tested this, it was executed at every startup of steam with the steamdeps.txt in your steam folder that only contained deps for the client itself. Therefore, I didn't try to port it further. Afaik, the only confirmed dep that is missing right now is media-libs/jasper. Games like TF2, HL+CS 1.6, CS:Source and FTL work fine here with the libs from emul packages. With the meta ebuilds from (my) steam-overlay the user only has to emerge steam-meta and then he can start steam with a single command. For TF2, an additional use-flag has to be set to pull in s3tc support with OSS graphics. I think that this is much more convenient than creating sets, downloading tarballs and moving files around myself. From my point of view, it's currently more a political question if steam is accepted in main tree. But I'm fine with the overlay approach.
(In reply to comment #192) Do not try to port it before https://github.com/ValveSoftware/steam-for-linux/issues/1200 will be fixed
(In reply to comment #180) > Seems to be a correct assertion. You have to hope that Valve packs Steam > with sensible install scripts. If not: Blame them on their own bugtracker, > and hopefully they will react upon it. They did not until now. https://github.com/ValveSoftware/steam-for-linux/issues/623
(In reply to comment #179) > > f) if we need special libraries that cannot be included in regular > > emul-linux libs we can simply add an app-emulation/emul-linux-x86-steam > > package, but I did not see a reason for that yet > Why? Steam is the only way we can buy games on gentoo (except humble bundle) because until now the amd64 team was able to add necessary libraries to the existing emul-linux packages
I wonder who's doing the packaging for steam. Now they got a new package again. Looks like steam-launcher replaces other packages but now it's only available as deb again...
(In reply to comment #196) > I wonder who's doing the packaging for steam. Now they got a new package > again. Looks like steam-launcher replaces other packages but now it's only > available as deb again... "Steam-launcher" apparently is the "steam" and "steam64" package merged, it does not affect us on Gentoo.
I updated the to the latest steam client but now it won't launch because of a problem with a missing libSDL2-2.0.so.0 I know I can get around it using the binaries from steam, but I was hoping for a compiled solution similar to the other media-libs packages in the overlay. Does anyone know if there is already an overlay for this?
(In reply to comment #198) > I updated the to the latest steam client but now it won't launch because of > a problem with a missing libSDL2-2.0.so.0 I know I can get around it using > the binaries from steam, but I was hoping for a compiled solution similar to > the other media-libs packages in the overlay. Does anyone know if there is > already an overlay for this? You can get media-libs/libsdl:2 from gamerlay.
I modified the ebuild from gamerlay, added multlib support with cmake-multilib and pushed the ebuild to steam-overlay. It works for me on AMD64. I don't know if it's appreciated by the gamerlay devs as people are arguing right now which multilib eclass to use. Therefore, I keep it only in steam-overlay for now.
i have this error on 32bits even with media-libs/libsdl:2 and lasted ebuild from steam-overlay. Error: You are missing the following 32-bit libraries, and Steam may not run: libSDL2-2.0.so.0 updatedb && locate libSDL2 shows: /opt/Steam/SteamApps/xxxxxxx/Counter-Strike Source/bin/libSDL2-2.0.so.0 /usr/lib/libSDL2.so /usr/lib/libSDL2.so.0 /usr/lib/libSDL2.so.2.0.0 /usr/lib/libSDL2main.a Thanks, salud.
ln -s /usr/lib/libSDL2.so /usr/lib/libSDL2-2.0.so.0 seems solve the problem, but is dirty . Salud.
(In reply to comment #202) > ln -s /usr/lib/libSDL2.so /usr/lib/libSDL2-2.0.so.0 seems solve the problem, > but is dirty . I just pushed a new version that should work for non-multilib, too. It's quick and dirty, yes. I'm not really familiar with these library name schemes but it works for now.
Removing the licenses team from CC. Feel free to re-add if there are further license related questions.
(In reply to comment #200) > I modified the ebuild from gamerlay, added multlib support with > cmake-multilib and pushed the ebuild to steam-overlay. It works for me on > AMD64. I don't know if it's appreciated by the gamerlay devs as people are > arguing right now which multilib eclass to use. Therefore, I keep it only in > steam-overlay for now. there is this in steam-client-meta-9999.ebuild and it makes it seem to me that you are forcing the libs to be installed in ${D}/usr/lib32/ no mater what (from libsdl-2.0.0_pre6940.ebuild ). Is this intended and if so, why? amd64? ( media-libs/libsdl:2[abi_x86_32] )
(In reply to comment #205) > there is this in steam-client-meta-9999.ebuild and it makes it seem to me > that you are forcing the libs to be installed in ${D}/usr/lib32/ no mater > what (from libsdl-2.0.0_pre6940.ebuild ). Is this intended and if so, why? > > amd64? ( > media-libs/libsdl:2[abi_x86_32] > ) The symlink is required as the steam client doesn't find the library under its normal name in Gentoo. The path to this library doesn't matter actually. I wrote the path explicitly because currently I don't know how to get the library install path from a variable but a fast fix was necessary. I know that this is not a proper construct, I'll check the docs for dynamic way to get the path.
I'm getting the same error in 64-bit mode as well. Is there a proper symlink for this?
Using gamerlay, we're having issues with "media-libs/libsdl:2[abi_x86_32]" ("Missing IUSE: abi_x86_32"), presumably since libsdl doesn't have any such use flag. Does it install the symlink unilaterally, making this constraint incorrect, or was something else missed?
(In reply to comment #208) > Using gamerlay, we're having issues with "media-libs/libsdl:2[abi_x86_32]" > ("Missing IUSE: abi_x86_32"), presumably since libsdl doesn't have any such > use flag. Does it install the symlink unilaterally, making this constraint > incorrect, or was something else missed? The multilib ebuild for libsdl:2 and other packages is currently only available in steam-overlay. I've contacted the gamerlay maintainer for libsdl in this case. Some games require special patched ebuilds, too. I don't know if it's appreciated if I add them to gamerlay just for steam. Maybe it's better to remove steam from gamerlay.
dev-libs/gobject-introspection from steam overlay lacks file "dev-libs/gobject-introspection/files/disable_python.patch" * Package: dev-libs/gobject-introspection-1.32.1-r1 * Repository: steam-overlay * USE: abi_x86_32 abi_x86_64 amd64 doc doctool elibc_glibc kernel_linux userland_GNU * FEATURES: preserve-libs sandbox splitdebug >>> cfg-update-1.8.2-r1: Skipping checksum index updating... >>> Unpacking source... >>> Unpacking gobject-introspection-1.32.1.tar.xz to /var/tmp/portage/dev-libs/gobject-introspection-1.32.1-r1/work >>> Source unpacked in /var/tmp/portage/dev-libs/gobject-introspection-1.32.1-r1/work >>> Preparing source in /var/tmp/portage/dev-libs/gobject-introspection-1.32.1-r1/work/gobject-introspection-1.32.1 ... * Fixing OMF Makefiles ... [ ok ] * Disabling deprecation warnings ... [ ok ] * Running elibtoolize in: gobject-introspection-1.32.1/build-aux/ * Applying portage/1.2.0 patch ... * Applying sed/1.5.6 patch ... * Applying as-needed/2.2.6 patch ... * Cleaning 'build-aux/py-compile' file * Will copy sources from /var/tmp/portage/dev-libs/gobject-introspection-1.32.1-r1/work/gobject-introspection-1.32.1 * x86: copying to /var/tmp/portage/dev-libs/gobject-introspection-1.32.1-r1/work/gobject-introspection-1.32.1-x86 * amd64: copying to /var/tmp/portage/dev-libs/gobject-introspection-1.32.1-r1/work/gobject-introspection-1.32.1-amd64 * x86: running disable_unrequired_stuff_for_x86 * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: * * /usr/local/portage/layman/steam/dev-libs/gobject-introspection/files/disable_python.patch * ( disable_python.patch )
(In reply to comment #210) > dev-libs/gobject-introspection from steam overlay lacks file > "dev-libs/gobject-introspection/files/disable_python.patch" Please resync the overlay, I've added the missing file an hour ago.
dev-libs/gobject-introspection-1.32.1-r1::steam-overlay Fails to compile: checking whether to build static libraries... yes checking for i686-pc-linux-gnu-pkg-config... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for flex... flex checking lex output file root... lex.yy checking lex library... none needed checking whether yytext is a pointer... no checking for bison... bison -y checking for dlopen in -ldl... yes checking for the suffix of shared libraries... .so checking for GLIB... yes checking for GOBJECT... yes checking for GMODULE... yes checking for GIO... yes checking for GIO_UNIX... yes checking for CAIRO... no configure: error: Tests enabled but cairo not found; pass --disable-tests or install cairo !!! Please attach the following file when seeking support: !!! /var/tmp/portage/dev-libs/gobject-introspection-1.32.1-r1/work/gobject-introspection-1.32.1-x86/config.log * ERROR: dev-libs/gobject-introspection-1.32.1-r1 failed (configure phase): * econf failed * * Call stack: * ebuild.sh, line 93: Called src_configure * environment, line 6351: Called multilib-minimal_src_configure * environment, line 3842: Called multilib_foreach_abi 'multilib-minimal_abi_src_configure' * environment, line 4009: Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure' * environment, line 3718: Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure' * environment, line 3716: Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_configure' * environment, line 696: Called multilib-minimal_abi_src_configure * environment, line 3838: Called default_src_configure * phase-functions.sh, line 782: Called __eapi2_src_configure * phase-helpers.sh, line 626: Called econf * phase-helpers.sh, line 521: Called die * The specific snippet of code: * die "econf failed" * * If you need support, post the output of `emerge --info '=dev-libs/gobject-introspection-1.32.1-r1'`, * the complete build log and the output of `emerge -pqv '=dev-libs/gobject-introspection-1.32.1-r1'`. * This ebuild is from an overlay named 'steam-overlay': '/var/lib/layman/steam/' * The complete build log is located at '/var/tmp/portage/dev-libs/gobject-introspection-1.32.1-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/gobject-introspection-1.32.1-r1/temp/environment'. * Working directory: '/var/tmp/portage/dev-libs/gobject-introspection-1.32.1-r1/work/gobject-introspection-1.32.1-x86' * S: '/var/tmp/portage/dev-libs/gobject-introspection-1.32.1-r1/work/gobject-introspection-1.32.1'
See https://github.com/anyc/steam-overlay/issues/48 for the dev-libs/gobject-introspection issue.
Please report issues regarding steam-overlay or steam ebuilds in gamerlay at https://github.com/anyc/steam-overlay
My steam client has trouble picking up installed themes. I copied theme folders to ~/.local/share/steam/skins but steam doesnt pick them up in settings. Am i doing something wrong?
(In reply to comment #215) > My steam client has trouble picking up installed themes. > I copied theme folders to ~/.local/share/steam/skins but steam doesnt pick > them up in settings. > Am i doing something wrong? Your issue is being tracked at https://github.com/ValveSoftware/steam-for-linux/issues/2400
The SDL2 ebuild in the steam overlay has stopped working for quite a while now (ever since libX11 1.5.99.902). Could you pull the new SDL2 ebuild from gamerlay? It comes with a patch that fixes the problem.
(In reply to Julian Ospald (hasufell) from comment #10) > The ebuild might help to figure out dependencies, but it's probably better > to start a gentoo wiki page for this. > > There is not much point in creating an ebuild, because this is just an > installer, nothing more. The real games files and data get placed somewhere > in $HOME and are meant to be controlled by steam/auto-updater, not the > package manager. By the way, we have a precedent of having ebuilds for installers - for example dev-util/android-sdk-update-manager .
(In reply to Nikos Chantziaras from comment #217) > The SDL2 ebuild in the steam overlay has stopped working for quite a while > now (ever since libX11 1.5.99.902). Could you pull the new SDL2 ebuild from > gamerlay? It comes with a patch that fixes the problem. Don't use broken overlays and if you do, follow this advise: https://wiki.gentoo.org/wiki/Overlay#Using_unsafe_overlays
Does anyone have it working on hardened? I've followed the wiki, but paxmarking /bin/bash is a bad idea, (it'll break bash and stuff...). Even when doing so it fails to spawn (because bash is broken). paxctl-ng -m /lib64/libc-2.15.so /lib64/libdl-2.15.so /lib64/libreadline.so.6.2 /lib64/libncurses.so.5.9 doesn't even help. So, if anyone has it working on hardened I'm all ears :D
*** Bug 488918 has been marked as a duplicate of this bug. ***
Should this also depend on bug #484130?
I just got a crash dump here./home/shentino/.local/share/Steam/steam.sh: line 152: DISTRIB_RELEASE: unbound variable /home/shentino/.local/share/Steam/steam.sh: line 152: DISTRIB_RELEASE: unbound variable Running Steam on gentoo 64-bit /home/shentino/.local/share/Steam/steam.sh: line 152: DISTRIB_RELEASE: unbound variable STEAM_RUNTIME is enabled automatically Installing breakpad exception handler for appid(steam)/version(1468023329) Installing breakpad exception handler for appid(steam)/version(1468023329) Installing breakpad exception handler for appid(steam)/version(1468023329) (steam:27369): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita", (steam:27369): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita", /usr/share/themes/Adwaita/gtk-2.0/gtkrc:1163: error: unexpected identifier `direction', expected character `}' Installing breakpad exception handler for appid(steam)/version(1468023329) Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 78: saw unknown, expected number [0731/062600:ERROR:main_delegate.cc(779)] Could not load cef_extensions.pak [0731/062600:ERROR:browser_main_loop.cc(217)] Running without the SUID sandbox! See https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the sandbox on. [0731/062600:ERROR:platform_thread_posix.cc(115)] pthread_create: Resource temporarily unavailable [0731/062600:ERROR:platform_thread_posix.cc(115)] pthread_create: Resource temporarily unavailable [0731/062600:ERROR:platform_thread_posix.cc(115)] pthread_create: Resource temporarily unavailable [0731/062600:ERROR:platform_thread_posix.cc(115)] pthread_create: Resource temporarily unavailable [0731/062600:ERROR:platform_thread_posix.cc(115)] pthread_create: Resource temporarily unavailable [0731/062600:FATAL:browser_main_loop.cc(898)] Failed to start the browser thread: id == 1 #0 0x0000baa20c4a <unknown> #1 0x0000baa3b47d <unknown> #2 0x0000be018905 <unknown> #3 0x0000be01ccc1 <unknown> #4 0x0000be34a41f <unknown> #5 0x0000be017d5d <unknown> #6 0x0000be01d9e3 <unknown> #7 0x0000ba96e872 <unknown> #8 0x0000be537201 <unknown> #9 0x0000be53801a <unknown> #10 0x0000ba8eb48a <unknown> #11 0x0000ba8eb24c <unknown> #12 0x0000ba87bc85 cef_initialize #13 0x00005660abe3 <unknown> #14 0x0000565d8d2b CCEFThread::Init() #15 0x0000565d90d6 <unknown> #16 0x00005656f757 <unknown> #17 0x0000ba27a43e __libc_start_main #18 0x00005657058d <unknown> Installing breakpad exception handler for appid(steamwebhelper)/version(20160708214346) Installing breakpad exception handler for appid(steamwebhelper)/version(1468014226) [0731/062600:ERROR:main_delegate.cc(779)] Could not load cef_extensions.pak Installing breakpad exception handler for appid(steam)/version(1468023329) Installing breakpad exception handler for appid(steam)/version(1468023329) Installing breakpad exception handler for appid(steam)/version(1468023329) Installing breakpad exception handler for appid(steam)/version(1468023329) Installing breakpad exception handler for appid(steam)/version(1468023329) Installing breakpad exception handler for appid(steam)/version(1468023329) Created shared memory when not owner SteamController_Shared_mem Installing breakpad exception handler for appid(steam)/version(1468023329) Installing breakpad exception handler for appid(steam)/version(1468023329) PulseAudio connect failed (used only for Mic Volume Control) with error: Access denied ** (steam:27369): WARNING **: Could not initialize NMClient /org/freedesktop/NetworkManager: The name org.freedesktop.NetworkManager was not provided by any .service files Installing breakpad exception handler for appid(steam)/version(1468023329) Generating new string page texture 2: 48x256, total string texture memory is 49.15 KB Installing breakpad exception handler for appid(steam)/version(1468023329) (steam:27369): GLib-ERROR **: creating thread 'gdbus': Error creating thread: Resource temporarily unavailable /home/shentino/.local/share/Steam/steam.sh: line 713: 27369 Trace/breakpoint trap (core dumped) $STEAM_DEBUGGER "$STEAMROOT/$STEAMEXEPATH" "$@"
In order to have the taskbar icon for steam useable in KDE, I had to install libdbusmenu. But since then I have a conflict: WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict: dev-libs/json-glib:0 (dev-libs/json-glib-1.2.8:0/0::gentoo, ebuild scheduled for merge) conflicts with >=dev-libs/json-glib-0.13.4[abi_x86_32(-),abi_x86_64(-)] required by (dev-libs/libdbusmenu-12.10.2-r2:0/0::gentoo, installed) dev-libs/dbus-glib:0 (dev-libs/dbus-glib-0.102:0/0::gentoo, ebuild scheduled for merge) conflicts with >=dev-libs/dbus-glib-0.100[abi_x86_32(-),abi_x86_64(-)] required by (dev-libs/libdbusmenu-12.10.2-r2:0/0::gentoo, installed)
Steam is not in Portage now?
Anyone interested in adding steam to the gentoo main repo is welcome to make a PR. While as for now, there is dedicated overlay for steam (which can be adde with eselet-repository).
I've been asked a few times to move it into the main repo. I'm a bit uneasy about it. It's a bit of a moving target, so the quality is sometimes a bit sketchy. If you're not using the Steam runtime (I don't recommend it) then you sometimes need other old package versions that we've had to resurrect after they were removed from the main repo.
