| Summary: | www-client/firefox-33.0 downloads and installs executable libgmpopenh264.so from the Internet | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Petr Pisar <petr.pisar> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | alexander, atrigent, luke, mail |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Petr Pisar
2014-10-18 21:22:05 UTC
Yes, yes it does. This is a module-update procedure that firefox (and presumably other mozilla packages) now does. Not only is it doing this but on occasion this process will also cause firefox to segfault the first time it is run after upgrading from a previous version. The tricky bit, here, is that I believe these modules are part of the profile, rather than part of the system. As such, at this time I don't think there is a way around them. However I will continue t olook into it and check with upstream to see if there's a way to avoid this binary-modules-update process. OK. So, first of all, setting "media.gmp-gmpopenh264.autoupdate" to "false" will disable auto-updates. This is also doable in a user-friendly way in the Addon Manager. Secondly, this "binary blob" is coming from Cisco, and due to license issues it has to happen this way. It's also integral to WebRTC support, apparently. That said, the sources are fully open and available at https://github.com/cisco/openh264 and apparently the build system used for this is unchanged from what's listed in that repo. I'm looking into how best to provide alternatives to updates of this binary blob; at this point i think that a flag which disables the auto-update and possibly also the main plugin itself (given it doesn't exist on a new/empty profile), and allowing a separate package to build and install the plugin into system paths, might be the best route forward, but i need to do more tests and research. My proposed solution is in mozilla-overlay now: - New package media-plugins/gmp-openh264 builds and installs a system copy of libgmpopenh264.so , and an /etc/env.d file to add its location to a MOZ_GMP_PATH environment variable - IUSE="system-gmps" in www-client/firefox (and others, eventually) which modifies depends on this (and others, eventually) plugin, and modifies the default prefs.js so that auto-updates are disabled, this ensuring the binary files are not fetched from upstream. Let me know if this solution works for you. FYI, if a ~/.mozilla profile already contains the gmp plugin(s), it looks like those plugins are still used first, so you'll need to delete those plugins by hand to force the system one. You'll also need to restart your login session in order to ensure the MOZ_GMP_PATH var is set in your environment. Thanks. The media-plugins/gmp-openh264 requires dev-lang/nasm on x86_64 (and maybe other architectures): nasm -DUNIX64 -f elf64 -I./codec/common/x86/ -o codec/encoder/core/x86/coeff.o codec/encoder/core/x86/coeff.asm make: nasm: Command not found codec/encoder/targets.mk:85: recipe for target 'codec/encoder/core/x86/coeff.o' failed make: *** [codec/encoder/core/x86/coeff.o] Error 127 I built the plug-in and 33.0 firefox from the overlay successfully. If I use fresh new profile, it will still download the plug-in. It reports that updating is disabled but installs it anyway. The about:plugins lists the the plug-in without details (version, file path), but after firefox downloads it (it happens later than one minute as documented), the details and the file appears. The MOZ_GMP_PATH is set correctly to directory containing two files (info and library). (In reply to Petr Pisar from comment #5) > I built the plug-in and 33.0 firefox from the overlay successfully. If I use > fresh new profile, it will still download the plug-in. It reports that > updating is disabled but installs it anyway. The about:plugins lists the the > plug-in without details (version, file path), but after firefox downloads it > (it happens later than one minute as documented), the details and the file > appears. The MOZ_GMP_PATH is set correctly to directory containing two files > (info and library). When you built firefox-33 from the overlay, USE="system-gmps" was set? Please browse to "about:config" and search 'gmp' , and let me know if media.gmp-gmpopenh264.autoupdate has a value (it should be 'false' and not user-set) You can set that to 'false' yourself as well, and just 'rm -Rf ~/.mozilla/firefox/*/gmp-gmpopenh264' instead of nuking your whole profile. Thanks for reporting about the missing dep on nasm, fixed in overlay now. Of course the system-gmps is set: # qlist -IUvR firefox www-client/firefox-33.0::mozilla (custom-cflags gstreamer jit linguas_cs minimal system-cairo system-gmps system-icu system-jpeg system-libvpx system-sqlite) The media.gmp-gmpopenh264.autoupdate has a default value and it is false. (In reply to Petr Pisar from comment #7) > Of course the system-gmps is set: > > # qlist -IUvR firefox > www-client/firefox-33.0::mozilla (custom-cflags gstreamer jit linguas_cs > minimal system-cairo system-gmps system-icu system-jpeg system-libvpx > system-sqlite) > > The media.gmp-gmpopenh264.autoupdate has a default value and it is false. Thanks for confirming. Unfortunately, I can't reproduce that here -- if media.gmp-gmpopenh264.autoupdate is false, then the update manager does not download the plugin on my system. Indeed, watching the console, I see: > 1414503227158 GMPInstallManager.simpleCheckAndInstall INFO Auto-update is off for openh264, aborting check. This pref setting is the key component for keeping the binary blob away; the external plugin package is just to provide the openh264 support for webrtc that would otherwise be missing. I made some adjustments to how things were being managed, in mozilla-overlay today, it might work better now. Seamonkey also honours the 'system-gmps' flag now if you care to test. I did a test and unfortunately it still downloads and installs the binary library. The only difference I spotted is that it reports "system-installed" version of the plug-in until it downloads the copy from Cisco. (In reply to Petr Pisar from comment #10) > I did a test and unfortunately it still downloads and installs the binary > library. The only difference I spotted is that it reports "system-installed" > version of the plug-in until it downloads the copy from Cisco. and if you check about:config , media.gmp-gmpopenh264.autoupdate is still set to false ? Yes, it's false. I can confirm that current FF 47.0.1 with "media.gmp-gmpopenh264.autoupdate" set to false will download Cisco binary blobs at least if you click on "Check for updates" in Extensions (this happens in Plugins too, but that's more understandable since this blob is also listed as plugin). Setting "media.gmp-provider.enabled" to false makes it behave nicer. Video / audio playback still works via libmozavcodec (on https://www.youtube.com/html5 all checkboxes are ticked). (In reply to Maciej S. Szmigiero from comment #13) > I can confirm that current FF 47.0.1 with "media.gmp-gmpopenh264.autoupdate" > set to false will download Cisco binary blobs at least if you click on > "Check for updates" in Extensions (this happens in Plugins too, but that's > more understandable since this blob is also listed as plugin). > > Setting "media.gmp-provider.enabled" to false makes it behave nicer. > Video / audio playback still works via libmozavcodec (on > https://www.youtube.com/html5 all checkboxes are ticked). The Cisco binary blob is *only* for "webrtc" , which is native support for one-way or two-way video conferencing. It doesn't have anything to do with HTML5 media elements. Also, the "gmp-autoupdate" option is not supposed to block any and all possible updates of this addon, but rather to just prevent it from being automatically downloaded and updated in the background without any user intervention or control whatsoever (because it will, automatically, as soon as you start up a new install or upgrade of firefox). Otherwise the control is entirely yours. If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team |
