With the ongoing port of Valve's Steam platform to Linux we will need additional libraries in the emul-linux-* packages to allow AMD64 users to play the x86 games. I'd like to propose this bug to gather missing dependencies until a new set of emul* packages is bumped. See also bug #442176. As a start, please include media-libs/jasper. Reproducible: Always
+1 Please, include sys-apps/pciutils - need for Serious Sam 3: BFE
It would be helpful to have a list of the exact games that need mentioned libraries. I'm not sure I fully understand what's so wrong with multilib ebuilds and why we have emul-linux-*… Why can't we just make those needed ebuilds (e.g. jasper) support multilib instead of adding even more stuff into emul-linux-*?
(In reply to comment #1) > Please, include sys-apps/pciutils - need for Serious Sam 3: BFE ArchWiki (https://wiki.archlinux.org/index.php/Steam#Native_Steam_on_Linux) says: "Useless as now SS3 uses lspci in a recent beta release". Could you check if this is true?
(In reply to comment #3) > (In reply to comment #1) > > Please, include sys-apps/pciutils - need for Serious Sam 3: BFE > > ArchWiki (https://wiki.archlinux.org/index.php/Steam#Native_Steam_on_Linux) > says: > "Useless as now SS3 uses lspci in a recent beta release". Could you check if > this is true? Yes, it is. SS3 no longer requires libpci.so
Don't we need dev-libs/libappindicator in 32bit to support tray icons outside of Unity?
(In reply to comment #5) > Don't we need dev-libs/libappindicator in 32bit to support tray icons > outside of Unity? Libappindicator is not a hard dependency and it's masked for all arches in main tree. So, first it should be stabilized on x86.
(In reply to comment #5) > Don't we need dev-libs/libappindicator in 32bit to support tray icons > outside of Unity? doesn't work for me in xfce (In reply to comment #6) > Libappindicator is not a hard dependency and it's masked for all arches in > main tree. So, first it should be stabilized on x86. It's not masked. And stabilizing is not a requirement.
> > doesn't work for me in xfce > Do you have a libappindicator 32bit .tbz2 available that we could test? Don't have any 32bit systems available here, unfortunately. I'm running KDE.
(In reply to comment #6) > (In reply to comment #5) > > Don't we need dev-libs/libappindicator in 32bit to support tray icons > > outside of Unity? > > Libappindicator is not a hard dependency and it's masked for all arches in > main tree. So, first it should be stabilized on x86. no plans in stabilizing any of the ayatana related libraries. they should stay in ~arch and even USE=ayatana is masked in use.mask as experimental unless amd64@ (pacho?) makes an exception of adding ~arch libs to emul- packages I doubt this will move anywhere
(In reply to comment #8) > > > > doesn't work for me in xfce > > > > Do you have a libappindicator 32bit .tbz2 available that we could test? > Don't have any 32bit systems available here, unfortunately. I'm running KDE. you can use a 32bit chroot http://www.gentoo.org/proj/en/base/amd64/howtos/chroot.xml however we could simply maintain our own emul-linux-x86-steam or similarly named package which would basically depend on the other emul-linux libs and add those not present there. but I still can't make it work with libappindicator, so...
+1 for the suggestion emul-linux-x86-steam, it sounds like a good idea :)
I would probably wait for new eclasses supporting multilib landing in the tree instead of making emul sets grow more and more :/
steam now has tray icon support without libappindicator I think at least a tray icon popped up after last update
The tray app that is now visible is the same libappindicator based tray app, the Valve linux team is making an entire runtime environment and they have internally packaged everything needed for the tray app to open. The runtime environment can be temporarily disabled by running 'STEAM_RUNTIME=0 steam' in a terminal.
I've run in lack of dev-dotnet/libgdiplus for Dwarfs!?
*** Bug 457906 has been marked as a duplicate of this bug. ***
I think, long term it would be better to port the necessary libraries to multilib-build.eclass. For most packages this is straight forward, see the fftw-3.3.3-r1 ebuild and bug #455220.
I just tried with media-libs/jasper - see http://bpaste.net/show/78170/ . It builds and install both .so files but I cannot test it as I don't have an application that uses it. Can anyone confirm that it works?
(In reply to comment #18) > I just tried with media-libs/jasper - see http://bpaste.net/show/78170/ . It > builds and install both .so files but I cannot test it as I don't have an > application that uses it. Can anyone confirm that it works? Good start, please open a separate bug (cc: me) for that with a diff against the latest ebuild in the tree.
Opened bug #458380 for jasper multilib support
(In reply to comment #17) > I think, long term it would be better to port the necessary libraries to > multilib-build.eclass. For most packages this is straight forward, see the > fftw-3.3.3-r1 ebuild and bug #455220. libgdiplus is a go-mono package.
(In reply to comment #21) > (In reply to comment #17) > > I think, long term it would be better to port the necessary libraries to > > multilib-build.eclass. For most packages this is straight forward, see the > > fftw-3.3.3-r1 ebuild and bug #455220. > > libgdiplus is a go-mono package. Reading eclass looks like libgdiplus could easily be moved to standard building as all that mono_multilib_comply stuff is deprecated (the problem is that none of dotnet team have had enough time to start moving to newer (and much simpler) eclasses for dotnet packages :S
(In reply to comment #22) > (In reply to comment #21) > > (In reply to comment #17) > > > I think, long term it would be better to port the necessary libraries to > > > multilib-build.eclass. For most packages this is straight forward, see the > > > fftw-3.3.3-r1 ebuild and bug #455220. > > > > libgdiplus is a go-mono package. > > Reading eclass looks like libgdiplus could easily be moved to standard > building as all that mono_multilib_comply stuff is deprecated (the problem > is that none of dotnet team have had enough time to start moving to newer > (and much simpler) eclasses for dotnet packages :S The only problem that you could get with dotnet packages is that most of them need MAKEOPTS="-j1" (upstream is aware but...)
I already tried that and get weird libtool failures. So I suggest to move libgdiplus to emul-linux packages first.
It looks like dwarfs is using its bundled libgdiplus but it's missing a 32bit version of libexif. I just uploaded a multilib-patched libexif ebuild [1] into steam-overlay and it works for me. If others confirm, we could request inclusion in main tree. [1] https://github.com/anyc/steam-overlay/blob/master/media-libs/libexif/libexif-0.6.21-r1.ebuild
Btw, anyone with steam can test, as there's a free-to-play version available but it only shows up in the store.
Works for me too with full version of Dwarfs.
Okay, I opened bug #458638 for the multilib patch.
I'm not sure if this is the proper place to report that bug, but in app-emulation/emul-linux-x86-baselibs-20130224 libudev.so.0 has been replaced by libudev.so.1 And if you try to start Steam now, it complains about the lack of libudev.so.0 .
(In reply to comment #29) > And if you try to start Steam now, it complains about the lack of > libudev.so.0 . I cannot confirm that steam complains. Where does it for you?
Steam applied an update here today and stopped working with the current default of STEAM_RUNTIME=0, because it now uses SDL2.
(In reply to comment #31) > Steam applied an update here today and stopped working with the current > default of STEAM_RUNTIME=0, because it now uses SDL2. Please see https://bugs.gentoo.org/show_bug.cgi?id=442176#c198 onwards.
32bit libexif library is missing for Steam game "Dwarfs F2P'
(In reply to comment #33) > 32bit libexif library is missing for Steam game "Dwarfs F2P' It's included in steam-overlay. Available through layman or https://github.com/anyc/steam-overlay
libexif has been converted to support multilib wrt bug 458638 Be careful when using system libraries from overlays.
It looks like the newest steam requires libnm-glib to start.
(In reply to comment #36) > It looks like the newest steam requires libnm-glib to start. My fault - something else was wrong.
We cannot include it if libsdl:2 is not added to the tree. For the rest of the packages, please open a bug report asking them to migrate to either multilib-minimal or autotools-multilib eclasses Thanks
*** Bug 460616 has been marked as a duplicate of this bug. ***
