Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

[Jeff Gilbert]

Clock speed and core count matter much more than ECC. I wouldn't chase
ECC support for general dev machines.

On Thu, Nov 2, 2017 at 6:46 PM, Gregory Szorc  wrote:
> On Thu, Nov 2, 2017 at 3:43 PM, Nico Grunbaum  wrote:
>
>> For rr I have an i7 desktop with a base clock of 4.0 Ghz, and for building
>> I use icecc to distribute the load (or rather I will be again when bug
>> 1412240[0] is closed).  The i9 series has lower base clocks (2.8 Ghz, and
>> 2.6Ghz for the top SKUs)[1], but high boost clocks of 4.2 Ghz.  If I were
>> to switch over to an i9 for everything, would I see a notable difference in
>> performance in rr?
>>
>
> Which i7? You should get better CPU efficiency with newer
> microarchitectures. The i9's we're talking about are based on Skylake-X
> which is based on Skylake which are the i7-6XXX models in the consumer
> lines. It isn't enough to compare MHz: you need to also consider
> microarchitectures, memory, and workload.
>
> https://arstechnica.com/gadgets/2017/09/intel-core-i9-7960x-review/2/ has
> some single-threaded benchmarks. The i7-7700K (Kaby Lake) seems to "win"
> for single-threaded performance. But the i9's aren't far behind. Not far
> enough behind to cancel out the benefits of the extra cores IMO.
>
> This is because the i9's are pretty aggressive about using turbo. More
> aggressive than the Xeons. As long as cooling can keep up, the top-end GHz
> is great and you aren't sacrificing that much perf to have more cores on
> die. You can counter by arguing that the consumer-grade i7's can yield more
> speedups via overclocking. But for enterprise uses, having this all built
> into the chip so it "just works" without voiding warranty is a nice trait :)
>
> FWIW, the choice to go with Xeons always bothered me because we had to make
> an explicit clock vs core trade-off. Building Firefox requires both many
> cores for compiling and fast cores for linking. Since the i9's turbo so
> well, we get the best of both worlds. And at a much lower price. Aside from
> the loss of ECC, it is a pretty easy decision to switch.
>
>
>> -Nico
>>
>> [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1412240 Build failure in
>> libavutil (missing atomic definitions), when building with clang and icecc
>>
>> [1] https://ark.intel.com/products/series/123588/Intel-Core-X-
>> series-Processors
>>
>> On 10/27/17 7:50 PM, Robert O'Callahan wrote:
>>
>>> BTW can someone forward this entire thread to their friends at AMD so AMD
>>> will fix their CPUs to run rr? They're tantalizingly close :-/.
>>>
>>> Rob
>>>
>>
>> ___
>> 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: verifying unpacked signed add-ons

[Andrew McKay]

> WebExtensions are never meant to be installed unpacked except during
> development. It's currently possible for some side-load methods to install
> them unpacked in production, but that's not supported. System add-ons are
> never installed unpacked in production builds.

We don't have any telemetry on the packed state of an extension, so we
don't know how widespread the use of unpacked extensions is. We might
want to collect first if there's a plan to disable that.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: verifying unpacked signed add-ons

[Kris Maglione]

On Fri, Nov 03, 2017 at 03:25:39PM -0700, David Keeler wrote:

[firefox-dev, dev-addons, and the enterprise mailing list cc'd - please
direct follow-up discussion to dev-platform]

Hello All,

As you're no doubt aware, from 57 onwards, only signed WebExtensions
will be available as add-ons for the general release population. My
understanding is these are all packaged as "xpi" files (zip files,
really, but what's important is that they're bundled up as a single file
rather than a directory). Add-on developers can develop their add-ons by
temporarily loading them as unsigned packages or unsigned unbundled
directories (again, if my understanding is correct).

This leaves the question of what use we have for verifying unbundled
add-ons. Is there ever a case where we want to verify an unbundled yet
signed add-on? For example, do we ever do this with system add-ons? (And
if we do, I've been told this would be bad for performance, so perhaps
we should disallow this?)


WebExtensions are never meant to be installed unpacked except during 
development. It's currently possible for some side-load methods to 
install them unpacked in production, but that's not supported. System 
add-ons are never installed unpacked in production builds.


So I'm fine with removing signature verification for unpacked add-ons as 
long as we make sure we never enable them when signatures are required.

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

Re: verifying unpacked signed add-ons

[Robert Helmer]

On Fri, Nov 3, 2017 at 3:43 PM, David Keeler  wrote:
> On 11/03/2017 03:34 PM, Robert Helmer wrote:
>> On Fri, Nov 3, 2017 at 3:25 PM, David Keeler  wrote:
>>> [firefox-dev, dev-addons, and the enterprise mailing list cc'd - please
>>> direct follow-up discussion to dev-platform]
>>>
>>> Hello All,
>>>
>>> As you're no doubt aware, from 57 onwards, only signed WebExtensions
>>> will be available as add-ons for the general release population. My
>>> understanding is these are all packaged as "xpi" files (zip files,
>>> really, but what's important is that they're bundled up as a single file
>>> rather than a directory). Add-on developers can develop their add-ons by
>>> temporarily loading them as unsigned packages or unsigned unbundled
>>> directories (again, if my understanding is correct).
>>>
>>> This leaves the question of what use we have for verifying unbundled
>>> add-ons. Is there ever a case where we want to verify an unbundled yet
>>> signed add-on? For example, do we ever do this with system add-ons? (And
>>> if we do, I've been told this would be bad for performance, so perhaps
>>> we should disallow this?)
>>
>>
>> System add-on updates must be packed into a XPI[1]. Built-in add-ons are 
>> always
>> shipped packed (along with Firefox in the application directory), but
>> unpacked will
>> work for builds so you can modify a file in ./browser/extensions/ and
>> see the change
>> without a rebuild.
>
> I imagine those directories are unsigned when you're doing that work,
> though, right?


Yes.


>> We plan to move built-in add-ons into the omni jar eventually (bug 1357205)
>>
>>
>>>
>>> Thanks,
>>> David
>>>
>>>
>>> ___
>>> firefox-dev mailing list
>>> firefox-...@mozilla.org
>>> https://mail.mozilla.org/listinfo/firefox-dev
>>>
>>
>> 1 - 
>> http://searchfox.org/mozilla-central/rev/af86a58b157fbed26b0e86fcd81f1b421e80e60a/toolkit/mozapps/extensions/internal/XPIProvider.jsm#6561
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: verifying unpacked signed add-ons

[David Keeler]

On 11/03/2017 03:34 PM, Robert Helmer wrote:
> On Fri, Nov 3, 2017 at 3:25 PM, David Keeler  wrote:
>> [firefox-dev, dev-addons, and the enterprise mailing list cc'd - please
>> direct follow-up discussion to dev-platform]
>>
>> Hello All,
>>
>> As you're no doubt aware, from 57 onwards, only signed WebExtensions
>> will be available as add-ons for the general release population. My
>> understanding is these are all packaged as "xpi" files (zip files,
>> really, but what's important is that they're bundled up as a single file
>> rather than a directory). Add-on developers can develop their add-ons by
>> temporarily loading them as unsigned packages or unsigned unbundled
>> directories (again, if my understanding is correct).
>>
>> This leaves the question of what use we have for verifying unbundled
>> add-ons. Is there ever a case where we want to verify an unbundled yet
>> signed add-on? For example, do we ever do this with system add-ons? (And
>> if we do, I've been told this would be bad for performance, so perhaps
>> we should disallow this?)
> 
> 
> System add-on updates must be packed into a XPI[1]. Built-in add-ons are 
> always
> shipped packed (along with Firefox in the application directory), but
> unpacked will
> work for builds so you can modify a file in ./browser/extensions/ and
> see the change
> without a rebuild.

I imagine those directories are unsigned when you're doing that work,
though, right?

> We plan to move built-in add-ons into the omni jar eventually (bug 1357205)
> 
> 
>>
>> Thanks,
>> David
>>
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
> 
> 1 - 
> http://searchfox.org/mozilla-central/rev/af86a58b157fbed26b0e86fcd81f1b421e80e60a/toolkit/mozapps/extensions/internal/XPIProvider.jsm#6561
> 



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: verifying unpacked signed add-ons

[Robert Helmer]

On Fri, Nov 3, 2017 at 3:25 PM, David Keeler  wrote:
> [firefox-dev, dev-addons, and the enterprise mailing list cc'd - please
> direct follow-up discussion to dev-platform]
>
> Hello All,
>
> As you're no doubt aware, from 57 onwards, only signed WebExtensions
> will be available as add-ons for the general release population. My
> understanding is these are all packaged as "xpi" files (zip files,
> really, but what's important is that they're bundled up as a single file
> rather than a directory). Add-on developers can develop their add-ons by
> temporarily loading them as unsigned packages or unsigned unbundled
> directories (again, if my understanding is correct).
>
> This leaves the question of what use we have for verifying unbundled
> add-ons. Is there ever a case where we want to verify an unbundled yet
> signed add-on? For example, do we ever do this with system add-ons? (And
> if we do, I've been told this would be bad for performance, so perhaps
> we should disallow this?)


System add-on updates must be packed into a XPI[1]. Built-in add-ons are always
shipped packed (along with Firefox in the application directory), but
unpacked will
work for builds so you can modify a file in ./browser/extensions/ and
see the change
without a rebuild.

We plan to move built-in add-ons into the omni jar eventually (bug 1357205)


>
> Thanks,
> David
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>

1 - 
http://searchfox.org/mozilla-central/rev/af86a58b157fbed26b0e86fcd81f1b421e80e60a/toolkit/mozapps/extensions/internal/XPIProvider.jsm#6561
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

verifying unpacked signed add-ons

[David Keeler]

[firefox-dev, dev-addons, and the enterprise mailing list cc'd - please
direct follow-up discussion to dev-platform]

Hello All,

As you're no doubt aware, from 57 onwards, only signed WebExtensions
will be available as add-ons for the general release population. My
understanding is these are all packaged as "xpi" files (zip files,
really, but what's important is that they're bundled up as a single file
rather than a directory). Add-on developers can develop their add-ons by
temporarily loading them as unsigned packages or unsigned unbundled
directories (again, if my understanding is correct).

This leaves the question of what use we have for verifying unbundled
add-ons. Is there ever a case where we want to verify an unbundled yet
signed add-on? For example, do we ever do this with system add-ons? (And
if we do, I've been told this would be bad for performance, so perhaps
we should disallow this?)

Thanks,
David



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Any intent to implement the W3C generic sensor API in Firefox?

[Boris Zbarsky]

On 11/3/17 5:00 PM, Stefan Höhn wrote:

I didn't intent to start any offensive questioning


Stefan,

I wasn't attacking you; I'm sorry it came across that way...


Having said, is there an official way in Firefox to use the Magnetometer?


Not yet.

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

Re: Any intent to implement the W3C generic sensor API in Firefox?

[Stefan Höhn]

Boris,

I didn't intent to start any offensive questioning nor did I intend to be 
unprecise or favor Chrome in any way. (I am actually using FF more than Chrome 
myself).

And I was not aware of what you found out. In my own post at SO I did mention 
that you need to enable it and that is only possible with the dev chrome 
version (which I meant when I said "early" version).

Sorry if I over-simplified "spec" vs. "working draft".

Indeed, in the post you mentioned this experiment is targeted for 63-65 and it 
is open if they stay with it which I hope they do.

Having said, is there an official way in Firefox to use the Magnetometer?

cheers
Stefan

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

TypeError: %d format: a number is required, not float when building Firefox 52.4.1esr in Linux from Scratch

[Gunner Hooper]

I'm trying to building Firefox 52.4.1esr on my Linux from Scratch 
system. The system I'm building on has 2 1GHz Pentium III processors and 
1GB of RAM. I was unable to build the latest version of Firefox because 
I can't run Rust on that system. Version 52.4.1esr was the latest 
version I found that could work on a Pentium III. After building Firefox 
for a little bit, I get the following error, which I suspect is Python 
related:


props2arrays.py main unixcharset.properties.h 
.deps/unixcharset.properties.h.pp 
/root/sources/firefox-52.4.1esr/intl/locale/unix/unixcharset.properties

Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File 
"/root/sources/firefox-52.4.1esr/python/mozbuild/mozbuild/action/file_generate.py", 
line 108, in 

sys.exit(main(sys.argv[1:]))
File 
"/root/sources/firefox-52.4.1esr/python/mozbuild/mozbuild/action/file_generate.py", 
line 63, in main

ret = module.__dict__[method](output, *args.additional_arguments)
File 
"/root/sources/firefox-52.4.1esr/toolkit/components/telemetry/gen-event-data.py", 
line 125, in main

write_common_event_table(events, output, string_table, extra_table)
File 
"/root/sources/firefox-52.4.1esr/toolkit/components/telemetry/gen-event-data.py", 
line 82, in write_common_event_table

e.dataset),
TypeError: %d format: a number is required, not float
make[5]: Leaving directory 
'/root/sources/firefox-52.4.1esr/firefox-build-dir/intl/locale/unix'

make[5]: *** [backend.mk:9: TelemetryEventData.h] Error 1
make[5]: *** Deleting file 'TelemetryEventData.h'
make[5]: Leaving directory 
'/root/sources/firefox-52.4.1esr/firefox-build-dir/toolkit/components/telemetry'
make[4]: *** [/root/sources/firefox-52.4.1esr/config/recurse.mk:79: 
toolkit/components/telemetry/export] Error 2
make[4]: Leaving directory 
'/root/sources/firefox-52.4.1esr/firefox-build-dir'
make[3]: *** [/root/sources/firefox-52.4.1esr/config/recurse.mk:33: 
export] Error 2
make[3]: Leaving directory 
'/root/sources/firefox-52.4.1esr/firefox-build-dir'
make[2]: *** [/root/sources/firefox-52.4.1esr/config/rules.mk:523: 
default] Error 2
make[2]: Leaving directory 
'/root/sources/firefox-52.4.1esr/firefox-build-dir'
make[1]: *** [/root/sources/firefox-52.4.1esr/client.mk:415: realbuild] 
Error 2

make[1]: Leaving directory '/root/sources/firefox-52.4.1esr'
make: *** [client.mk:170: build] Error 2

I have installed all the recommended dependencies from the Beyond Linux 
from Scratch book and installed OpenSSL 1.1.0f before Python 2.7.14. I'm 
using GCC 7.2.0 and added -O2 to the enable optimize option as I heard 
optimization was broken in the latest GCC. I'm currently using Linux 
from Scratch 20170924-systemd.


A solution for this problem is much appreciated.

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

“approval required” for changes affecting CI infrastructure

[Chris AtLee]

To ensure a successful Firefox 57 release, teams responsible for Firefox CI
& release infrastructure have adopted an “approval required” policy for
changes that could impact Firefox development or release. This includes
systems like buildbot, Taskcluster services, puppet, hg, product delivery,
and in-tree changes that could impact task scheduling.

If you have a change you’d like to land that impacts one of the above
systems, or you think could impact the infrastructure, please let the
firefox-ci@ list know. Most changes are fine to land, we just want to be
aware of what’s changing in the overall system in the leadup to 57.

If you don’t hear a response back in 24h, you can assume that your proposal
is fine, and proceed to land it.

Thanks in advance,
Chris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Upcoming C++ standards meeting in Albuquerque, New Mexico

[Botond Ballo]

Hi everyone!

The next meeting of the C++ Standards Committee will be November 6-11
in Albuquerque, New Mexico.

The focus of this meeting will be features targeting C++20 and
Technical Specifications (TS). I expect significant emphasis will be
placed on the Modules TS, whose Proposed Draft [1] has been published
earlier this year, and which has garnered a wide range of feedback
that the Committee will now address. Other exciting areas to watch
include Concepts, which has been merged into C++20 with some
modifications (compared to the TS published in 2015) [2] motivated by
implementation and use experience, and for which more potential
modifications have been proposed; Reflection, for which an initial set
of facilities [3] is headed towards a TS while more ambitious features
are being proposed [4]; and the standard library, for which a
"refresh" / v2 is being contemplated, with the Ranges TS [5] as a
possible starting point.

If you're curious about the state of C++ standardization, I encourage
you to check out my blog posts where I summarize each meeting in
detail (most recent one here [6]), and the list of proposals being
considered by the committee (new ones since the last meeting can be
found here [7] and here [8]).

I will be attending this meeting, hanging out in the Evolution Working
Group (where new language features are discussed at the design level)
as usual. As always, if there's anything you'd like me to find out for
you at the meeting, or any feedback you'd like me to communicate,
please let me know!

Finally, I encourage you to reach out to me if you're thinking of
submitting a proposal to the committee. I'm always happy to help with
formulating and, if necessary, presenting a proposal.

Cheers,
Botond


[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4689.pdf
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0734r0.pdf
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0194r4.html
[4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r2.pdf
[5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4671.pdf
[6] 
https://botondballo.wordpress.com/2017/08/02/trip-report-c-standards-meeting-in-toronto-july-2017/
[7] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/#mailing2017-07
[8] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/#mailing2017-10
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: (hyperlink auditing)

[Anne van Kesteren]

On Tue, Oct 17, 2017 at 11:00 PM, James Graham  wrote:
> Are there cross-browser (i.e. wpt) tests for this feature?

Not that I know of, html/semantics/links/downloading-resources/ is
still empty. I added a comment to our bug.


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