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
Could you please test www-client/firefox with your patch? I believe it may be breaked.
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.
Sounds like firefox install on Gentoo is broken by diverging from upstream.
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)
If we can't fix it, no point in pretending we can have it.
maybe other option is to live with it broken in firefox (but still working with chrom*) :/
Created attachment 554842 [details, diff] Proposed workaround Here is proposed workaround for this issue. Any reviews are welcome.
(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?
(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}
(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.
(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
(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
(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?
(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.
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.
Ping.
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.
@Ian, does it look correct to you?
Ok, given no reply I'm finally going to merge it. I'm sorry that it took this long.
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(+)