Flame Fingerprint to be updated to the new base build fingerprint

RESOLVED FIXED

Status

Firefox OS
Gaia::Build
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: nhirata, Assigned: nhirata)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(firefox46 fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

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
Created attachment 8679251 [details] [diff] [review]
bug_1218492_fingerprint_update_WIP.patch

WIP patch.  Need to test.
Created attachment 8701288 [details] [diff] [review]
bug_1218492_fingerprint_update.patch

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:
https://tools.taskcluster.net/task-inspector/#Klig12ESSiy3-ipgluKhVw/

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

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 : 
https://drive.google.com/drive/folders/0B_0LdM1CVycIeXlobjdzRTM1SDg

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]
bug_1218492_fingerprint_update.patch

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, https://github.com/mozilla-b2g/B2G/blob/a83900b66096b22cd1fd2f340e09461710ec4d0f/tools/update-tools/update_tools.py#L927 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.
Keywords: checkin-needed

Comment 7

2 years ago
https://hg.mozilla.org/integration/b2g-inbound/rev/6a5db1bf699c
Keywords: checkin-needed

Comment 8

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/6a5db1bf699c
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox46: --- → fixed
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.