Closed Bug 1194979 Opened 9 years ago Closed 9 years ago

Use Mulet in Gaia

Categories

(Release Engineering :: General, defect)

Product:
Release Engineering
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: gerard-majax, Assigned: gerard-majax)

References

Details

Attachments

(1 file)

[gaia] lissyx:bug1194979 > mozilla-b2g:master
46 bytes, text/x-github-pull-request
aus
: feedback+
Details | Review 
      No description provided.
Summary: Update mozilla-get-url to be able to get a Mulet → Update mozilla-download to be able to get a Mulet
So mozilla-download seems to be ready. Gaia needs to make use of it.
Summary: Update mozilla-download to be able to get a Mulet → Use Mulet in Gaia
https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=2475331609d4e9555d604310fbbc7feb97f6f1a4

mozilla-runner is not finding the b2g binary. How can we teach him to use Mulet?
Flags: needinfo?(gaye)
Flags: needinfo?(aus)
Right, that's better: https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=29b7063f7e3c9ab374429a38ef1320d6a3b5fe23

The JSM failures seems to come from mozilla-runner which is still trying to run b2g.
Greg, I know you already have some Gij to investigate, but you might be interested in the faiures on GU25 there: https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=29b7063f7e3c9ab374429a38ef1320d6a3b5fe23

It seems to be pretty permanent
Flags: needinfo?(gweng)
See it. But I'm dealing with Gij that I finally have some clues, so I will switch to this when it get solved or stuck again (hope not).
Mostly green, fixed JSM perma fail: https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=c1aaa0fc7cac159024aab6027a63623298fd0428
Flags: needinfo?(gaye)
Flags: needinfo?(aus)
Comment on attachment 8648369 [details] [review]
[gaia] lissyx:bug1194979 > mozilla-b2g:master

Is it the proper way to switch ? Specifically for the npm modules.
Attachment #8648369 - Flags: feedback?(gaye)
Attachment #8648369 - Flags: feedback?(aus)
Just an update: since I still have no luck at debugging intermittent Gij, I now try to solve the unit test failure first. Debugging.
Comment on attachment 8648369 [details] [review]
[gaia] lissyx:bug1194979 > mozilla-b2g:master

The node module related changes look good to me. The rest of the patch also seems alright although I haven't tried it myself.
Attachment #8648369 - Flags: feedback?(aus) → feedback+
https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=8815380d4d3b718c2e52a792077214cb2e3d0857

Calendar and Keyboard unit tests failures.
Flags: needinfo?(timdream)
Flags: needinfo?(dylan)
(In reply to Alexandre LISSY :gerard-majax from comment #12)
> https://treeherder.mozilla.org/#/
> jobs?repo=gaia&revision=8815380d4d3b718c2e52a792077214cb2e3d0857
> 
> Calendar and Keyboard unit tests failures.

False alarm, a lot of retriggers later they are a bit intermittent but that's all.
Flags: needinfo?(timdream)
Flags: needinfo?(dylan)
So I am reproducing your GU25 100% locally:
 - get a mulet runtime, mine is built from source in ../gecko/obj-mulet/
 - run: RUNTIME=../gecko/obj-mulet/dist/firefox/firefox ./bin/gaia-test
 - open ./apps/system/test/unit/lockscreen/lockscreen_notifications_test.js and save it to trigger tests

That is 100% bingo repro of:
  1) [system-test/unit/lockscreen/lockscreen_notifications_test.js] system/LockScreenNotifications Remove top mask when actionable notification is at the visual top ofthe container viewport top-actionable class is correctly added in onNotificationHighlighted test on 0-th notification:
     Error: with notification index 0 container should not have the top-actionable class: expected true to equal false
      at chaiAssert (app://system.gaiamobile.org/common/test/helper.js:32:1)
      at equal (app://system.gaiamobile.org/common/vendor/chai/chai.js:2438:1)
      at testTopActionableClass (app://system.gaiamobile.org/test/unit/lockscreen/lockscreen_notifications_test.js:543:1)
      at (anonymous) (app://system.gaiamobile.org/test/unit/lockscreen/lockscreen_notifications_test.js:560:1)
      at wrapper (app://system.gaiamobile.org/common/test/mocha_generators.js:62:19)
      at run (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3709:7)
      at runTest (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4081:5)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4127:7)
      at next (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4007:1)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4016:7)
      at next (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3964:1)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3984:5)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4932:28)
  

  2) [system-test/unit/lockscreen/lockscreen_notifications_test.js] system/LockScreenNotifications Remove top mask when actionable notification is at the visual top ofthe container viewport top-actionable class is correctly added in onNotificationHighlighted test on 1-th notification:
     Error: with notification index 1 container should have the top-actionable class: expected false to equal true
      at chaiAssert (app://system.gaiamobile.org/common/test/helper.js:32:1)
      at equal (app://system.gaiamobile.org/common/vendor/chai/chai.js:2438:1)
      at testTopActionableClass (app://system.gaiamobile.org/test/unit/lockscreen/lockscreen_notifications_test.js:543:1)
      at (anonymous) (app://system.gaiamobile.org/test/unit/lockscreen/lockscreen_notifications_test.js:560:1)
      at wrapper (app://system.gaiamobile.org/common/test/mocha_generators.js:62:19)
      at run (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3709:7)
      at runTest (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4081:5)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4127:7)
      at next (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4007:1)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4016:7)
      at next (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3964:1)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3984:5)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4932:28)
  

  3) [system-test/unit/lockscreen/lockscreen_notifications_test.js] system/LockScreenNotifications Remove top mask when actionable notification is at the visual top ofthe container viewport top-actionable class is correctly removed with tryAddTopMaskByNotification test on 0-th notification:
     Error: with notification index 0 container should have the top-actionable class: expected false to equal true
      at chaiAssert (app://system.gaiamobile.org/common/test/helper.js:32:1)
      at equal (app://system.gaiamobile.org/common/vendor/chai/chai.js:2438:1)
      at testTopActionableClass (app://system.gaiamobile.org/test/unit/lockscreen/lockscreen_notifications_test.js:664:1)
      at (anonymous) (app://system.gaiamobile.org/test/unit/lockscreen/lockscreen_notifications_test.js:681:1)
      at wrapper (app://system.gaiamobile.org/common/test/mocha_generators.js:62:19)
      at run (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3709:7)
      at runTest (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4081:5)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4127:7)
      at next (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4007:1)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4016:7)
      at next (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3964:1)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3979:7)
      at done (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3700:5)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3712:9)
      at (anonymous) (app://system.gaiamobile.org/common/test/mocha_generators.js:46:20)
      at wrapper (app://system.gaiamobile.org/common/test/mocha_generators.js:73:15)
      at run (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3709:7)
      at next (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3973:5)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3984:5)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4932:28)
  

  4) [system-test/unit/lockscreen/lockscreen_notifications_test.js] system/LockScreenNotifications Remove top mask when actionable notification is at the visual top ofthe container viewport top-actionable class is correctly removed with tryAddTopMaskByNotification test on 1-th notification:
     Error: with notification index 1 container should not have the top-actionable class: expected true to equal false
      at chaiAssert (app://system.gaiamobile.org/common/test/helper.js:32:1)
      at equal (app://system.gaiamobile.org/common/vendor/chai/chai.js:2438:1)
      at testTopActionableClass (app://system.gaiamobile.org/test/unit/lockscreen/lockscreen_notifications_test.js:664:1)
      at (anonymous) (app://system.gaiamobile.org/test/unit/lockscreen/lockscreen_notifications_test.js:681:1)
      at wrapper (app://system.gaiamobile.org/common/test/mocha_generators.js:62:19)
      at run (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3709:7)
      at runTest (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4081:5)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4127:7)
      at next (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4007:1)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4016:7)
      at next (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3964:1)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3979:7)
      at done (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3700:5)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3712:9)
      at (anonymous) (app://system.gaiamobile.org/common/test/mocha_generators.js:46:20)
      at wrapper (app://system.gaiamobile.org/common/test/mocha_generators.js:73:15)
      at run (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3709:7)
      at next (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3973:5)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:3984:5)
      at (anonymous) (app://system.gaiamobile.org/common/vendor/mocha/mocha.js:4932:28)
Flags: needinfo?(gweng)
gasp, sorry for this the env variable should be FIREFOX= and not RUNTIME= ...
And local repro is stil here if I use a mulet downloaded from TaskCluster ...
Update and bad news (to me): I installed another fresh Ubuntu 14.04 VM, built Gaia and ran the test exactly followed what you described, but it just worked well. No error occurred. The steps:

1. Install Ubuntu 14.04 VM on my Mac in Parallels Desktop (don't tell me this software makes the difference...)
2. Install git, python-pip from apt-get
3. Install nvm[1] for the case I may need to switch node versions since Gaia always prints the log "please 0.10 or you may encounter problems" during building and running tests, but I have an opposite experience: 0.10 never worked on my Ubuntu 14.04, and only 0.12 can work well
4. Run 'make' once to make sure everything is fine

- Then I run the test-

5. Download Mulet from the updated link on MDN[2]: I fetched the one just ran about 7 hours ago, so it's relatively "fresh" one, not like the 3 months old one I fetched once
6. Unpack Mulet and put it under /home/ubuntu/mulet
7. In Gaia directory, execute the command: FIREFOX=/home/ubuntu/mulet/firefox ./bin/gaia-test
8. After test-agent shows up, open the ./apps/system/test/unit/lockscreen/lockscreen_notifications_test.js and trigger the test

9. It shows 29 passed...even for those failed tests as your log shows.

The next step? I submitted a loan request to test it on the remote server, which now has been granted. So I will connect to that and repeat the steps to see if I can find any different results. But before that I will to check code again to see if it could pass all incorrectly (false negative). If so I will try to fix the code and push to Mulet via Gecko try configs.

And I also suspect if nvm/node/npm caused the issue. But I have no other options since 0.10 just refused to work on my machine, which showed the dependencies were broken while I try to make it, which will invoke `npm install`. However, the most weird thing is if I install them manually one-by-one, they're all good to install. But since I need to install at least 20 packages manually...it's just too painful and sometimes the dependencies of dependencies still failed, so I gave up to think it's "good", and switched to 0.12 solved all the problems.

---
 
[1]: https://github.com/creationix/nvm
[2]: https://tools.taskcluster.net/index/artifacts/#gecko.v1.mozilla-central.latest.linux.mulet/gecko.v1.mozilla-central.latest.linux.mulet.opt
The loan instance now unfortunately has some connection issue. So while releng people try to solve that I'm not digging into the code, and will pick some suspicious part to do some modifications.
Okay I  did some change in the test file and pushed to the try. Wait the result while I'm trying it on loan instance again.
Update: Now I finally can reproduce it on the remote instance. I'm debugging it.
And it looks like:

1. With MacOSX + node 0.12 and latest Mulet[1] it won't reproduce
2. With Ubuntu 15.04(latest), 14.04 (LTS) + node 0.12 and latest Mulet it won't reproduce
3. With Ubuntu 12.04(which TaskCluster uses) + node 0.12 and latest Mulet it CAN reproduce

I don't know if TaskCluster instance make other differences. If not, the only difference is the version of Ubuntu, which means Mulet is possibly relying on some system features which may affect the test results. However, since I'm not expert of TaskCluster and Mulet, I can only raise what I doubted here, and fix the test first.

[1]: https://tools.taskcluster.net/task-inspector/#If5ja8xATC2-XaB_-2GTYw/
Update: on my local console, with Ubuntu 12.04 + node 0.12 and the latest Mulet, it won't reproduce... It looks like a TaskCluster only bug. Anyway, I will still try solve it.
Update: I've found the main failure point is on B2G desktop, in

    LockScreenNotifications#onNotificationHighlighted

The `_getNumNotificationInContainerViewport()` returns '3', but on Mulet it returns 4. This is a direct failure cause, so I will try to dig in that.
I think I can debug it now and I need to send a patch. So I now fire another bug to track and patch it.
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #21)
> And it looks like:
> 
> 1. With MacOSX + node 0.12 and latest Mulet[1] it won't reproduce
> 2. With Ubuntu 15.04(latest), 14.04 (LTS) + node 0.12 and latest Mulet it
> won't reproduce
> 3. With Ubuntu 12.04(which TaskCluster uses) + node 0.12 and latest Mulet it
> CAN reproduce
> 
> I don't know if TaskCluster instance make other differences. If not, the
> only difference is the version of Ubuntu, which means Mulet is possibly
> relying on some system features which may affect the test results. However,
> since I'm not expert of TaskCluster and Mulet, I can only raise what I
> doubted here, and fix the test first.

Or it's because of some race and some environment exposes it more easily ...

> 
> [1]: https://tools.taskcluster.net/task-inspector/#If5ja8xATC2-XaB_-2GTYw/
Still don't know the cause of different behavior, but I've fixed the root cause. Maybe Alexandre can verify that? I've done it manually on my loaner machine, but more eyes on that makes sure the result is really verified.
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #26)
> Still don't know the cause of different behavior, but I've fixed the root
> cause. Maybe Alexandre can verify that? I've done it manually on my loaner
> machine, but more eyes on that makes sure the result is really verified.

Thanks! I have rebased my PR on top of master:
https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=94a3e639c7139ef0f3336cbeceaa5410deac291c
(In reply to Alexandre LISSY :gerard-majax from comment #27)
> (In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #26)
> > Still don't know the cause of different behavior, but I've fixed the root
> > cause. Maybe Alexandre can verify that? I've done it manually on my loaner
> > machine, but more eyes on that makes sure the result is really verified.
> 
> Thanks! I have rebased my PR on top of master:
> https://treeherder.mozilla.org/#/
> jobs?repo=gaia&revision=94a3e639c7139ef0f3336cbeceaa5410deac291c

And we have GU25 green \o/
(In reply to Alexandre LISSY :gerard-majax from comment #27)
> (In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #26)
> > Still don't know the cause of different behavior, but I've fixed the root
> > cause. Maybe Alexandre can verify that? I've done it manually on my loaner
> > machine, but more eyes on that makes sure the result is really verified.
> 
> Thanks! I have rebased my PR on top of master:
> https://treeherder.mozilla.org/#/
> jobs?repo=gaia&revision=94a3e639c7139ef0f3336cbeceaa5410deac291c

Looks like we have two new failures on GU9 in two FTU unit tests :(
Flags: needinfo?(sfoster)
I cant reproduce these test failures - in nightly or using mulet. 
The FTU tutorial appears to play normally on device with the latest gaia+gecko. 
I do however see a new error in the console when running the FTU on nightly and mulet: 

HTTP "Content-Type" of "video/mp4" is not supported. Load of media resource app://ftu.gaiamobile.org/style/images/tutorial/VerticalScroll.mp4 failed. index.html
Failed to load tutorial media: /style/images/tutorial/VerticalScroll.mp4 tutorial.js:32:11

We try not to block the tutorial - or the unit tests - on the successful loading of the videos to avoid effectively bricking the phone with a bad path or asset. However, that is concerning, and might be implicated in the test failures.
Flags: needinfo?(sfoster)
If I use mulet to browse to the assets in gaia/apps/ftu/style/images/tutorial/ I get the issue - the mp4s are downloaded rather than played.
I filed bug 1199348 for the above.
(In reply to Sam Foster [:sfoster] from comment #31)
> If I use mulet to browse to the assets in
> gaia/apps/ftu/style/images/tutorial/ I get the issue - the mp4s are
> downloaded rather than played.

I'm not sure this is relevant: I do have this behavior when I try this locally too. But a |make APP=ftu test-agent-test| does pass with Mulet on my system.

Do we know if video playback is working well on the gaia-try infra ?
This is the status for Mulet/Gaia
Flags: needinfo?(aus)
Depends on: 1201070
Depends on: 1199429
Flags: needinfo?(aus)
Fixed by bug 1199429.
Status: NEW → RESOLVED
Closed: 9 years ago
No longer depends on: 1201070
Resolution: --- → FIXED
I pushed a follow-up to add the firefox directory to the gitignore: https://github.com/mozilla-b2g/gaia/commit/ef5a291e44fea82f0e3793ac4f17eaa2188af7e0
Assignee: nobody → lissyx+mozillians
Attachment #8648369 - Flags: feedback?(gaye)
Component: Tools → General
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: