Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1648024
Summary: | mozilla-openh264 not recognized | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Harald Reindl <h.reindl> |
Component: | firefox | Assignee: | Martin Stransky <stransky> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | 0xalen+redhat, anto.trande, dimitris, dominik, dridi.boukelmoune, fweimer, gecko-bugs-nobody, h.reindl, jhorak, john.j5live, jpokorny, kengert, mhroncok, pjasicek, rhughes, rstrode, sandmann, stransky |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | firefox-81.0-7.fc32 firefox-81.0.1-3.fc31 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-09-25 12:36:24 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Harald Reindl
2018-11-08 19:17:19 UTC
I've hit this too, and all this seems rather strange to me: - gmp-gmpopenh264/1.7.1/gmpopenh264.info (mtime 2017-10-29) says: > Version: 1.7.1 - I am not aware of ever allowing nor hand-picking respective libgmpopenh264.so in - I have mozilla-openh264-1.8.0-2.fc30.x86_64 installed, yet it doesn't appear to be honored as pointed by OP - gmpopenh264.info in Fedora's built-from-source packages never stated "Version: 1.7.1": https://codecs.fedoraproject.org/openh264/28/x86_64/m/mozilla-openh264-1.8.0-1.fc28.x86_64.rpm -> Version: 1.8.0 https://codecs.fedoraproject.org/openh264/29/x86_64/m/mozilla-openh264-1.7.0-6.fc29.x86_64.rpm -> Version: 1.6.0 and there was no other build in between 1.7.0-6 and 1.8.0-1 per https://koji.fedoraproject.org/koji/packageinfo?packageID=21431 Now, colour me betrayed that Fedora did not protect my privacy and let Firefox download some "random binary code" (exaggeration intended) behind my back, which downright verges on whether having something like that (which moreover proceeds without asking) in Fedora is acceptable: > Software which downloads code bundles from the internet in order to be > functional or useful is not acceptable for inclusion in Fedora https://fedoraproject.org/wiki/Packaging:What_Can_Be_Packaged#Packages_which_are_not_useful_without_external_code :-/ FWIW.
# dnf history show mozilla-openh264
> No transaction which manipulates package 'show' was found.
> ID | Command line | Date and time | Action(s) | Altered
> -------------------------------------------------------------------------------
> 1056 | update --enablerepo fedo | 2018-11-09 09:20 | Upgrade | 3 <
> 102 | install /var/cache/dnf/f | 2017-01-11 18:11 | Install | 2 >
Harald, can you post sha256sum of libgmpopenh264.so from that user profile if you still have it handy, please? I don't quite understand why do you file that fesco ticket and what do you expect from it? Firefox team does not decline this bugreport and we didn't refuse to work on it. Perhaps the prefs from https://bugzilla.redhat.com/show_bug.cgi?id=1155499#c22 are not sufficient now and need to be fixed. Jan, I'm a bit confused how to proceed now...do you want to leave this bug open/unfixed until it's discussed at next FESCO meeting or so? I don't want to predate your plans here. [harry@srv-rhsoft:~]$ locate libgmpopenh264.so /mnt/data/profiles/firefox/harry/gmp-gmpopenh264/1.7.1/libgmpopenh264.so [harry@srv-rhsoft:~]$ sha256sum /mnt/data/profiles/firefox/harry/gmp-gmpopenh264/1.7.1/libgmpopenh264.so 513277b94fd0b36c63e3ed0d29519d68c3aaa7358f191363aad1e408cccfd05d /mnt/data/profiles/firefox/harry/gmp-gmpopenh264/1.7.1/libgmpopenh264.so I'm unable to reproduce. Steps: 1) Create a new Firefox profile ($firefox -ProfileManager) or remove gmp plugins from your recent profile (/home/komat/.mozilla/firefox/7931hc0b.webrtc/gmp in my case). 2) Run Firefox and check about:plugins - it's empty. 3) Install mozilla-openh264 4) Go to about:plugins and see File: system-installed Path: /home/komat/.mozilla/firefox/7931hc0b.webrtc/gmp-gmpopenh264/system-installed Version: system-installed Perhaps if you have already installed the mozilla gmp plugin the system wide is ignored. and how do you remove that crap cleanly from the profile? you can't disable or remove it from Firefox because the options are not available Sorry, I don't know how to remove a crap from your profile. But I used: rm -rf /home/komat/.mozilla/firefox/7931hc0b.webrtc/gmp* to delete the mozilla cisco plugin. Martine, sorry for perhaps unccessary noise, I appreciate your dedication to Firefox over and beyond, but this aspect that I only accidentally noticed got me from a comfort zone, since I really thought I don't have to worry about the web browser beside caring to have it updated. And then, all of a sudden (is there any notion of "internal installation log" in Firefox, I'd really love to avoid rumours and exclude a possibility this was my own fault of some kind), I discover that there's some binary code sitting in my profile, silently overriding the system wide version I have more trust in -- I already trust Fedora with everything else, after all). That ticket was meant as a heads-up that things "declaratively solved" may not be "practically solved". With the awareness of this freedoms' touching problem, perhaps investigation and finding of more reliable solution for something I guess quite some time was already spent (negoations regardin build infra -- hosting cooperation) can perhaps be prioritized. Hopefully this answers your question, feel free cope with the bug and the ticker as you wish as long as the underlying problem won't get totally ignored (cooling this down a bit is fine). Thanks for understanding. re [comment 8]: Thanks, have the same file then (x86_64), so at least a partial relief. re "reproducing" [comment 9]: Note that it could have happened with any version I used in the past, just for reference, my first Firefox installation was: > Thu 05 Jan 2017 > Install firefox-50.1.0-2.fc26.x86_64 @rawhide I can provide a list of all versions I ever had installed. Okay, Thanks for the explanation. Please test if the fedora cisco is enabled when you remove the mozila one - which may be a different bug - see comment 9. Another problem may be that the Fedora provided mozilla-openh264 package is not installed by default and the repo is not present in the installation (IMHO). I have a clean F29 install and the mozilla-openh264 is missing. The plugin download itself looks disabled but when Firefox profile is migrated from old installation it may still contain the gmp* entries and thus the mozilla plugin is used. Maybe the mozilla-openh264 should remove the plugin downloaded from mozilla when it's installed. Thanks for looking into this. I haven't migrated the profile, it was brand new at stated Firefox installation time. Per what I provided, there was apparently a window in which just firefox without mozilla-openh264 was installed (2017-01-05 - 2017-01-11) but I don't think I had the codec installed, with an active consent, natively in that timeframe. That's where said "internal installation log" would definitely help, provided something like that exists. Do you think Firefox would update pre-existing user-installed codec on its own even with said protection in place if it detected, say, that system-wide version is older that the "current"? Why would it do so around last year's autumn up to 1.7.1 and not subsequently to version 1.8.0? Can Firefox install-as-override the codec into user profile by force as an "proactive security feature"? Note that in case there was a security finding in the library in question, one would possibly live with a false notion of being secure when system-wide copy updated while the one in the user profile remained stale. [re comment 13]: Confirming that previously this: > OpenH264 Video Codec provided by Cisco Systems, Inc. > > File: 1.7.1 > Path: <PROFILE-PATH>/gmp-gmpopenh264/1.7.1 > Version: 1.7.1 > State: Enabled > This plugin is automatically installed by Mozilla to comply with [...] now has become this: > OpenH264 Video Codec provided by Cisco Systems, Inc. > > File: system-installed > Path: <PROFILE-PATH>/gmp-gmpopenh264/system-installed > Version: system-installed > State: Enabled > This plugin is automatically installed by Mozilla to comply with [...] (Previously, there was also something like [plus view other fields] > media.gmp-gmpopenh264.version = 1.7.1 in about:support, which now is no longer present.) > Sorry, I don't know how to remove a crap from your profile. But I used:
> rm -rf /home/komat/.mozilla/firefox/7931hc0b.webrtc/gmp*
> to delete the mozilla cisco plugin
there are 3 folders with "gmp"
gmp
gmp-gmpopenh264
gmp-widevinecdm
deleted them, started firefox, about:plugins told both will be installed in a short, "updat eplugins" - voila - that crap is back
version 1.7.1 - and now?
[harry@srv-rhsoft:/mnt/data/profiles/firefox/harry]$ rpm -qa | grep h264
openh264-1.8.0-1.fc28.x86_64
gstreamer1-plugin-openh264-1.14.1-1.fc28.x86_64
I think I've found the "betraying loophole" that kicks in for me that unfortunately stands in my way of browser maintenance workflow (add-ons are not allowed to update automatically, on purpose): 1. go to about:addons, extensions tab 2. click on "Check for Updates" from the gear icon's popup menu at the top right (basic assumptions: this will only ever effect "extensions" [since that's where I am currenty navigated at], not the "plugins" in any way, but even if that was naive, for "extensions" that action behaves sanely, i.e., passively checks the updates and presents the respective options to update to the user) 3. voila, <PROFILE-PATH>/gmp-gmpopenh264/1.7.1 is back - without ever being asked about that beforehand - totally ignoring system-wide mozilla-openh264-1.8.0-2.fc30.x86_64 (not to speak about pushing effectively an older version on me) - totally ignoring media.gmp-gmpopenh264.autoupdate=false [*] Then indeed, I classify this as a misbehaviour interfering with perhaps arduously established delivery scheme of proper packages in Fedora, if if not downright crossing my freedoms. Would also note that this behaviour was actually pointed out back then, but in a far distant context: https://bugs.gentoo.org/525810#c13 [*] found it was introduced 3 years back when that topic was widely discussed: https://src.fedoraproject.org/rpms/firefox/c/f12a1190513226091a93bb42066b9c6773438ce5 I see. IIUC the bug should be "Check for Updates overrides mozilla-openh264 from Fedora", correct? (In reply to Harald Reindl from comment #16) > > Sorry, I don't know how to remove a crap from your profile. But I used: > > rm -rf /home/komat/.mozilla/firefox/7931hc0b.webrtc/gmp* > > to delete the mozilla cisco plugin > > there are 3 folders with "gmp" > gmp > gmp-gmpopenh264 > gmp-widevinecdm > > deleted them, started firefox, about:plugins told both will be installed in > a short, "updat eplugins" - voila - that crap is back > > version 1.7.1 - and now? Can you please try: 1) a clean firefox profile 2) install Fedora mozilla-openh264 package to check if the mozilla-openh264 is replaced by the upstream plugin 3) check if the plugin is installed when Fedora mozilla-openh264 is missing? re [comment 18]: > I see. IIUC the bug should be "Check for Updates overrides > mozilla-openh264 from Fedora", correct? The needinfo flag is set on Harald, but I concur. However, there's also an "plugin update can effectively downgrade it when shadowing the system-wide plugin deployment" aspect. Can this be under the same umbrella or does it ask for a separate tracking ... or is it and intentional design (if so, again, end user should be the active arbiter to decide, IMHO)? Okay, let's me summarize what we have there: 1) If Fedora mozilla-openh264 package is missing Firefox downloads the mozilla one. 2) According to comment 17 the Fedora mozilla-openh264 package is replaced by mozilla one when manual plugin check is performed. 3) If mozilla plugin is installed the Fedora one may not be picked up - needs manual removal from user profile. I'm not sure how to address all those issues. IMHO the easiest way is to disable all updates from mozilla site and always have Fedora mozilla-openh264 installed. Is that possible? We can make firefox require mozilla-openh264 package from Fedora but AFAIK it's not at Fedora core repository. A separate fixes for case 2) and 3) only on Fedora side are not realistic - we'll need a GUI for that and we'll need to backport/maintain it along the upstream Firefox. > IMHO the easiest way is to disable all updates from mozilla site and > always have Fedora mozilla-openh264 installed. Is that possible? Is this meant to satisfy: - neither 1) nor 2) can happen - OpenH264 is available for user's needs regardless of the previous point ? That sounds good, but I am afraid, "disable all updates from mozilla site" means that management of extensions (as opposed to plugins) will not be possible or become pretty cumbersome ... and I admit it would likely be far greater show stopper for Fedora audience. Ditto for some other codecs alone, perhaps. > We can make firefox require mozilla-openh264 package from Fedora but > AFAIK it's not at Fedora core repository. This alone, without tackling 2) (IIUIC) or better yet, 3) will not bring anything, right? What I mean, perhaps the current state is the best of bad on the second look, but is not something along 2) or 3) (or both) negotiable with upstream? Also would state a possible consensus solution for 2) that, with good enough packaging discipline, could always achieve that users will be served with Fedora round-tripped OpenH264: make the _plugin_ version comparison for the purpose of updating actually version aware (not per user-customizable field that's set to "system-wide" currently, but per some built-in versioning), and consequently, do not download anything if the current version (whether in the profile or system-wide) is newer-or-equal to Mozilla-offered one I don't know the internals, though. (In reply to Jan Pokorný [poki] from comment #22) > > IMHO the easiest way is to disable all updates from mozilla site and > > always have Fedora mozilla-openh264 installed. Is that possible? > > Is this meant to satisfy: > - neither 1) nor 2) can happen > - OpenH264 is available for user's needs regardless of the previous > point > ? > > That sounds good, but I am afraid, "disable all updates from mozilla > site" means that management of extensions (as opposed to plugins) will > not be possible or become pretty cumbersome ... and I admit it would > likely be far greater show stopper for Fedora audience. Sorry, I mean "disable all updates of mozilla h264 cisco plugin from mozilla sites", not all extensions. FWIW., possible workaround preventing the codec to be unconditionally installed while still allowing the extensions to be updated natively is to go plugin by plugin, checking for updates at each individually, then going to a new "available updates" subtab (if there are any), then "Install Updates" button. That's pretty cumbersome, though. firefox --no-remote --profile /home/harry/firefox-tmp-profile
* it's disable dby default
* after enable play-on-click
* that plugin will be installed in a short
* automatic update
* version 1.7.1
Fedora package: openh264-1.8.0-1.fc28.x86_64
> I'm unable to reproduce. Steps:
> 1) Create a new Firefox profile
did you do that?
[harry@srv-rhsoft:~]$ rm -rf /home/harry/firefox-tmp-profile
[harry@srv-rhsoft:~]$ mkdir /home/harry/firefox-tmp-profile
[harry@srv-rhsoft:~]$ firefox --no-remote --profile /home/harry/firefox-tmp-profile
frankly the plugin does not work at all from the repos and you are nearly unable to prevent the automatic install because when i switch automtaich updates from "default" to "off", stop firefox and start it again it's still at "default" which is obviously enabled
that crap get nstalled in a virgin install and you can't do anything against it - no idea why you are not capable to reprodcue that [harry@srv-rhsoft:~/firefox-tmp-profile]$ ls -lhaR gmp* gmp: insgesamt 12K drwx------ 2 harry verwaltung 4,0K 2018-12-03 14:05 Linux_x86_64-gcc3 drwx------ 3 harry verwaltung 4,0K 2018-12-03 14:05 . drwxr-x--- 17 harry verwaltung 4,0K 2018-12-03 14:07 .. gmp/Linux_x86_64-gcc3: insgesamt 8,0K drwx------ 2 harry verwaltung 4,0K 2018-12-03 14:05 . drwx------ 3 harry verwaltung 4,0K 2018-12-03 14:05 .. gmp-gmpopenh264: insgesamt 12K drwxr-x--- 3 harry verwaltung 4,0K 2018-12-03 14:07 . drwxr-x--- 17 harry verwaltung 4,0K 2018-12-03 14:07 .. drwxr-x--- 2 harry verwaltung 4,0K 2018-12-03 14:07 1.7.1 gmp-gmpopenh264/1.7.1: insgesamt 1,4M drwxr-x--- 2 harry verwaltung 4,0K 2018-12-03 14:07 . drwxr-x--- 3 harry verwaltung 4,0K 2018-12-03 14:07 .. -rwx------ 1 harry verwaltung 116 2018-12-03 14:07 gmpopenh264.info -rwx------ 1 harry verwaltung 1,4M 2018-12-03 14:07 libgmpopenh264.so Okay, will look at it. This is still happening with firefox-66.0.3-1.fc30.x86_64.
I have no mozilla-openh264 installed.
$ rpm -rf ~/tmp/firefox_profile
$ mkdir ~/tmp/firefox_profile
$ firefox --no-remote --profile ~/tmp/firefox_profile
Got o Add-ons manager, Plugins.
I see "OpenH264 Video Codec provided by Cisco Systems, Inc. (disabled)" - no version is listed when I click on details
I click on "Check for Updates" - and I get "No updates found"
I go back to "Plugins" and back to "OpenH264 Video Codec provided by Cisco Systems, Inc. (disabled)" - suddenly version 1.7.1 is listed, last updated on today
I get:
$ ls -l ~/tmp/firefox_profile/gmp-gmpopenh264/1.7.1
.rwx------@ 116 churchyard 26 Apr 0:14 gmpopenh264.info
.rwx------@ 1.4M churchyard 26 Apr 0:14 libgmpopenh264.so
------
$ sudo dnf install --enablerepo=fedora-cisco-openh264 mozilla-openh264 # gets me mozilla-openh264-1.8.0-3.fc30.x86_64
(repeat the steps above)
Plugins show "OpenH264 Video Codec provided by Cisco Systems, Inc. (disabled)" - "system-installed" is listed as version, updated at January 1, 1970
I click on "Check for Updates" - and I get "No updates found"
I go back to "Plugins" and back to "OpenH264 Video Codec provided by Cisco Systems, Inc. (disabled)" - suddenly version 1.7.1 is listed, last updated on today
And I get:
$ ls -l ~/tmp/firefox_profile/gmp-gmpopenh264/1.7.1
.rwx------@ 116 churchyard 26 Apr 0:20 gmpopenh264.info
.rwx------@ 1.4M churchyard 26 Apr 0:20 libgmpopenh264.so
And (obviously):
$ diff /usr/lib64/mozilla/plugins/gmp-gmpopenh264/system-installed/libgmpopenh264.so.1.8.0 ~/tmp/firefox_profile/gmp-gmpopenh264/1.7.1/libgmpopenh264.so
Binary files /usr/lib64/mozilla/plugins/gmp-gmpopenh264/system-installed/libgmpopenh264.so.1.8.0 and /home/churchyard/tmp/firefox_profile/gmp-gmpopenh264/1.7.1/libgmpopenh264.so differ
$ diff /usr/lib64/mozilla/plugins/gmp-gmpopenh264/system-installed/gmpopenh264.info ~/tmp/firefox_profile/gmp-gmpopenh264/1.7.1/gmpopenh264.info
3c3
< Version: 1.8.0
---
> Version: 1.7.1
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Some behind-user's-back soliciting of OpenH264 plugin was also mentioned in a recent analysis posted on twitter: https://twitter.com/jonathansampson/status/1165858896176660480 It contains whole a lot of unsettling facts, on-topic here is also that mere HTTP is used for download of that plugin. It may also be true for the *unsolicited _downgrade_* as demonstrated (!). This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. I think we may ship a patch where openh264 download is disabled completely. There's no point to download outdated plugin when Fedora has a recent one and also it's shipped by Fedora. firefox-81.0-7 has the openh264 completely disabled. FEDORA-2020-981b61a03a has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-981b61a03a FEDORA-2020-a3e1b9025c has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-a3e1b9025c FEDORA-2020-a3e1b9025c has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-a3e1b9025c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a3e1b9025c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-981b61a03a has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-981b61a03a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-981b61a03a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-a3e1b9025c has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. Firefox still shows it uses the randomly downloaded and outdated crap Version 1.8.1.1 Zuletzt aktualisiert 23. Oktober 2019 mozilla-openh264-2.1.0-1.fc32.x86_64 [root@srv-rhsoft:~]$ rpm -q --changelog firefox | head * Fr Sep 25 2020 Martin Stransky <stransky> - 81.0-7 - Added openh264 fixes * stopped firefox * removed the folders "gmp", "gmp-gmpopenh264", "gmp-widevinecdm" * after start firefox it indeed one showed using "system-installed" * i even disabled automatic updates in Extras -> plugins * "Widevine Content Decryption Module" was marked to get installed * Extras -> Addons -> look for updates Automatische Updates erlauben Standard An Aus Version 1.8.1.1 Zuletzt aktualisiert 26. September 2020 the shitty 1.8.1.1 is instaleld and used again and even if remove the 3 folders had solved teh issue it's unacceptable becaus enobody ut me out there is aware and capable doing so come on are these fools at mozilla really that incompetent? Harald, your language is not acceptable and I'm not going to response to your comments unless you behave politely. reported: 2018-11-08 19:17:19 UTC Martin Stransky 2020-09-25 12:36:24 UTC firefox-81.0-7 has the openh264 completely disabled you don't need to repsond. it would be enough that you verify what you pretend after 2 years and nobody would need to say a word at all Martin, I still see this with 81.0-7.fc32; checking for extension updates overrides and downgrades the system-installed one. $ dnf list installed *264* Installed Packages gstreamer1-plugin-openh264.x86_64 1.16.2-2.fc32 @fedora-cisco-openh264 mozilla-openh264.x86_64 2.1.1-1.fc32 @fedora-cisco-openh264 openh264.x86_64 2.1.1-1.fc32 @fedora-cisco-openh264 firefox-wayland --no-remote --profile /tmp/d/ff-tmp-profile $ find /tmp/d/ff-tmp-profile/ -iname '*gmp*' $ about:plugins: File: system-installed Path: /tmp/d/ff-tmp-profile/gmp-gmpopenh264/system-installed about:addons: check for updates $ find /tmp/d/ff-tmp-profile/ -iname '*gmp*' /tmp/d/ff-tmp-profile/gmp-gmpopenh264 /tmp/d/ff-tmp-profile/gmp-gmpopenh264/1.8.1.1/libgmpopenh264.so /tmp/d/ff-tmp-profile/gmp-gmpopenh264/1.8.1.1/gmpopenh264.info about:plugins: File: 1.8.1.1 Path: /tmp/d/ff-tmp-profile/gmp-gmpopenh264/1.8.1.1 (In reply to Dimitris from comment #45) > Martin, I still see this with 81.0-7.fc32; checking for extension updates > overrides and downgrades the system-installed one. > > $ dnf list installed *264* > Installed Packages > gstreamer1-plugin-openh264.x86_64 > 1.16.2-2.fc32 > @fedora-cisco-openh264 > mozilla-openh264.x86_64 > 2.1.1-1.fc32 > @fedora-cisco-openh264 > openh264.x86_64 > 2.1.1-1.fc32 > @fedora-cisco-openh264 > > firefox-wayland --no-remote --profile /tmp/d/ff-tmp-profile > > $ find /tmp/d/ff-tmp-profile/ -iname '*gmp*' > $ > > about:plugins: > > File: system-installed > Path: /tmp/d/ff-tmp-profile/gmp-gmpopenh264/system-installed > > about:addons: check for updates > > $ find /tmp/d/ff-tmp-profile/ -iname '*gmp*' > /tmp/d/ff-tmp-profile/gmp-gmpopenh264 > /tmp/d/ff-tmp-profile/gmp-gmpopenh264/1.8.1.1/libgmpopenh264.so > /tmp/d/ff-tmp-profile/gmp-gmpopenh264/1.8.1.1/gmpopenh264.info > > about:plugins: > > File: 1.8.1.1 > Path: /tmp/d/ff-tmp-profile/gmp-gmpopenh264/1.8.1.1 Thanks for your report. The update profile is a bit tricky but I manage to reproduce that with clear profile. Filed a followup as Bug 1883006. FEDORA-2020-12012bf6b1 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-12012bf6b1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-12012bf6b1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-1c7c9d0932 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-1c7c9d0932` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1c7c9d0932 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-38b5ecdd73 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-38b5ecdd73` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-38b5ecdd73 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-38b5ecdd73 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report. |