PSA: ESlint 4 upgrade & node_modules clobber

[Mark Banner]

I have just landed an upgrade to ESLint 4 on autoland, this will make 
its way to mozilla-central later today.


One thing to note: on upgrading from ESLint 3 to 4, it will clobber your 
topsrcdir/node_modules directory - this is intentional to try and avoid 
issues we've seen previously with upgrades of npm modules (for npm 
version 5).


ESLint 4 has lots of new features, including glob based configuration 
options, and lots of improved rules. We'll be making more use of these 
over the next few cycles.


Please consider installing the lint commit/push hooks 
 
if you haven't already.


Mark


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

Re: Intent to ship: Retained Display Lists

[matt . woodrow]

On Thursday, October 26, 2017 at 5:13:15 PM UTC+13, mwoo...@mozilla.com wrote:
> On Monday, October 9, 2017 at 1:22:55 PM UTC+13, Matt Woodrow wrote:
> 
> > 
> > We're planning on landing the code for retaining display lists in 58, 
> > behind the pref layout.display.list.retain.
> > 
> 
> This has now landed in Nightly, and looks to be working really well.
> 
> We'd really appreciate some early feedback, so feel free to set 
> layout.display-list.retain=true and give it a try!
> 
> Please file bugs blocking 1352499 if you find any issues.
> 
> Thanks!
> 
>  - Matt

And now it's enabled by default for mozilla-central, and should go out in 
tonight's Nightly.

As above, please file bugs blocking 1352499 if you find any issues.

Thanks!

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

Proposal to remove the xpfe autocomplete bindings and the xpfe/components/autocomplete directory

[Brian Grinstead]

While tracking down the XBL bindings in the tree, I noticed that there are 4 
inside the xpfe/ directory at 
https://github.com/mozilla/gecko-dev/blob/master/xpfe/components/autocomplete/resources/content/autocomplete.xml.

I'd like to remove those bindings, and AFAICT we aren't using them in Firefox. 
Are there any objections to removing the code from m-c?

Thanks,
Brian

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

Re: Intent to require Python 3 to build Firefox 59 and later

[Jeff Gilbert]

As long as we follow PEP 394, I'm super excited. (including on our
mozilla-build windows system, which counts as 'unix-like')

On Sun, Nov 12, 2017 at 9:12 AM, David Burns  wrote:
> I am not saying it should but if we have a requirement for python 3, we are
> also going to have a requirement for py2 to both be available for local
> development.
>
> David
>
> On 11 November 2017 at 14:10, Andrew Halberstadt 
> wrote:
>
>> On Fri, Nov 10, 2017 at 9:44 PM David Burns  wrote:
>>
>>> My only concern about this is how local developer environments are going
>>> to be when it comes to testing. While I am sympathetic to moving to python
>>> 3 we need to make sure that all the test harnesses have been moved over and
>>> this is something that needs a bit of coordination. Luckily a lot of the
>>> mozbase stuff is already moving to python 3 support but that still means we
>>> need to have web servers and the actual test runners moved over too.
>>>
>>> David
>>>
>>
>> For libraries like mozbase, I think the plan will be to support both 2 and
>> 3 at
>> the same time. There are libraries (like 'six') that make this possible.
>> I'd bet
>> there are even parts of the build system that will still need to support
>> both at
>> the same time.
>>
>> With that in mind, I don't think python 3 support for test harnesses needs
>> to
>> block the build system.
>>
>> Andrew
>>
>> On 10 November 2017 at 23:27, Gregory Szorc  wrote:
>>>
 For reasons outlined at https://bugzilla.mozilla.org/
 show_bug.cgi?id=1388447#c7, we would like to make Python 3 a
 requirement to build Firefox sometime in the Firefox 59 development cycle.
 (Firefox 59 will be an ESR release.)

 The requirement will likely be Python 3.5+. Although I would love to
 make that 3.6 if possible so we can fully harness modern features and
 performance.

 I would love to hear feedback - positive or negative - from downstream
 packagers and users of various operating systems and distributions about
 this proposal.

 Please send comments to dev-bui...@lists.mozilla.org or leave them on
 bug 1388447.

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

 ___
>>> dev-builds mailing list
>>> dev-bui...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-builds
>>>
>>
> ___
> 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 remove client.mk

[Gregory Szorc]

On Fri, Oct 27, 2017 at 4:16 PM, Gregory Szorc  wrote:

> client.mk has existed since 1998 (https://hg.mozilla.org/
> experimental/mozilla-central-cvs/rev/0a5e1fa423bd). Before `mach`,
> client.mk was the recommended way to build Firefox and perform other
> build tasks. client.mk has rarely changed in recent years because the
> build system maintainers have been working around it and because not much
> has changed around how the very early parts of "invoke the build system"
> work.
>
> The build system maintainers are making a significant push towards
> supporting building Firefox without GNU make in this and future quarters.
>
> Since client.mk is a make file and we want to not require make to build
> Firefox, client.mk is incompatible with our vision for the future of the
> Firefox build system. Furthermore, client.mk represents an ancient piece
> of build system infrastructure and its convoluted content creates
> consternation and inhibits forward progress. For these reasons, I'm
> announcing the intent to remove client.mk.
>
> If you have tools, infrastructure, workflows, etc that use client.mk - or
> any direct use of `make` for that matter - please transition them to `mach`
> commands and/or check with a build peer regarding your use case. You can
> file bugs regarding client.mk dependencies against bug 1412398.
>
> Thank you for your understanding.
>

Heads up: the patches to ween off client.mk have started landing. As I'm
touching the code, it is obvious how brittle things are and that there is a
web of under-documented dependencies everywhere I look.

If you see the build system behaving in strange ways - e.g. running
configure twice, complaining about clobbers when it shouldn't, running
moz.build sandbox evaluation when it shouldn't, etc, please don't hesitate
to make noise in #build or file a bug blocking 1412398. Even if we break a
workflow you relied on and there isn't a good equivalent, we'd like to
know. Disrupting people unnecessarily is definitely not a goal of this
refactor.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Building mozilla-central with clang + icecream

[Jean-Yves Avenard]

> On 7 Nov 2017, at 2:48 am, zbranie...@mozilla.com wrote:
> 
> I tried to build m-c today with clang 5.0 and icecream using the following 
> mozconfig:
> 
> 
> ```
> mk_add_options MOZ_MAKE_FLAGS="-j$(icecc-jobs)"
> 
> mk_add_options 'export CCACHE_PREFIX=icecc'
> mk_add_options "export RUSTC_WRAPPER=sccache" 
> 
> export CC=clang
> export CXX=clang++
> 
> ac_add_options --with-ccache
> 
> ```


Ensure you’re running the latest stable version of icecream.

The version shipping with ubuntu in particular is rather old, and there’s a few 
bugs related to races causing intermittent failure.

Those problems have almost all disappeared using icecream 1.1 for me.

I still have intermittent build failures however. I often have a ./mach build 
following a ./mach clobber to completing successfully and restarting the build 
will then complete with no trouble.

so there’s still races out there.

I run icecream with clang as compiler…

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

[Firefox Desktop] Issues found: November 6th to November 10th

[Cornel Ionce]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *November 6 - November 10* (week 45).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1416174 
Crash in mozilla::dom::WorkerGlobalScope::GetExistingNavigator
Core
DOM
NO  Andrea Marchesini 
1416200 
Zooming out on google maps results in tab crash
Core
Canvas: WebGL
	YES 
 
	NOBODY



*BETA CHANNEL
*

*
*
ID  Summary Product Component   Is a regression 
Assigned to
1414832 
	Firefox shows only one instance in the Control panel if two versions 
are installed using separate accounts

Firefox
Installer
TBD NOBODY
1414833 
	Release version is being upgraded to beta instead of being installed in 
two different locations

Firefox
Installer
TBD NOBODY
1415089 
A blank icon is displayed after renaming and updating Firefox
Firefox
Installer
NO  NOBODY

**

*
NIGHTLY CHANNEL**
*

none


*ESR CHANNEL*
none


Regards,
Cornel (:cornel_ionce)
Desktop Release QA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform