On 6/10/20 1:51 PM, Kartikaya Gupta wrote:
For those of you who like me are still running Ubuntu 16.04 LTS: the
minimum version of python required to build gecko got bumped from 3.5
to 3.6. As Ubuntu 16.04 doesn't offer python3.6 out of the box, you
may need to build it from source to get going
The pyenv[1] project is a great way to manage multiple versions of python
on your system. I've found it easier than trying to compile directly from
source.
Cheers,
Chris
[1] https://github.com/pyenv/pyenv
On Wed, 10 Jun 2020 at 16:52, Kartikaya Gupta wrote:
> For those of you who like me are
For those of you who like me are still running Ubuntu 16.04 LTS: the
minimum version of python required to build gecko got bumped from 3.5
to 3.6. As Ubuntu 16.04 doesn't offer python3.6 out of the box, you
may need to build it from source to get going again. See
I can't speak for what TB development plan is.
One thing I observe as an occasional submitter of TB patches is this.
Thunderbird ditched |mozmill| test December 2019, and switched to
mochitest in place of mozmill test.
Unfortunately, valgrind no longer works locally for mochitest.
This is
In general, this obviously makes a lot of sense. However, because there is
so much extra complication for accessibility when e10s is enabled, I find
myself disabling e10s in local opt/debug builds to isolate problems to the
core a11y engine (vs the a11y e10s stuff). The ability to do this was
I agree about not shipping this to our users, but I see several needs to keep
this option for developers working on Firefox:
* GeckoView still supports running in non-e10s mode, and inability to mimic
that environment on desktop builds would complicate writing code that works on
android.
* As
I can't speak for Thunderbird's plans, but either way these plans
shouldn't affect them and is restricted to desktop Firefox; the pref
still works there:
https://searchfox.org/mozilla-central/rev/4bb2401ecbfce89af06fb2b4d0ea3557682bd8ff/toolkit/xre/nsAppRunner.cpp#5020-5024
, and they set it:
I agree that it's a bad idea for users to be running permanently with this
setting on their daily driver browsers.
But the environment variable has been a huge productivity enhancer to
reduce my mental load when setting up an extra-hairy debug session or
taking system traces.
I wish we could
I was asked off-list why I'm not suggesting we remove support for the
environment variable entirely (ie why keep it for tests). That's a good
question, so I will attempt to address it.
I think that's a laudable goal, but it's more work. Practically
speaking, AIUI valgrind still runs with e10s
What is the situation of Thunderbird? I think they don't have e10s enabled
yet, and it may be worth at least knowing what their plans are.
-- Emilio
On Wed, Jun 10, 2020, 8:44 PM Dave Townsend wrote:
> Non-e10s is such a different environment that I don't think we have any
> hope of keeping
Non-e10s is such a different environment that I don't think we have any
hope of keeping it working without running the full test suite in that mode
and I don't think anyone wants to do that. Now that this has started
breaking I think it is actively harmful to our users for us to allow them
to
(Copied to fx-dev; Replies to dev-platform please.)
Hello,
Just over a year ago, I started a discussion[0] about our support for
disabling e10s. The outcome of that was that we removed support for
disabling e10s with a pref on Desktop Firefox with version 68, except
for use from automation.
The implementation of JavaScript BinAST [1] is currently a prototype with
shipping in nightly behind an pref for limited experiments. This prototype
code needs an overhaul to be able to ship and the spec is still very far from
final.
In order to reduce developer and CI costs while we make rapid
13 matches
Mail list logo
