Closed Bug 1218492 Opened 6 years ago Closed 6 years ago

Flame Fingerprint to be updated to the new base build fingerprint


(Firefox OS Graveyard :: Gaia::Build, defect)

Gonk (Firefox OS)
Not set


(firefox46 fixed)

Tracking Status
firefox46 --- fixed


(Reporter: nhirata, Assigned: nhirata)




(1 file, 1 obsolete file)

See bug 1213824 for Finger print code
Finger print needs to be adjusted for new T2M build in bug 1217582.
Assignee: nobody → nhirata.bugzilla
Blocks: 1217582
WIP patch.  Need to test.
New build, made an update patch, still need to test; creating a new build with this patch.
Attachment #8679251 - Attachment is obsolete: true
Taskcluster test build is kicked off here:

Will test later when it's done and build correctly.
Comment on attachment 8701288 [details] [diff] [review]

Review of attachment 8701288 [details] [diff] [review]:

Context is that I created a new v5 base build that can only be accessed currently via Mozilla employees here :

Asking Wesly to have the build hosted by T2M.

I tested the patch and it seems to work.  I think we'll need an interim time for T2M to host and a transition period before we disable the old fingerprint and that's why I allowed for both fingerprints.
Attachment #8701288 - Flags: review?(lissyx+mozillians)
Comment on attachment 8701288 [details] [diff] [review]

Review of attachment 8701288 [details] [diff] [review]:

::: b2g/config/flame-kk/config.json
@@ +42,4 @@
>          "MOZ_TELEMETRY_REPORTING": "1",
>          "B2G_UPDATE_CHANNEL": "nightly",
>          "GAIA_KEYBOARD_LAYOUTS": "en,pt-BR,es,de,fr,pl,zh-Hans-Pinyin,zh-Hant-Zhuyin,en-Dvorak",
> +        "FOTA_FINGERPRINTS": "qcom/flame/flame:4.4.2/KOT49H/eng.cltbld.20150527.043015:userdebug/test-keys,qcom/flame/flame:4.4.2/KOT49H/eng.naoki.20151216.105618:userdebug/test-keys"

That's good. FTR, this variable will be split over the comma, and the resulting array will serve to check that the recovery package gets applied to ONE of ALL the values.

Said otherwise, that patch will be able to produce recovery packages that can be applied on both those base systems. Said otherwise, we can get:
 (1) Gecko/Gaia FOTA package applied on v4_nightly OR v5_nightly
 (2) fullimg FOTA package applied on v4_nightly or v5_nightly

So I guess we want people running:
 (a) v4_nightly to get a FOTA fullimg package to update to v5_nightly
 (b) v5_nightly to get a FOTA Gecko/Gaia package

Hence, as long as we don't send people along an upgrade path that makes no sense, that should be good. Right now, I don't see such kind of upgrade path, but I have a poor overview of the Balrog updates states and it's starting to be a bit late.
Attachment #8701288 - Flags: review?(lissyx+mozillians) → review+
Thanks for the comments.

There's also a concern of the complexity of testing that we may have to do; hopefully we can minimize this by implementing the FOTA quickly so that we can minimize the impact.

Now that I think about it, I'm going to hold off in landing this patch until Jan.
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.