Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 643522 - gnome-extra/chrome-gnome-shell is not compatible with a SYMLINK_LIB=no system
Summary: gnome-extra/chrome-gnome-shell is not compatible with a SYMLINK_LIB=no system
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: nE0sIghT
URL: https://bugzilla.mozilla.org/show_bug...
Whiteboard:
Keywords: PullRequest
Depends on:
Blocks: no-symlink-lib
  Show dependency tree
 
Reported: 2018-01-05 10:25 UTC by Seheon Ryu
Modified: 2019-04-19 12:52 UTC (History)
7 users (show)

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


Attachments
Added -DCMAKE_INSTALL_LIBDIR=lib (chrome-gnome-shell-9-r1.ebuild,1.85 KB, text/plain)
2018-01-05 10:25 UTC, Seheon Ryu
Details
Proposed workaround (chrome-gnome-shell-firefox-bin.patch,779 bytes, patch)
2018-11-11 15:37 UTC, nE0sIghT
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Seheon Ryu 2018-01-05 10:25:26 UTC
Created attachment 513384 [details]
Added -DCMAKE_INSTALL_LIBDIR=lib

My system uses customized no-multilib profile based on 17.1 profile.

I found gnome-extra/chrome-gnome-shell-9 is not working with www-client/firefox-bin-57.0.3 after migrating to 17.1 profile.

Adding -DCMAKE_INSTALL_LIBDIR=lib to ebuild fixed the problem.
Fixed ebuild is attached.


emerge --info
Portage 2.3.19 (python 2.7.14-final-0, default/linux/amd64/17.1, gcc-7.2.0, glibc-2.26-r5, 4.14.11-gentoo x86_64)
=================================================================
System uname: Linux-4.14.11-gentoo-x86_64-Intel-R-_Core-TM-_i5-4302Y_CPU_@_1.60GHz-with-gentoo-2.4.1
KiB Mem:     4110728 total,   2187328 free
KiB Swap:          0 total,         0 free
Timestamp of repository gentoo: Fri, 05 Jan 2018 07:15:01 +0000
Head commit of repository gentoo: 9f291cc30937e495f0bbaece989803f9a57c4119
sh bash 4.4_p12
ld GNU ld (Gentoo 2.29.1 p2) 2.29.1
app-shells/bash:          4.4_p12::gentoo
dev-lang/perl:            5.26.1-r1::gentoo
dev-lang/python:          2.7.14-r1::gentoo, 3.5.4-r1::gentoo
dev-util/cmake:           3.10.1::gentoo
dev-util/pkgconfig:       0.29.2::gentoo
sys-apps/baselayout:      2.4.1-r2::gentoo
sys-apps/sandbox:         2.12::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69-r4::gentoo
sys-devel/automake:       1.15.1-r1::gentoo
sys-devel/binutils:       2.29.1-r1::gentoo
sys-devel/gcc:            7.2.0::gentoo
sys-devel/gcc-config:     1.9.1::gentoo
sys-devel/libtool:        2.4.6-r4::gentoo
sys-devel/make:           4.2.1-r1::gentoo
sys-kernel/linux-headers: 4.14::gentoo (virtual/os-headers)
sys-libs/glibc:           2.26-r5::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://ftp.jaist.ac.jp/gentoo-portage
    priority: -1000
    sync-rsync-extra-opts: 

local
    location: /home/sh/maintenance/gentoo/portage
    masters: gentoo

ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA AdobeFlash-11.x"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -mabm -maes -mbmi -mcx16 -mf16c -mfma -mfxsr -mlzcnt -mmmx -mpclmul -msahf"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/chromium/policies/managed/chrome-gnome-shell.json /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/opt/chrome/policies/managed/chrome-gnome-shell.json /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe -mabm -maes -mbmi -mcx16 -mf16c -mfma -mfxsr -mlzcnt -mmmx -mpclmul -msahf"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox selinux sesandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://ftp.kaist.ac.kr/pub/gentoo http://ftp.lanet.kr/pub/gentoo http://ftp.daum.net/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo"
LANG="en_US.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j8"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac acl acpi alsa amd64 branding bzip2 cairo cdr crypt cxx dbus dri dts dvd dvdr eds emboss encode evo fam firefox flac gif glamor gnome gnome-keyring gtk hardened iconv introspection ipv6 jpeg lcms libkms libnotify libsecret mad mng mp4 mpeg nautilus ncurses nls nptl open_perms opengl openmp pam pango pcre pdf pie png policykit ppds pulseaudio qt3support readline seccomp selinux ssl ssp startup-notification svg symlink systemd truetype udev udisks unconfined unicode upower wayland wxwidgets xa xattr xcb xml xtpax xv zlib" ABI_X86="64" ALSA_CARDS="hda-intel" CPU_FLAGS_X86="aes avx f16c fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GRUB_PLATFORMS="pc" INPUT_DEVICES="libinput" KERNEL="linux" LLVM_TARGETS="BPF" PYTHON_SINGLE_TARGET="python3_5" PYTHON_TARGETS="python2_7 python3_5" RUBY_TARGETS="ruby22" USERLAND="GNU" VIDEO_CARDS="vmware"
Unset:  CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS


equery f chrome-gnome-shell
 * Searching for chrome-gnome-shell ...
 * Contents of gnome-extra/chrome-gnome-shell-9:
/etc
/etc/chromium
/etc/chromium/native-messaging-hosts
/etc/chromium/native-messaging-hosts/org.gnome.chrome_gnome_shell.json
/etc/chromium/policies
/etc/chromium/policies/managed
/etc/chromium/policies/managed/chrome-gnome-shell.json
/etc/env.d
/etc/env.d/50chrome-gnome-shell
/etc/opt
/etc/opt/chrome
/etc/opt/chrome/native-messaging-hosts
/etc/opt/chrome/native-messaging-hosts/org.gnome.chrome_gnome_shell.json
/etc/opt/chrome/policies
/etc/opt/chrome/policies/managed
/etc/opt/chrome/policies/managed/chrome-gnome-shell.json
/usr
/usr/bin
/usr/bin/chrome-gnome-shell
/usr/lib64
/usr/lib64/mozilla
/usr/lib64/mozilla/native-messaging-hosts
/usr/lib64/mozilla/native-messaging-hosts/org.gnome.chrome_gnome_shell.json
/usr/lib64/python3.5
/usr/lib64/python3.5/site-packages
/usr/lib64/python3.5/site-packages/chrome_gnome_shell-0.0.0-py3.5.egg-info
/usr/share
/usr/share/applications
/usr/share/applications/org.gnome.ChromeGnomeShell.desktop
/usr/share/dbus-1
/usr/share/dbus-1/services
/usr/share/dbus-1/services/org.gnome.ChromeGnomeShell.service
/usr/share/doc
/usr/share/doc/chrome-gnome-shell-9
/usr/share/doc/chrome-gnome-shell-9/NEWS.bz2
/usr/share/doc/chrome-gnome-shell-9/README.md.bz2
/usr/share/icons
/usr/share/icons/gnome
/usr/share/icons/gnome/128x128
/usr/share/icons/gnome/128x128/apps
/usr/share/icons/gnome/128x128/apps/org.gnome.ChromeGnomeShell.png
/usr/share/icons/gnome/16x16
/usr/share/icons/gnome/16x16/apps
/usr/share/icons/gnome/16x16/apps/org.gnome.ChromeGnomeShell.png
/usr/share/icons/gnome/48x48
/usr/share/icons/gnome/48x48/apps
/usr/share/icons/gnome/48x48/apps/org.gnome.ChromeGnomeShell.png


equery f chrome-gnome-shell
 * Searching for chrome-gnome-shell ...
 * Contents of gnome-extra/chrome-gnome-shell-9-r1:
--skipped--
/usr/lib
/usr/lib/mozilla
/usr/lib/mozilla/native-messaging-hosts
/usr/lib/mozilla/native-messaging-hosts/org.gnome.chrome_gnome_shell.json
Comment 1 nE0sIghT 2018-01-08 06:59:18 UTC
Could you please test www-client/firefox with your patch?
I believe it may be breaked.
Comment 2 Seheon Ryu 2018-01-08 11:28:01 UTC
You are correct.
www-client/firefox requires json file to be placed in /usr/lib64/mozilla.
My patch breaks compatibility with www-client/firefox.

Installing symlink may be a workaround.
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-01-08 13:15:05 UTC
Sounds like firefox install on Gentoo is broken by diverging from upstream.
Comment 4 Seheon Ryu 2018-01-09 16:33:01 UTC
I had some free time, examined upstream code.

https://hg.mozilla.org/mozilla-central/file/tip/toolkit/xre/nsXREDirProvider.cpp
revision 6f5fac320fcb line 298


  NS_NAMED_LITERAL_CSTRING(dirname,
#ifdef HAVE_USR_LIB64_DIR
                           "/usr/lib64/mozilla"
#elif defined(__OpenBSD__) || defined(__FreeBSD__)
                           "/usr/local/lib/mozilla"
#else
                           "/usr/lib/mozilla"
#endif
                           );


I wondered if HAVE_USR_LIB64_DIR was set and stumbled upon this bug report.

https://bugzilla.mozilla.org/show_bug.cgi?id=1428821
(64-bit builds do not always have HAVE_USR_LIB64_DIR set)
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-06-17 06:41:40 UTC
If we can't fix it, no point in pretending we can have it.
Comment 6 Pacho Ramos gentoo-dev 2018-11-11 12:05:39 UTC
maybe other option is to live with it broken in firefox (but still working with chrom*) :/
Comment 7 nE0sIghT 2018-11-11 15:37:29 UTC
Created attachment 554842 [details, diff]
Proposed workaround

Here is proposed workaround for this issue.
Any reviews are welcome.
Comment 8 Ian Stakenvicius gentoo-dev 2018-11-14 15:14:51 UTC
(In reply to nE0sIghT from comment #7)
> Created attachment 554842 [details, diff] [details, diff]
> Proposed workaround
> 
> Here is proposed workaround for this issue.
> Any reviews are welcome.

This type of workaround is likely the way to go -- I've looked into the firefox codebase and because of the way that /usr/lib64/mozilla is used for extensions with binary objects I don't feel comfortable with trying to figure out how to make it load from both /usr/lib64 and /usr/lib.

I am a little bit confused on the patch itself though, as it looks like it's doing the opposite of what I thought was needed based on reading this bug -- isn't the issue that the files are presently installed to /usr/lib/mozilla when SYMLINK_LIB=no and so firefox ignores it?  

Also, I'm not sure if calling doins on a file that's already in ${ED} is the best idea, could this file be doins'ed from ${S}, or copied/symlinked directly in ${ED} instead?
Comment 9 nE0sIghT 2018-11-14 15:27:25 UTC
(In reply to Ian Stakenvicius from comment #8)
> (In reply to nE0sIghT from comment #7)
> I am a little bit confused on the patch itself though, as it looks like it's
> doing the opposite of what I thought was needed based on reading this bug --
> isn't the issue that the files are presently installed to /usr/lib/mozilla
> when SYMLINK_LIB=no and so firefox ignores it?  

Currently, binary version of Firefox is built on Debian host which doesn't have lib{32,64} dirs. Binary Firefox expect native messaging manifests in libdir - "/usr/lib" on Debian hosts. For Gentoo amd64 libdir is "/usr/lib64" - and this is the place where manifests are expected.
There are no issues with dynamic libraries (ldconfig etc), but manifests - just text files and we should provide them in expected locations.
We can not fix firefox-bin and as I think there is nothing to fix in www-client/firefox - there is upstream issue (https://bugzilla.mozilla.org/show_bug.cgi?id=1318461 - reported by me 2 years ago).

> Also, I'm not sure if calling doins on a file that's already in ${ED} is the
> best idea, could this file be doins'ed from ${S}, or copied/symlinked
> directly in ${ED} instead?

This file is generated, so we can not use ${S}. I can replace doins with symlink/cp in ${ED}
Comment 10 Ian Stakenvicius gentoo-dev 2018-11-14 16:37:50 UTC
(In reply to nE0sIghT from comment #9)
> (In reply to Ian Stakenvicius from comment #8)
> > (In reply to nE0sIghT from comment #7)
> > I am a little bit confused on the patch itself though, as it looks like it's
> > doing the opposite of what I thought was needed based on reading this bug --
> > isn't the issue that the files are presently installed to /usr/lib/mozilla
> > when SYMLINK_LIB=no and so firefox ignores it?  
> 
> Currently, binary version of Firefox is built on Debian host which doesn't
> have lib{32,64} dirs. Binary Firefox expect native messaging manifests in
> libdir - "/usr/lib" on Debian hosts. For Gentoo amd64 libdir is "/usr/lib64"
> - and this is the place where manifests are expected.
> There are no issues with dynamic libraries (ldconfig etc), but manifests -
> just text files and we should provide them in expected locations.

*OH*.  *facepalm*

...  so in actual fact then, anything installed in either /usr/lib64/nsbrowser/plugins or /usr/lib64/mozilla will not be found or loaded by firefox-bin with SYMLINK_LIB=no ... That means libflashplayer.so from www-plugins/adobe-flash can't be loaded by firefox-bin anymore either.

This is a firefox-bin issue more than it is a chrome-gnome-shell issue.

Unfortunately there isn't a feasible way I can think of to address this in the mozilla *-bin ebuilds.  Polluting /usr/lib/ with symlinks to /usr/lib64/{mozilla,nsbrowser} is the only thing I can think of and I'm pretty sure that would be a bad idea.
Comment 11 nE0sIghT 2018-11-14 17:24:59 UTC
(In reply to Ian Stakenvicius from comment #10)
> ...  so in actual fact then, anything installed in either
> /usr/lib64/nsbrowser/plugins or /usr/lib64/mozilla will not be found or
> loaded by firefox-bin with SYMLINK_LIB=no ... That means libflashplayer.so
> from www-plugins/adobe-flash can't be loaded by firefox-bin anymore either.

This should be tested, but things looks like so.
Actually, Adobe Flash should be last NPAPI plugin supported by current FF. And similar workaround can be placed to www-plugins/adobe-flash
Comment 12 Seheon Ryu 2018-11-15 16:34:20 UTC
(In reply to nE0sIghT from comment #11)
> (In reply to Ian Stakenvicius from comment #10)
> > ...  so in actual fact then, anything installed in either
> > /usr/lib64/nsbrowser/plugins or /usr/lib64/mozilla will not be found or
> > loaded by firefox-bin with SYMLINK_LIB=no ... That means libflashplayer.so
> > from www-plugins/adobe-flash can't be loaded by firefox-bin anymore either.
> 
> This should be tested, but things looks like so.
> Actually, Adobe Flash should be last NPAPI plugin supported by current FF.
> And similar workaround can be placed to www-plugins/adobe-flash

adobe-flash works fine.

firefox-bin-63.0.1-r1
about:plugins

Shockwave Flash

    File: libflashplayer.so
    Path: /usr/lib64/nsbrowser/plugins/libflashplayer.so
    Version: 31.0.0.122
    State: Enabled
    Shockwave Flash 31.0 r0
Comment 13 Ian Stakenvicius gentoo-dev 2018-11-15 16:39:08 UTC
(In reply to Seheon Ryu from comment #12)
> (In reply to nE0sIghT from comment #11)
> > (In reply to Ian Stakenvicius from comment #10)
> > > ...  so in actual fact then, anything installed in either
> > > /usr/lib64/nsbrowser/plugins or /usr/lib64/mozilla will not be found or
> > > loaded by firefox-bin with SYMLINK_LIB=no ... That means libflashplayer.so
> > > from www-plugins/adobe-flash can't be loaded by firefox-bin anymore either.
> > 
> > This should be tested, but things looks like so.
> > Actually, Adobe Flash should be last NPAPI plugin supported by current FF.
> > And similar workaround can be placed to www-plugins/adobe-flash
> 
> adobe-flash works fine.
> 
> firefox-bin-63.0.1-r1
> about:plugins
> 
> Shockwave Flash
> 
>     File: libflashplayer.so
>     Path: /usr/lib64/nsbrowser/plugins/libflashplayer.so
>     Version: 31.0.0.122
>     State: Enabled
>     Shockwave Flash 31.0 r0


Well that doesn't make any sense.  HAS_USR_LIB64_DIR does two things and only two things, sets the nsplugin dir to /usr/lib64/nsbrowser and sets the extensions dir to /usr/lib64/mozilla , if HAS_USR_LIB64_DIR is off for extensions then it must be off for nsplugins too.  This confirmation was on a SYMLINK_LIB=no system?
Comment 14 Seheon Ryu 2018-11-15 16:48:14 UTC
(In reply to Ian Stakenvicius from comment #13)
> (In reply to Seheon Ryu from comment #12)
> > (In reply to nE0sIghT from comment #11)
> > > (In reply to Ian Stakenvicius from comment #10)
> > > > ...  so in actual fact then, anything installed in either
> > > > /usr/lib64/nsbrowser/plugins or /usr/lib64/mozilla will not be found or
> > > > loaded by firefox-bin with SYMLINK_LIB=no ... That means libflashplayer.so
> > > > from www-plugins/adobe-flash can't be loaded by firefox-bin anymore either.
> > > 
> > > This should be tested, but things looks like so.
> > > Actually, Adobe Flash should be last NPAPI plugin supported by current FF.
> > > And similar workaround can be placed to www-plugins/adobe-flash
> > 
> > adobe-flash works fine.
> > 
> > firefox-bin-63.0.1-r1
> > about:plugins
> > 
> > Shockwave Flash
> > 
> >     File: libflashplayer.so
> >     Path: /usr/lib64/nsbrowser/plugins/libflashplayer.so
> >     Version: 31.0.0.122
> >     State: Enabled
> >     Shockwave Flash 31.0 r0
> 
> 
> Well that doesn't make any sense.  HAS_USR_LIB64_DIR does two things and
> only two things, sets the nsplugin dir to /usr/lib64/nsbrowser and sets the
> extensions dir to /usr/lib64/mozilla , if HAS_USR_LIB64_DIR is off for
> extensions then it must be off for nsplugins too.  This confirmation was on
> a SYMLINK_LIB=no system?

Yes.

sh@SH-VM / $ cd /usr/lib/nsbrowser
cd: no such file or directory: /usr/lib/nsbrowser
sh@SH-VM / $ cd /usr/lib64/nsbrowser
sh@SH-VM /usr/lib64/nsbrowser $ 

I temporarily removed /usr/lib/mozilla symlink and
GNOME Shell integration extension does not detect native host connector.
Comment 15 Ian Stakenvicius gentoo-dev 2018-11-15 17:26:50 UTC
ok, well, even though the issue does very much seem to be a firefox one, if any and all providers of native-messaging-hosts can install their files to both of /usr/lib{,64}/mozilla/native-messaging-hosts/ (assuming the path isn't identical due to SYMLINK_LIB=yes), it would be appreciated.
Comment 16 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-03-22 07:14:09 UTC
Ping.
Comment 17 nE0sIghT 2019-03-22 07:25:42 UTC
I'm unsure which actions do we wait for.

Michał, what do you think about linked PR? Since this is proxy maintained package some proxy-maint dev action needed.
Or I can try to improve PR if any changes needed.
Comment 18 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-03-22 07:34:33 UTC
@Ian, does it look correct to you?
Comment 19 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-04-19 12:44:58 UTC
Ok, given no reply I'm finally going to merge it.  I'm sorry that it took this long.
Comment 20 Larry the Git Cow gentoo-dev 2019-04-19 12:52:21 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3d78ce7f7d4173f0cd57b958a5702ac5a63e44ec

commit 3d78ce7f7d4173f0cd57b958a5702ac5a63e44ec
Author:     Yuri Konotopov <ykonotopov@gnome.org>
AuthorDate: 2018-11-12 16:35:54 +0000
Commit:     Michał Górny <mgorny@gentoo.org>
CommitDate: 2019-04-19 12:52:17 +0000

    gnome-extra/chrome-gnome-shell: properly support firefox-bin.
    
    www-client/firefox-bin is built on Debian host which doesn't have
    /usr/lib{32,64}, so it expects native host manifest in /usr/lib.
    With this change native host manifest will be additionally installed in
    /usr/lib when needed.
    
    Closes: https://bugs.gentoo.org/643522
    Signed-off-by: Yuri Konotopov <ykonotopov@gnome.org>
    Closes: https://github.com/gentoo/gentoo/pull/10401
    Signed-off-by: Michał Górny <mgorny@gentoo.org>

 .../chrome-gnome-shell-10-r1.ebuild                | 51 ++++++++++++++++++++++
 1 file changed, 51 insertions(+)