Since commit 97999f62[1], /usr/bin/firefox script sets MOZ_GMP_PATH without regard to existing MOZ_GMP_PATH value. I maintain a local package of widevine CDM[2] that can be installed for all users to avoid duplication of the library in each user's home directory and profile. However, since the above commit, it's not possible to add anything to MOZ_GMP_PATH without modifying /usr/bin/firefox script. The system-installed widevine is not used and a local copy is downloaded instead for each user and new profile. [1] https://src.fedoraproject.org/rpms/firefox/c/97999f62afe478c3d75261b19e19bba82bec6c0d?branch=rawhide [2] https://gitlab.com/greysector/rpms/widevine-cdm/ Reproducible: Always Steps to Reproduce: 1. Build and install widevine-cdm from above repo 2. Re-login and open Firefox 3. Check about:plugins Actual Results: Path: /home/rathann/.mozilla/firefox/b7lcd5wg.default-release/gmp-widevinecdm/4.10.2557.0 Version: 4.10.2557.0 Expected Results: Path: /home/rathann/.mozilla/firefox/b7lcd5wg.default-release/gmp-widevinecdm/system-installed Version: system-installed Example test site: https://bitmovin.com/demos/drm The relevant line in /usr/bin/firefox should read: export MOZ_GMP_PATH="${MOZ_GMP_PATH}${MOZ_GMP_PATH:+:}/usr/lib64/mozilla/plugins/gmp-gmpopenh264/system-installed" instead of: export MOZ_GMP_PATH=$MOZ_LIB_DIR/mozilla/plugins/gmp-gmpopenh264/system-installed
We're set MOZ_GMP_PATH only if it's missing in firefox-115.0.2-2.
With this update firefox won't start, in the console it says: /usr/bin/firefox: line 136: syntax error near unexpected token `fi' /usr/bin/firefox: line 136: `fi' which makes no sense, as there are other if...fi structures in /usr/bin/firefox
(In reply to Brian Morrison from comment #2) > With this update firefox won't start, in the console it says: > > /usr/bin/firefox: line 136: syntax error near unexpected token `fi' > /usr/bin/firefox: line 136: `fi' > > which makes no sense, as there are other if...fi structures in > /usr/bin/firefox You're absolutely right, it's a bug in the script.
Fix added to -3 build.
FEDORA-2023-e324369796 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-e324369796
The -3 build has fixed the bug for me.
FEDORA-2023-e324369796 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-e324369796` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-e324369796 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Martin Stransky from comment #4) > Fix added to -3 build. While it doesn't overwrite MOZ_GMP_PATH anymore, it doesn't add $MOZ_LIB_DIR/mozilla/plugins/gmp-gmpopenh264/system-installed to it if it's set to something already. So, if I set it in /etc/profile.d/foo.sh, the system-installed openh264 plugin won't get used unless I add the above path to what I'm setting manually.
Okay, I didn't expect MOZ_GMP_PATH can contain multiple entries but it apparently can: https://searchfox.org/mozilla-central/rev/385f408040a8bb5fd9d168fb16a4e9071a13938d/dom/media/gmp/GMPServiceParent.cpp#489 so I'll update it then.
I tend to remove MOZ_GMP_PATH settings from Firefox launch script entirely. MOZ_GMP_PATH is set by /etc/profile.d/gmpopenh264.sh to /usr/lib64/mozilla/plugins/gmp-gmpopenh264/system-installed and that's fine. Firefox doesn't need to update that path.
Added to -4 package.
Thank you!
The F38 -4 package build has stalled for x86_64. Could someone please give it a poke?
FEDORA-2023-e324369796 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Brian Morrison from comment #13) > The F38 -4 package build has stalled for x86_64. Could someone please give > it a poke? Looks like the F38 (x86_64 only!) failed with a weird error: error: Installed (but unpackaged) file(s) found: /usr/lib64/firefox/libxul.so.gdb-index-4rSjdO probably because an OOM kill earlier: debugedit: Warning, not replacing comp_dir '/builddir/build/BUILD/firefox-115.0.2/third_party/dav1d/src/x86/' prefix ('/builddir/build/BUILD/firefox-115.0.2' -> '/usr/src/debug/firefox-115.0.2-4.fc38.x86_64') encoded as DW_FORM_string. Replacement too large. /usr/bin/gdb.minimal /usr/bin/gdb-add-index: line 159: 70802 Killed $GDB --batch -nx -iex 'set auto-load no' -iex 'set debuginfod enabled off' -ex "file $file" -ex "save gdb-index $dwarf5 $dir" and F39 builds of -4 failed with: + cp -p /usr/share/bookmarks/default-bookmarks.html objdir/dist/bin/browser/chrome/browser/content/browser/default-bookmarks.html cp: cannot create regular file 'objdir/dist/bin/browser/chrome/browser/content/browser/default-bookmarks.html': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.WH5DNq (%install) F37 succeeeded.
Firefox 116.0 is released next week so we're going to ship it there.
Seems fair, let's hope that builds ;-)
FEDORA-2023-a1a0c3f6af has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a1a0c3f6af
FEDORA-2023-a1a0c3f6af has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
I would just like to point out that the change implemented here changes for me the steps necessary to enable H.264 in WebRTC on a fresh Fedora install. In the past (e.g. Fedora 38), all that was necessary was `sudo dnf install mozilla-openh264` and (re)starting Firefox. Now one also has to log out and log back in before starting Firefox. Or alternatively: `. /etc/profile.d/gmpopenh264.sh && firefox`. Here is an example of a funny situation. If you start with Fedora 38 and install `mozilla-openh264`, you have working H.264. If you then update your Firefox (`sudo dnf upgrade firefox`), H.264 stops working. If you log out and log back in, H.264 is working again. This took me a while to troubleshoot.