Re: Builds docs on MDN

On Tue, Jun 20, 2017 at 12:40 PM, Ehsan Akhgari wrote: > On 06/20/2017 11:21 AM, Benjamin Smedberg wrote: > >> Coming in late to this thread, but I'd like to strongly support moving >> our Mozilla internals documentation in the tree. >> > It seems that the rest o

Re: MozillaBuild 3.0 Release Candidate

d via the --with-visual-studio-version option, however. > > -Ryan > > On Tue, Jun 20, 2017 at 11:47 AM, Benjamin Smedberg > wrote: > >> >> >> On Tue, Jun 20, 2017 at 11:35 AM, Ryan VanderMeulen < >> rvandermeu...@mozilla.com> wrote: >> >>>

Re: MozillaBuild 3.0 Release Candidate

On Tue, Jun 20, 2017 at 11:35 AM, Ryan VanderMeulen < rvandermeu...@mozilla.com> wrote: > After a lot of local testing and help from others, I think MozillaBuild > 3.0 is ready to be considered a release candidate. If I don't hear of any > late-breaking blockers, I intend to get this signed and re

Re: Builds docs on MDN

Coming in late to this thread, but I'd like to strongly support moving our Mozilla internals documentation in the tree. The fundamental problem with our current doc situation is not that contributing is too hard: the fundamental problem is that our docs are wrong more often than they are right, an

Re: Optimizing what runs on which push

On Wed, May 31, 2017 at 11:08 AM, Dustin Mitchell wrote: > > > So the proposal addresses three issues: > - frustrating and ineffective try user interface > - high load and consequent long wait times > - elevated backout rate > Let me try and repeat back the assumptions/assertions I've heard,

Re: Optimizing what runs on which push

I don't know if I'm the typical use-case, but the big problem for me is that when I change something such as plugins, the jobs as currently bucketed don't help much. There are reftests, crashtests, mochitest-plain, and mochitest-browser-chrome which test plugin code paths, and the splitting means t

Re: Optimizing what runs on which push

Dustin, I am very interested in following up on this. I believe that our current strategy of running every almost every test on every checkin is unsustainable long-term, and we're going to have to move to a model where expensive tests typically are run less frequently. In order to make this success

Re: Is mach show-log supposed to show test logs?

ok, I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1338240 --BDS On Wed, Feb 8, 2017 at 5:09 PM, Mike Hommey wrote: > On Wed, Feb 08, 2017 at 10:51:03AM -0500, Benjamin Smedberg wrote: > > I'm a bit confused about mach show-log and what it's supposed to cont

Is mach show-log supposed to show test logs?

I'm a bit confused about mach show-log and what it's supposed to contain. If I run a test command, for example: `mach mochitest dom/plugins/test` I see a bunch of output and no clear indication of whether any particular test failed. So then I was going to go back through the log and look for UNEXPE

Re: repository review does not exist

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, 2016, at 05:18, Benjamin Smedberg > wrote: > > > > Windows 10 build machine. Pushing to r

repository review does not exist

Windows 10 build machine. Pushing to review used to work, but I recently re-ran mach bootstrap to get rust and now when I try to push to review I get: benja@JWILLIAMS ~/hg-mozilla $ hg push -r 362376::362389 mozreview abort: repository mozreview does not exist! mozreview shows up as an enabled ex

Re: Build system and Bugzilla

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 :: Build Config > Toolkit :: Build Config > > (The latter 2 aren't really used that often.) > > There are also a handf

Re: Unable to build Firefox 47 on OS X

I think the error message explains itself here. The static function PRTImeToSeconds is defined but not used in this filed, which is triggering a warning which you've turned into an error. Looking at this file, I think this is because you're compiling with --disable-accessibility, which is a non-de

Re: Where should be plugins for Linux ?

On 10/15/2015 1:45 PM, swojskichlo...@wp.pl wrote: Can I ask why binary Firefox not using /usr/lib64/mozilla/plugins ? This is firefox bug ? No, this is intentional. The directory layout of Linux systems varies by OS. So for instance on most debian-based systems, the 64-bit lib go into /

Re: Failed to link single SO with reference to libxul in c++

On 8/26/2015 11:26 PM, Samuel Yang wrote: Do you guys know what is wrong? Or how can I build a single SO with xul references? The symbol is a private (hidden) symbol by design. I don't know exactly why your attempts with VISIBILITY_FLAGS didn't work, but this is really not something that is

Re: Firefox Build Exception: Could not find a suitable make implementation

On 6/17/15 3:45 AM, rac...@gmail.com wrote: Hi, I am trying to setup firefox build following https://developer.mozilla.org/en/docs/Simple_Firefox_build but I am getting exception: Exception: Could not find a suitable make implementation. File "/cygdrive/c/mozilla-central/python/mozbuild/m

Re: When signing for OSX V2 signatures, MainMenu.nib isn't in proper format

On 10/13/2014 1:15 PM, digitalc...@gmail.com wrote: I am building a variant of Firefox, and am trying to sign the code with the new V2 Signature on OSX. I'm able to get everything signed OK except for the following error: bundle format unrecognized, invalid, or unsuitable In subcomponent: (

Re: [pymake] Import challenges

On 7/10/2014 11:10 AM, Kim Gräsman wrote: On Mon, Jul 7, 2014 at 10:24 PM, Kim Gräsman > wrote: It seems to me the way forward is to attack the circular dependencies head-on on a couple of fronts: - command-process-jobs can be split up into independent

Re: Pymake/py3k: lazy vs eager

On 7/2/2014 3:45 PM, Kim Gräsman wrote: Related question: there are differences between the pymake in mozilla-central and the master at http://hg.mozilla.org/users/bsmedberg_mozilla.com/pymake/ on which you based the GitHub repo. That's unfortunate. the mozilla-central version was supposed to

Re: Future of pymake

On 6/30/2014 4:12 AM, Kim Gräsman wrote: For Python 2, is it enough to target the version in the latest MozillaBuild, i.e 2.7.5? Yes. --BDS ___ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds

Re: Future of pymake

On 6/25/2014 6:19 PM, Gregory Szorc wrote: Does this look right? https://github.com/mozilla/pymake Yeah, looks good. Can you make me a committer? --BDS ___ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/de

Re: Future of pymake

- Can I ask questions on this list? Send patches for review? I vote for converting the repo to Git and throwing it up at github.com/mozilla/pymake. Benjamin? That sounds reasonable. I haven't done an hg/git conversion so if you want to do that I'm all for it. Then we can just deal with

Re: Future of pymake

On 6/24/2014 3:39 PM, Kim Gräsman wrote: The message I'm hearing is that you _do_ see a future for pymake, and would rather not rip out a separate project, is that right? "future" is a strong word. Mozilla is unlikely to make future improvements to the project, but it mostly-works now. So to

Re: Future of pymake

On 6/24/2014 2:52 PM, Kim Gräsman wrote: My initial instinct was to contribute Python3 support to pymake, but I got the impression from Gregory that Mozilla's long-term plan is to abandon pymake in favor of the now Windows-friendlier GNU Make 4, and that pymake is gradually becoming less maintai

Re: Configure bug with checking for GCC bug 20297

izbyshev wrote: Is this configure check really relevant now? The fact that it is always successfully passed by any compiler that can somehow compile the conftest.c and that it has not been fixed since its introduction in 2006 probably shows that no. Does anybody have ideas about what should be d

Re: Overhauling MozillaBuild

On 3/12/2014 5:57 PM, Mike Hommey wrote: On Tue, Mar 11, 2014 at 08:02:31AM -0700, Ryan VanderMeulen wrote: As some of you on this list are already aware of, I have recently been toying with the idea of overhauling MozillaBuild. I'm sending this message out to flesh out the plan more and collect

Re: dom/src/events has no Makefile. How are build parameters passed to it?

On 2/3/2014 3:52 PM, Alex wrote: Ah right okay. Is it possible to set CC and CXX in moz.build? Or will that have to be added? Both the short and the long answer to that are probably "don't do that". Could you be more specific about what your actual goal is? Are you trying to add a specific bu