Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)
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
> 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
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
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
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
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
[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?
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?
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
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
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
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)
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