Webrtc is used to provide realtime access to video/media. I certainly don't know if this is an important feature for most users, but it has its downsides as it bloats the binaries for all users and can be seen as a bad idea in terms of maintaining privacy. And for the case of thunderbird, I have not any idea how to make use of it for composing emails? To fix this on a per user choice, and from my understanding of the in tree ebuilds, to pass over arguments for the mozconfig file one has to execute this during src_configure mozconfig_annotate '' --disable-webrtc if you choose to have it per useflag, it would be something as if ! use webrtc && mozconfig_annotate '' --disable-webrtc
Created attachment 471388 [details, diff] patch for firefox-52.1-r1 as an example This introduces the new useflag webrtc, has it enable per default and if disabled passes over mozconfig_annotate '' --disable-webrtc during src_prepare It might be a good idea to store this in the mozconfig eclass.
I tested this for hapieness with the old 45-esr releases before filling this bug, but I just recently noticed that on the new 52-esr the use of --disable-webrtc leads to compile errors. Upstream should know about it https://bugzilla.mozilla.org/buglist.cgi?quicksearch=FileSystemDirectory https://bugzilla.mozilla.org/show_bug.cgi?id=1360903 (without patch) https://bugzilla.mozilla.org/show_bug.cgi?id=1353765 (with patch) shall I open a new bug for this?
no, this bug is fine, no need for a new one. I'll have to think about this some more. I can see where someone might want to disable webrtc, but at the same time, mozilla may well integrate webrtc code to use it for other components (which is why, without actually looking at it yet, I figure there are compile-time issues now).
There indeed are some compile failure bugs with --disable-webrtc in bugzilla, which shows more that mozilla doesn't test their code properly than anything else. At least Fedora and I think Debian/Ubuntu/Mint do use --disable-webrtc too on their binaries, so this shouldn't be a nightmare to maintain because it is a relativly common practice to disable it. firefox-53.0 blows up too, see https://bugzilla.mozilla.org/show_bug.cgi?id=1335250 this patch is only for 54.0, Fedora has a (for me) working patch. http://pkgs.fedoraproject.org/cgit/rpms/firefox.git/tree/mozilla-1335250.patch
I have been maintaining exactly this in my local overlay for some time. I pinged anarchy about this on freenode a few months ago, and they mentioned that they would try to do something similar with mozconfig to savedconfig that exists for busybox, et al. FWIW, firefox has worked flawlessly with me up until <52.1 with this configuration, but since then I have been having more build issues than usual.
(In reply to gentoo from comment #5) > I have been maintaining exactly this in my local overlay for some time. I > pinged anarchy about this on freenode a few months ago, and they mentioned > that they would try to do something similar with mozconfig to savedconfig > that exists for busybox, et al. FWIW, firefox has worked flawlessly with me > up until <52.1 with this configuration, but since then I have been having > more build issues than usual. No THAT is something I can look into doing right away, for sure: rolling EXTRA_ECONF into mozconfig, so you don't need to overlay the ebuild just to inject some configuration options. That, plus user-patches, should cover most custom cases I expect?
(In reply to Ian Stakenvicius from comment #6) > (In reply to gentoo from comment #5) > > I have been maintaining exactly this in my local overlay for some time. I > > pinged anarchy about this on freenode a few months ago, and they mentioned > > that they would try to do something similar with mozconfig to savedconfig > > that exists for busybox, et al. FWIW, firefox has worked flawlessly with me > > up until <52.1 with this configuration, but since then I have been having > > more build issues than usual. > > Now THAT is something I can look into doing right away, for sure: rolling > EXTRA_ECONF into mozconfig, so you don't need to overlay the ebuild just to > inject some configuration options. > > That, plus user-patches, should cover most custom cases I expect? OK, mozilla-overlay now contains support for appending any specified EXTRA_ECONF options into .mozconfig ; Please test and let me know if it works or needs improvement. I'll look into --disable-webrtc directly via use flag in the coming days.
(In reply to tt_1 from comment #2) > I tested this for hapieness with the old 45-esr releases before filling this > bug, but I just recently noticed that on the new 52-esr the use of > --disable-webrtc leads to compile errors. Upstream should know about it > > https://bugzilla.mozilla.org/buglist.cgi?quicksearch=FileSystemDirectory > > https://bugzilla.mozilla.org/show_bug.cgi?id=1360903 (without patch) > https://bugzilla.mozilla.org/show_bug.cgi?id=1353765 (with patch) > > shall I open a new bug for this? this is fixed for < esr-52.1.1 https://hg.mozilla.org/releases/mozilla-esr52/rev/1d2e2fde559a
the new coreconf eclass works like a charm, thanks for the magic :-) Have you been thoughtfull about the webrtc useflag? Fedora disables this too per default, if it breaks a build they usually take care of it and fix it + provide patches in their git. Maybe you want to push it to the overlay for testing, as you did with the once egl-useflag?
52-esr needs the upstream patch until next release bump (52.1.2 or 52.2.0) 53.0 needs the patch from fedora, it shoud be fixed for non esr in 54.0 I believe
(In reply to tt_1 from comment #10) > 52-esr needs the upstream patch until next release bump (52.1.2 or 52.2.0) > 53.0 needs the patch from fedora, it shoud be fixed for non esr in 54.0 I > believe I personally do not care what other distros do. This is gentoo, we have provided a way to pass additional arguments. You are free to play with the patches but upstream is moving to remove unsupported options.
Closing as wontfix, as there's not going to be a webrtc useflag as decided by the mozilla team. The eclass hack allows to pass additional command line optins via package.env entries, which is fine by me.
