Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 446682 - app-emulation/emul-linux-x86* - new libraries for steam platform
Summary: app-emulation/emul-linux-x86* - new libraries for steam platform
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal enhancement with 2 votes (vote)
Assignee: AMD64 Project
URL:
Whiteboard:
Keywords:
: 457906 460616 (view as bug list)
Depends on: 416723 460432
Blocks: 442176
  Show dependency tree
 
Reported: 2012-12-10 03:34 UTC by Mario Kicherer
Modified: 2013-08-19 15:22 UTC (History)
14 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mario Kicherer 2012-12-10 03:34:20 UTC
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
Comment 1 Pavel Borisov 2012-12-10 07:37:23 UTC
+1

Please, include sys-apps/pciutils - need for Serious Sam 3: BFE
Comment 2 Kirill Elagin 2012-12-10 09:58:20 UTC
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-*?
Comment 3 Mario Kicherer 2012-12-11 02:52:25 UTC
(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?
Comment 4 Pavel Borisov 2012-12-11 10:04:55 UTC
(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
Comment 5 Mads 2013-01-29 12:08:42 UTC
Don't we need dev-libs/libappindicator in 32bit to support tray icons outside of Unity?
Comment 6 Mario Kicherer 2013-01-29 12:16:04 UTC
(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.
Comment 7 Julian Ospald 2013-01-29 12:22:22 UTC
(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.
Comment 8 Mads 2013-01-29 17:10:31 UTC
> 
> 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.
Comment 9 Samuli Suominen (RETIRED) gentoo-dev 2013-01-29 17:37:50 UTC
(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
Comment 10 Julian Ospald 2013-01-29 17:46:26 UTC
(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...
Comment 11 Mads 2013-01-29 18:03:10 UTC
+1 for the suggestion emul-linux-x86-steam, it sounds like a good idea :)
Comment 12 Pacho Ramos gentoo-dev 2013-01-29 21:41:53 UTC
I would probably wait for new eclasses supporting multilib landing in the tree instead of making emul sets grow more and more :/
Comment 13 Julian Ospald 2013-02-02 14:35:08 UTC
steam now has tray icon support without libappindicator I think

at least a tray icon popped up after last update
Comment 14 kisak42 2013-02-05 15:13:40 UTC
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.
Comment 15 Maciej Piechotka 2013-02-16 10:50:59 UTC
I've run in lack of dev-dotnet/libgdiplus for Dwarfs!?
Comment 16 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-02-16 21:36:55 UTC
*** Bug 457906 has been marked as a duplicate of this bug. ***
Comment 17 Christoph Junghans (RETIRED) gentoo-dev 2013-02-18 20:00:40 UTC
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.
Comment 18 Mario Kicherer 2013-02-18 21:42:59 UTC
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?
Comment 19 Christoph Junghans (RETIRED) gentoo-dev 2013-02-19 02:30:00 UTC
(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.
Comment 20 Mario Kicherer 2013-02-19 23:42:04 UTC
Opened bug #458380 for jasper multilib support
Comment 21 Julian Ospald 2013-02-20 22:44:38 UTC
(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.
Comment 22 Pacho Ramos gentoo-dev 2013-02-21 19:01:13 UTC
(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
Comment 23 Pacho Ramos gentoo-dev 2013-02-21 19:01:50 UTC
(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...)
Comment 24 Julian Ospald 2013-02-21 19:06:25 UTC
I already tried that and get weird libtool failures. So I suggest to move libgdiplus to emul-linux packages first.
Comment 25 Mario Kicherer 2013-02-21 20:36:30 UTC
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
Comment 26 Mario Kicherer 2013-02-21 21:08:40 UTC
Btw, anyone with steam can test, as there's a free-to-play version available but it only shows up in the store.
Comment 27 Pavel Borisov 2013-02-21 22:01:25 UTC
Works for me too with full version of Dwarfs.
Comment 28 Mario Kicherer 2013-02-21 22:20:34 UTC
Okay, I opened bug #458638 for the multilib patch.
Comment 29 EoD 2013-02-27 12:31:15 UTC
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 .
Comment 30 Mario Kicherer 2013-02-27 21:41:37 UTC
(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?
Comment 31 Nikos Chantziaras 2013-03-05 16:53:45 UTC
Steam applied an update here today and stopped working with the current default of STEAM_RUNTIME=0, because it now uses SDL2.
Comment 32 Mario Kicherer 2013-03-05 16:55:39 UTC
(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.
Comment 33 T. S. 2013-03-08 10:44:37 UTC
32bit libexif library is missing for Steam game "Dwarfs F2P'
Comment 34 Mario Kicherer 2013-03-08 10:54:08 UTC
(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
Comment 35 Julian Ospald 2013-03-09 21:43:51 UTC
libexif has been converted to support multilib wrt bug 458638

Be careful when using system libraries from overlays.
Comment 36 Maciej Piechotka 2013-04-26 11:47:02 UTC
It looks like the newest steam requires libnm-glib to start.
Comment 37 Maciej Piechotka 2013-04-27 09:51:12 UTC
(In reply to comment #36)
> It looks like the newest steam requires libnm-glib to start.

My fault - something else was wrong.
Comment 38 Pacho Ramos gentoo-dev 2013-07-21 17:58:37 UTC
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
Comment 39 Pacho Ramos gentoo-dev 2013-07-21 18:03:27 UTC
*** Bug 460616 has been marked as a duplicate of this bug. ***