| Summary: | gnome-extra/chrome-gnome-shell is not compatible with a SYMLINK_LIB=no system | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Seheon Ryu <sh41790> |
| Component: | Current packages | Assignee: | nE0sIghT <ykonotopov> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexander, gnome, mgorny, mozilla, pacho, proxy-maint, treecleaner |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| URL: | https://bugzilla.mozilla.org/show_bug.cgi?id=1318461 | ||
| See Also: | https://github.com/gentoo/gentoo/pull/10401 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 506276 | ||
| Attachments: |
Added -DCMAKE_INSTALL_LIBDIR=lib
Proposed workaround |
||
|
Description
Seheon Ryu
2018-01-05 10:25:26 UTC
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(+) |
