Re: Linux distro readiness for Rust in Gecko

[Petr Cerny]

Henri Sivonen wrote:

On Wed, Mar 23, 2016 at 1:51 AM, Petr Cerny  wrote:

Saying "Linux is good, we can actually do things there, that are
more complicated elsewhere, but you are hindering our development"
 sound a bit unfair.


There is no contradiction between Rust working the best on Linux and
being of the opinion that limiting ourselves to Rust features that
were part of rustc when Debian stable last shipped is not okay.
Clearly, there are distros that are don't have a policy issue with
Firefox gaining a dependency on an actively-developed compiler. It's
just that the need of a policy exception is what generates email.


Right, but Debian is part of the ecosystem. I think you might have 
(unpleasant) reminiscences about the later days of WinXP, but people 
were using it for some reason, and I bet they have good reasons to use 
Debian stable and not some faster moving distributions.



It's hard for me to tell if you represent a distro with which a
rustc dependency will be a non-issue, since your comments run the
gamut of implying your distro had a compiler bootstrapping policy
stricter than Fedora's to saying that six weeks is viable.


Because it all depends on precise conditions. (And my comments were
meant also more generally than just for SLE). Six weeks is viable
technically iff all works as expected. Like Sylvester mentioned, once
there is a hiccup (rustc pulling in an update of llvm, llvm pulling in
update of gcc) we're all out of luck.

The dependency on non-stable build tools is not just a technical problem
- anyone not having a special taste for using bleeding edge technologies
will tell you such approach is broken. It may help the development big
time, but for packagers it is just pain.


The all-from-source, stable interfaces and similar policies are
there for a reason.


Again, "stable" is a loaded word. Maintaining interface
compatibility in the sense that stuff written to the old interface
doesn't break on update is reasonable to want, but e.g. in the case
of Debian that's not the criterion for getting to update a package
(absent policy exception). rustc maintains compatibility in the sense
that source code that compiled with some version (1.0 or later) of
rustc continues to compile with later versions.


Which is good, but only half of the problem. The other is that the
language itself is not stable enough to provide some sort compatibility
in the other direction. Which is why (with my limited understanding of
Debian policies) assume it could live in Unstable or Testing but not Stable.


As I understand Debian policy, even if upstream says that it's their
explicit goal to maintain compatibility in the sense that new
versions don't break stuff written for old versions, Debian assumes
that upstream won't meet such a goal and instead only cherry-picking
security fixes from the upstream is permitted (absent the sort of
exception Chromium got).


Well... most of the time things work. The problem are the cases when
seemingly innocent upstream changes break working setups (because
upstream doesn't care about history, they want progress). Policies like
this are motivated exactly by this sort of things happening in the past.
Does Chromium pull in new versions of compilers or comparable packages
every other month?


Actually you could package Firefox for generic Linux by building
your own GCC and bundling all libraries (the whole GTK stack) into
 the tarball/rpm - at some point replicating good portion of
packages installed on an average desktop system. ... You don't
want to go there.


Mozilla already ships binary tarballs compiled with a GCC version of
Mozilla's choice. Those tarballs don't even need to include GTK+,
because except for the changes between gtk2 and gtk3, GTK+ does a
good job maintaining ABI compatibility.


Let's just say that we do have separate GTK package for Firefox on older
SLE code streams. Although "older" in this case is not the 3-5 years you
would see with Debian. I think you understand my feelings the day it 
turns out I'll have to package and regularly update LLVM and rustc every 
6 weeks...



Distributions should be fine with 6 weeks, if changes are announced
with reasonable time buffer.


I'd expect it to make sense to update rustc every six weeks without
specific notice. Maybe Firefox won't need a new rustc for every
Firefox release, but considering the pace of development of rustc
and the Rust standard library, I think it would make the most sense
to plan with the assumption that both Firefox and rustc update every
six weeks.


OK, but 6 weeks for a compiler update is not big-enough time buffer: if
at some point rustc indeed pulls in newer LLVM things will get nasty.
You can't update system LLVM, so you have to build a separate one. If
that one for some reason requires newer GCC... well you get the picture.

If you can guarantee such things won't happen, good. Telling packagers 6
weeks ahead that for Firefox update they will need newer LLVM and
possibly newer G

Re: MOZ_LOG_FILE and MOZ_LOG_MODULES are now the environment variables for logging

[Honza Bambas]

On 3/21/2016 18:17, Nicholas Alexander wrote:

On Mon, Mar 21, 2016 at 9:13 AM, Honza Bambas  wrote:


tl;dr: Start migrating to use of MOZ_LOG_* instead of NSPR_LOG_*.  Don't
worry about backward compatibility tho, when MOZ_LOG_* is not set, we
fallback to NSPR_LOG_* values.


Hi Honza,

Thanks for making the world a better place!  I'm sorry to add to your
burden, but could you drop links to updated MDN documentation?  I know that
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR/Reference/NSPR_LOG_MODULES
probably wants to reference your new work, and there are probably
additional places.  Is this in the coding styles document?  (Yet?)

Thanks again!
Nick



A started a dev-doc-needed job on the bug.  I think we need to update an 
existing XPCOM logging document (if any) or start a new one.  Honestly, 
something a bit beyond my scope, tho.


-hb-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux distro readiness for Rust in Gecko

[Selena Deckelmann]

Hi!

We are holding off on packaging with nix for a couple quarters because of
how much work in the TC-worker we have ahead of us.

Let's have a nix conversation the first week of the quarter and then we can
see what low hanging fruit there is. Right now, lots of people are stressed
with gsoc and outreachy and end of quarter goal work :)

I'm so glad you're advocating for this :). Have you talked with gps at all
about nix and reproducible builds?

-Selena

On Thu, Mar 24, 2016 at 4:50 AM Petr Cerny  wrote:

> Henri Sivonen wrote:
> > On Wed, Mar 23, 2016 at 1:51 AM, Petr Cerny  wrote:
> >> Saying "Linux is good, we can actually do things there, that are
> >> more complicated elsewhere, but you are hindering our development"
> >>  sound a bit unfair.
> >
> > There is no contradiction between Rust working the best on Linux and
> > being of the opinion that limiting ourselves to Rust features that
> > were part of rustc when Debian stable last shipped is not okay.
> > Clearly, there are distros that are don't have a policy issue with
> > Firefox gaining a dependency on an actively-developed compiler. It's
> > just that the need of a policy exception is what generates email.
>
> Right, but Debian is part of the ecosystem. I think you might have
> (unpleasant) reminiscences about the later days of WinXP, but people
> were using it for some reason, and I bet they have good reasons to use
> Debian stable and not some faster moving distributions.
>
> > It's hard for me to tell if you represent a distro with which a
> > rustc dependency will be a non-issue, since your comments run the
> > gamut of implying your distro had a compiler bootstrapping policy
> > stricter than Fedora's to saying that six weeks is viable.
>
> Because it all depends on precise conditions. (And my comments were
> meant also more generally than just for SLE). Six weeks is viable
> technically iff all works as expected. Like Sylvester mentioned, once
> there is a hiccup (rustc pulling in an update of llvm, llvm pulling in
> update of gcc) we're all out of luck.
>
> The dependency on non-stable build tools is not just a technical problem
> - anyone not having a special taste for using bleeding edge technologies
> will tell you such approach is broken. It may help the development big
> time, but for packagers it is just pain.
>
> >> The all-from-source, stable interfaces and similar policies are
> >> there for a reason.
> >
> > Again, "stable" is a loaded word. Maintaining interface
> > compatibility in the sense that stuff written to the old interface
> > doesn't break on update is reasonable to want, but e.g. in the case
> > of Debian that's not the criterion for getting to update a package
> > (absent policy exception). rustc maintains compatibility in the sense
> > that source code that compiled with some version (1.0 or later) of
> > rustc continues to compile with later versions.
>
> Which is good, but only half of the problem. The other is that the
> language itself is not stable enough to provide some sort compatibility
> in the other direction. Which is why (with my limited understanding of
> Debian policies) assume it could live in Unstable or Testing but not
> Stable.
>
> > As I understand Debian policy, even if upstream says that it's their
> > explicit goal to maintain compatibility in the sense that new
> > versions don't break stuff written for old versions, Debian assumes
> > that upstream won't meet such a goal and instead only cherry-picking
> > security fixes from the upstream is permitted (absent the sort of
> > exception Chromium got).
>
> Well... most of the time things work. The problem are the cases when
> seemingly innocent upstream changes break working setups (because
> upstream doesn't care about history, they want progress). Policies like
> this are motivated exactly by this sort of things happening in the past.
> Does Chromium pull in new versions of compilers or comparable packages
> every other month?
>
> >> Actually you could package Firefox for generic Linux by building
> >> your own GCC and bundling all libraries (the whole GTK stack) into
> >>  the tarball/rpm - at some point replicating good portion of
> >> packages installed on an average desktop system. ... You don't
> >> want to go there.
> >
> > Mozilla already ships binary tarballs compiled with a GCC version of
> > Mozilla's choice. Those tarballs don't even need to include GTK+,
> > because except for the changes between gtk2 and gtk3, GTK+ does a
> > good job maintaining ABI compatibility.
>
> Let's just say that we do have separate GTK package for Firefox on older
> SLE code streams. Although "older" in this case is not the 3-5 years you
> would see with Debian. I think you understand my feelings the day it
> turns out I'll have to package and regularly update LLVM and rustc every
> 6 weeks...
>
> >> Distributions should be fine with 6 weeks, if changes are announced
> >> with reasonable time buffer.
> >
> > I'd expect it to make sense to update rus

How to change the default profile in the profile manager?

[Tobias B. Besemer]

Hi!

I resorted/renamed my profile folders...
Now, when I start the Developer Edition with the profile manager, FF creates a 
new entry with "dev-edition-default" and the according folders in 
\Roaming\Mozilla\Firefox\Profiles\ and \Local\Mozilla\Firefox\Profiles\ (Win7).
How to prevent this and maybe select a other profile the profile manager should 
point to as default?

Greets, Tobias.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Update of "removed-files"?

[Tobias B. Besemer]

Hi!

In the program folder of FF by Windows there is a file called "removed-files"...
This file includes a list with files (rules) that should be removed...
What's about updating this?
I see a lot of (old) files and folders in the profile folders that should be 
IMHO removed to clean up the profiles from old garbage...

Here are some examples:
- c:\Users\Administrator\AppData\Local\Mozilla\Firefox\firefox\
Seems to be a mistake by a old install?

- 
c:\Users\Administrator\AppData\Local\Mozilla\Firefox\Profiles\zypzyju5.default\urlclassifier.pset
A really old files that was replaced with a new file with a other extension.

- 
c:\Users\Administrator\AppData\Local\Mozilla\Firefox\Profiles\zypzyju5.default\urlclassifier3.sqlite
The new files of the file above, but only in one of my profile folders... So 
why?

- 
c:\Users\Administrator\AppData\Local\Mozilla\Firefox\Profiles\zypzyju5.default\chrome_debugger_profile\
Also only in one of my profiles... Should be kept?

- 
c:\Users\Administrator\AppData\Local\Mozilla\Firefox\Profiles\zypzyju5.default\safebrowsing\test-*.*
Gets still daily updated but there are also mozstd-*.* and goog-*.* files...

- c:\Users\Administrator\AppData\LocalLow\Mozilla\
Created by mistake by a old installer? Gets never used...

- c:\Users\Administrator\AppData\Roaming\Mozilla\Firefox\Crash 
Reports\InstallTime*
Every (daily) update creates a new file... Over time the user (tester) have 
hundreds of them in his folder...

- I see in my profile folders under "Roaming" a lot of other (really) old files 
getting no more used...

- There exist also (really) old extensions in the profiles like the "Update 
Channel Extension" that user should use no more... Is there maybe a solution 
possible that a extension developer can mark his old extension in AMO as 
"should be deinstalled" (with maybe a list of data files that should be deleted 
too)?

Guess that every files that is for FF Versions older then 1-2 years can be 
deleted because this old browsers are no more save, the update/upgarde is for 
free and the user should really update his FF...
(Whats about a message that when a FF starts on a system that is older then 
1-2years that says the user he should really upgrade is FF for free?)


Greets, Tobias.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ Core Guidelines

[Jeff Muizelaar]

On Wed, Jan 6, 2016 at 7:15 AM, Henri Sivonen  wrote:
> On Thu, Oct 1, 2015 at 9:58 PM, Jonathan Watt  wrote:
>> For those who are interested in this, there's a bug to consider integrating
>> the Guidelines Support Library (GSL) into the tree:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1208262
>
> This bug appears to have stalled.
>
> What should my expectations be regarding getting an equivalent of (at
> least single-dimensional) GSL span (formerly array_view;
> conceptually Rust's slice) into MFBT?

Something like this already exits: mfbt/Range.h

-Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to enable e10s by default when running tests locally

[Andrew Halberstadt]

Bug 1243083 tracks enabling e10s by default when running tests locally.
I intend to do this for as many harnesses as possible unless someone
says otherwise.

The implication is that the --e10s flag will be renamed to
--disable-e10s. So you'll need to pass in --disable-e10s if you wish to
run without e10s enabled. This also means that tests that are skipped
with 'e10s' will no longer run by default locally. The hope is that this
will make it easier for devs to find and fix tests that are broken with
e10s enabled, as well as ensure that new tests work with e10s right out
of the gate. CI jobs will not be affected, only running locally.

One potential sticking point is mochitest-chrome. It currently does not
get run in e10s in CI, so local configuration should mirror this.
However, since --e10s is being removed, this means it would be
impossible to run mochitest-chrome in e10s without modifying source
files. Maybe this just needs some argparse hackery.

If you have any concerns or know of other suites that should explicitly
*not* be run with e10s enabled by default, please let me know.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Boris Zbarsky]

On 3/24/16 12:15 PM, Andrew Halberstadt wrote:

If you have any concerns or know of other suites that should explicitly
*not* be run with e10s enabled by default, please let me know.


Do we have any plans for making --debugger not completely useless when 
running tests in e10s mode?  There are various ways of hacking around 
it, but it would be awesome if we just made it work by default somehow...


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to switch to Visual Studio 2015

[Gregory Szorc]

On Wed, Mar 23, 2016 at 7:03 PM, Gregory Szorc  wrote:

> On Wed, Mar 16, 2016 at 11:49 PM, Gregory Szorc  wrote:
>
>>
>> On Thu, Mar 10, 2016 at 8:14 AM, Gregory Szorc  wrote:
>>
>>> Visual Studio 2015 has been out for a while. Many people have put in
>>> work to make Firefox build on it. The time has come to officially
>>> transition release builds from Visual Studio 2013 to Visual Studio 2015.
>>>
>>> This email serves as an intent to switch automation to Visual Studio
>>> 2015 Update 1 (latest stable release) as soon as possible, hopefully in
>>> the next week or two.
>>>
>>> A big driver for the switch is that builds with VS2015 are faster. PGO
>>> builds in automation are 1+ hour faster than with VS2013 (see data in bug
>>> 1250797)! (Windows PGO builds are a long pole in the release process and
>>> therefore prevent us from releasing faster - this is highly relevant during
>>> chemspills.)
>>>
>>> A host of new C++ features should be available after the switch.
>>> Although, we may have to drop support for VS2013 before those can be fully
>>> realized. I defer to others to determine when VS2013 will be dropped.
>>>
>>> I feel like 95% of the transition work is completed. However, the
>>> following Try pushes appear to have some new failures:
>>>
>>> https://treeherder.mozilla.org/#/jobs?repo=try&revision=d67e4a1f3735
>>> https://treeherder.mozilla.org/#/jobs?repo=try&revision=5c2a7b4e81d0
>>> (PGO)
>>>
>>> (Ignore SpiderMonkey failures - they are due to how the toolchain is
>>> being hackily installed in those Try pushes.)
>>>
>>> I could use your help triaging test failures and fixing fallout so we
>>> can complete the transition to VS2015.
>>>
>>> I'm very much a fan of perfect is the enemy of done and I feel temporary
>>> workarounds (like e.g. disabling tests if there appears to be a minor
>>> regression) may be warranted so we can give VS2015 extra time to bake on
>>> Nightly. Otherwise, this may slip ~6 weeks until the next release. I feel
>>> like we're too close to being able to transition to VS2015 to wait ~6 more
>>> weeks.
>>>
>>> Bug 1186060 is our master tracking bug for the VS2015 switch.
>>>
>>> Thank you for everyone that has contributed to VS2015 fixes so far.
>>> Thank you in advance for helping complete the transition.
>>>
>>
>> (+1 week progress report)
>>
>> All Windows builds are now working with VS2015u1 running from tooltool
>> (read: we have a zip file containing all the toolchain files so we don't
>> need changes to build machines to roll out new Visual Studio / SDK versions
>> going forward). This includes PGO and SpiderMonkey builds.
>>
>> Talos numbers are at
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1254767#c9 and
>> investigation into changes is ongoing. There are some concerning
>> regressions - particularly around e10s - that have yet to be explained.
>>
>> Bug 1124033 has turned into a rabbit hole *and I could use help*. When
>> VS2015 support was first added to the build system, new-to-VS2015 compiler
>> warnings were blanket disabled. Bug 1124033 is about undoing that and
>> enabling those warnings. There are 20+ open bugs tracking fixing compiler
>> warnings. I've submitted patches to wallpaper over them by disabling
>> warnings in specific files or directories. But this is not optimal: we
>> should just fix the underlying warnings and leave the warning detection
>> enabled. Unfortunately, my C++ knowledge is about 10 years out of date,
>> very rusty, and I know very little about the C++ conventions used in
>> mozilla-central. This is where I could use help. *If you see a bug chained
>> up to bug 1124033 related to VS2015 compiler warnings, I'd appreciate help
>> with patches to C++ to fix the warnings.*
>>
>> If you'd like to submit Try pushes using VS2015,
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1124033#c21 contains
>> instructions.
>>
>> I'm still optimistic we'll be able to perform the switch (or at least
>> attempt the switch) this release cycle.
>>
>
> (+2 week progress report)
>
> Thanks to a lot of help from a lot of people, the compiler warnings
> strategy for VS2015 is now much better. Before, we had globally disabled
> all new-to-VS2015 compiler warnings. With bug 1124033 landing on inbound a
> few minutes ago, only C5026 and C5027 are now globally disabled. Many
> compiler warnings were fixed. Others were worked around by disabling
> specific warnings in moz.build files. The intent is to remove these
> workarounds and bugs have been filed to track their removal.
>
> At this point, the only blockers to VS2015 landing are bug 1255656 and bug
> 1257722. And I'm pretty confident those will get sorted out soon.
>
> So if everything goes according to plan, VS2015 will land tomorrow. You
> may want to prepare by installing VS2015 on your machines.
>

Inbound is now building with VS2015!

Thank you to everyone who helped with the transition over the past ~1 year.
I only got involved at the end of this effort. IMO the people who came
before and w

Re: Intent to enable e10s by default when running tests locally

[Andrew Halberstadt]

I'm not aware of work around this. If --debugger is completely busted
with e10s, I could potentially make --debugger imply --disable-e10s
until it gets fixed. Is there a bug on file?

I also forgot to mention that command defaults are likely coming soon,
so once bug 1255450 lands you'll be able to make a .machrc with:

[defaults]
mochitest = --disable-e10s


On 24/03/16 12:30 PM, Boris Zbarsky wrote:

On 3/24/16 12:15 PM, Andrew Halberstadt wrote:

If you have any concerns or know of other suites that should explicitly
*not* be run with e10s enabled by default, please let me know.


Do we have any plans for making --debugger not completely useless when
running tests in e10s mode?  There are various ways of hacking around
it, but it would be awesome if we just made it work by default somehow...

-Boris


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Ralph Giles]

Discussion seems to have wound down. Is there a decision on this?

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Boris Zbarsky]

On 3/24/16 12:43 PM, Andrew Halberstadt wrote:

I'm not aware of work around this. If --debugger is completely busted
with e10s, I could potentially make --debugger imply --disable-e10s
until it gets fixed. Is there a bug on file?


I don't know of one.

It's not that it's busted per se, it's that it attaches the debugger to 
the parent process.  Which is not very helpful, in most cases.  What 
would be ideal (at least on unixy systems) is if we managed to detect 
the child process starting and popped up an instance of $TERM or so, 
with a debugger running in it and attached to the child.



I also forgot to mention that command defaults are likely coming soon,
so once bug 1255450 lands you'll be able to make a .machrc with:

[defaults]
mochitest = --disable-e10s


Ah, nice.  Still, I agree it would be good to be testing e10s if we can 
make the debugging experience there better.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MOZ_LOG_FILE and MOZ_LOG_MODULES are now the environment variables for logging

[Ralph Giles]

On Mon, Mar 21, 2016 at 9:13 AM, Honza Bambas  wrote:

> tl;dr: Start migrating to use of MOZ_LOG_* instead of NSPR_LOG_*.  Don't
> worry about backward compatibility tho, when MOZ_LOG_* is not set, we
> fallback to NSPR_LOG_* values.

Could this be an opportunity to shorten NSPR_LOG_MODULES to just MOZ_LOG?

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Bobby Holley]

+1. The MOZ_DEBUG_CHILD_PROCESS hack is pretty arcane.

On Thu, Mar 24, 2016 at 9:30 AM, Boris Zbarsky  wrote:

> On 3/24/16 12:15 PM, Andrew Halberstadt wrote:
>
>> If you have any concerns or know of other suites that should explicitly
>> *not* be run with e10s enabled by default, please let me know.
>>
>
> Do we have any plans for making --debugger not completely useless when
> running tests in e10s mode?  There are various ways of hacking around it,
> but it would be awesome if we just made it work by default somehow...
>
> -Boris
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Aaron Klotz]

I know that most people aren't debugging e10s on Windows, but if you 
are, here's a protip (provided that you are using WinDbg):


If you include the "-o" option in the debugger args, WinDbg will 
automatically attach itself to all child processes that are started by 
the chrome process. No special environment variables or process startup 
sleeps required.


-Aaron

On 3/24/2016 10:51 AM, Boris Zbarsky wrote:

On 3/24/16 12:43 PM, Andrew Halberstadt wrote:

I'm not aware of work around this. If --debugger is completely busted
with e10s, I could potentially make --debugger imply --disable-e10s
until it gets fixed. Is there a bug on file?


I don't know of one.

It's not that it's busted per se, it's that it attaches the debugger 
to the parent process.  Which is not very helpful, in most cases.  
What would be ideal (at least on unixy systems) is if we managed to 
detect the child process starting and popped up an instance of $TERM 
or so, with a debugger running in it and attached to the child.



I also forgot to mention that command defaults are likely coming soon,
so once bug 1255450 lands you'll be able to make a .machrc with:

[defaults]
mochitest = --disable-e10s


Ah, nice.  Still, I agree it would be good to be testing e10s if we 
can make the debugging experience there better.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MOZ_LOG_FILE and MOZ_LOG_MODULES are now the environment variables for logging

[Justin Dolske]

On 3/24/16 9:54 AM, Ralph Giles wrote:

On Mon, Mar 21, 2016 at 9:13 AM, Honza Bambas  wrote:


tl;dr: Start migrating to use of MOZ_LOG_* instead of NSPR_LOG_*.  Don't
worry about backward compatibility tho, when MOZ_LOG_* is not set, we
fallback to NSPR_LOG_* values.


Could this be an opportunity to shorten NSPR_LOG_MODULES to just MOZ_LOG?


+1 to MOZ_LOG. It's better than bad, it's good.

Justin

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux distro readiness for Rust in Gecko

[aturon]

On Tuesday, March 22, 2016 at 4:25:35 PM UTC-7, atu...@mozilla.com wrote:
> The Rust compiler has had over 300 snapshots, so re-bootstrapping from ocaml 
> would take at least 900 compiles (each one requires three stages of internal 
> builds); by my estimation, this would take at least a month of constant 
> compilation. Moreover, it's not clear this is even possible: a few points 
> along the early history involved manual edits as well.
> 
> I don't think this line of investigation is worth pursuing. I think the 
> reasonable route is to:
> 
> - Get Rust snapshotting based on the previous stable compiler, for ease of 
> following the release train. (I hope to have news on that front tomorrow.)
> 
> - Seed distros from a relatively recent point in the chain.

An update on the snapshot front:

The Rust core team met yesterday and developed a complete plan for Rust to be 
build with the previous stable compiler as snapshot. We will be landing the 
infrastructure needed to do this shortly. 

In terms of release timing, it will take some time for this change to fully 
propagate. Our most recent Rust snapshot happened after the 1.8 beta, leading 
to the following picture:

- Rust 1.8 -- already in beta; hits stable on Apr 14th
- Ad hoc snapshot
- Rust 1.9 -- builds from ad hoc snapshot
- Rust 1.10 -- builds from Rust 1.9 stable

The Rust 1.10 stable release will happen about 15 weeks from now, and under 
this plan will be the first release to bootstrap this way.

In terms of bootstrapping the distros themselves, as I mentioned before the 
simplest approach seems to be starting with a recent Rust snapshot and going 
from there.

How does all this sound?

Aaron
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Paul Adenot]

Do we know whether `set follow-fork-mode child` in gdb would work ? If
not, can we fix it ? It would be a pretty good experience for most
developers that only care about the child.

Paul.

On Thu, Mar 24, 2016, at 06:05 PM, Aaron Klotz wrote:
> I know that most people aren't debugging e10s on Windows, but if you 
> are, here's a protip (provided that you are using WinDbg):
> 
> If you include the "-o" option in the debugger args, WinDbg will 
> automatically attach itself to all child processes that are started by 
> the chrome process. No special environment variables or process startup 
> sleeps required.
> 
> -Aaron
> 
> On 3/24/2016 10:51 AM, Boris Zbarsky wrote:
> > On 3/24/16 12:43 PM, Andrew Halberstadt wrote:
> >> I'm not aware of work around this. If --debugger is completely busted
> >> with e10s, I could potentially make --debugger imply --disable-e10s
> >> until it gets fixed. Is there a bug on file?
> >
> > I don't know of one.
> >
> > It's not that it's busted per se, it's that it attaches the debugger 
> > to the parent process.  Which is not very helpful, in most cases.  
> > What would be ideal (at least on unixy systems) is if we managed to 
> > detect the child process starting and popped up an instance of $TERM 
> > or so, with a debugger running in it and attached to the child.
> >
> >> I also forgot to mention that command defaults are likely coming soon,
> >> so once bug 1255450 lands you'll be able to make a .machrc with:
> >>
> >> [defaults]
> >> mochitest = --disable-e10s
> >
> > Ah, nice.  Still, I agree it would be good to be testing e10s if we 
> > can make the debugging experience there better.
> >
> > -Boris
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux distro readiness for Rust in Gecko

[Chris Peterson]

On 3/24/16 10:13 AM, atu...@mozilla.com wrote:

The Rust core team met yesterday and developed a complete plan for Rust to be 
build with the previous stable compiler as snapshot. We will be landing the 
infrastructure needed to do this shortly.

In terms of release timing, it will take some time for this change to fully 
propagate. Our most recent Rust snapshot happened after the 1.8 beta, leading 
to the following picture:

- Rust 1.8 -- already in beta; hits stable on Apr 14th
- Ad hoc snapshot
- Rust 1.9 -- builds from ad hoc snapshot
- Rust 1.10 -- builds from Rust 1.9 stable

The Rust 1.10 stable release will happen about 15 weeks from now, and under 
this plan will be the first release to bootstrap this way.


Aaron, so going forward, Rust version N should always be buildable by 
version N-1 (starting with N = 1.10)?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Jeff Muizelaar]

We fork a process to test gfx early on so 'set follow-for-mode child'
might end up following that.
'set detach-on-fork off' will keep you attached to everything though.

-Jeff

On Thu, Mar 24, 2016 at 1:21 PM, Paul Adenot  wrote:
> Do we know whether `set follow-fork-mode child` in gdb would work ? If
> not, can we fix it ? It would be a pretty good experience for most
> developers that only care about the child.
>
> Paul.
>
> On Thu, Mar 24, 2016, at 06:05 PM, Aaron Klotz wrote:
>> I know that most people aren't debugging e10s on Windows, but if you
>> are, here's a protip (provided that you are using WinDbg):
>>
>> If you include the "-o" option in the debugger args, WinDbg will
>> automatically attach itself to all child processes that are started by
>> the chrome process. No special environment variables or process startup
>> sleeps required.
>>
>> -Aaron
>>
>> On 3/24/2016 10:51 AM, Boris Zbarsky wrote:
>> > On 3/24/16 12:43 PM, Andrew Halberstadt wrote:
>> >> I'm not aware of work around this. If --debugger is completely busted
>> >> with e10s, I could potentially make --debugger imply --disable-e10s
>> >> until it gets fixed. Is there a bug on file?
>> >
>> > I don't know of one.
>> >
>> > It's not that it's busted per se, it's that it attaches the debugger
>> > to the parent process.  Which is not very helpful, in most cases.
>> > What would be ideal (at least on unixy systems) is if we managed to
>> > detect the child process starting and popped up an instance of $TERM
>> > or so, with a debugger running in it and attached to the child.
>> >
>> >> I also forgot to mention that command defaults are likely coming soon,
>> >> so once bug 1255450 lands you'll be able to make a .machrc with:
>> >>
>> >> [defaults]
>> >> mochitest = --disable-e10s
>> >
>> > Ah, nice.  Still, I agree it would be good to be testing e10s if we
>> > can make the debugging experience there better.
>> >
>> > -Boris
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Andrew McCreight]

On Thu, Mar 24, 2016 at 9:15 AM, Andrew Halberstadt <
ahalberst...@mozilla.com> wrote:

> Bug 1243083 tracks enabling e10s by default when running tests locally.
> I intend to do this for as many harnesses as possible unless someone
> says otherwise.


Great!

[some text deleted]

One potential sticking point is mochitest-chrome. It currently does not
> get run in e10s in CI, so local configuration should mirror this.
> However, since --e10s is being removed, this means it would be
> impossible to run mochitest-chrome in e10s without modifying source
> files. Maybe this just needs some argparse hackery.
>

My impression was that mochitest-chrome doesn't actually run with e10s,
even when you specify the flag. Is that not correct?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Andrew Halberstadt]

Afaict, ./mach mochitest -f chrome --e10s enables e10s. At least the
python side isn't overriding that default. Maybe there's some JS code
somewhere that overrides it.

But if the intent is for mochitest-chrome to never run with e10s enabled
anyway, then I guess not having that option isn't a big deal.

On 24/03/16 01:25 PM, Andrew McCreight wrote:

On Thu, Mar 24, 2016 at 9:15 AM, Andrew Halberstadt <
ahalberst...@mozilla.com> wrote:


Bug 1243083 tracks enabling e10s by default when running tests locally.
I intend to do this for as many harnesses as possible unless someone
says otherwise.



Great!

[some text deleted]

One potential sticking point is mochitest-chrome. It currently does not

get run in e10s in CI, so local configuration should mirror this.
However, since --e10s is being removed, this means it would be
impossible to run mochitest-chrome in e10s without modifying source
files. Maybe this just needs some argparse hackery.



My impression was that mochitest-chrome doesn't actually run with e10s,
even when you specify the flag. Is that not correct?



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Ehsan Akhgari]

On 2016-03-24 1:25 PM, Andrew McCreight wrote:
> One potential sticking point is mochitest-chrome. It currently does not
>> get run in e10s in CI, so local configuration should mirror this.
>> However, since --e10s is being removed, this means it would be
>> impossible to run mochitest-chrome in e10s without modifying source
>> files. Maybe this just needs some argparse hackery.
>>
> 
> My impression was that mochitest-chrome doesn't actually run with e10s,
> even when you specify the flag. Is that not correct?

No.  You currently can force it to run in e10s with --e10s like other
mochitest variants.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Felipe G]

Yeah, --e10s enables e10s in the browser for mochitest-chrome.  However,
the test harness is a .xul file opened in a tab, and that runs that tab as
non-remote, so for most tests it ends up testing the same thing as not
using --e10s. Other tabs and/or windows opened manually by the test would
be remote.


On Thu, Mar 24, 2016 at 3:05 PM, Ehsan Akhgari 
wrote:

> On 2016-03-24 1:25 PM, Andrew McCreight wrote:
> > One potential sticking point is mochitest-chrome. It currently does not
> >> get run in e10s in CI, so local configuration should mirror this.
> >> However, since --e10s is being removed, this means it would be
> >> impossible to run mochitest-chrome in e10s without modifying source
> >> files. Maybe this just needs some argparse hackery.
> >>
> >
> > My impression was that mochitest-chrome doesn't actually run with e10s,
> > even when you specify the flag. Is that not correct?
>
> No.  You currently can force it to run in e10s with --e10s like other
> mochitest variants.
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Ehsan Akhgari]

On Thu, Mar 24, 2016 at 2:10 PM, Felipe G  wrote:

> Yeah, --e10s enables e10s in the browser for mochitest-chrome.  However,
> the test harness is a .xul file opened in a tab, and that runs that tab as
> non-remote, so for most tests it ends up testing the same thing as not
> using --e10s. Other tabs and/or windows opened manually by the test would
> be remote.
>

D'oh, I have been working on this stuff and I didn't realize that's the
case (I was operating as if a passing mochitest-chrome when run in e10s
actually works with e10s).  That's extremely confusing.  :(  Should we
refuse to accept --e10s when running mochitest-chrome to help avoid this
confusion?


>
> On Thu, Mar 24, 2016 at 3:05 PM, Ehsan Akhgari 
> wrote:
>
>> On 2016-03-24 1:25 PM, Andrew McCreight wrote:
>> > One potential sticking point is mochitest-chrome. It currently does not
>> >> get run in e10s in CI, so local configuration should mirror this.
>> >> However, since --e10s is being removed, this means it would be
>> >> impossible to run mochitest-chrome in e10s without modifying source
>> >> files. Maybe this just needs some argparse hackery.
>> >>
>> >
>> > My impression was that mochitest-chrome doesn't actually run with e10s,
>> > even when you specify the flag. Is that not correct?
>>
>> No.  You currently can force it to run in e10s with --e10s like other
>> mochitest variants.
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>
>


-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux distro readiness for Rust in Gecko

[aturon]

On Thursday, March 24, 2016 at 10:21:12 AM UTC-7, Chris Peterson wrote:
> On 3/24/16 10:13 AM, atu...@mozilla.com wrote:
> > The Rust core team met yesterday and developed a complete plan for Rust to 
> > be build with the previous stable compiler as snapshot. We will be landing 
> > the infrastructure needed to do this shortly.
> >
> > In terms of release timing, it will take some time for this change to fully 
> > propagate. Our most recent Rust snapshot happened after the 1.8 beta, 
> > leading to the following picture:
> >
> > - Rust 1.8 -- already in beta; hits stable on Apr 14th
> > - Ad hoc snapshot
> > - Rust 1.9 -- builds from ad hoc snapshot
> > - Rust 1.10 -- builds from Rust 1.9 stable
> >
> > The Rust 1.10 stable release will happen about 15 weeks from now, and under 
> > this plan will be the first release to bootstrap this way.
> 
> Aaron, so going forward, Rust version N should always be buildable by 
> version N-1 (starting with N = 1.10)?

Correct.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Felipe G]

Yeah, that sounds like another good outcome of replacing --e10s with
--disable-e10s.

On Thu, Mar 24, 2016 at 3:59 PM, Ehsan Akhgari 
wrote:

> On Thu, Mar 24, 2016 at 2:10 PM, Felipe G  wrote:
>
>> Yeah, --e10s enables e10s in the browser for mochitest-chrome.  However,
>> the test harness is a .xul file opened in a tab, and that runs that tab as
>> non-remote, so for most tests it ends up testing the same thing as not
>> using --e10s. Other tabs and/or windows opened manually by the test would
>> be remote.
>>
>
> D'oh, I have been working on this stuff and I didn't realize that's the
> case (I was operating as if a passing mochitest-chrome when run in e10s
> actually works with e10s).  That's extremely confusing.  :(  Should we
> refuse to accept --e10s when running mochitest-chrome to help avoid this
> confusion?
>
>
>>
>> On Thu, Mar 24, 2016 at 3:05 PM, Ehsan Akhgari 
>> wrote:
>>
>>> On 2016-03-24 1:25 PM, Andrew McCreight wrote:
>>> > One potential sticking point is mochitest-chrome. It currently does not
>>> >> get run in e10s in CI, so local configuration should mirror this.
>>> >> However, since --e10s is being removed, this means it would be
>>> >> impossible to run mochitest-chrome in e10s without modifying source
>>> >> files. Maybe this just needs some argparse hackery.
>>> >>
>>> >
>>> > My impression was that mochitest-chrome doesn't actually run with e10s,
>>> > even when you specify the flag. Is that not correct?
>>>
>>> No.  You currently can force it to run in e10s with --e10s like other
>>> mochitest variants.
>>>
>>> ___
>>> firefox-dev mailing list
>>> firefox-...@mozilla.org
>>> https://mail.mozilla.org/listinfo/firefox-dev
>>>
>>
>>
>
>
> --
> Ehsan
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MOZ_LOG_FILE and MOZ_LOG_MODULES are now the environment variables for logging

[Eric Rahm]

On Thursday, March 24, 2016 at 10:10:30 AM UTC-7, Justin Dolske wrote:
> On 3/24/16 9:54 AM, Ralph Giles wrote:
> > On Mon, Mar 21, 2016 at 9:13 AM, Honza Bambas  wrote:
> >
> >> tl;dr: Start migrating to use of MOZ_LOG_* instead of NSPR_LOG_*.  Don't
> >> worry about backward compatibility tho, when MOZ_LOG_* is not set, we
> >> fallback to NSPR_LOG_* values.
> >
> > Could this be an opportunity to shorten NSPR_LOG_MODULES to just MOZ_LOG?
> 
> +1 to MOZ_LOG. It's better than bad, it's good.
> 
> Justin

That might be confusing as there's also the |MOZ_LOG| macro. OTOH it might be 
easier to remember...

I don't feel particularly strongly about it, I'd r+ a patch if it came my way.

-e
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Andrew McCreight]

I have already filed bug 1255095 about this, as you are far from the first
person to be confused by this!

Andrew

On Thu, Mar 24, 2016 at 11:59 AM, Ehsan Akhgari 
wrote:

> On Thu, Mar 24, 2016 at 2:10 PM, Felipe G  wrote:
>
>> Yeah, --e10s enables e10s in the browser for mochitest-chrome.  However,
>> the test harness is a .xul file opened in a tab, and that runs that tab as
>> non-remote, so for most tests it ends up testing the same thing as not
>> using --e10s. Other tabs and/or windows opened manually by the test would
>> be remote.
>>
>
> D'oh, I have been working on this stuff and I didn't realize that's the
> case (I was operating as if a passing mochitest-chrome when run in e10s
> actually works with e10s).  That's extremely confusing.  :(  Should we
> refuse to accept --e10s when running mochitest-chrome to help avoid this
> confusion?
>
>
>>
>> On Thu, Mar 24, 2016 at 3:05 PM, Ehsan Akhgari 
>> wrote:
>>
>>> On 2016-03-24 1:25 PM, Andrew McCreight wrote:
>>> > One potential sticking point is mochitest-chrome. It currently does not
>>> >> get run in e10s in CI, so local configuration should mirror this.
>>> >> However, since --e10s is being removed, this means it would be
>>> >> impossible to run mochitest-chrome in e10s without modifying source
>>> >> files. Maybe this just needs some argparse hackery.
>>> >>
>>> >
>>> > My impression was that mochitest-chrome doesn't actually run with e10s,
>>> > even when you specify the flag. Is that not correct?
>>>
>>> No.  You currently can force it to run in e10s with --e10s like other
>>> mochitest variants.
>>>
>>> ___
>>> firefox-dev mailing list
>>> firefox-...@mozilla.org
>>> https://mail.mozilla.org/listinfo/firefox-dev
>>>
>>
>>
>
>
> --
> Ehsan
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Update of "removed-files"?

[Robert Strong]

The removed-files file is only used for files within the application
directory during an application update. This mitigates security issues of
having an elevated process manipulating files outside of the application
directory which can lead to exploits. There are cases where this process
won't have access to all profiles on a system and hence won't be able to
remove the files in all cases. Cleaning up files in profiles should be done
by Firefox itself since it can remove the files without the issues noted
above.

Robert

On Thu, Mar 24, 2016 at 8:17 AM, Tobias B. Besemer <
tobias.bese...@googlemail.com> wrote:

> Hi!
>
> In the program folder of FF by Windows there is a file called
> "removed-files"...
> This file includes a list with files (rules) that should be removed...
> What's about updating this?
> I see a lot of (old) files and folders in the profile folders that should
> be IMHO removed to clean up the profiles from old garbage...
>
> Here are some examples:
> - c:\Users\Administrator\AppData\Local\Mozilla\Firefox\firefox\
> Seems to be a mistake by a old install?
>
> -
> c:\Users\Administrator\AppData\Local\Mozilla\Firefox\Profiles\zypzyju5.default\urlclassifier.pset
> A really old files that was replaced with a new file with a other
> extension.
>
> -
> c:\Users\Administrator\AppData\Local\Mozilla\Firefox\Profiles\zypzyju5.default\urlclassifier3.sqlite
> The new files of the file above, but only in one of my profile folders...
> So why?
>
> -
> c:\Users\Administrator\AppData\Local\Mozilla\Firefox\Profiles\zypzyju5.default\chrome_debugger_profile\
> Also only in one of my profiles... Should be kept?
>
> -
> c:\Users\Administrator\AppData\Local\Mozilla\Firefox\Profiles\zypzyju5.default\safebrowsing\test-*.*
> Gets still daily updated but there are also mozstd-*.* and goog-*.*
> files...
>
> - c:\Users\Administrator\AppData\LocalLow\Mozilla\
> Created by mistake by a old installer? Gets never used...
>
> - c:\Users\Administrator\AppData\Roaming\Mozilla\Firefox\Crash
> Reports\InstallTime*
> Every (daily) update creates a new file... Over time the user (tester)
> have hundreds of them in his folder...
>
> - I see in my profile folders under "Roaming" a lot of other (really) old
> files getting no more used...
>
> - There exist also (really) old extensions in the profiles like the
> "Update Channel Extension" that user should use no more... Is there maybe a
> solution possible that a extension developer can mark his old extension in
> AMO as "should be deinstalled" (with maybe a list of data files that should
> be deleted too)?
>
> Guess that every files that is for FF Versions older then 1-2 years can be
> deleted because this old browsers are no more save, the update/upgarde is
> for free and the user should really update his FF...
> (Whats about a message that when a FF starts on a system that is older
> then 1-2years that says the user he should really upgrade is FF for free?)
>
>
> Greets, Tobias.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Mike de Boer]

Slightly related: since bug 1253233 landed (well, hum, the most important parts 
of it), it’s possible to add fully functioning  
elements to mochitest-chrome test windows. Since many chrome test use the 
pattern of adding a browser element and do stuff with it upon load, I thought 
this might be a nice pattern to reuse. (Run the current test code twice, once 
for each browser element.)

You can also use Task.jsm and ContentTask.jsm tasks just like you’re used to 
from mochitest-browser tests. You can also use Assert.* assertions _inside_ 
frame scripts spawned by ContentTask.
Example that converts a mochitest-chrome test to use ContentTask: 
https://hg.mozilla.org/mozilla-central/rev/2aad094c7cf8#l1.34 


Just FYI, have fun!

Mike.

> On 24 Mar 2016, at 20:27, Andrew McCreight  wrote:
> 
> I have already filed bug 1255095 about this, as you are far from the first
> person to be confused by this!
> 
> Andrew
> 
> On Thu, Mar 24, 2016 at 11:59 AM, Ehsan Akhgari  >
> wrote:
> 
>> On Thu, Mar 24, 2016 at 2:10 PM, Felipe G  wrote:
>> 
>>> Yeah, --e10s enables e10s in the browser for mochitest-chrome.  However,
>>> the test harness is a .xul file opened in a tab, and that runs that tab as
>>> non-remote, so for most tests it ends up testing the same thing as not
>>> using --e10s. Other tabs and/or windows opened manually by the test would
>>> be remote.
>>> 
>> 
>> D'oh, I have been working on this stuff and I didn't realize that's the
>> case (I was operating as if a passing mochitest-chrome when run in e10s
>> actually works with e10s).  That's extremely confusing.  :(  Should we
>> refuse to accept --e10s when running mochitest-chrome to help avoid this
>> confusion?
>> 
>> 
>>> 
>>> On Thu, Mar 24, 2016 at 3:05 PM, Ehsan Akhgari 
>>> wrote:
>>> 
 On 2016-03-24 1:25 PM, Andrew McCreight wrote:
> One potential sticking point is mochitest-chrome. It currently does not
>> get run in e10s in CI, so local configuration should mirror this.
>> However, since --e10s is being removed, this means it would be
>> impossible to run mochitest-chrome in e10s without modifying source
>> files. Maybe this just needs some argparse hackery.
>> 
> 
> My impression was that mochitest-chrome doesn't actually run with e10s,
> even when you specify the flag. Is that not correct?
 
 No.  You currently can force it to run in e10s with --e10s like other
 mochitest variants.
 
 ___
 firefox-dev mailing list
 firefox-...@mozilla.org
 https://mail.mozilla.org/listinfo/firefox-dev
 
>>> 
>>> 
>> 
>> 
>> --
>> Ehsan
>> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org 
> https://lists.mozilla.org/listinfo/dev-platform 
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Flagging Sandboxing bugs

[Jim Mathies]

Hey all,

Sandboxing is currently enabled for content processes for a couple platforms. 
If you're curious where a sandbox is running you can check current status at 
the sandboxing wiki page [1].

The team has a process in place for triaging incoming bugs on a weekly basis. 
If you think you have a bug related to sandboxing that is filed outside the 
Core/Security: Process Sandboxing component, please add the |sb?| whiteboard 
tag to it so that our triage lists pick it up.

Also please note that the tracking-e10s bugzilla flag is not a sandboxing 
triage flag.

Thanks!

[1] https://wiki.mozilla.org/Security/Sandbox
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Porting Firefox OS 2.5 to my phone with libxul.so error.

[Nick]

I want to port Firefox OS 2.5 to my phone which support android system. And 
I've done the following things:
1. Get the Firefox OS 2.5 code from git and config the nexus-5-l branch.
2. Replace the kernel with the prebuilt one from my android kernel source code.
3. Modify a little in init.rc ( which is built in boot.img) to cut out the 
useless service.
4. Flash the system.img and boot.img into my android phone.


However, the OS porting to my phone can't run normally. And I get the error 
information from "adb logcat" like this:


I/DEBUG   (  228): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 
***
I/DEBUG   (  232): pid: 878, tid: 878, name: b2g  >>> /system/b2g/b2g <<<
I/DEBUG   (  232): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
I/DEBUG   (  232): r0 b4f41332  r1 ec8846a2  r2 02d7  r3 
I/DEBUG   (  232): r4 b623d7a8  r5 b5f11610  r6 0001  r7 
I/DEBUG   (  232): r8   r9 b6071360  sl b5012938  fp b624c880
I/DEBUG   (  232): ip b6ec697d  sp be8bf348  lr b41a89b9  pc b41a89be  cpsr 
60010030
I/DEBUG   (  232): 
I/DEBUG   (  232): backtrace:
I/DEBUG   (  232): #00 pc 010119be  /system/b2g/libxul.so


The processor on my phone is msm8974, simillar to nexus-5-l.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Karl Tomlinson]

Felipe G. writes:

> Yeah, --e10s enables e10s in the browser for mochitest-chrome.  However,
> the test harness is a .xul file opened in a tab, and that runs that tab as
> non-remote, so for most tests it ends up testing the same thing as not
> using --e10s. Other tabs and/or windows opened manually by the test would
> be remote.

What makes that first tab non-remote?

I had guessed that documents from "chrome:" would run in the browser
process (by default, at least), but is it all determined by
attributes on a browser element?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to switch to Visual Studio 2015

[Xidorn Quan]

On Fri, Mar 25, 2016 at 12:44 AM, Gregory Szorc  wrote:

> On Wed, Mar 23, 2016 at 7:03 PM, Gregory Szorc  wrote:
>
> > On Wed, Mar 16, 2016 at 11:49 PM, Gregory Szorc  wrote:
> >
> >>
> >> On Thu, Mar 10, 2016 at 8:14 AM, Gregory Szorc  wrote:
> >>
> >>> Visual Studio 2015 has been out for a while. Many people have put in
> >>> work to make Firefox build on it. The time has come to officially
> >>> transition release builds from Visual Studio 2013 to Visual Studio
> 2015.
> >>>
> >>> This email serves as an intent to switch automation to Visual Studio
> >>> 2015 Update 1 (latest stable release) as soon as possible, hopefully in
> >>> the next week or two.
> >>>
> >>> A big driver for the switch is that builds with VS2015 are faster. PGO
> >>> builds in automation are 1+ hour faster than with VS2013 (see data in
> bug
> >>> 1250797)! (Windows PGO builds are a long pole in the release process
> and
> >>> therefore prevent us from releasing faster - this is highly relevant
> during
> >>> chemspills.)
> >>>
> >>> A host of new C++ features should be available after the switch.
> >>> Although, we may have to drop support for VS2013 before those can be
> fully
> >>> realized. I defer to others to determine when VS2013 will be dropped.
> >>>
> >>> I feel like 95% of the transition work is completed. However, the
> >>> following Try pushes appear to have some new failures:
> >>>
> >>> https://treeherder.mozilla.org/#/jobs?repo=try&revision=d67e4a1f3735
> >>> https://treeherder.mozilla.org/#/jobs?repo=try&revision=5c2a7b4e81d0
> >>> (PGO)
> >>>
> >>> (Ignore SpiderMonkey failures - they are due to how the toolchain is
> >>> being hackily installed in those Try pushes.)
> >>>
> >>> I could use your help triaging test failures and fixing fallout so we
> >>> can complete the transition to VS2015.
> >>>
> >>> I'm very much a fan of perfect is the enemy of done and I feel
> temporary
> >>> workarounds (like e.g. disabling tests if there appears to be a minor
> >>> regression) may be warranted so we can give VS2015 extra time to bake
> on
> >>> Nightly. Otherwise, this may slip ~6 weeks until the next release. I
> feel
> >>> like we're too close to being able to transition to VS2015 to wait ~6
> more
> >>> weeks.
> >>>
> >>> Bug 1186060 is our master tracking bug for the VS2015 switch.
> >>>
> >>> Thank you for everyone that has contributed to VS2015 fixes so far.
> >>> Thank you in advance for helping complete the transition.
> >>>
> >>
> >> (+1 week progress report)
> >>
> >> All Windows builds are now working with VS2015u1 running from tooltool
> >> (read: we have a zip file containing all the toolchain files so we don't
> >> need changes to build machines to roll out new Visual Studio / SDK
> versions
> >> going forward). This includes PGO and SpiderMonkey builds.
> >>
> >> Talos numbers are at
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1254767#c9 and
> >> investigation into changes is ongoing. There are some concerning
> >> regressions - particularly around e10s - that have yet to be explained.
> >>
> >> Bug 1124033 has turned into a rabbit hole *and I could use help*. When
> >> VS2015 support was first added to the build system, new-to-VS2015
> compiler
> >> warnings were blanket disabled. Bug 1124033 is about undoing that and
> >> enabling those warnings. There are 20+ open bugs tracking fixing
> compiler
> >> warnings. I've submitted patches to wallpaper over them by disabling
> >> warnings in specific files or directories. But this is not optimal: we
> >> should just fix the underlying warnings and leave the warning detection
> >> enabled. Unfortunately, my C++ knowledge is about 10 years out of date,
> >> very rusty, and I know very little about the C++ conventions used in
> >> mozilla-central. This is where I could use help. *If you see a bug
> chained
> >> up to bug 1124033 related to VS2015 compiler warnings, I'd appreciate
> help
> >> with patches to C++ to fix the warnings.*
> >>
> >> If you'd like to submit Try pushes using VS2015,
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1124033#c21 contains
> >> instructions.
> >>
> >> I'm still optimistic we'll be able to perform the switch (or at least
> >> attempt the switch) this release cycle.
> >>
> >
> > (+2 week progress report)
> >
> > Thanks to a lot of help from a lot of people, the compiler warnings
> > strategy for VS2015 is now much better. Before, we had globally disabled
> > all new-to-VS2015 compiler warnings. With bug 1124033 landing on inbound
> a
> > few minutes ago, only C5026 and C5027 are now globally disabled. Many
> > compiler warnings were fixed. Others were worked around by disabling
> > specific warnings in moz.build files. The intent is to remove these
> > workarounds and bugs have been filed to track their removal.
> >
> > At this point, the only blockers to VS2015 landing are bug 1255656 and
> bug
> > 1257722. And I'm pretty confident those will get sorted out soon.
> >
> > So if everything goes according to plan, VS2015 w

Re: Intent to switch to Visual Studio 2015

[Gregory Szorc]

> On Mar 24, 2016, at 23:25, Xidorn Quan  wrote:
> 
>> On Fri, Mar 25, 2016 at 12:44 AM, Gregory Szorc  wrote:
>> On Wed, Mar 23, 2016 at 7:03 PM, Gregory Szorc  wrote:
>> 
>> > On Wed, Mar 16, 2016 at 11:49 PM, Gregory Szorc  wrote:
>> >
>> >>
>> >> On Thu, Mar 10, 2016 at 8:14 AM, Gregory Szorc  wrote:
>> >>
>> >>> Visual Studio 2015 has been out for a while. Many people have put in
>> >>> work to make Firefox build on it. The time has come to officially
>> >>> transition release builds from Visual Studio 2013 to Visual Studio 2015.
>> >>>
>> >>> This email serves as an intent to switch automation to Visual Studio
>> >>> 2015 Update 1 (latest stable release) as soon as possible, hopefully in
>> >>> the next week or two.
>> >>>
>> >>> A big driver for the switch is that builds with VS2015 are faster. PGO
>> >>> builds in automation are 1+ hour faster than with VS2013 (see data in bug
>> >>> 1250797)! (Windows PGO builds are a long pole in the release process and
>> >>> therefore prevent us from releasing faster - this is highly relevant 
>> >>> during
>> >>> chemspills.)
>> >>>
>> >>> A host of new C++ features should be available after the switch.
>> >>> Although, we may have to drop support for VS2013 before those can be 
>> >>> fully
>> >>> realized. I defer to others to determine when VS2013 will be dropped.
>> >>>
>> >>> I feel like 95% of the transition work is completed. However, the
>> >>> following Try pushes appear to have some new failures:
>> >>>
>> >>> https://treeherder.mozilla.org/#/jobs?repo=try&revision=d67e4a1f3735
>> >>> https://treeherder.mozilla.org/#/jobs?repo=try&revision=5c2a7b4e81d0
>> >>> (PGO)
>> >>>
>> >>> (Ignore SpiderMonkey failures - they are due to how the toolchain is
>> >>> being hackily installed in those Try pushes.)
>> >>>
>> >>> I could use your help triaging test failures and fixing fallout so we
>> >>> can complete the transition to VS2015.
>> >>>
>> >>> I'm very much a fan of perfect is the enemy of done and I feel temporary
>> >>> workarounds (like e.g. disabling tests if there appears to be a minor
>> >>> regression) may be warranted so we can give VS2015 extra time to bake on
>> >>> Nightly. Otherwise, this may slip ~6 weeks until the next release. I feel
>> >>> like we're too close to being able to transition to VS2015 to wait ~6 
>> >>> more
>> >>> weeks.
>> >>>
>> >>> Bug 1186060 is our master tracking bug for the VS2015 switch.
>> >>>
>> >>> Thank you for everyone that has contributed to VS2015 fixes so far.
>> >>> Thank you in advance for helping complete the transition.
>> >>>
>> >>
>> >> (+1 week progress report)
>> >>
>> >> All Windows builds are now working with VS2015u1 running from tooltool
>> >> (read: we have a zip file containing all the toolchain files so we don't
>> >> need changes to build machines to roll out new Visual Studio / SDK 
>> >> versions
>> >> going forward). This includes PGO and SpiderMonkey builds.
>> >>
>> >> Talos numbers are at
>> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1254767#c9 and
>> >> investigation into changes is ongoing. There are some concerning
>> >> regressions - particularly around e10s - that have yet to be explained.
>> >>
>> >> Bug 1124033 has turned into a rabbit hole *and I could use help*. When
>> >> VS2015 support was first added to the build system, new-to-VS2015 compiler
>> >> warnings were blanket disabled. Bug 1124033 is about undoing that and
>> >> enabling those warnings. There are 20+ open bugs tracking fixing compiler
>> >> warnings. I've submitted patches to wallpaper over them by disabling
>> >> warnings in specific files or directories. But this is not optimal: we
>> >> should just fix the underlying warnings and leave the warning detection
>> >> enabled. Unfortunately, my C++ knowledge is about 10 years out of date,
>> >> very rusty, and I know very little about the C++ conventions used in
>> >> mozilla-central. This is where I could use help. *If you see a bug chained
>> >> up to bug 1124033 related to VS2015 compiler warnings, I'd appreciate help
>> >> with patches to C++ to fix the warnings.*
>> >>
>> >> If you'd like to submit Try pushes using VS2015,
>> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1124033#c21 contains
>> >> instructions.
>> >>
>> >> I'm still optimistic we'll be able to perform the switch (or at least
>> >> attempt the switch) this release cycle.
>> >>
>> >
>> > (+2 week progress report)
>> >
>> > Thanks to a lot of help from a lot of people, the compiler warnings
>> > strategy for VS2015 is now much better. Before, we had globally disabled
>> > all new-to-VS2015 compiler warnings. With bug 1124033 landing on inbound a
>> > few minutes ago, only C5026 and C5027 are now globally disabled. Many
>> > compiler warnings were fixed. Others were worked around by disabling
>> > specific warnings in moz.build files. The intent is to remove these
>> > workarounds and bugs have been filed to track their removal.
>> >
>> > At this point, the only blockers to VS2015 landing