B2G_DEBUG = 0 B2G_NOOPT = 0 MOZ_DMD = 0 REFCNT_LOGGING = 0 ENABLE_PROFILING = 0 GECKO_PATH = /home/mikeh/dev/mozilla/m-c/b2g-inbound GECKO_OBJDIR = /home/mikeh/dev/mozilla/b2g/051_emulator/objdir-gecko-b2g-inbound /home/mikeh/dev/mozilla/b2g/051_emulator/../../m-c/b2g-inbound/python/mach/mach/main.py:246: UserWarning: Module mozprocess was already imported from /home/mikeh/dev/mozilla/b2g/051_emulator/../../m-c/b2g-inbound/testing/mozbase/mozprocess/mozprocess/__init__.pyc, but /usr/local/lib/python2.7/dist-packages/mozprocess-0.11-py2.7.egg is being added to sys.path import pkg_resources /home/mikeh/dev/mozilla/b2g/051_emulator/../../m-c/b2g-inbound/python/mach/mach/main.py:246: UserWarning: Module mozfile was already imported from /home/mikeh/dev/mozilla/b2g/051_emulator/../../m-c/b2g-inbound/testing/mozbase/mozfile/mozfile/__init__.pyc, but /usr/local/lib/python2.7/dist-packages/mozfile-0.9-py2.7.egg is being added to sys.path import pkg_resources From _tests: Kept 12281 existing; Added/updated 0; Removed 0 files and 0 directories. waiting for system-message-listener-ready... ...done MochitestServer : launching [u'/home/mikeh/dev/mozilla/b2g/051_emulator/gaia/xulrunner-sdk-30/xulrunner-sdk/bin/xpcshell', '-g', u'/home/mikeh/dev/mozilla/b2g/051_emulator/gaia/xulrunner-sdk-30/xulrunner-sdk/bin', '-v', '170', '-f', u'/home/mikeh/dev/mozilla/b2g/051_emulator/objdir-gecko-b2g-inbound/_tests/testing/mochitest/httpd.js', '-e', "const _PROFILE_PATH = '/tmp/tmpWP5qnh'; const _SERVER_PORT = '8888'; const _SERVER_ADDR = '10.242.25.9'; const _TEST_PREFIX = undefined; const _DISPLAY_RESULTS = false;", '-f', '/home/mikeh/dev/mozilla/b2g/051_emulator/objdir-gecko-b2g-inbound/_tests/testing/mochitest/server.js'] runtests.py | Server pid: 18885 runtests.py | Websocket server pid: 18887 INFO | runtests.py | expected to find ssltunnel at /home/mikeh/dev/mozilla/b2g/051_emulator/gaia/xulrunner-sdk-30/xulrunner-sdk/bin/ssltunnel Automation Error: Exception caught while running tests Traceback (most recent call last): File "/home/mikeh/dev/mozilla/b2g/051_emulator/objdir-gecko-b2g-inbound/_tests/testing/mochitest/runtestsb2g.py", line 332, in run_remote_mochitests retVal = mochitest.run_tests(options) File "/home/mikeh/dev/mozilla/b2g/051_emulator/objdir-gecko-b2g-inbound/_tests/testing/mochitest/runtestsb2g.py", line 117, in run_tests self.startServers(options, None) File "/home/mikeh/dev/mozilla/b2g/051_emulator/objdir-gecko-b2g-inbound/_tests/testing/mochitest/runtestsb2g.py", line 209, in startServers MochitestUtilsMixin.startServers(self, options, debuggerInfo) File "/home/mikeh/dev/mozilla/b2g/051_emulator/objdir-gecko-b2g-inbound/_tests/testing/mochitest/runtests.py", line 555, in startServers self.sslTunnel.start() File "/home/mikeh/dev/mozilla/b2g/051_emulator/objdir-gecko-b2g-inbound/_tests/testing/mochitest/runtests.py", line 742, in start exit(1) File "/usr/lib/python2.7/site.py", line 375, in __call__ raise SystemExit(code) SystemExit: 1 Stopping web server Stopping web socket server Stopping ssltunnel 12:38:52 ➜ 051_emulator git:(master) ./mach mochitest-remote dom/camera/test/test_bug975472.html STR: 0. git clone ... && cd into folder 1. modify .userconfig to point to external b2g-inbound tree 2. ./config.sh emulator 3. ./build.sh 4. ./mach mochitest-remote dom/camera/test/test_bug975472.html Above output observed.

The default build reads the file from xulrunner-sdk-30/.url, which is in my build: http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/2014/03/2014-03-08-03-02-03-mozilla-central/xulrunner-30.0a1.en-US.linux-x86_64.sdk.tar.bz2 This doesn't include ssltunnel. I think that you can work around this by building gecko for the host platform (i.e., linux) and setting the following variables: USE_LOCAL_XULRUNNER_SDK=1 XULRUNNER_DIRECTORY=<objdir for linux build>/dist (disclaimer, this might need tweaking, my linux distro works for b2g, but won't build firefox at the moment)

Thanks, mt--that works.

So, what I *want* to do here is have the B2G build create a second gecko build. I've finally worked through the build system enough to know that B2G/gonk-misc/Android.mk is where gecko is built for the target platform; so I can add a section to that to build xpcshell and everything else we need. The cost here is the extra compilation time, so I'm tempted to add a way to add something to .config/environment to identify a pre-existing build.

Seriously rough WIP.

More WIP, this time for gaia.

So I've an in progress hack that removes the option to download xulrunner and instead builds it. This is not tested, so YMMV. Downside is that you lose the ability to download xulrunner. It should still let you set XRE_PATH to avoid building it, but that's untested as much as anything else here.

This runs a gecko build for the host platform, producing xulrunner and all the other files. BTW, I tried running this with --disable-webm and --disable-gstreamer to cut times down, but that doesn't work because configure misses the fact that we still actually need libvorbis and fails to add -lvorbis to the linker params. So this currently builds everything. I'm sure that this could be cut down further to save time, but the best way to do that is to set XULRUNNER_DIRECTORY.

This removes the xulrunner download from gaia. I could restore the option to download, but this takes the more aggressive option and removes what is almost dead code.

Moves the XRE directory up to somewhere less obscure, by default. Again, optional.

Stuffed up the last upload.

Comment on attachment 8417511 [details] [diff] [review] 0001-Bug-1002545-Adding-new-xulrunner-build-target.patch Review of attachment 8417511 [details] [diff] [review]: ----------------------------------------------------------------- This makes sense to me, but I'm not the right person to review B2G build system changes. I think :julienw did some work around downloading xulrunner not too long ago. I think either him or :mwu would be good people to ask.

Comment on attachment 8417511 [details] [diff] [review] 0001-Bug-1002545-Adding-new-xulrunner-build-target.patch We can't rely on building xulrunner any more, since the mochitests for b2g rely on having ssltunnel. This adds a target for that purpose. This changes the gonk-misc repo, since it appears that information was lost when creating the patch.

Comment on attachment 8417513 [details] [diff] [review] 0001-Bug-1002545-Configuring-default-XRE_OBJDIR-location.patch This one is for b2g itself.

Comment on attachment 8417639 [details] [diff] [review] 0001-Bug-1002545-Forcing-XRE-build-for-Gaia.patch This is for gaia, which previously downloaded xulrunner. I am particularly interested in feedback regarding whether I should retain the xulrunner download, knowing that it will likely rot on TBPL. In favour of retaining is is the fact that gaia doesn't need ssltunnel to do its business, and a standalone gaia might be better without an explicit dependency on a gecko build.

After a lot of back-and-forth about what the right options are here, :mwu and I decided to try downloading the firefox test package, which includes ssltunnel, rather than having it built from gecko source. This is significantly more bits to download and - as it turns out - a pretty complex patch due to a range of issues that I won't get into right now. I'm leaving the other patches live now, so we can discuss the approach that we want to take, which might be a combination of approaches, or something else entirely. For instance, this patch could be compatible with building gecko, because that could export USE_LOCAL_XULRUNNER_SDK and avoid this whole download process in favour of building.

Comment on attachment 8417639 [details] [diff] [review] 0001-Bug-1002545-Forcing-XRE-build-for-Gaia.patch I'm not the right guy for this. I'm sure Vivien will have a lot of good comments on this.

FTR I think we want that people that only clone Gaia have simple steps to make it work, and I'm not sure these changes are achieving this. Why can't we just reuse USE_LOCAL_XULRUNNER_SDK?

(In reply to Julien Wajsberg [:julienw] from comment #19) > Why can't we just reuse USE_LOCAL_XULRUNNER_SDK? That's the plan. The point is that the steps are easier when you don't have to have a separate install. You config and build and it runs. People with separate installs can use the environment variable to skip a build (or download) step.

Comment on attachment 8417639 [details] [diff] [review] 0001-Bug-1002545-Forcing-XRE-build-for-Gaia.patch this patch will break workflow for gaia developer, previously we can just execute |make| and we will get a profile for b2g, but after your patch we need to download xulrunner manually and it breaks travis-ci (continues integration service for gaia). I suggest using USE_LOCAL_XULRUNNER_SDK in this case and then you don't need to patch gaia. if you still need to patch gaia, please send a pull request to github.com/mozilla-b2g/gaia, travis-ci will run automatically. and you also can execute |make build-test-unit| & |make build-test-integration| to test gaia build system.

(In reply to Martin Thomson [:mt] from comment #20) > (In reply to Julien Wajsberg [:julienw] from comment #19) > > Why can't we just reuse USE_LOCAL_XULRUNNER_SDK? > > That's the plan. The point is that the steps are easier when you don't have > to have a separate install. You config and build and it runs. People with > separate installs can use the environment variable to skip a build (or > download) step. Martin Thomson. All the reviews flags on this bug are a bit confusing. Is your intent to have only the last patch reviewed ? On a side note having to use the firefox test utils seems a short term solution. One of the thing we are going to is instead of downloading xulrunner for the build process, is to download the future 'Mulet' that also include xpcshell (which is the thing we need in xulrunner here). (see bug 943878) Can you add what you want to be packaged into the Mulet as well ?

Comment on attachment 8417511 [details] [diff] [review] 0001-Bug-1002545-Adding-new-xulrunner-build-target.patch R- as building xulrunner is really not a solution for Gaia developers.

Comment on attachment 8417639 [details] [diff] [review] 0001-Bug-1002545-Forcing-XRE-build-for-Gaia.patch Xulrunner is really needed to be able to build Gaia :) I want to keep things simple for Gaia devs.

(In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, needinfo? please) from comment #22) > (In reply to Martin Thomson [:mt] from comment #20) > > (In reply to Julien Wajsberg [:julienw] from comment #19) > > > Why can't we just reuse USE_LOCAL_XULRUNNER_SDK? > > > > That's the plan. The point is that the steps are easier when you don't have > > to have a separate install. You config and build and it runs. People with > > separate installs can use the environment variable to skip a build (or > > download) step. > > Martin Thomson. All the reviews flags on this bug are a bit confusing. Is > your intent to have only the last patch reviewed ? Yes. I've let this drop, since I've been traveling. > On a side note having to use the firefox test utils seems a short term > solution. One of the thing we are going to is instead of downloading > xulrunner for the build process, is to download the future 'Mulet' that also > include xpcshell (which is the thing we need in xulrunner here). (see bug > 943878) > > Can you add what you want to be packaged into the Mulet as well ? The last patch downloads firefox and its tests bundle, which is a few more bytes, but it includes all the necessary prerequisites. I don't know what Mulet is, but if that can include ssltunnel, then that's great.

Mulet is just another build app aimed to replace b2g_desktop. I don't think mulet will *solve* this any more than desktop firefox can. :mt, would it be possible to put the step that either downloads or builds ssltunnel (whatever you end up choosing) in the B2G section of gecko/testing/mochitest/mach_commands.py ? That way we only need to do it when someone runs ./mach mochitest-remote, not when building.

Oh sorry, I skimmed over the part where Vivien said they would download Mulet instead of xulrunner.. Yes, that would indeed solve the problem :p. I don't know if we want to have broken mochitests that long though.

Yes, assuming that Mulet is ready and includes ssltunnel, then this will be a good replacement for what I've done here. Unfortunately, if we're downloading stuff, the only way I've found that gets ssltunnel and xpcshell is what is in the last patch (which I'm going to submit as a PR instead as recommended by :21). It's more bytes to download, but probably a good-enough stop-gap.

OK, here goes, I hope that I got this right. https://github.com/mozilla-b2g/gaia/pull/19480

Oh this is lame: https://travis-ci.org/mozilla-b2g/gaia/jobs/25688172 The new, larger download trips the stderr buffer limit, causing the exec call to fail. I've updated the pull request with a hack that reduces the amount of output wget produces. That should avoid that issue, assuming that travis finds no other problems.

I think we'll need a review from :yurenju too, as he's the one responsible for the build process these days.

Martin, looks you want to use xpchsell/firefox in gaia to run mochitest of emulator, why don't we just use another firefox build by USE_LOCAL_XULRUNNER_SDK or add this feature in emualtor build system? downloading mochitest package in gaia build system is very weird since we don't use them in gaia.

(In reply to Martin Thomson [:mt] from comment #28) > Yes, assuming that Mulet is ready and includes ssltunnel, then this will be > a good replacement for what I've done here. Unfortunately, if we're > downloading stuff, the only way I've found that gets ssltunnel and xpcshell > is what is in the last patch (which I'm going to submit as a PR instead as > recommended by :21). It's more bytes to download, but probably a > good-enough stop-gap. ochameau, how close are we to get nightly build for the Mulet ?

(In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, needinfo? please) from comment #33) > (In reply to Martin Thomson [:mt] from comment #28) > > Yes, assuming that Mulet is ready and includes ssltunnel, then this will be > > a good replacement for what I've done here. Unfortunately, if we're > > downloading stuff, the only way I've found that gets ssltunnel and xpcshell > > is what is in the last patch (which I'm going to submit as a PR instead as > > recommended by :21). It's more bytes to download, but probably a > > good-enough stop-gap. > > ochameau, how close are we to get nightly build for the Mulet ? I discussed that with ochameau directly. Seems like what you want is to fix https://bugzilla.mozilla.org/show_bug.cgi?id=943892 Then on top of that you can do a patch like https://bugzilla.mozilla.org/show_bug.cgi?id=943895 in order to ship ssltunnel. How does it sounds ?

(In reply to Yuren [:yurenju] from comment #32) > Martin, looks you want to use xpchsell/firefox in gaia to run mochitest of > emulator, why don't we just use another firefox build by > USE_LOCAL_XULRUNNER_SDK or add this feature in emualtor build system? > > downloading mochitest package in gaia build system is very weird since we > don't use them in gaia. We don't have anything suitable available when we build gaia. So the only options are: 1. Have someone build their own copy of xpcshell/ssltunnel and reference that manually. 2. Build one. 3. Download one. The first is always possible, but not sufficient for automated systems. I got some pretty strong push back on building a copy, because that adds a lot of time to the build process. Downloading is unpleasant, but the point here is to provide something that will act as a stopgap until Mulet is ready. Not having tests is, in my option at least, bad enough to justify an ugly fix.

Martin, Could you consider the solution on comment 34? I know tests are really important but it's not right to download test package and firefox browser in gaia build system which is never used in gaia (only used for xpcshell part). for automated system you also can write a script to download firefox/test package before building gaia and then use |USE_LOCAL_XULRUNNER_SDK=1 make| to use it.

Comment on attachment 8426184 [details] 0001-Bug-1002545-Downloading-firefox-test-package-instead.PR Cancel review request since I feel we should get better solution like comment 34 or write a automation script outside of gaia.

Martin, if we happen to switch from xpcshell to b2g-desktop via bug 943892, you can easily ensure that ssltunnel is shipped in b2g-desktop tarball by providing a patch similar to attachment 8340065 [details] [diff] [review], but for ssltunnel: diff --git a/b2g/installer/package-manifest.in b/b2g/installer/package-manifest.in index 7818d6d..0a809ab 100644 --- a/b2g/installer/package-manifest.in +++ b/b2g/installer/package-manifest.in @@ -765,6 +765,13 @@ bin/components/@DLL_PREFIX@nkgnomevfs@DLL_SUFFIX@ @BINPATH@/xpcshell #endif #endif +#ifndef MOZ_WIDGET_GONK +#ifdef XP_WIN32 +@BINPATH@/ssltunnel.exe +#else +@BINPATH@/ssltunnel +#endif +#endif @BINPATH@/chrome/icons/ @BINPATH@/chrome/chrome@JAREXT@ @BINPATH@/chrome/chrome.manifest

(In reply to Martin Thomson [:mt] from comment #35) > (In reply to Yuren [:yurenju] from comment #32) > > Martin, looks you want to use xpchsell/firefox in gaia to run mochitest of > > emulator, why don't we just use another firefox build by > > USE_LOCAL_XULRUNNER_SDK or add this feature in emualtor build system? > > > > downloading mochitest package in gaia build system is very weird since we > > don't use them in gaia. > > We don't have anything suitable available when we build gaia. So the only > options are: > > 1. Have someone build their own copy of xpcshell/ssltunnel and reference > that manually. > 2. Build one. > 3. Download one. > > The first is always possible, but not sufficient for automated systems. > > I got some pretty strong push back on building a copy, because that adds a > lot of time to the build process. Downloading is unpleasant, but the point > here is to provide something that will act as a stopgap until Mulet is > ready. Not having tests is, in my option at least, bad enough to justify an > ugly fix. The comment at #c34 mean that you don't need to wait for the Mulet to be ready. There is already nightly build of B2G desktop that embeds xpcshell (look at ftp://ftp.mozilla.org/pub/b2g/nightly/latest-mozilla-central/). You can replace the download of XULRUNNER by that, and also fix package-manifest.in to ship ssltunnel directly in B2G Desktop. This fits better into our longer term plan as b2g desktop is going to be replace by the Mulet, but the core of the Mulet is built based on the packaging files from b2g/. Hope it makes sense.

It sounds like others have more expertise in this area than I. Feel free to do that then.

(In reply to Martin Thomson [:mt] from comment #40) > It sounds like others have more expertise in this area than I. Feel free to > do that then. Martin, the work to download b2g-desktop is pretty close to the work you did to download ff_test. Can you do this part ? Then I can find someone to do the bits to package ssltunnel into b2g-desktop.

It's not that simple. Sadly. I've tried a couple of b2g builds and they don't work. It's not that they don't run, it's that they emit perplexing errors like this: run-js-command gaia/preferences Exception: TypeError: "toString" is read-only @resource://gre/modules/osfile/osfile_unix_allthreads.jsm:89:1 @resource://gre/modules/osfile/osfile_async_front.jsm:44:3 @resource://gre/modules/osfile.jsm:11:3 @file:///Users/martin/code/gaia/build/utils-xpc.js:7:1 @file:///Users/martin/code/gaia/build/utils.js:9:3 @file:///Users/martin/code/gaia/build/preferences.js:4:1 CommonjsRunner.prototype.run@/Users/martin/code/gaia/build/xpcshell-commonjs.js:69:5 run@/Users/martin/code/gaia/build/xpcshell-commonjs.js:84:3 @-e:1:1 System JS : ERROR resource://gre/modules/osfile/osfile_unix_allthreads.jsm:89 - TypeError: "toString" is read-only ``` That's on a mac, so maybe it's OK elsewhere. Macs are odd. I've pushed this code to my branch and see what Travis produces, but I'm not happy with this as is.

OK, I've done what I can here. But that error in Comment 42 is beyond my ability to diagnose. It happens on both mac and linux, and though I have no windows machine on which to check that platform, I'm going to bet that it's an issue there. This didn't happen with Firefox builds, so there's something in the b2g desktop setup that is breaking this. I don't even know where to start to debug this one.

Switching from xpcshell of xulrunner-sdk to b2g desktop one is being tracked in bug 943892, the exception you saw in osfile has already been reported there and a fix should land soon in bug 1014484.

OK, so here's your patch for bug 943892 too. I'll let you work out whether to mark this as a duplicate or not.

(In reply to Martin Thomson [:mt] from comment #42) > It's not that simple. Sadly. > > I've tried a couple of b2g builds and they don't work. It's not that they > don't run, it's that they emit perplexing errors like this: > > run-js-command gaia/preferences > Exception: TypeError: "toString" is read-only > @resource://gre/modules/osfile/osfile_unix_allthreads.jsm:89:1 > @resource://gre/modules/osfile/osfile_async_front.jsm:44:3 > @resource://gre/modules/osfile.jsm:11:3 > @file:///Users/martin/code/gaia/build/utils-xpc.js:7:1 > @file:///Users/martin/code/gaia/build/utils.js:9:3 > @file:///Users/martin/code/gaia/build/preferences.js:4:1 > CommonjsRunner.prototype.run@/Users/martin/code/gaia/build/xpcshell-commonjs. > js:69:5 > run@/Users/martin/code/gaia/build/xpcshell-commonjs.js:84:3 > @-e:1:1 > > System JS : ERROR > resource://gre/modules/osfile/osfile_unix_allthreads.jsm:89 - TypeError: > "toString" is read-only > ``` > > That's on a mac, so maybe it's OK elsewhere. Macs are odd. I've pushed > this code to my branch and see what Travis produces, but I'm not happy with > this as is. David, have you ever heard about this error on osfile ?

Just realized you already answered on https://bugzilla.mozilla.org/show_bug.cgi?id=943892#c4 ...

Comment on attachment 8426184 [details] 0001-Bug-1002545-Downloading-firefox-test-package-instead.PR I guess I don't need to review this anymore.

(In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, needinfo? please) from comment #48) > Comment on attachment 8426184 [details] > 0001-Bug-1002545-Downloading-firefox-test-package-instead.PR > > I guess I don't need to review this anymore. The PR was updated with a b2g desktop download. Though this will block on bug 1014484. I can squash the commits, if that helps.

I tried the workaround in comment 1, but then I get this error: mach: error: --xre-path points to an ARM version of xpcshell; it should instead point to a version that can run on your desktop

I guess I didn't follow the step mentioned in comment 1: "I think that you can work around this by building gecko for the host platform (i.e., linux)" I'm not sure how to do that, though.

(In reply to Martijn Wargers [:mwargers] (QA) from comment #51) > I guess I didn't follow the step mentioned in comment 1: "I think that you > can work around this by building gecko for the host platform (i.e., linux)" > > I'm not sure how to do that, though. It's pretty simple*: # hg clone http://hg.mozilla.org/mozilla-central # cd mozilla-central # ./mach build # export XULRUNNER_DIRECTORY=$PWD/b2g-inbound/obj-x86_64-unknown-linux-gnu/dist Then change to your b2g folder and run the emulator. ----- *for arbitrary values of simple.

Comment on attachment 8426184 [details] 0001-Bug-1002545-Downloading-firefox-test-package-instead.PR Now that we are on the same page and agree on the solution, I feel like Yuren can review the patch. Yuren, let me know if there is any issue.

:mt, could you rebase your pr since it was conflicted by other changes?

Comment on attachment 8426184 [details] 0001-Bug-1002545-Downloading-firefox-test-package-instead.PR we don't need to download test package if 1019117 is landed. please remove that part and make sure travis is green then set review flag to me.

OK, I've rebased and made the changes in preparation for bug 1019117. The problem here is that xpcshell barfs. I could debug this, but I really don't have the time. ``` run-js-command gaia/pre-app [svoperapps.js] PROFILE_DIR, GAIA_DISTRIBUTION_DIR, VARIANT_PATH are all required ************************* A coding exception was thrown in a Promise resolution callback. Full message: TypeError: btoa is not a function See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise Full stack: getFileAsDataURI@resource://gre/modules/commonjs/toolkit/loader.js -> file:///home/martin/code/gaia/build/utils-xpc.js:167:7 setWallpaper@resource://gre/modules/commonjs/toolkit/loader.js -> file:///home/martin/code/gaia/build/settings.js:32:3 execute/result<@resource://gre/modules/commonjs/toolkit/loader.js -> file:///home/martin/code/gaia/build/settings.js:255:5 Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:79:72 this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:72:31 processEvents@resource://gre/modules/commonjs/toolkit/loader.js -> file:///home/martin/code/gaia/build/utils-xpc.js:541:5 execute@resource://gre/modules/commonjs/toolkit/loader.js -> file:///home/martin/code/gaia/build/settings.js:277:3 execute@resource://gre/modules/commonjs/toolkit/loader.js -> file:///home/martin/code/gaia/build/pre-app.js:23:5 CommonjsRunner.prototype.run@/home/martin/code/gaia/build/xpcshell-commonjs.js:69:5 run@/home/martin/code/gaia/build/xpcshell-commonjs.js:84:3 @-e:1:1 ************************* ```

OK, there's a simple explanation for the above: btoa is not exported into the sandbox that newer versions of gecko create when loading. I have a fix, and then we'll see.

Hi :mt, since I can't help on bug 1019117, so please let me know if you need my help on this bug.

Hey :mt, is there anything I can do to help move this along? I'm getting pinged about this on an almost daily basis :)

There are a few concerns that will prevent this from landing - bug 1019117 is ready for landing pending a final check - bug 1029953 is waiting on ryanvm, but I'm not sure if that blocks this landing (maybe you can confirm what is needed there) - I'm still a little worried that this will break gaia C-I again I'm sorry about the delay, this has not been given the priority it deserves. I have re-opened the pull request on gaia and maybe you can review it. But the branch will need to be updated to reference a nightly after bug 1019117 lands on m-c.

I've tried to fix the failures arising from the gaia C-I runs. I have no idea where to even start with these. I think that I've got a handle on the OSX runs, but the test harness failures are baffling. Can you find someone who is likely to know what is going on here? https://tbpl.mozilla.org/?rev=ae6004116150c3c20bcd5eee0052d70b10949452&tree=Gaia-Try https://travis-ci.org/mozilla-b2g/gaia/jobs/29364991#L2776

Gi is permafail on TBPL right now, I've retriggered G to see if it's just an intermittent you're hitting.

Good to know about Gi. That's a pretty bad state to be in. It's not intermittent as far as I can tell. I think that G is failing because 'atob' is not getting propagated through into all the different sandboxed JS contexts. It's probably down to having a newer b2g desktop build (maybe it's e10s) rather than xulrunner. I've tried chasing it down, but I'm lost.

Ah, I think you're running into the same issue as in bug 1035624; xulrunner wasn't updated for Gaia unit tests. I just pushed a fix, but jhford will need to merge it to his repo. I'll needinfo him.

let's wait new xulrunner for G.

New xulrunner is up, can you make a new try run?

It works! Finally. What a giant mess! https://tbpl.mozilla.org/?rev=b8c42db5892d820aeb479193b0c8ec5ca3503e1a&tree=Gaia-Try That code includes a reference to a b2g build that includes ssltunnel.

Comment on attachment 8426184 [details] 0001-Bug-1002545-Downloading-firefox-test-package-instead.PR Feel free to pass this review on to anyone you think might be better suited.

Comment on attachment 8426184 [details] 0001-Bug-1002545-Downloading-firefox-test-package-instead.PR steal review request. :mt, I left comments on github please check it, major concern is we should use b2g_sdk_<VERSION> to avoid painful debuging between branches, see bug 906316. otherwise looks good. it's so great to use b2g to build gaia and we can file follow up bug to use it for integration test then we don't need to download twice. thanks!

Comment on attachment 8426184 [details] 0001-Bug-1002545-Downloading-firefox-test-package-instead.PR This seems good to me, though Makefiles are definitely not my forte (also I'm not a gaia peer). Changing to f+. Please fix Yuren's comments and re-flag him for review. Thanks for sticking through this! :)

Thanks for the comments :yurenju. I added a new commit that I hope addresses your concerns. I decided to do a little cleaning up, particularly with respect to the comments; it should be a lot clearer now. The directory that we download to is now is a little ugly, but I think that it's a cleaner solution than bug 906316 had. It does depend a little on the naming/versioning scheme we use for nightly builds; but I think that's OK. Happy to trim it down or tweak as necessary.

Comment on attachment 8426184 [details] 0001-Bug-1002545-Downloading-firefox-test-package-instead.PR See comment #74.

Comment on attachment 8426184 [details] 0001-Bug-1002545-Downloading-firefox-test-package-instead.PR :mt, thanks for your patch, it works pretty good on Mac and Linux both for gaia building process and switching b2g between different versions. however it does not work on Windows, I did some investigation and have a patch for it, there are two issues: 1. ssl: we always get certification error for msys and try server, so we should use http instead of https 2. XPCSHELLSDK is empty but we can fix that with two lines, so r=yurenju and please apply the patch and push to gecko try server again for Windows before land it thanks, it's awesome!

Thanks :yurenju I was hoping that bug 1029953 and the new version of mozbuild would fix the certificate validation error. And the abspath problem is just my bad. I also noticed an error on Mac related to the bug 1019117 fixup and fixed that up. How do I land this now?

we got some error on try server, one of this issues is makefile rule |jsonlint| need to depend on b2g_sdk not $(XULRUNNER_BASE_DIRECTORY). I'm investigating other issues.

rebased to master and push to try again. https://tbpl.mozilla.org/?rev=92994eaadcfbea4dd012488fefcb08b636e75fef&tree=Gaia-Try

Thanks for doing that :yurenju, I'm @ietf this week, so not really able to dedicate any real time to this. (The dependency error was on me, a lazy rebase.)

With the new release of MozBuild including bug 1029953, the wget issue on Windows should go away. I've rebased (again) and we'll see how the integration tests work out.

seems gaia build bot does not work now?

gaia build test is passed on my local linux box.

recent gaia try https://tbpl.mozilla.org/?rev=93637d23ee52264482b5ef7d16bca8eea9351bd6&tree=Gaia-Try

Might need a different b2g build there. There's a hard crash in there, for which I can't find a bugzilla entry. I updated to the latest. And I finally found what was going on with Gij. The marionette runner doesn't die when it can't find xpcshell. Worse, it tries to find xpcshell on its own. :yurenju, can you check the last commit in the PR?

"Build Integration tests make app with custom origin" passes on my machine, don't know what the concern is. https://tbpl.mozilla.org/?rev=5feed64320efc93513d2892fc60b2a823f1ae2f2&tree=Gaia-Try

I have a loaner machine for build server, let's try to reproduce on it.

finally, I can reproduce it \o/

builg log, reason is b2g crashed.

It seems to be related to additional-extensions and Downloads.jsm (via download-manager). 1/ I'm not sure there is a value in installing the additional addons on automation. 2/ I would imagine the crash happens within Downloads.jsm (which is a pretty big/complex piece of code). At some point I tried to replace Downloads.jsm usage with saveURI - https://developer.mozilla.org/en-US/Add-ons/Code_snippets/Downloading_Files (which is very old/simple/robust)

looks like the same problem as bug 1022196, patch is coming.

Hi Alex, welcome back :-) this problem only happend on try server, so I would like to use the same solution on bug 1022196, and we should file another bug for using robust way to download file.

(In reply to Yuren [:yurenju] from comment #93) > Hi Alex, > > welcome back :-) Thanks! > > this problem only happend on try server, so I would like to use the same > solution on bug 1022196, Instead of hacking json files like that, I would have tuned additional-extensions to be configurable (disabled?) via an env variable of something. (Note that SIMULATOR=1 already disable it) > and we should file another bug for using robust way > to download file. Sounds good. I just wanted to share my suspicion about Downloads.jsm.

bug 1050173 filed.

since it's really close to land, I squash the commits and send a new pull request, I'll send an email to dev-gaia for this change. https://github.com/mozilla-b2g/gaia/pull/22765 https://tbpl.mozilla.org/?rev=d077d9c1d9f5f91bf94976680fccc666ef45df72&tree=Gaia-Try

:mt, could you push to gecko try server again for Windows? I got an error "sandboxbroker.dll not found" on Windows but I'm not sure if this only happend on my box.

I rebased and took the latest b2g build. Which target are you running to get the error? https://tbpl.mozilla.org/?rev=454b2a583d5c64fbb5da591d213a0d01eef57c7c&tree=Gaia-Try

(In reply to Yuren [:yurenju] from comment #99) > :mt, could you push to gecko try server again for Windows? > > I got an error "sandboxbroker.dll not found" on Windows but I'm not sure if > this only happend on my box. Should be fixed after a rebase. This is due to a packaging error that I fixed in bug 1045533.

I got another error when building on Windows 7 in my box. :jryans, do you have any idea for this?

(In reply to Yuren [:yurenju] from comment #102) > Created attachment 8472030 [details] > build.log > > I got another error when building on Windows 7 in my box. > > :jryans, do you have any idea for this? The build script in the PR is set to download the 2014-07-31-04-02-03 build, but the fix in bug 1045533 also landed on 2014-07-31, so your build is too old. It works here if you set it to the latest build date.

I used the latest available this morning: 2014-08-12-04-02-01 Does that fix the issue?

I will try it later, and :mt, could you pick this commit to your pull request and squash to one commit? it can fix the previous build error on try server. https://github.com/yurenju/gaia/commit/02427d69535533b521b3beb12c9f0883305e1964

although I got that error message on Windows, but I extract all zip files in profile directory and compare them and all files are same as before. :mt, please squash to one commit then we can land it :D

:jryans, I believe the issue mentioned on comment 102 is still worth to trace, since I'm not familiar with b2g-desktop, could you help to file a bug for it?

(In reply to Yuren [:yurenju] from comment #107) > :jryans, > > I believe the issue mentioned on comment 102 is still worth to trace, since > I'm not familiar with b2g-desktop, could you help to file a bug for it? This looks more like a crash and less like a dll issue jryans fixed. We would have to look into pre-app build script to see where/why it crashes. (xpcshell shipped with b2g is most likely different, I imagine it is built with b2g flags, like MOZ_B2G [and others]...)

(In reply to Yuren [:yurenju] from comment #107) > :jryans, > > I believe the issue mentioned on comment 102 is still worth to trace, since > I'm not familiar with b2g-desktop, could you help to file a bug for it? I am confused, are you still seeing issues? After I change the SDK build date as I mentioned above, this PR works for me on Windows.

(In reply to J. Ryan Stinnett [:jryans] from comment #109) > (In reply to Yuren [:yurenju] from comment #107) > > :jryans, > > > > I believe the issue mentioned on comment 102 is still worth to trace, since > > I'm not familiar with b2g-desktop, could you help to file a bug for it? > > I am confused, are you still seeing issues? After I change the SDK build > date as I mentioned above, this PR works for me on Windows. Yes, there is still an issue, but as said before, it has nothing to do with what you fixed. This is something you can't really help us look into, unless you wish to start looking into gaia build system guts :p run-js-command gaia/pre-app [svoperapps.js] PROFILE_DIR, GAIA_DISTRIBUTION_DIR, VARIANT_PATH are all required 2014-08-13 10:23:35: stackwalker.cc:125: INFO: Couldn't load symbols for: ntdll.pdb|CD4062A231154A17A18DAE7D1A0FBACC2 2014-08-13 10:23:35: stackwalker.cc:125: INFO: Couldn't load symbols for: xul.pdb|841793F31A494BD1A2725D6F64C515541 This is the crash reported that fails to fetch symbols. Gaia build system makes xpcshell crash during pre-app command. But as it seems to still be able to compute the profile, it is most likely a crash during shutdown.

(In reply to Alexandre Poirot [:ochameau] from comment #110) > (In reply to J. Ryan Stinnett [:jryans] from comment #109) > > (In reply to Yuren [:yurenju] from comment #107) > > > :jryans, > > > > > > I believe the issue mentioned on comment 102 is still worth to trace, since > > > I'm not familiar with b2g-desktop, could you help to file a bug for it? > > > > I am confused, are you still seeing issues? After I change the SDK build > > date as I mentioned above, this PR works for me on Windows. > > Yes, there is still an issue, but as said before, it has nothing to do with > what you fixed. > This is something you can't really help us look into, unless you wish to > start looking into gaia build system guts :p Ah, fair enough. I thought I wasn't seeing this anymore either, but I guess it's there. At least the build finishes now! ;) As you've guessed, I don't have any other advice on this issue.

Rebased to master and squashed. Should be good to land, assuming that the cited problems aren't fatal.

Oops, missed the extra commit. Let me try that again.

OK, that was unpleasant. A pull request would have been easier to deal with. I've pushed the squashed branch, and just to avoid any unpleasantness of the sort that happened earlier this week, reviewed :yurenju's proposed changes. They are OK. :yurenju, let's wait for the try runs to clear just to be certain, but it's landing time.

Hi :mt, I think your pull request does not up to date since I compare our branch and looks my branch is newer than you after your branch was squashed. > git fetch upstream > git fetch upstream pull/19480/head:pull/19480 > git fetch upstream pull/22765/head:pull/22765 > git rebase upstream/master pull/19480 > git rebase upstream/master pull/22765 > git diff pull/19480..pull/22765 so I would like to land pull request 22867, it includes all changes which we discussed and reviewed. I will also verify it on Windows, Linux and Mac before landing. https://github.com/mozilla-b2g/gaia/pull/22867 https://tbpl.mozilla.org/?rev=98bddde1f837de4b8be7e98d64fe41088d09e608&tree=Gaia-Try

If the Gij failure there doesn't bother you, that's OK with me. #22867 looks OK.

okay let's land it, cross fingers. merged https://github.com/mozilla-b2g/gaia/commit/5f51ff804b815033cd71e750c52cf19fd3950f29

Reverted again for broken Windows builds. Master: https://github.com/mozilla-b2g/gaia/commit/203aca9ab0af253841957409c447e08b8b611f1e https://tbpl.mozilla.org/php/getParsedLog.php?id=45998570&tree=B2g-Inbound

:RyanVM, it looks like a certification issue which mentioned on comment 76 and it should be fixed on Bug 1029953, could you check if this build machine have the patch from Bug 1029953?

I asked in the #releng IRC channel - the Windows build slaves are running GNU Wget 1.10.2. You'll almost certainly need to file a Release Engineering bug to get wget updated to something newer on the Windows slaves. Bug 1029953 only affects people's local build environments.

thanks, RyanVM, I filed bug 1054812 for this.

to unlock this situation, I will use http in this bug and file another bug to change protocol from http to https and then set bug 1054812 to depend on the new bug.

bug 1055397 is filed, change dependency.

pull request for downloading b2g-desktop from HTTP https://github.com/mozilla-b2g/gaia/pull/23018 try for Windows: https://tbpl.mozilla.org/?tree=Try&rev=81e991ed1160 gaia try server: https://tbpl.mozilla.org/?rev=e64b3803fb3111b51af194b87dd25fdcf7275b30&tree=Gaia-Try

rebase to last master, I don't have enough time to help on it. https://tbpl.mozilla.org/?rev=ae1ee3bb86e2fd2994007a126fd7777c7ce3a70c&tree=Gaia-Try

I'm working for adding a lot of log to find out root cause for build failure.

I assume that the 'keyboard != u'keyboard' error is known. It looks like the call here: helper.exec('PRODUCTION=1 make', function(error, stdout, stderr) { Is terminating early, leaving the profile unbuilt. Do we need to alter the way that we are invoking make here? The line you have might work if you had 'sh -c "PRODUCTION=1 make"' instead, or maybe even child_process.exec(make, env: { PRODUCTION: '1' }, callback), but I'm not sure that passing environment overrides on the command line is guaranteed to work.

looks like some files in build_stage does not exist. https://tbpl.mozilla.org/php/getParsedLog.php?id=47274294&tree=Gaia-Try&full=1#error1

... I don't know the reason, but Gb is green with last master. run 10 times to ensure everything good. https://tbpl.mozilla.org/?rev=7e1eedcbd3ab3ce9d46e73d6c3e727589f33b159&tree=Gaia-Try

looks fine now, what the hell... I also remove all commits for log information, I will land it if we don't get other problems. https://tbpl.mozilla.org/?rev=34400fa5f2269be3c66d667d8dbb2943820080a4&tree=Gaia-Try

merged. https://github.com/mozilla-b2g/gaia/commit/68bf9d234f8c9ba7488754685106bd55373683f5

b2g-inbound: https://tbpl.mozilla.org/?tree=B2g-Inbound&rev=14c4c72563d2