Closed
Bug 1037056
Opened 10 years ago
Closed 9 years ago
[Flame] We need a way to FOTA our Gecko/Gaia.
Categories
(Firefox OS Graveyard :: Vendcom, defect, P1)
Tracking
(blocking-b2g:2.5?, firefox44 fixed, b2g-v2.2r fixed)
People
(Reporter: nhirata, Assigned: catlee)
References
Details
(Whiteboard: [b2g-build-support])
Attachments
(7 files, 6 obsolete files)
335.91 KB,
text/plain
|
Details | |
56 bytes,
text/x-github-pull-request
|
catlee
:
review+
|
Details | Review |
1.94 KB,
patch
|
rail
:
review+
|
Details | Diff | Splinter Review |
1.82 KB,
patch
|
rail
:
review+
|
Details | Diff | Splinter Review |
1.20 MB,
image/jpeg
|
Details | |
24.08 KB,
application/zip
|
Details | |
3.48 KB,
patch
|
wcosta
:
review+
|
Details | Diff | Splinter Review |
When testing the URL override with the straight 122 OEM build, the override did not override to our server. I had to flash a v1.3 gaia on top in order for the override to work. We need a way to switch back to check their OTA server for gonk updates. This might be a two part bug? Not sure.
Reporter | ||
Comment 1•10 years ago
|
||
I filed this bug to figure out the mechanism where we need to get OTA updates from two different locations. David, is there a good way to achieve this?
Flags: needinfo?(dhylands)
Flags: needinfo?(bhearsum)
Reporter | ||
Comment 2•10 years ago
|
||
To note : https://developer.mozilla.org/en-US/docs/Mozilla/Setting_up_an_update_server I am referring to the app.update.url.override These are the steps that I took in regards to getting the logcat attached: 1. flash the OEM v122 build ; turned wifi on through ftu 2. ran the following commands : ./change_channel.sh -v aurora ./change_ota_url.sh -u https://aus4.mozilla.org/update/3/B2G/28.0/20140709000201/flame/en-US/aurora/Boot2Gecko%202.0.0.0-prerelease/default/default/update.xml?force=1 [ note these are scripts from : https://github.com/Mozilla-TWQA/B2G-flash-tool ] 3. adb logcat > logcat.txt 4. on the phone : settings -> device info -> system updates -> Check for updates First time I tried check for updates, it says check again later. Second time I tried it says the system was already up to date. If I flash my own v1.3 gaia on top, I am able to update to 2.0 with the same steps above.
Comment 3•10 years ago
|
||
The phone really only supports getting updates from a single location. You can mix FOTA and OTA on the same server from the same URL. Although it's almost like we want to have 2 different update checks. Currently, we use the gecko/gaia build id and look for new gecko/gaia updates. It's almost like we need a parallel update channel to look for gonk updates. So not only change URLs, but also change how the version is calculated. So you'd have URL1 using buildid and URL2 using some gonkid
Flags: needinfo?(dhylands)
Reporter | ||
Comment 4•10 years ago
|
||
We can find the gonk id currently with : adb shell getprop t2m.sw.version
Comment 5•10 years ago
|
||
Naoki and I chatted on IRC about this a bit. For starters, the reason that setting app.update.url.override doesn't work in a T2M image is because our updater doesn't run as part of that (verified through the lack of GeckoUpdater or AUS:SVC in the attached logcat). At least our Gaia needs to be flashed before our updater runs - though it seems like a good idea to do a matching Gecko as well. In an ideal world, I would suggest that the best way to deal with updates that require Gonk is to ship a FOTA containing Gonk+Gecko+Gaia from one update server. Doing that is the simplest thing from a management standpoint, and also provides better UX. In a world where we're not allowed to distribute Gonk bits, we could, in theory, have our update server point to a Gonk MAR hosted elsewhere, and a Gecko+Gaia MAR hosted by us. That would require update server changes that are unlikely to happen for awhile. The other way to live in this world is to have the partner do Gonk+Gecko+Gaia updates instead. In any case, right now the reality is that when you need to take a Gonk change, you need to flash the partner image, then flash our Gecko/Gaia. Then you'll receive updates from us again.
Flags: needinfo?(bhearsum)
Reporter | ||
Comment 6•10 years ago
|
||
Thanks bhearsum, dhylands! It seems like if there's a way for T2M to have a Gonk.mar, checking via the adb shell getprop t2m.sw.version and they allow the F/OTA gecko/gaia to point to : https://aus4.mozilla.org/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%PRODUCT_DEVICE%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml That might work. I think we also would need to have the gaia/gecko changes that they make to accommodate two URLs like this? Francis, could you chat with T2M to see if something like this might be possible since we can't distribute the Gonk? This may make things easier for dogfooders.
Flags: needinfo?(frlee)
Comment 7•10 years ago
|
||
I feel like this should be discussed between releng and some b2g folks more before we actually try to do anything here. I can't volunteer myself at this moment, but I'm happy to help when my schedule clears up a bit. There's lots of tricky issues at play when we're talking about the updater, and I don't want us to go halfway into a fix only to discover it won't work.
Comment 8•10 years ago
|
||
This deserves a meeting, soon. Who do we need in the room? Michael Treese can probably help organize.
Assignee | ||
Comment 9•10 years ago
|
||
When I spoke with Fabrice and Mwu about this a few months ago we agreed that the client side would be responsible for knowing if it could safely apply a gecko update given its current gonk state. Agreed on need for a meeting, sign me up.
Updated•10 years ago
|
Flags: needinfo?(frlee)
Comment 10•10 years ago
|
||
If we do need to put the Gonk version in the update URL, I would suggest that it belongs in OS_VERSION somewhere. This would be similar-ish to how we put OS + Service pack information in there for desktop OS'. It looks like that could be done with a new ifdef in https://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.js#340 But I agree that we need a meeting to figure out what's actually needed here.
Comment 11•10 years ago
|
||
guys - I am not sure why this meeting is not happening so I will set up a meeting for next week - I will assume it's for the group on this bug but please add to the meeting attendee list as you see fit.
Comment 12•10 years ago
|
||
Calling for this meeting without a clear problem statement is premature. First, depending on what we are trying to sovle, MWu and Fabrice may be needed. Most of the things Asa and I discussed are engineering questions. A second meeting will still be needed to work out our FOTA options and potential engineering roadmap and the Monday meeting in my opinion should be cancelled. I will work on the problem statement and set up a meeting later in the week.
Reporter | ||
Comment 13•9 years ago
|
||
I think we can't do a FOTA for the gonk layer; having said that we still need to do a gecko/gaia FOTA for Flame as the system partition doesn't have enough space for multiple OTAing. Changing the title to match.
Summary: [Flame] We need a way to FOTA our Gecko/Gaia as well as their use their FOTA when they have a gonk layer update → [Flame] We need a way to FOTA our Gecko/Gaia.
Comment 14•9 years ago
|
||
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #13) > I think we can't do a FOTA for the gonk layer; having said that we still > need to do a gecko/gaia FOTA for Flame as the system partition doesn't have > enough space for multiple OTAing. > > Changing the title to match. Producing such a package is simple: ./build.sh gecko-update-fota
Updated•9 years ago
|
Whiteboard: [tc-build-support]
Updated•9 years ago
|
Whiteboard: [tc-build-support] → [b2g-build-support]
Updated•9 years ago
|
Flags: needinfo?(jgong)
Flags: needinfo?(drs)
Updated•9 years ago
|
Assignee: nobody → lissyx+mozillians
Comment 15•9 years ago
|
||
From bug 1201540 comment 42 and discussion on IRC, :bhearsum suggested we allow setting "update_type" also in Gecko config JSON. The file is loaded by http://hg.mozilla.org/mozilla-central/file/default/testing/mozharness/scripts/b2g_build.py#l358 from |b2g/configs/<device>/config.json|. So a plan would be to: - add update_type override support in b2g_build.py, like https://hg.mozilla.org/try/rev/e75147e495c0#l3.18 but reading also from gecko_config - add update_type definition to fota value in the proper flame-kk ota definition We will still have to fix the balrog pushing. We also need to make sure there is no other way to set update_type value for a Flame KK OTA build.
Comment 16•9 years ago
|
||
Comment 18•9 years ago
|
||
OR .... http://hg.mozilla.org/build/buildbot-configs/file/56bcb5e87c33/mozilla/b2g_config.py#l778 ? With ./testing/mozharness/configs/b2g/releng-fota-updates.py instead of ./testing/mozharness/configs/b2g/releng-private-updates.py
Comment 19•9 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #18) > OR .... > http://hg.mozilla.org/build/buildbot-configs/file/56bcb5e87c33/mozilla/ > b2g_config.py#l778 ? With > ./testing/mozharness/configs/b2g/releng-fota-updates.py instead of > ./testing/mozharness/configs/b2g/releng-private-updates.py At least on TaskCluster we have something that now seems to do the trick: https://tools.taskcluster.net/task-graph-inspector/#CtoB30EjReCc16jeQJvKWw/HTlVe5e0QziqJ_eBYdJ0eA/0 See the "fota-flame-update.mar" artifact, this is what we want !
Comment 20•9 years ago
|
||
All green: https://tools.taskcluster.net/task-graph-inspector/#GZeqRuMsQRypZ0SwBmXrAg/aqmfK-IaRXO7xF_ODDHH0A/
Comment 21•9 years ago
|
||
Attachment #8668386 -
Attachment is obsolete: true
Comment 22•9 years ago
|
||
Comment on attachment 8668501 [details] [diff] [review] Flame FOTA r=... One last round of review: this is doing what I want and what was suggested. Next step is making sure Balrog communication is fine, but that is out of my scope!
Attachment #8668501 -
Flags: review?(wcosta)
Attachment #8668501 -
Flags: review?(jlund)
Comment 24•9 years ago
|
||
Comment on attachment 8668501 [details] [diff] [review] Flame FOTA r=... Review of attachment 8668501 [details] [diff] [review]: ----------------------------------------------------------------- lgtm ::: testing/taskcluster/tasks/builds/b2g_flame_kk_ota_base.yml @@ +6,5 @@ > payload: > env: > TARGET: 'flame-kk' > DEBUG: 0 > + MOZHARNESS_CONFIG: b2g/taskcluster-phone-fota.py Shouldn't fota have its own task file?
Comment 25•9 years ago
|
||
So we create testing/taskcluster/tasks/builds/b2g_flame_kk_fota_base.yml ?
Flags: needinfo?(wcosta)
Comment 26•9 years ago
|
||
And we add a device build "flame-kk-fota" next to "flame-kk-ota" ? Why not.
Comment 27•9 years ago
|
||
Attachment #8668501 -
Attachment is obsolete: true
Attachment #8668501 -
Flags: review?(wcosta)
Attachment #8668501 -
Flags: review?(jlund)
Attachment #8668849 -
Flags: review?(wcosta)
Attachment #8668849 -
Flags: review?(jlund)
Comment 29•9 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #26) > And we add a device build "flame-kk-fota" next to "flame-kk-ota" ? Why not. Yeah, although ota builds are currently done in bb, plans are to move to TC in future, so the OTA tasks should be preserved.
Flags: needinfo?(wcosta)
Updated•9 years ago
|
Attachment #8668849 -
Flags: review?(wcosta) → review+
Comment 30•9 years ago
|
||
Attachment #8668877 -
Flags: review?(catlee)
Comment 31•9 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #28) > https://treeherder.mozilla.org/#/jobs?repo=try&revision=73414b379f91 All good. Let's check we do not break anything: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c6a891ea3a0e
Updated•9 years ago
|
Attachment #8668849 -
Flags: review?(catlee)
Comment 32•9 years ago
|
||
Rebased and cleaned up the hacks for try
Attachment #8668849 -
Attachment is obsolete: true
Attachment #8668849 -
Flags: review?(jlund)
Attachment #8668849 -
Flags: review?(catlee)
Comment 33•9 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #32) > Created attachment 8668897 [details] [diff] [review] > Adding support for producing Gecko/Gaia FOTA for Flame > > Rebased and cleaned up the hacks for try https://tools.taskcluster.net/task-graph-inspector/#YtX0zNSqSpeq53f7r-W0Ag/
Updated•9 years ago
|
Attachment #8668897 -
Flags: review?(catlee)
Updated•9 years ago
|
Attachment #8668897 -
Flags: review?(jlund)
Comment 34•9 years ago
|
||
Comment on attachment 8668897 [details] [diff] [review] Adding support for producing Gecko/Gaia FOTA for Flame Carrying r+ from :wcosta
Attachment #8668897 -
Flags: review+
Comment 35•9 years ago
|
||
Still looking good: https://tools.taskcluster.net/task-graph-inspector/#Ancw92gORzWq0wOYvDbLXg/
Comment 36•9 years ago
|
||
Comment on attachment 8668897 [details] [diff] [review] Adding support for producing Gecko/Gaia FOTA for Flame Review of attachment 8668897 [details] [diff] [review]: ----------------------------------------------------------------- looks good. is the only change between testing/mozharness/configs/b2g/taskcluster-phone-fota.py and testing/mozharness/configs/b2g/taskcluster-phone-ota.py the addition of `"update_type": "fota"` ? if so and if you expect these two config files to continue sharing any future changes, it might be better to make 'update_type' a command line option that gets passed by taskcluster e.g. `hg mv testing/mozharness/configs/b2g/taskcluster-phone-ota.py testing/mozharness/configs/b2g/taskcluster-phone-update.py` # add --update-type command line option and then ... fota case: `--config b2g/taskcluster-phone-update.py --update-type fota` ota case: `--config b2g/taskcluster-phone-update.py --update-type ota`
Attachment #8668897 -
Flags: review?(jlund)
Attachment #8668897 -
Flags: review?(catlee)
Attachment #8668897 -
Flags: review+
Updated•9 years ago
|
Assignee | ||
Comment 37•9 years ago
|
||
Comment on attachment 8668877 [details] [review] Buildbot config PR committed as https://hg.mozilla.org/build/buildbot-configs/rev/f4e8891b9849
Attachment #8668877 -
Flags: review?(catlee) → review+
Assignee | ||
Comment 38•9 years ago
|
||
We're going to be disabling the flame-kk-ota builds in TC in bug 1188992 to try and reduce confusion.
Comment 39•9 years ago
|
||
In production: https://hg.mozilla.org/build/buildbot-configs/rev/f4e8891b9849
Comment 40•9 years ago
|
||
Can we also land the patch for TaskCluster? I know it's not being used yet, but I would prefer we keep everything in sync at that point.
Flags: needinfo?(catlee)
Assignee | ||
Comment 41•9 years ago
|
||
No, I'd prefer not to land in TC, since your patch will schedule new builds that will also be publishing updates. The buildbot patch however, is not working. The build is failing at some point late in the process; I'm digging into this today.
Flags: needinfo?(catlee)
Assignee | ||
Comment 42•9 years ago
|
||
Assignee | ||
Updated•9 years ago
|
Assignee: lissyx+mozillians → catlee
Status: NEW → ASSIGNED
Assignee | ||
Updated•9 years ago
|
Attachment #8670967 -
Flags: review?(nhirata.bugzilla)
Updated•9 years ago
|
Attachment #8670967 -
Flags: review?(nhirata.bugzilla) → review+
Assignee | ||
Comment 43•9 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/9ccd468f27bd86b7d0267cb975d0e0e8c511422c Bug 1037056: Add java to flame-kk builds r=rail
Assignee | ||
Comment 44•9 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/9ccd468f27bd
https://hg.mozilla.org/mozilla-central/rev/c6ede6f30f3d
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox44:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → FxOS-S9 (16Oct)
Comment 47•9 years ago
|
||
(In reply to Wes Kocher (:KWierso) from comment #46) > https://hg.mozilla.org/mozilla-central/rev/c6ede6f30f3d I don't think we're ready to resolve yet -- this is just for the java dependency, right?
Flags: needinfo?(wkocher)
Oh. Happy to reopen if that's the case.
Status: RESOLVED → REOPENED
Flags: needinfo?(wkocher)
Resolution: FIXED → ---
Target Milestone: FxOS-S9 (16Oct) → ---
Reporter | ||
Comment 49•9 years ago
|
||
Slight correction : Build bot patch + java dependency. Having said that, we still need to have it working for Taskcluster as we're moving towards taskcluster as the long term solution. So yes, we still need this bug open.
Comment 50•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/9ccd468f27bd
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → FxOS-S9 (16Oct)
Reporter | ||
Comment 51•9 years ago
|
||
Carsten, this isn't completed yet. Please read comment 49.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 52•9 years ago
|
||
Too many patches in here causing some confusion, tagging leave-open.
Keywords: leave-open
Assignee | ||
Comment 53•9 years ago
|
||
Assignee | ||
Comment 54•9 years ago
|
||
Comment on attachment 8671660 [details] [diff] [review] Silence extraneous l10n warnings My local builds are working, and yet the ones in buildbot are failing, but I can't see why because the log exceeds the maximum. This patch should remove quite a bit of l10n warnings, and hopefully let me see what's going wrong with the builds.
Attachment #8671660 -
Flags: review?(rail)
Updated•9 years ago
|
Attachment #8671660 -
Flags: review?(rail) → review+
Assignee | ||
Comment 55•9 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/6e02bb301c4d9dbd1ae185f23310ad58d85f0257 Bug 1037056: Silence extraneous l10n warnings r=rail
Assignee | ||
Comment 56•9 years ago
|
||
Comment on attachment 8671660 [details] [diff] [review] Silence extraneous l10n warnings https://hg.mozilla.org/integration/b2g-inbound/rev/6e02bb301c4d
Assignee | ||
Comment 57•9 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/a891728a0947ef7aa96a8229c62d19b6e45abce8 Bug 1037056 - Adding support for producing Gecko/Gaia FOTA for Flame r=wcosta,jlund,catlee
Comment 59•9 years ago
|
||
Added FOTA_FINGERPRINTS in sync with bug 1213824
Attachment #8668897 -
Attachment is obsolete: true
Attachment #8672592 -
Flags: review+
Comment 61•9 years ago
|
||
Removed fingerprints
Attachment #8672592 -
Attachment is obsolete: true
Attachment #8673161 -
Flags: review+
Comment 62•9 years ago
|
||
Triggered new build: https://tools.taskcluster.net/task-graph-inspector/#PF5WRfaCQsG0lSGzbjQkIg/
Reporter | ||
Comment 63•9 years ago
|
||
I tried testing via upgrading build 20151009150221 and I got the signature error again.
Reporter | ||
Comment 64•9 years ago
|
||
Recovery logs and logcat file attached.
Flags: needinfo?(nhirata.bugzilla) → needinfo?(catlee)
Comment 65•9 years ago
|
||
Naoki, I cannot debug this without the full logs, namely I need to make sure your system partition matches. The Edify code we make use of from AOSP:
> if not fp:
> raise ValueError("must specify some fingerprints")
> cmd = (
> ' ||\n '.join([('file_getprop("/system/build.prop", '
> '"ro.build.fingerprint") == "%s"')
> % i for i in fp]) +
> ' ||\n abort("Package expects build fingerprint of %s; this '
> 'device has " + getprop("ro.build.fingerprint") + ".");'
> ) % (" or ".join(fp),)
> self.script.append(cmd)
So I guess the fingerprint is really wrong on system partition.
Comment 66•9 years ago
|
||
I have retested on my side, and it is working as expected. Naoki, that fingerprint will only match the v18D_v4 build. It will fail for anything else. Please make sure you tested with a recovery and system partition from v18D_v4 build.
Assignee | ||
Comment 67•9 years ago
|
||
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #64) > Created attachment 8673360 [details] > recovery_logcat.zip > > Recovery logs and logcat file attached. I can't help debug this, sorry.
Flags: needinfo?(catlee)
Comment 68•9 years ago
|
||
(In reply to Chris AtLee [:catlee] from comment #67) > (In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from > comment #64) > > Created attachment 8673360 [details] > > recovery_logcat.zip > > > > Recovery logs and logcat file attached. > > I can't help debug this, sorry. It's okay, we checked with Naoki on IRC, he tested applying a FOTA with fingerprint check enabled on an invalid base system. So the error was expected as I said in comment 66.
Updated•9 years ago
|
Priority: -- → P1
Comment 70•9 years ago
|
||
So, as we spoke on IRC, maybe we do not need a new base image. That depends on the changes needed for bluetooth of course. But, if we only need to unpack/add new binaries we do build on the system partition, and to flash new init scripts that are part of the boot partition, then we can do all of that as part of a FOTA Gecko/Gaia update package: B2G_FOTA_PARTS env variable will control that. So Thomas, what are all the changes that we need for Bluetooth on Flame?
Flags: needinfo?(tzimmermann)
Flags: needinfo?(nhirata.bugzilla)
Comment 71•9 years ago
|
||
None. (?) I don't think there have been any Bluetooth changes recently that require base-image updates. Maybe you're talking about Sensors, but this work is delayed by the technical discussion anyway.
Flags: needinfo?(tzimmermann)
Reporter | ||
Comment 72•9 years ago
|
||
Thomas, we're showing that there's a difference between base build of flame 18Dv4 and the fullflash (fastboot flash) of a recent flame build in bug 1204617. This is why we think we may need a new base build and was exploring to see if we could potentially update using a FOTA that doesn't contain proprietary parts. Based on what you are saying, it sounds like we should see about getting a new base build. Is that correct?
Flags: needinfo?(nhirata.bugzilla) → needinfo?(tzimmermann)
Comment 73•9 years ago
|
||
https://hg.mozilla.org/releases/mozilla-b2g37_v2_2r/rev/6b4e563acaf9
status-b2g-v2.2r:
--- → fixed
Comment 74•9 years ago
|
||
Naoki, I left a comment in the other bug report to explain the current behavior.
Flags: needinfo?(tzimmermann)
Comment 76•9 years ago
|
||
I just had my first System Update on my Flame. I'm on a the nightly channel :D Does this mean the bug is fixed?
Reporter | ||
Comment 77•9 years ago
|
||
Based on Thomas's comment, we can close this bug out as FOTA is fixed via buildbot. We still need to branch out for the longer term solution for taskcluster.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 78•9 years ago
|
||
to note : The FOTA builds being made by taskcluster will be handled in bug 1218544
Comment 79•9 years ago
|
||
The Flame device updates have been broken for a while because of updates starting to be too big. Because of the way applying OTA works, there is no good solution except switching to applying Gecko/Gaia updates in recovery mode. This was done in bug 1037056 on the Buildbot instances, but we need to support this on TaskCluster also.
Attachment #8673161 -
Attachment is obsolete: true
Attachment #8682403 -
Flags: review?(wcosta)
Comment 80•9 years ago
|
||
Comment on attachment 8682403 [details] [diff] [review] Producing FOTA packages for Flame Review of attachment 8682403 [details] [diff] [review]: ----------------------------------------------------------------- ::: testing/mozharness/configs/b2g/taskcluster-phone-ota.py @@ +37,5 @@ > "env": { > "GAIA_OPTIMIZE": "1", > "WGET_OPTS": "-c -q" > }, > + "update_types": [ "ota", "fota" ], Although this script currently runs only for flame-kk, this is intended as a generic config file for OTA builds, are you sure you want to build fota for every device?
Attachment #8682403 -
Flags: review?(wcosta) → review+
Comment 81•9 years ago
|
||
(In reply to Wander Lairson Costa [:wcosta] from comment #80) > Comment on attachment 8682403 [details] [diff] [review] > Producing FOTA packages for Flame > > Review of attachment 8682403 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: testing/mozharness/configs/b2g/taskcluster-phone-ota.py > @@ +37,5 @@ > > "env": { > > "GAIA_OPTIMIZE": "1", > > "WGET_OPTS": "-c -q" > > }, > > + "update_types": [ "ota", "fota" ], > > Although this script currently runs only for flame-kk, this is intended as a > generic config file for OTA builds, are you sure you want to build fota for > every device? Well that's something we can change if we need, but I guess it will do no harm to produce OTA and FOTA. Do you see any reason we should not? Just from a QA point of view I guess it's useful to keep both on all devices, since it can help QA to check behavior of both.
Comment 82•9 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #81) > (In reply to Wander Lairson Costa [:wcosta] from comment #80) > > Comment on attachment 8682403 [details] [diff] [review] > > Producing FOTA packages for Flame > > > > Review of attachment 8682403 [details] [diff] [review]: > > ----------------------------------------------------------------- > > > > ::: testing/mozharness/configs/b2g/taskcluster-phone-ota.py > > @@ +37,5 @@ > > > "env": { > > > "GAIA_OPTIMIZE": "1", > > > "WGET_OPTS": "-c -q" > > > }, > > > + "update_types": [ "ota", "fota" ], > > > > Although this script currently runs only for flame-kk, this is intended as a > > generic config file for OTA builds, are you sure you want to build fota for > > every device? > > Well that's something we can change if we need, but I guess it will do no > harm to produce OTA and FOTA. Do you see any reason we should not? Just from > a QA point of view I guess it's useful to keep both on all devices, since it > can help QA to check behavior of both. I see no problem with that :)
Comment 83•9 years ago
|
||
https://tools.taskcluster.net/task-graph-inspector/#Pjwd3f3tTxaiKYdHktvVew/
Comment 84•9 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #83) > https://tools.taskcluster.net/task-graph-inspector/#Pjwd3f3tTxaiKYdHktvVew/ See bug 1201540 comment 86: OTA and FOTA produced out of the same Flame KK build
Comment 85•9 years ago
|
||
checkin-needed for attachment 8682403 [details] [diff] [review]: that should wait bug 1201540 to land attachment 8683110 [details] [diff] [review]
Keywords: leave-open → checkin-needed
Comment 86•9 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/5a3d69c1b2ad
Keywords: checkin-needed
Comment 87•9 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/5a3d69c1b2ad
Updated•9 years ago
|
Flags: needinfo?(bugzilla)
You need to log in
before you can comment on or make changes to this bug.
Description
•