Closed Bug 826583 Opened 12 years ago Closed 6 years ago

have ./flash.sh gecko build system.img for emulators

Categories

(Firefox OS Graveyard :: GonkIntegration, defect)

Product:
Firefox OS Graveyard
Component:
GonkIntegration
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: bholley, Unassigned)

Details

I'm developing a mochitest on a b2g emulator setup [1].

I was editing testing/specialpowers/content/specialPowersAPI.js, and introduced a silly syntax error. This caused b2g mochitests to hang with a white screen on startup, without any useful debug spew.

However, when I fixed it, and tried to run |./build.sh gecko|, the problem persisted until I did a full |./build.sh|.

cjones indicated that this was not expected, and that I should file a bug.


[1] - https://developer.mozilla.org/en-US/docs/Mozilla/Boot_to_Gecko/B2G_Mochitests
That helper doesn't do anything custom, just wraps the equivalent of
$ make -f client.mk
$ make package
$ [mv some stuff around]

Quick question: after you built, you did |./flash.sh gecko| right?
Summary: ./build.sh gecko misses certain things (such as testing/specialpowers) → make -f client.mk misses certain things (such as testing/specialpowers) (?)
(In reply to Chris Jones [:cjones] [:warhammer] from comment #1)
> Quick question: after you built, you did |./flash.sh gecko| right?

Nope. Wasn't aware that was necessary for an emulator build. That's almost certainly it.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Hm, looks like |./flash.sh gecko| doesn't work for emulator builds:

bholley@righteous /files/mozilla/b2g/take2-arm (master) $ ./flash.sh gecko
error: device not found
bholley@righteous /files/mozilla/b2g/take2-arm (master) $ ./flash.sh
Unsupported device "generic", can't flash
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Component: Build Config → Builds
Product: Core → Boot2Gecko
So anyway, presumably the issue here is that there's no ./flash.sh equivalent to update the emulator, and the entire ./build.sh step here is necessary. Does that jive with reality, Chris? Not sure whether it should be considered a bug or not, but the docs should at least be updated.
Hm, |./flash.sh gecko| should work.  Our testing infrastructure uses that ...
(In reply to Chris Jones [:cjones] [:warhammer] from comment #5)
> Hm, |./flash.sh gecko| should work.  Our testing infrastructure uses that ...

For emulators? It doesn't appear to for me. Unless this changed since Dec 23rd, which was around when I did my last ./repo sync.
Hey jgriffin, how do we push a new gecko build onto emulators in infra?
Flags: needinfo?(jgriffin)
Our b2g test runners have a --gecko-path argument, e.g., --gecko-path /path/to/$objdir/dist/b2g, that causes the runner to install the specified gecko version onto the emulator and restart B2G.
Flags: needinfo?(jgriffin)
(In reply to Jonathan Griffin (:jgriffin) from comment #8)
> Our b2g test runners have a --gecko-path argument, e.g., --gecko-path
> /path/to/$objdir/dist/b2g, that causes the runner to install the specified
> gecko version onto the emulator and restart B2G.

So, the bug I was experiencing (in comment 0) was that testing infrastructure, in particular the SpecialPowers extension, are not updated by ./build.sh gecko. Given how things work, is that expected?
Flags: needinfo?(jgriffin)
(In reply to Bobby Holley (:bholley) from comment #9)
> (In reply to Jonathan Griffin (:jgriffin) from comment #8)
> > Our b2g test runners have a --gecko-path argument, e.g., --gecko-path
> > /path/to/$objdir/dist/b2g, that causes the runner to install the specified
> > gecko version onto the emulator and restart B2G.
> 
> So, the bug I was experiencing (in comment 0) was that testing
> infrastructure, in particular the SpecialPowers extension, are not updated
> by ./build.sh gecko. Given how things work, is that expected.

No, it's not.  But are you sure that's the case?  ./build.sh gecko will build gecko, but not install it in the emulator; you'd have to launch runtestsb2g.py with the --gecko-path argument in order to get that version onto the emulator, since ./flash.sh doesn't work with the emulator.
Flags: needinfo?(jgriffin)
(In reply to Jonathan Griffin (:jgriffin) from comment #10)
> > So, the bug I was experiencing (in comment 0) was that testing
> > infrastructure, in particular the SpecialPowers extension, are not updated
> > by ./build.sh gecko. Given how things work, is that expected.
> 
> No, it's not.  But are you sure that's the case?  ./build.sh gecko will
> build gecko, but not install it in the emulator; you'd have to launch
> runtestsb2g.py with the --gecko-path argument in order to get that version
> onto the emulator, since ./flash.sh doesn't work with the emulator.

Yeah, that's what I was doing. Though maybe I was doing something wrong.

I'll confirm at some point, but doing the requisite sync + multiple full builds to confirm this bug is probably a half-hour process that might take me a while to get to.
FWIW, I'm working on adding support for mochitests to the b2g desktop build and it should be ready this week.
(In reply to Jonathan Griffin (:jgriffin) from comment #12)
> FWIW, I'm working on adding support for mochitests to the b2g desktop build
> and it should be ready this week.


<3 <3 <3
Summary: make -f client.mk misses certain things (such as testing/specialpowers) (?) → |./build.sh gecko| on an emulator misses certain things (such as testing/specialpowers) (?)
(In reply to Bobby Holley (:bholley) from comment #11)
> (In reply to Jonathan Griffin (:jgriffin) from comment #10)
> > > So, the bug I was experiencing (in comment 0) was that testing
> > > infrastructure, in particular the SpecialPowers extension, are not updated
> > > by ./build.sh gecko. Given how things work, is that expected.
> > 
> > No, it's not.  But are you sure that's the case?  ./build.sh gecko will
> > build gecko, but not install it in the emulator; you'd have to launch
> > runtestsb2g.py with the --gecko-path argument in order to get that version
> > onto the emulator, since ./flash.sh doesn't work with the emulator.
> 
> Yeah, that's what I was doing. Though maybe I was doing something wrong.

Oh, I see! I was passing --b2gpath, which presumably requires a full ./build.sh to take effect on an emulator build. Is that correct jgriffin? If so, then the --gecko-path stuff should probably be documented somewhere.
Hm, passing --gecko-patch=$(OBJDIR) seems to get bogged down trying to sync everything (all the mochitest, object files, etc). Is there something else you're supposed to pass?
you need to pass --gecko-path $OBJDIR/dist/b2g
(In reply to Jonathan Griffin (:jgriffin) from comment #16)
> you need to pass --gecko-path $OBJDIR/dist/b2g

Hm, I see.

This still seems to spend some extra time copying everything from that directory over. Is that more time than it takes if you just pass --b2gpath? Or is there analogous copying that just isn't showing up in the terminal?
The purpose of these arguments is very different.

--b2gpath points to the B2G home dir, which is needed so that the harness can find the files it needs to simply launch the emulator.

--gecko-path (optionally) points to the b2g binaries which the harness will install onto the emulator after it starts, which involves copying a lot of files to the emulator after it's running

--gecko-path is only useful if you want to run the tests with a different version of gecko than is already built into the emulator.  For instance, you can use ./build.sh gecko and then launch the harness with --gecko-path as an alternative to doing a full ./build.sh.  Note that what gecko is updated this way, it needs to be updated the same way each time you run the test, because the emulator does not persist changes to the system partition.
(In reply to Jonathan Griffin (:jgriffin) from comment #18)
> --gecko-path is only useful if you want to run the tests with a different
> version of gecko than is already built into the emulator.  For instance, you
> can use ./build.sh gecko and then launch the harness with --gecko-path as an
> alternative to doing a full ./build.sh.  Note that what gecko is updated
> this way, it needs to be updated the same way each time you run the test,
> because the emulator does not persist changes to the system partition.

OK, then back to my original question. In emulator builds, what emulator-installing shenanigans happen in |./build.sh| that don't happen in |./build.sh gecko|? Can we have |./flash.sh gecko| do that magic on emulator builds so as to speed up the turnaround time? Or would it be no faster than just |./build.sh|?
'./build.sh gecko' doesn't actually package the built gecko into system.img, which is what's used when launching the emulator.

To do that, you need to run a full ./build.sh.

It's possible we could try to make './flash.sh gecko' update the emulator's system.img file for emulator builds (or create a new build.sh target that does that), but I'm not certain how much time that would save over ./build.sh...my guess is, not much.
May not be high priority, but worth doing to at least align the behavior and workflow with what happens on the device. Morphing the bug.
Summary: |./build.sh gecko| on an emulator misses certain things (such as testing/specialpowers) (?) → have ./flash.sh gecko build system.img for emulators
Firefox OS is not being worked on
Status: REOPENED → RESOLVED
Closed: 12 years ago → 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.