Valve's Steam client uses the appindicator framework to create a tray menu. The client is only available as 32bit version and therefore, a multilib version of mentioned ebuilds is required. Additional info with the patches follows. Reproducible: Always
Created attachment 342958 [details, diff] libindicator.patch This creates a multilib version of the libindicator ebuild. It also introduces a gtk3 use flag as the steam client requires gtk2 and gtk2 is used if gtk3 is not enabled.
Created attachment 342960 [details, diff] libdbusmenu.patch This patch also introduces multilib and a gtk3 use flag in the ebuild. The PKG_CONFIG_PATH export is required as workaround - a patch has been reported in a separate bug.
Created attachment 342962 [details, diff] libappindicator.patch This patch introduces multilib and a gtk3 use flag. The building of python bindings is disabled by the build system for gtk3 but enabled for gtk2. Building those bindings fails for me with and without multilib, therefore I disabled the python bindings. Unfortunately it's not as easy as in the mono case. It also adds $(use_enable introspection) to the econf flags, this was missing in the original ebuild.
The patched ebuilds can be found here: https://github.com/anyc/steam-overlay/tree/master/dev-libs
Created attachment 342970 [details, diff] libindicator.patch Small fix for the libindicator patch. I just remembered why I didn't post these patches before: introspection is not multilib capable. I'm currently working on this.
Created attachment 342980 [details, diff] gobject-introspection.patch Multilib patch for gobject-introspection ebuild. I guess this would require an own bug but I post it here so we can discuss if it's even worth to request inclusion.
AFAICS we have separate GTK+2 and GTK+3 ebuilds for the libs. Please use that properly rather than adding USE=gtk3. Also, the official QA-blessed way of running multilib with autotools is through the use of autotools-multilib eclass. Please don't use multilib-minimal unless dealing with a messy build system.
(In reply to comment #6) > Created attachment 342980 [details, diff] [details, diff] > gobject-introspection.patch > > Multilib patch for gobject-introspection ebuild. I guess this would require > an own bug but I post it here so we can discuss if it's even worth to > request inclusion. Please do *not* assume that $(get_libdir) will be "lib32" for x86-on-amd64. It is possible (and, from what I understand, eventually will be a primary configuration) to have LIBDIR_x86=lib (without a lib->lib64 symlink), which makes get_libdir() return "lib" for x86-on-amd64, and "lib64" for amd64.
(In reply to comment #7) > AFAICS we have separate GTK+2 and GTK+3 ebuilds for the libs. Please use > that properly rather than adding USE=gtk3. USE=gtk3 was purposely removed already from every ayatana ebuilds, and since we don't have staffing we decided to only maintain GTK+ 3.x versions in tree currently if you want support for both 2 and 3, then you should submit patches to upstream to allow clean splitting which isn't possible with the current way
First, thank you all for your hints, I'm currently fiddling with those changes. If gtk2 and gtk3 versions cannot be installed in parallel, wouldn't it be better to remove slotting and handle the choice using use-flags? The gtk2 versions of those three ebuilds work for me and some of the overlay users so far. With "gtk3" use flag the ebuilds should behave like those in main tree. If gtk2 cannot be supported, couldn't we just mask it in main tree? I'm not completely happy with my approach either but I think it makes things a little bit less troublesome.
Sorry, I mean, adding gtk3 to package.use.force for those packages.
Is there anyway we could support both gtk2 and gtk3 libraries in the ebuild? It looks like the library names do not collide. This is important for supporting system tray icons in Plasma Desktop 5.
For reference: https://bugzilla.redhat.com/show_bug.cgi?id=842509#c20 It looks like other distros have solved this by multiple builds and install. I suspect it will work to run two builds and install them into the same tree. I'll see if I can modify the ebuilds to do that.
I've created some initial builds for this that support building both gtk2 and gtk3 libraries. https://github.com/murrant/murrant-overlay/commit/5e7f80555e6f597c70edbdf00b2b88fcc89707bb They are incomplete, but I wanted input on the approach before I polish them. libdbusmenu and libappindicator are not working on multilib and I skip non-native gtk3 builds because of dependencies that don't support multilib. The libappindicators bindings do some weird things in the gtk2 build, so if we are building gtk2 I yank them out right now, that needs to be fixed. Please let me know if this is worth more work from me, otherwise, I'll just get them good enough for my own uses. (System tray support in Plasma 5)
libappindicator can be slotted very easily without file collisons: https://gist.github.com/karolherbst/c067f1c2e483570fbbfc I think this is the best approach for libappindicator
I've updated the stuff a little bit: it basically contains some gtk2/gtk3 handling inside libappindicator and libdbusmenu. I could integrate the multilib parts from indicator and appindicator, too. https://github.com/karolherbst/kde/compare/karolherbst:975c41bd7157110972e6c055122b9a46187d8b74...systray-stuff-gentoo-bug
so on my github branch are now the needed bits for libappindicator multilib gtk2/gtk3 and multilib sni-qt. Both seems to work nice (tested sni-qt with skype and libappindicator with various gtk apps)
newest ebuilds are here: https://github.com/karolherbst/gentoo-portage-rsync-mirror/commits/appindicator
I'm starting to apply those changes. I'm going to start with the slotmove + gtk->gtk3 flag change.
+*libdbusmenu-12.10.2-r2 (19 Apr 2015) + + 19 Apr 2015; Michał Górny <mgorny@gentoo.org> + +files/libdbusmenu-12.10.2-gtk2-signal-fix.patch, + +libdbusmenu-12.10.2-r2.ebuild, metadata.xml: + Enable optional GTK+2 support. Enable multilib support. Remove gtk-doc install + hacks, just install into the proper gtk-doc location. Based on the work done + by Karol Herbst on https://github.com/gentoo/gentoo-portage-rsync- + mirror/pull/65. Part of bug #462764.
And all shall be done now. Please test.
