Disclaimer: I will be copying a large part of what follows almost word-by-word from https://bugzilla.redhat.com/show_bug.cgi?id=2250527, as this is basically the same bug. The path where Firefox searches for media plugins is specified by the MOZ_GMP_PATH environment variable. For arm64 systems, widevine-installer sets this environment variable by making use of a profile file, /etc/profile.d/gmpwidevine.sh. GDM is known not to source those files directly when logging into gnome-wayland sessions (see references below). Instead, as I understand it, gnome-session passes them to the user's default shell, which is then responsible for re-exporting them. As a result, when the DE uses the user's default shell to source /etc/profile.d/*, and if the user's default shell does not understand the `export` command (or variable assignment in the form VAR=VALUE), the MOZ_GMP_PATH environment variable is never set, and the Widevine plugin is never loaded as it is not found on the system. For example, Spotify does not work on arm64 Fedora Workstation's Firefox if the user has fish as its default shell. This can be checked as detailed in the "Steps to Reproduce". That the path is not being set correctly in this situation can be checked by stracing the Firefox session that runs Spotify with strace -f firefox 2>&1 | grep widevine and comparing the output with one obtained when bash is the default shell. In the former case, Firefox is clearly not looking for libwidevinecmd.so in /var/lib/widevine/gmp-widevinecdm/system-installed, and Spotify doesn't work. In the latter it clearly is and Spotify works, as it should happen when MOZ_GMP_PATH is set correctly. To solve this bug in GNOME/GDM/Wayland, one could remove the /etc/profile.d/gmpwidevine.sh file from the package and add a new /etc/environment.d/gmpwidevine.conf file instead with the following content: MOZ_GMP_PATH="$MOZ_GMP_PATH${MOZ_GMP_PATH:+:}/var/lib/widevine/gmp-widevinecdm/system-installed" This way, MOZ_GMP_PATH will be caught by systemd during the init phase and then re-exported to GDM and to gnome-wayland sessions, without being filtered by the user's default shell. I can confirm that this fixes the issue on GNOME/GDM/Wayland, but I didn't test what happens with other DMs/DEs/X11, etc. *** Note *** - /etc/environment{,.d/*} are sourced by systemd, so any changes to those files require either a full reboot or killing the systemd user session to enter into effect. A re-login is not sufficient. *** GNOME/GDM/Wayland /etc/profile behavior references *** - https://bugzilla.gnome.org/show_bug.cgi?id=736660 (GNOME/GDM/Wayland do not source profile files directly. This was solved by wrapping gnome-wayland sessions within the user's default shell, see below) - https://github.com/swaywm/sway/issues/3109 (as above, but in sway) - https://gitlab.gnome.org/GNOME/gnome-session/-/commit/5e36cd63e71520f829bbd77c102b64179e08992a (the fix introduced to work around GNOME/GDM/Wayland not sourcing profile files directly: wrap GNOME Wayland sessions around the user's default shell) Reproducible: Always Steps to Reproduce: 1. sudo dnf install widevine-installer fish 2. sudo widevine-installer 3. chsh -s /usr/bin/fish 4. Reboot/re-login 5. Try to listen to music on Spotify Actual Results: Spotify doesn't work. Expected Results: Spotify should work. Other services that require Widevine, such as Amazon Prime, don't work either.
As an afterthought, I think the reason why the plugin is not working when the user's default shell is the fish shell is not just because fish does not understand VAR=VALUE assignments and the `export` command, but even more basically because it just isn't reading /etc/profile{,.d/*} when it is invoked as a login shell. To see this, run strace -e trace=openat fish -l 2>&1 | grep etc and compare the output to that of strace -e trace=openat bash -l 2>&1 | grep etc or strace -e trace=openat zsh -l 2>&1 | grep etc fish's analogue of /etc/profile{,.d/*} is /etc/fish/conf{ig.fish,.d/*}. Thus, this bug can arise either when the user's default shell doesn't understand `export` and VAR=VALUE, or when it just doesn't read /etc/profile{,.d/*} when invoked as a login shell, implying that any solution based on just changing the content of /etc/profile.d/gmpwidevine.sh won't fix the issue.
After some discussion upstream I agree that environment.d is preferable here.
Put up https://src.fedoraproject.org/rpms/widevine-installer/pull-request/1 for this
I've tested the PR and it works for me. I will close this bug report when it gets merged. I've left a comment with a suggestion there. Thank you for the fix!
FEDORA-2023-471cd39ea3 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-471cd39ea3
FEDORA-2023-471cd39ea3 has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-562915c3d5 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-562915c3d5
FEDORA-2023-c5c91fef19 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c5c91fef19
FEDORA-2023-c5c91fef19 has been pushed to the Fedora 38 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-c5c91fef19` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-c5c91fef19 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-562915c3d5 has been pushed to the Fedora 39 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-562915c3d5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-562915c3d5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-562915c3d5 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-c5c91fef19 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
This broke Widevine for everyone *not* using fish, because openh264 is still not fixed and their script *clobbers* the path instead of appending to it. Our original solution relied on alphabetically running *after* openh264 to work. Now we run before and get clobbered. Reverting. We can revisit this after openh264 switches over to environment.d *and* to appending to the variable first.
FEDORA-2023-d957f751a6 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d957f751a6
FEDORA-2023-3d6752f5ba has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-3d6752f5ba
FEDORA-2023-ea1faa4a96 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ea1faa4a96
FEDORA-2023-d957f751a6 has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
I think the revert commit description is triggering the closes, sorry :/
> This broke Widevine for everyone *not* using fish, because openh264 is still not fixed and their script *clobbers* the path instead of appending to it. For the record, fish has nothing to do with this. mozilla-openh264 is breaking stuff by not releasing an already-merged, fish-unrelated, one-month old fix (https://src.fedoraproject.org/rpms/openh264/c/01e104cfc7e5c92e529c7c703a37b06b37d755ec?branch=rawhide) to a non-working patch that was merged 4 months ago (https://src.fedoraproject.org/rpms/openh264/c/10b5521dd013e27d25cdc30162d44b1882f8bae2?branch=rawhide). @kalev
FEDORA-2023-3d6752f5ba has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-ea1faa4a96 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
A new version of openh264 which does not overwrite `MOZ_GMP_PATH` has now been released. > We can revisit this after openh264 switches over to environment.d *and* to appending to the variable first. @marcan: they are still not using environment.d, but given the content of their profile.d file, > if [[ ":$MOZ_GMP_PATH:" != *":/usr/lib64/mozilla/plugins/gmp-gmpopenh264/system-installed:"* ]]; then > MOZ_GMP_PATH="${MOZ_GMP_PATH}${MOZ_GMP_PATH:+:}/usr/lib64/mozilla/plugins/gmp-gmpopenh264/system-installed" > export MOZ_GMP_PATH > fi now it could be safe to switch to environment.d anyway.
FEDORA-2024-f1e0e4da25 (widevine-installer-0^20240811git1923815-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-f1e0e4da25
FEDORA-2024-33fdd1f8b6 (widevine-installer-0^20240811git1923815-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-33fdd1f8b6
FEDORA-2024-735ac1b724 (widevine-installer-0^20240811git1923815-1.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-735ac1b724
FEDORA-2024-f1e0e4da25 (widevine-installer-0^20240811git1923815-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
Nope, that broke on KDE, this time due to https://bugs.kde.org/show_bug.cgi?id=491579 (just filed).
The short-term workaround here (and probably safer option) would be to ship *both* environment.d and profile.d files. Other than that, we have to wait until the KDE side figures out how to fix this corner case.
FEDORA-2024-ef1eae18e8 (widevine-installer-0^20240812giteab8c66-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-ef1eae18e8
FEDORA-2024-2e0ed64767 (widevine-installer-0^20240812giteab8c66-1.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-2e0ed64767
FEDORA-2024-ef1eae18e8 (widevine-installer-0^20240812giteab8c66-1.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-2e0ed64767 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-2e0ed64767` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-2e0ed64767 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-2e0ed64767 (widevine-installer-0^20240812giteab8c66-1.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days