I have been the module owner for the Core :: Build Config module since
2013. I am no longer a Mozilla employee and am effectively dormant in The
Project.
The build system module requires someone who is active in The Project and
has experience with its vast scope and impact.
I am honored to announ
The modern way to detect the Visual Studio install is to run vswhere.exe,
which is distributed with MozillaBuild (
https://hg.mozilla.org/mozilla-build/log/tip/vswhere.exe). NSS's build
system does use vswhere.exe. So I'd like to think things would "just work."
I'm a bit surprised things aren't wor
https://apenwarr.ca/log/20181113
This article has a terrific overview on mtime and other file system wonkiness
and goes into detail on implications for build systems. There’s even discussion
of implications of using file hashes for build system DAGs. As a bonus, it is
also a fairly good overvie
On Wed, Nov 7, 2018 at 5:35 AM Martin Husemann wrote:
> I understand the desire for developers do use the best tool for each job,
> and integrating NodeJS in the regular work flow during development might be
> a good idea.
>
> However, requiring NodeJS for each build (including the official relea
(moving to dev-builds)
Background on our desire to use Node as part of the build can be found at
https://groups.google.com/d/msg/mozilla.dev.builds/kuo6WycEcFk/jrdYydhHAQAJ
and
https://groups.google.com/d/msg/mozilla.dev.builds/L2Tp2uS1PGE/yiy30e1EAgAJ.
The tl;dr is that not having access to the r
On Fri, Jul 6, 2018 at 3:12 AM, Axel Hecht wrote:
> Nice.
>
> I'm just devoting my Friday productivity to fixing bustages in python 3.7
> compared to 3.6. Which affect code I copied from mozpack.path ;-) [0]
>
> Which leads me to: We should run tests in automation for at least 3.7 and
> 3.6. Not
On Tue, Jul 10, 2018 at 1:29 PM, David Major wrote:
> Bug 1443590 is switching our official Windows builds to use clang-cl
> as the compiler.
>
> Please keep an eye out for regressions and file a blocking bug for
> anything that might be fallout from this change. I'm especially
> interested in he
David Major has demonstrated a knack to tackle toolchain problems in the
build system, notably those involving MSVC, Clang, and debugging. He's
become a go-to person for questions in this domain. Toolchain work
(especially efforts to move to Clang) are a significant area of focus right
now and I t
On Fri, Apr 20, 2018 at 10:24 AM, Nicholas Alexander wrote:
> Colleagues,
>
> I have a patch series that adds an opt-in --enable-node-environment
> configure flag and, when that flag is set, uses Node (via Webpack) to
> generate the Activity Stream content bundle. This patch series does not
> tr
On Fri, Jan 26, 2018 at 1:10 AM, Wolfgang Rosenauer
wrote:
> Hi,
>
> (wondering if this goes through. Somehow I miss another answer sent to
> this list earlier.)
>
> Am 24.01.2018 um 10:26 schrieb Landry Breuil:
> > On Tue, Jan 23, 2018 at 04:50:10PM -0800, Gregory Szorc
On Fri, Nov 10, 2017 at 3:27 PM, Gregory Szorc wrote:
> For reasons outlined at https://bugzilla.mozilla.org/s
> how_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 relea
On Tue, Mar 20, 2018 at 10:44 AM, Gregory Szorc wrote:
> moz.build files have a mechanism for associating metadata with files [1].
> We use the "with Files()" primitive [2] for:
>
> * Associating files with Bugzilla components
> * Defining how files impact certain CI com
moz.build files have a mechanism for associating metadata with files [1].
We use the "with Files()" primitive [2] for:
* Associating files with Bugzilla components
* Defining how files impact certain CI components
In the future, I fully anticipate us wanting to have a primitive that
allows us to
Phabricator has the ability to assign reviews to a group. As a reviewer,
when you "accept" the review (the equivalent of r+ in Phabricator
terminology), you can do so as an individual and/or as a member of a group.
i.e. reviewers can signal their individual sign-off versus a more official
sign-off
On Tue, Jan 23, 2018 at 4:34 PM, Gregory Szorc wrote:
> Speaking as a maintainer of the Firefox build system, we try to be
> conservative about the set of dependencies required to build Firefox from
> source. We recognize that every required dependency is a potential source
> of
Firefox, what are the requirements, desires,
and hardships of downstream packagers and consumers of the Firefox build
system? Keep in mind that mozilla-central right now is Firefox 60. That
will become ESR 60 in May.
Gregory Szorc
g...@mozilla.com
Firefox build system module owner
___
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
On Fri, Nov 17, 2017 at 2:08 PM, Mike Hommey wrote:
> On Fri, Nov 17, 2017 at 01:06:05PM -0800, Gregory Szorc wrote:
> > As I'm working to remove client.mk, I'm encountering quite the
> spiderweb of
> > dependencies between:
> >
> > * mach
> >
As I'm working to remove client.mk, I'm encountering quite the spiderweb of
dependencies between:
* mach
* client.mk
* configure.in and configure
* moz.configure / configure.py
* config.status
* build backend (Makefile.in, etc)
Today, it is possible to bypass our frontends (mach and client.mk) an
plicit binary, use
the PYTHON3 environment variable. From a mozconfig:
ac_add_options PYTHON3=/opt/local/bin/python3.6
Configure's output will print the path and version of any discovered Python
3.5+ binary. You can also look for PYTHON3 in objdir/config.status.
>
> On Mon, Nov 13
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.m
On Mon, Nov 13, 2017 at 5:22 AM, Ted Mielczarek wrote:
> On Sun, Nov 12, 2017, at 12:12 PM, 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.
>
>
> Correct, an
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 mak
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
On Thu, Oct 19, 2017 at 5:37 PM, Andreas Tolfsen wrote:
> Some time ago there was a discussion on dev-builds@ regarding
> the state of our in-tree source code documentation. The main
> focus was that MDN, moving forward, will mainly revolve around web
> platform documentation and would actively
On Thu, Sep 7, 2017 at 5:05 AM, Axel Hecht wrote:
> Am 07.09.17 um 00:45 schrieb Mike Hommey:
>
>> On Thu, Sep 07, 2017 at 12:19:14AM +0200, Axel Hecht wrote:
>>
>>> Am 29.08.17 um 06:16 schrieb Mike Hommey:
>>>
>>>> On Mon, Aug 28, 2017 at 06:1
On Mon, Aug 28, 2017 at 9:16 AM, Axel Hecht wrote:
> Hi,
>
> as some of you probably noticed, I've been hacking around our localized
> builds a bit over the past few weeks.
>
> Context:
>
> For https://bugzilla.mozilla.org/show_bug.cgi?id=1362617, I wonder where
> to put the generation of res/mul
ce
a module passes a tokenize/ast or import threshold, it stays that way.
> 2017-08-16 12:54 GMT-04:00 Gregory Szorc :
>
>> In the past few weeks, a few independent projects have inquired about
>> using Python 3 for Firefox build/development tooling.
>>
>> tl;dr we no
In the past few weeks, a few independent projects have inquired about using
Python 3 for Firefox build/development tooling.
tl;dr we now have bug 1388447 (aliased as "buildpython3") tracking
everything Python 3 related to Firefox development. Please use it.
My thoughts on Python 3 and Firefox fol
On Fri, Aug 4, 2017 at 10:13 AM, wrote:
> On Wednesday, December 14, 2016 at 6:03:34 PM UTC+11, harshit jain wrote:
> > I am a newbie and hope to start contributing to mozilla. So, according
> to instructions on this page https://developer.mozilla.org/
> en-US/docs/Mozilla/Developer_guide/Build_I
uly 21, 2017 at 11:49:44 PM UTC-4, Gregory Szorc wrote:
> > That error shouldn't occur if the repository and your checkout is in a
> good state. Maybe do an `hg pull` and `hg up` and try again. And verify `hg
> status` says no files are missing.
> >
> >
> >
>
That error shouldn't occur if the repository and your checkout is in a good
state. Maybe do an `hg pull` and `hg up` and try again. And verify `hg
status` says no files are missing.
On Fri, Jul 21, 2017 at 6:46 PM, Brian Shreve wrote:
> Thanks for responding. I am doing this on a Surface Pro, Wi
Thanks for all your work on this, Ryan!
So everyone knows, this is hopefully the last major overhaul of
MozillaBuild.
The plan from build system land is to attempt to go "all in" on Windows
Subsystem for Linux (WSL). That's the feature in Windows 10 (and even in
Server additions now) that impleme
On Wed, Jun 21, 2017 at 9:11 PM, ISHIKAWA,chiaki
wrote:
>
> (I am posting a response to Ehsan's message which somehow was garbled and
> he kindly corrected in a personal exchange.)
>
>
> On 2017/06/22 6:10, Ehsan Akhgari wrote:
>
>> Oops, not sure how that happened, sorry about that! But that fo
On Fri, Jun 16, 2017 at 7:40 AM, Boris Zbarsky wrote:
> On 6/16/17 9:33 AM, Ehsan Akhgari wrote:
>
>> I certainly feel like the
>> barrier for filing bugs, creating a patch, figuring out how to use
>> readthedocs infrastructure, getting reviews, etc. isn't really worth it
>>
>
> I believe we shou
s, themes, etc we use. You may
find tools/docs/conf.py and `./mach doc` useful for tinkering. The Sphinx
bits are an underloved feature. So any contributions would be greatly
appreciated. Feel free to flag me for review.
>
>
>
> On Thu, Jun 15, 2017 at 3:41 PM, Gregory Szorc wrote:
MDN is pivoting hard to focus on web docs:
https://blog.mozilla.org/opendesign/future-mdn-focus-web-docs/
MDN will actively start de-emphasizing docs that aren't related to the web.
You can already see this on things like search results:
https://developer.mozilla.org/en-US/search?q=firefox%20build
] sometimes [ ] often [ ] always]
>> * to run all jobs for one or more platforms
>>[ ] never [ ] rarely [ ] sometimes [ ] often [ ] always]
>>
>> Or something like that?
>>
>> 2017-05-30 21:21 GMT-04:00 Mike Hommey :
>> > On Tue, May 30, 2017 at 05:2
On Thu, May 11, 2017 at 10:05 AM, wrote:
> Background:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1359942
>
> As jobs move to taskcluster, we have an improved opportunity to do some
> smarter scheduling of what jobs to run on what sort of push. Of course,
> it's a thorny subject: optimizing
On Fri, May 12, 2017 at 1:47 PM, Nicholas Alexander
wrote:
> On Fri, May 12, 2017 at 1:44 PM, Gregory Szorc wrote:
>
>> There currently exist "Build Config" bug components in both the Core and
>> Firefox products. I think I understand the history of why there are
&g
There currently exist "Build Config" bug components in both the Core and
Firefox products. I think I understand the history of why there are
multiple components. But in 2017, I question the value of having multiple
components. The Firefox component is low traffic and the kinds of bugs it
is trackin
On Fri, Mar 31, 2017 at 11:00 AM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:
>
> We've gotten a number of reports from users lately regarding OOM issues
> with git-cinnabar. Additionally, I've heard anecdotal evidence that
> Mercurial can run into issues on 32-bit these days under certa
Bug 1262241 is pretty high priority for developers, IMO. The way things
work today is that js/src - specifically Interpreter.cpp - is stacked up
behind a very long line of dependencies and its 2+ minute compilation often
becomes a long pole in the compile tier. Unfortunately, there doesn't
appear m
On Wed, Mar 22, 2017 at 4:05 AM, wrote:
> Hi, I got the following error while running bootstrap.py on my system -
>
> Traceback (most recent call last):
> File "bootstrap.py", line 170, in
> sys.exit(main(sys.argv))
> File "bootstrap.py", line 160, in main
> dasboot = cls(choice=opti
http://hg.mozilla.org now HTTP 301s to https://hg.mozilla.org/. Please
report any problems against bug 450645 and/or make noise in #vcs on
irc.mozilla.org.
On Thu, Jan 26, 2017 at 2:17 PM, Gregory Szorc wrote:
> It may be surprising, but hg.mozilla.org is still accepting plain t
Thank you for tracking this down and submitting patches to fix
-Werror=sign-compare problems.
For the record, this thread is a clear example of where the lack of a
compiler warning/error led to a crash. In some contexts, I imagine this
compiler warning could lead to a security vulnerability. And s
On Fri, Jan 27, 2017 at 6:55 AM, ISHIKAWA,chiaki
wrote:
> On 2017/01/10 8:37, Gregory Szorc wrote:
>
>> On Sat, Jan 7, 2017 at 9:31 AM, ISHIKAWA,chiaki > <mailto:ishik...@yk.rim.or.jp>> wrote:
>>
>> Hi,
>>
>> I have used hg (mercurial)
It may be surprising, but hg.mozilla.org is still accepting plain text
connections via http://hg.mozilla.org/ and isn't redirecting them to
https://hg.mozilla.org/.
On February 1 likely around 0800 PST, all requests to http://hg.mozilla.org/
will issue an HTTP 301 Moved Permanently redirect to htt
Ralph Giles has been doing a lot of work to improve everything Rust in the
build system lately. This is a significant area of focus for Mozilla right
now and we can use all the help we can get to ensure that Rust related
changes and improvements are made as efficiently as possible.
So, as of today
On Thu, Dec 15, 2016 at 5:42 PM, Gregory Szorc wrote:
> There is currently a sub-module of the Build Config module governing the
> Fennec build system. The peers are all the Build Config peers plus Nick
> Alexander. I am the current owner.
>
> The sub-module was created to allow
On Sat, Jan 7, 2017 at 9:31 AM, ISHIKAWA,chiaki
wrote:
> Hi,
>
> I have used hg (mercurial) satisfactorily until about a month ago or so.
> Somehow hg diff has become very slow.
> I am using it on two Debian GNU/Linux PC (64-bit).
> It is possible that latest OK kernel update in Debian may have c
There is currently a sub-module of the Build Config module governing the
Fennec build system. The peers are all the Build Config peers plus Nick
Alexander. I am the current owner.
The sub-module was created to allow Fennec's build system to have some
autonomy from the overall build system and to h
I've been assessing new hardware options for Mozilla to issue to
developers. As part of evaluating some dual socket Xeon processors, I found
some unexpected behavior: these processors routinely underclock in Windows
10 unless several cores or are used. Contrast with the behavior of my i7
Skylake pr
Nathan Froyd has been doing a lot of great work at the periphery of the
build system for years, especially around toolchain configuration and
management. Recently, he's been improving our integration with Rust!
I've been trying to cajole Nathan into being a build peer for a while.
After half-jokin
oblems I'll file a bug.
>
> --BDS
>
>> On Mon, Dec 5, 2016 at 11:46 AM, Gregory Szorc wrote:
>> If you run 'hg paths' you'll find there is no "mozreview" path
>> defined. Perhaps you meant "review?"
>>
>> Instructi
If you run 'hg paths' you'll find there is no "mozreview" path
defined. Perhaps you meant "review?"
Instructions for configuring the remote path are at
https://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview/install-mercurial.html#configuring-the-auto-review-repository
> On Dec 5
image comparison, max difference: 32, number of
> differing pixels: 1
>
>
> The images look identical to me, but 1 pixel is supposedly different - I'm
> wondering why the test fails if the max. acceptable diff is 32. Some other
> cases I look into also had "identical"
On Sat, Nov 26, 2016 at 9:31 AM, Ehsan Akhgari
wrote:
> On 2016-11-24 7:04 PM, Nathan Froyd wrote:
> > On Wed, Nov 23, 2016 at 4:31 PM, Mike Hommey wrote:
> >> I know OSX can be bad with I/O, but that seems unusually bad. IIRC gps
> >> found that there's a relatively low limit to the number of f
On Mon, Nov 21, 2016 at 2:06 PM, Ehsan Akhgari
wrote:
> On 2016-11-21 1:08 PM, Gregory Szorc wrote:
> > On Sat, Nov 19, 2016 at 1:32 PM, Ehsan Akhgari > <mailto:ehsan.akhg...@gmail.com>> wrote:
> >
> > On 2016-11-19 4:26 PM, Mike Hommey wrote:
> >
On Sat, Nov 19, 2016 at 1:32 PM, Ehsan Akhgari
wrote:
> On 2016-11-19 4:26 PM, Mike Hommey wrote:
> > On Sat, Nov 19, 2016 at 04:12:22PM -0500, Ehsan Akhgari wrote:
> >> On 2016-11-18 7:22 PM, Gregory Szorc wrote:
> >>> On Fri, Nov 18, 2016 at 3:50 PM, Ehsan Akhga
On Wed, Nov 16, 2016 at 12:25 PM, Gratian Lup wrote:
> On Wednesday, November 16, 2016 at 5:23:58 AM UTC-8, Ted Mielczarek wrote:
> > Gratian,
> >
> > One of my coworkers reminded me of something that might be an option for
> > you--we have scripts that would allow you to provide a Firefox build
On Fri, Nov 18, 2016 at 3:50 PM, Ehsan Akhgari
wrote:
> Here are the moz.build processing times on my machine when I add one
> line to a LOCAL_INCLUDES in one moz.build file:
>
> 0:02.97 Reticulating splines...
> 0:37.16 Finished reading 3131 moz.build files in 23.09s
> 0:37.16 Processed into
If you look at the Perfherder build metrics, there are some things you need
to know about.
As of 950d65906200 (bug 1315041) landing on autoland a few minutes ago,
metrics will now be segmented by execution platform instead of being lumped
into a single bucket. Before, TaskCluster and Buildbot stor
On Fri, Oct 28, 2016 at 3:04 AM, Xidorn Quan wrote:
> On Friday, October 28, 2016 at 1:57:39 PM UTC+11, Bobby Holley wrote:
> > On Thu, Oct 27, 2016 at 7:45 PM, Mike Hommey wrote:
> >
> >
> > On Thu, Oct 27, 2016 at 07:38:27PM -0700, Bobby Holley wrote:
> >
> > > On Thu, Oct 27, 2016 at 7:21 PM,
On Sat, Oct 15, 2016 at 1:28 PM, Jack Bates wrote:
> What do you think about making the mozilla-central/obj-x86_64-pc-
> linux-gnu/dist/bin/libnssutil3.so symlink relative vs. absolute?
> When I follow these instructions [1] to build Firefox, I get the following
> error:
>
> > $ ./mach run
> >
The opt-macosx64, dbg-macosx64, and android-api-15 TaskCluster worker types
have been upgraded from c3, m3, or r3 instances to c4 or m4 instances. The
macosx64 worker types have also been upgraded from 2xlarge to 4xlarge.
If tasks on these worker types become faster for no obvious reason, this is
Bug 1289249 just landed on the autoland repository. It refactors most (but
not all) build related TaskCluster tasks to use `run-task` and `hg
robustcheckout` for managing the version control checkout.
This means:
* All lines in task output will now be prefixed with timestamps, making it
easier to
dy.
>
> I very much agree with the goal of simplifying and streamlining how we run
> tests. I think we do have to keep the above in mind when we go about that
> simplification.
>
>
>> On Thu, Sep 22, 2016 at 3:54 PM, Gregory Szorc wrote:
>> On Thu, Sep 22, 2016 at
On Thu, Sep 22, 2016 at 2:49 PM, Nicholas Alexander
wrote:
>
>
> On Thu, Sep 22, 2016 at 1:20 PM, Gregory Szorc wrote:
>
>> For years it has been a common pattern for local builds and Firefox
>> automation to copy test files to the object directory (or some other
>&
For years it has been a common pattern for local builds and Firefox
automation to copy test files to the object directory (or some other
staging area) and run them from there. This creates several inefficiencies:
* The build system must symlink or copy thousands of test related files
during the bu
If there is local build bustage impacting a reasonably sane/default build
configuration, I'd encourage you or anyone else to make noise in #build
before it goes on for "days." I consider fixing local development
environments on mozilla-central a high priority because it can be a severe
impediment t
On Wed, Aug 17, 2016 at 2:48 AM, Ted Mielczarek wrote:
> On Wed, Aug 17, 2016, at 05:29 AM, Mike Hommey wrote:
> > Partly related, there's another one:
> > - there are optional parts of moz.configure that are completely unknown
> > when they are not included. This can complicate things in some
You may want to file a bug at
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=JavaScript%20Engine
with your experience.
On Wed, Aug 10, 2016 at 6:58 AM, wrote:
> hey, just letting anyone know that all coredumps are gone with this tiny
> patch(aside from not using --enable-optim
On Mon, Aug 8, 2016 at 2:38 PM, Gregory Szorc wrote:
> Bug 1290282 landed on the autoland repo. It transitioned all our Linux
> TaskCluster tasks from c3/m3/r3.2xlarge instances to c4/m4.4xlarge
> instances. This means:
>
> * Builds now have access to 16 vCPUs instead of 8
> *
On Mon, Aug 8, 2016 at 6:06 PM, Ted Mielczarek wrote:
> On Mon, Aug 8, 2016, at 05:38 PM, Gregory Szorc wrote:
>
> * We're using EBS instead of local instance storage
>
>
> Did this turn out to be faster? In all the benchmarks I had previously
> read EBS was way slower
Bug 1290282 landed on the autoland repo. It transitioned all our Linux
TaskCluster tasks from c3/m3/r3.2xlarge instances to c4/m4.4xlarge
instances. This means:
* Builds now have access to 16 vCPUs instead of 8
* Builds are running on Haswell instead of Ivy Bridge and are cycle for
cycle faster
*
On Sat, Aug 6, 2016 at 10:16 PM, ISHIKAWA,chiaki
wrote:
> Thank you for the tips.
>
> More comments inline.
>
> On 2016/08/07 2:52, Gregory Szorc wrote:
>
>> On Fri, Aug 5, 2016 at 7:36 PM, ISHIKAWA,chiaki > <mailto:ishik...@yk.rim.or.jp>> wrote:
>>
>
On Fri, Aug 5, 2016 at 7:36 PM, ISHIKAWA,chiaki
wrote:
> Hi,
>
> I am patching, compiling and testing C-C TB locally under linux (inside a
> virtualbox).
>
> I have noticed that hg "qpush -a", "hg qpop -a", "hg identity" seems to
> have slow down considerably after I installed |watchman| based on
On Fri, Aug 5, 2016 at 11:21 AM, Ted Mielczarek wrote:
> On Fri, Aug 5, 2016, at 01:33 PM, Gregory Szorc wrote:
>
>
> The overhead of serialization/deserialization + process startup has a
> strong chance of canceling out any perf wins with Python.
> Despite the GIL, P
On Fri, Aug 5, 2016 at 9:52 AM, Boris Zbarsky wrote:
> On 8/5/16 12:20 AM, Gregory Szorc wrote:
>
>> If someone could make WebIDL or IPDL processing faster, that would help
>> people with high core machines, including distributed compilation
>> environments. I believe W
a 64 core
machine.)
> On Aug 4, 2016, at 20:49, Nicholas Nethercote wrote:
>
> Can you buy chips with that many cores, or are these instances
> aggregations of multiple chips?
>
> Nick
>
>> On Fri, Aug 5, 2016 at 9:01 AM, Gregory Szorc wrote:
>> I
> On Aug 4, 2016, at 21:00, Boris Zbarsky wrote:
>
>> On 8/4/16 4:01 PM, Gregory Szorc wrote:
>> * between the "export" and "compile" tiers (WebIDL and IPDL processing
>> delay start of compile tier)
>
> Do we do WebIDL and IPDL stuff in par
I've been playing around with various Amazon EC2 instances lately. They
offer a x1.32xlarge instance that features 128 vCPUs. So I did what any
engineer with access to a corporate AWS account would do: I obtained an
instance and measured how long it took to build Firefox!
$ time ./mach build
...
O
Core :: Build Config
On Thu, Jul 28, 2016 at 10:55 AM, allassopraise .
wrote:
> I'm happy to do that, can you recommend the proper product and
> component to file it under?
>
> On 7/28/16, Gregory Szorc wrote:
> > To my knowledge, no bug has been filed.
> >
>
ersion 3.9.0 on OS X 10.9.4.
>
> I'll file one if needed.
>
> Allasso
>
> On 7/26/16, Gregory Szorc wrote:
> > On Fri, Jul 22, 2016 at 5:29 AM, Paolo Amadini <
> paolo.02@amadzone.org>
> > wrote:
> >
> >> I build mozilla-centra
On Fri, Jul 22, 2016 at 5:29 AM, Paolo Amadini
wrote:
> I build mozilla-central on OS X 10.9.5 with the latest compatible
> version of XCode.
>
> $ clang --version
> Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
> Target: x86_64-apple-darwin13.4.0
> Thread model: posix
>
> A clob
On Mon, Jul 18, 2016 at 6:48 AM, Justin Wood wrote:
> Hey Everyone,
>
> I have recently decided to take ownership of Localization from a
> Release Engineering perspective. Specifically what this means is that
> I'll own most bustages in the process as it relates to our
> infrastructure, as well
> On Jul 11, 2016, at 22:15, Boris Zbarsky wrote:
>
>> On 7/12/16 1:02 AM, Mike Hommey wrote:
>> The envisioned workflow is that you don't rebase on inbound to push,
>> since autoland handles the landing for you. So you can keep your tree as
>> it was before you wanted to land.
>
> OK, what ab
On Mon, Jul 11, 2016 at 6:53 PM, Nicholas Nethercote wrote:
> On Tue, Jul 12, 2016 at 2:27 AM, Jonathan Griffin
> wrote:
> >
> > 2 - people sometimes push to try from bad heads (like a mozilla-inbound
> push
> > that will eventually get backed out)
> >
> > For 2, making sure you push to try only
On Wed, Jun 8, 2016 at 10:22 AM, Benjamin Smedberg
wrote:
>
>
> On Wed, Jun 8, 2016 at 12:04 PM, Gregory Szorc wrote:
>
>> Currently, there are 3 bug components related to the build system in
>> mozilla-central:
>>
>> Core :: Build Config
>> Firefox
Currently, there are 3 bug components related to the build system in
mozilla-central:
Core :: Build Config
Firefox :: Build Config
Toolkit :: Build Config
(The latter 2 aren't really used that often.)
There are also a handful of other pieces of software that have strong
tie-ins to the build syst
Did you use one of the "start-shell-msvc.bat" scripts to launch a
shell? The build targets 32-bit platforms by default. Don't use the -x64
versions of the batch scripts.
Pasting the output of configure somewhere would also help diagnosing. If
you join #build on irc.mozilla.org and ask for help
There is a compiler bug in VS2015 that results in SSE instructions being
emitted when they shouldn't be. Since Firefox still needs to remain
compatible with ancient hardware that doesn't support SSE, this is causing
crashes on Firefox built with VS2015 (see bug 1265615).
The good news is glandium
On Tue, May 3, 2016 at 1:45 PM, Christopher Manchester <
chmanches...@gmail.com> wrote:
> We're moving some things currently defined in various confvars.sh files to
> Python configure (moz.configure), and have reached a point where feedback
> would be helpful, as we are replacing a relatively long
add the missing transition from
system dependencies to build/source config.
>
> On Thu, Apr 07, 2016 at 11:07:37PM -0400, Gregory Szorc wrote:
> > The current reason we separate is to install the minimum set of required
> > dependencies for developing any particular product.
>
The current reason we separate is to install the minimum set of required
dependencies for developing any particular product.
We've always wanted bootstrap to more seamlessly transition into "and
configure VCS, clone the repository, configure the build, and perform the
build" but we haven't execute
On Sat, Feb 27, 2016 at 7:35 PM, wrote:
> Hi,
>
> Today I cloned mozilla repository using this command.
> hg clone https://hg.mozilla.org/mozilla-central
>
> While doing so Kaspersky detected a virus in file
> media/libstagefright/gtest/test_case_1216748.mp4.
>
> Is that a false warning and is it
It is my honor to announce that Chris Manchester is now a Core :: Build
Config module peer!
Please congratulate him and/or send your condolences his way. And please
don't all bombard him with reviews at once.
Congratulations, Chris!
___
dev-builds maili
HTTPS Everywhere loaded this as https://people.mozilla.org/ which made
Firefox block the request to http://activedata.allizom.org/query due to
mixed content. So I see nothing on the site :/
Any chance we can get TLS on the ActiveData connection?
On Wed, Feb 17, 2016 at 4:25 PM, Jonathan Griffin
https://bugzilla.mozilla.org/show_bug.cgi?id=1244835 is tracking restoring
non level 3 and HTTP access.
On Fri, Jan 29, 2016 at 12:22 PM, Allasso Travesser wrote:
> Okay, thanks for the update. Do you have an idea of time? hours? days?
>
>
> On Jan 29, 2016, at 12:50 PM, Gregory
We locked down the server to require level 3 access for the time being. We did
so via file permissions, which is why you see the permissions error. Hopefully
this restriction is dropped soon.
> On Jan 29, 2016, at 11:58, Allasso Travesser wrote:
>
> Possible, before I got that error I was gett
1 - 100 of 160 matches
Mail list logo
