[Flame] Create Kitkat based pvtbuilds for 2.0 and 2.1

VERIFIED FIXED

Status

Release Engineering
General Automation
VERIFIED FIXED
3 years ago
2 years ago

People

(Reporter: tchung, Assigned: nthomas)

Tracking

unspecified
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.0+, b2g-v2.0 fixed, b2g-v2.1 fixed, b2g-v2.2 fixed)

Details

Attachments

(8 attachments, 4 obsolete attachments)

986 bytes, patch
catlee
: review+
mshal
: checked-in+
Details | Diff | Splinter Review
2.72 KB, patch
catlee
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
770 bytes, patch
catlee
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
9.49 KB, patch
catlee
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
2.51 KB, patch
catlee
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
655 bytes, patch
bhearsum
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
3.17 KB, patch
bhearsum
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
1.66 KB, patch
bhearsum
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
(Reporter)

Description

3 years ago
[Blocking Requested - why for this release]:

Now that we have a kitkat base image (1.4), for the Flame from T2M, we would like to generate pvtbuilds for Firefox OS engineering/QA to use.   Requesting both User and Engineering based images.

The link to base image v165 is at: https://drive.google.com/a/mozilla.com/file/d/0B7_yuXt7x6y4NE95TXVzY1NJbHc/edit?usp=sharing

I'd like to just have supported Gecko and Gaia nightly builds for 2.0 and 2.1 (aka Master/m-c) available so we can shallow flash over the base image.

Viral, Mwu, Nthomas, Catlee, what needs to be done to proceed forward?
Flags: needinfo?(vwang)
Flags: needinfo?(nthomas)
Flags: needinfo?(mwu)
(Assignee)

Comment 1

3 years ago
Looks like flame-kk.xml is the manifest to use, are we done stabilizing that ? We would need devs to port that to the 2.0 branch to do builds there.

We (RelEng) don't need to sync any new repos for master, so something like apply base image to flame, use build system to pull backup, upload backup to tooltool; add in-tree files; add config to buildbot; test in staging; deploy. (From https://wiki.mozilla.org/ReleaseEngineering/How_To/Create_new_B2G_build)
Flags: needinfo?(nthomas)

Updated

3 years ago
blocking-b2g: 2.0? → 2.0+
Whiteboard: NPOTB
(Reporter)

Comment 2

3 years ago
(In reply to Nick Thomas [:nthomas] from comment #1)
> Looks like flame-kk.xml is the manifest to use, are we done stabilizing that
> ? We would need devs to port that to the 2.0 branch to do builds there.
> 
> We (RelEng) don't need to sync any new repos for master, so something like
> apply base image to flame, use build system to pull backup, upload backup to
> tooltool; add in-tree files; add config to buildbot; test in staging;
> deploy. (From
> https://wiki.mozilla.org/ReleaseEngineering/How_To/Create_new_B2G_build)

Viral, mwu, are finalized on flame-kk.xml yet?   we are looking for next steps to get mozilla builds generated.

Comment 3

3 years ago
Not ready yet.
Flags: needinfo?(mwu)
Do we need builds for both flame.xml and flame-kk.xml on the same branch?

If not, we could just rename flame-kk.xml to flame.xml when ready.
(Assignee)

Comment 5

3 years ago
Good question! We'd need to update https://hg.mozilla.org/integration/b2g-inbound/file/default/b2g/config/flame/releng-flame.tt too, for the new base image. People would need to flash again to pick up the base image ? Would an OTA of kitkat gecko+gaia continue to work fine on jb base ?

Comment 6

3 years ago
OTA of kitkat gecko is not expected to work on JB base.

Comment 7

3 years ago
Also note: we need the latest ADSP builds possible, as fixes are going in there which impact webRTC testing.  We also need to know what version from the readme notes are going in the builds (so we can know for testing if we should be seeing fixes).
(Assignee)

Comment 8

3 years ago
(In reply to Tony Chung [:tchung] from comment #0)
> The link to base image v165 is at:
> https://drive.google.com/a/mozilla.com/file/d/0B7_yuXt7x6y4NE95TXVzY1NJbHc/
> edit?usp=sharing

Could someone either convert this to a tarball of backup-flame/, or confirm that 
  https://github.com/mozilla-b2g/device-flame/blob/master/extract-files.sh
will pull the right files if I use it (after flashing the image on my device).

Comment 9

3 years ago
Hi Michael,

I think we could prepare the 2.0 build after bug 1052865 (SIM card can't detect) fix.
Could you please help to create the branch on https://github.com/mozilla-b2g/device-flame?
I'm thinking we should have the branch like "kitkat-v2.0" and "kitkat-v1.4".
Thank you!
Flags: needinfo?(vwang) → needinfo?(mwu)
(Reporter)

Updated

3 years ago
Blocks: 1052865
No longer blocks: 1052865
Depends on: 1052865

Updated

3 years ago
Component: Gaia::Build → General Automation
Product: Firefox OS → Release Engineering
(Reporter)

Comment 10

3 years ago
(In reply to viral [:viralwang] from comment #9)
> Hi Michael,
> 
> I think we could prepare the 2.0 build after bug 1052865 (SIM card can't
> detect) fix.
> Could you please help to create the branch on
> https://github.com/mozilla-b2g/device-flame?
> I'm thinking we should have the branch like "kitkat-v2.0" and "kitkat-v1.4".
> Thank you!

hi viral, are you saying this bug is blocked by bug 1052865 landing first?   just clarifying what are next steps here and ETA on builds.

Comment 11

3 years ago
Created attachment 8479603 [details] [review]
Bug 1055305 - create flame-kk for BRANCH=v2.0

Hi Seinlin,

Could you please review the PR for branch v2.0 flame-kk?
I think we can keep device-flame same as we use for master branch.
Attachment #8479603 - Flags: review?(kli)

Updated

3 years ago
Depends on: 1054180

Comment 12

3 years ago
Hi Michael,

I think we don't need the branch in comment 9 since v2.0 can share the master branch.
So far I'm not sure we should support v1.4 branch or not.
remove the ni flag first.
Thank you.
Flags: needinfo?(mwu)

Comment 13

3 years ago
(In reply to Tony Chung [:tchung] from comment #10)
> (In reply to viral [:viralwang] from comment #9)
> > Hi Michael,
> > 
> > I think we could prepare the 2.0 build after bug 1052865 (SIM card can't
> > detect) fix.
> > Could you please help to create the branch on
> > https://github.com/mozilla-b2g/device-flame?
> > I'm thinking we should have the branch like "kitkat-v2.0" and "kitkat-v1.4".
> > Thank you!
> 
> hi viral, are you saying this bug is blocked by bug 1052865 landing first?  
> just clarifying what are next steps here and ETA on builds.

Hi Tony,

bug 1052865 already has patches with r+, I think we can provide the manifest for v2.0 now.
Thank you for your reminder.
Assignee: nobody → vwang
Comment on attachment 8479603 [details] [review]
Bug 1055305 - create flame-kk for BRANCH=v2.0

Hi Viral, I suggest you to file a new bug such as add flame-kk manifest for v2.0 branch and which blocks this bug. Let's review the manifest in new bug then. Thanks!
Attachment #8479603 - Flags: review?(kli) → review-
Attachment #8479603 - Flags: review-
Attachment #8479603 - Attachment is obsolete: true

Updated

3 years ago
Depends on: 1059092

Comment 15

3 years ago
Use bug 1059092 to create the flame-kk.xml manifest for v2.0
Assignee: vwang → administration
(Reporter)

Comment 16

3 years ago
Hi nick, Catlee

according to Viral, this would be your steps to generate the 2.0 and 2.1 KK images.  it's ready to go now since 1059092 has just merged:

=> "BRANCH=v2.0 ./config.sh flame-kk && ./build.sh" should be fine, please make sure we use base image v165 for backup-flame folder

Let us know what else releng needs.   Looking forward to those builds soon!
Flags: needinfo?(nthomas)
Flags: needinfo?(catlee)
(Assignee)

Comment 17

3 years ago
Tony, can we deprecate the flame builds and just have flame-kk ?
Flags: needinfo?(tchung)
Flags: needinfo?(nthomas)
Flags: needinfo?(catlee)
(Assignee)

Comment 18

3 years ago
Created attachment 8480256 [details] [diff] [review]
[mozharness] b2b_bumper config

This says we don't need to mirror any new repos down to git.mozilla.org.
Assignee: administration → nthomas
Status: NEW → ASSIGNED
Attachment #8480256 - Flags: review?(catlee)
(Reporter)

Comment 19

3 years ago
(In reply to Nick Thomas [:nthomas] from comment #17)
> Tony, can we deprecate the flame builds and just have flame-kk ?

not yet, id like to give the flame-kk images a shot before we move off of flame-jb.   also, the flame-kk image has not been widespread yet, so many engineers and community still are using it.

but i certainly agree we should have a EOL plan. 

Thanks,
Tony
Flags: needinfo?(tchung)
(Assignee)

Comment 20

3 years ago
I tried to create backup-flame/ without having to pull all the source in, using a flame flashed with the v165 base, then 
 mkdir -p device/tcm
 cd device/tcm
 git clone https://github.com/mozilla-b2g/device-flame flame
 cd flame
 ./extract-files.sh

But it ends up with
 [lots of files pulled from /system]
 pull: /system/system.ver -> ../../../backup-flame/system/system.ver
 pull: /system/build.prop -> ../../../backup-flame/system/build.prop
 1573 files pulled. 0 files skipped.
 4872 KB/s (269865462 bytes in 54.082s)
 Pulling files from ../../../backup-flame
 Pulling "libalsa-intf.so"
 cp: ../../../backup-flame/system/lib/libalsa-intf.so: No such file or directory
 Failed to pull libalsa-intf.so. Giving up.

Could you please advise if I'm doing something incorrectly, or provide a backup-flame.tar.xz from the v165.
Flags: needinfo?(vwang)

Comment 21

3 years ago
Hi Nick,

Please assign the branch as follow command:
git clone https://github.com/mozilla-b2g/device-flame flame --branch kitkat
Flags: needinfo?(vwang)
(Assignee)

Comment 22

3 years ago
Thanks viral, I must have missed that in the manifest. 

I've extracted the files and uploaded them to tooltool. A little further down the track b2g/config/flame-kk/releng-flame-kk.tt should look like this:
[
{
"size": 118323840, 
"digest": "f18aabdf19ce8b630d9724ecf7d3a130e6b020a9e4d4e222bba6d4b3d4303c30dc3c5162a55b0f85de926077be59e17cfe49eb7314dca7e1bb5741a260148083", 
"algorithm": "sha512", 
"filename": "backup-flame.tar.xz"
}
]

Updated

3 years ago
Attachment #8480256 - Flags: review?(catlee) → review+
(Assignee)

Updated

3 years ago
Depends on: 1060081
Created attachment 8480880 [details] [diff] [review]
[m-c] flamekk

Differences from flame config:

$ diff flame/releng-flame.tt flame-kk/releng-flame-kk.tt 
2,3c2,3
< {"size": 149922032,
< "digest": "8d1a71552ffee561e93b5b3f1bb47866592ab958f908007c75561156430eb1b85a265bfc4dc2038e58dda0264daa9854877a84ef3b591c9ac2f1ab97c098e61e",
---
> {"size": 118323840,
> "digest": "f18aabdf19ce8b630d9724ecf7d3a130e6b020a9e4d4e222bba6d4b3d4303c30dc3c5162a55b0f85de926077be59e17cfe49eb7314dca7e1bb5741a260148083",


$ diff flame/config.json flame-kk/config.json
3c3
<     "tooltool_manifest": "releng-flame.tt",
---
>     "tooltool_manifest": "releng-flame-kk.tt",
34c34
<     "b2g_manifest": "flame.xml",
---
>     "b2g_manifest": "flame-kk.xml",
Attachment #8480880 - Flags: review?(catlee)
Created attachment 8480882 [details] [diff] [review]
[buildbot-configs] buildbot_flamekk

There's a few things I'm not sure about here:

1) Are the enable_nightly lines needed? It sounds like from #c1 maybe not

2) Do the flame-kk and flame-kk_eng platforms need to go in this for loop?

# b2g 1.4+
for name, branch in items_before(BRANCHES, 'gecko_version', 30):
    for p in ('flame', 'flame_eng', 'linux64_gecko-debug',
              'macosx64_gecko-debug', 'linux32_gecko-debug', 'win32_gecko-debug',
              'emulator-kk', 'emulator-kk-debug'):
Attachment #8480882 - Flags: review?(catlee)
bhearsum, is there a concern here that the update channel for flame and flame-kk might get mixed up? How do I verify that they are separate?
Flags: needinfo?(bhearsum)
(Assignee)

Comment 26

3 years ago
re updates, perhaps we should be submitting into balrog with flame-kk (this may just work, haven't checked), and devices querying with %PRODUCT% of flame-kk (harder!). In the meantime we could leave nightly builds off.
Assignee: nthomas → mshal
Created attachment 8480893 [details] [diff] [review]
[buildbot-configs] buildbot_flamekk

Turning nightlies off per #c26. See also my question 2 in #c24
Attachment #8480882 - Attachment is obsolete: true
Attachment #8480882 - Flags: review?(catlee)
Attachment #8480893 - Flags: review?(catlee)
(Assignee)

Comment 28

3 years ago
I flashed mshal's eng build from staging onto my flame, and it queried for updates with this:
 https://aus4.mozilla.org/update/3/B2G/34.0a1/20140828163852/flame/en-US/default/Boot2Gecko%202.1.0.0-prerelease/default/default/update.xml?force=1

The .../flame/en-US/default/... is the relevant part, because it's the same as the existing flame jellybean builds. default is normal for a non-nightly, the in tree patch would have it set to 'nightly' - same as JB again. So definitely work to do here, as we can't mix updates between JB and KK.

Updated

3 years ago
Attachment #8480880 - Flags: review?(catlee) → review+
Comment on attachment 8480893 [details] [diff] [review]
[buildbot-configs] buildbot_flamekk

Review of attachment 8480893 [details] [diff] [review]:
-----------------------------------------------------------------

probably need to adjust try slaves below as well?
Attachment #8480893 - Flags: review?(catlee) → review+

Comment 30

3 years ago
Hi!

I've built several 2.0 betas on various platforms in the last weeks.

As its short before release and the manifest got updated I thought its time for a -kk build.

But unfortunately I'm not able to create a new "backup-flame" with the now needed files because I have no access to a v165 image or something similar (or the proprietary sources..).

I'm not authorized to access bug #1019011 (https://bugzilla.mozilla.org/show_bug.cgi?id=1019011) so that I could add my name there for access to
https://secure.pub.build.mozilla.org/tooltool/pvt/build .

tooltool-uploads.pub.build.mozilla.org propably is only for uploads
http://runtime-binaries.pvt.build.mozilla.org/tooltool/sha512 seems private.

No login for
https://intranet.mozilla.org/B2G_Team/Flame
as for
https://pvtbuilds.mozilla.org/pvt/(mozilla.org/b2gotoro/tinderbox-builds/b2g-inbound-flame-eng/latest/ ?).

Nothing like that to find at
http://ftp.mozilla.org/pub/mozilla.org/b2g/ .

Also no access to
https://drive.google.com/a/mozilla.com/file/d/0B7_yuXt7x6y4NE95TXVzY1NJbHc/edit?usp=sharing
(and no google account, but tried with a friend which has - but private file).

Can you please help me?
And aren't there more people with that problem?

I have only found the question what to do with the v165 flame image at b2g qa meetings (https://wiki.mozilla.org/B2G/QA/Meetings/2014-08-20) but not the answer.

I'm new on mobile os builds, but did many openwrt builds and tests, and i.e. was able to add support for a device (without the need for binary blobs there ;-) ).
And if time allows I would be happy to be able to contribute a bit here too.

Thank you!
(Assignee)

Comment 31

3 years ago
Hi Alexander, at the moment we are getting started with KitKat for flame, and this bug is about standing up builds on the Mozilla build infrastucture. At the end of it we'll have builds for QA to use, and hopefully daily updates of gecko+gaia for interested people like yourself. But the base image from Thundersoft will need to be released by them, and I don't have any information on when or if that will happen.
(In reply to Chris AtLee [:catlee] from comment #29)
> Comment on attachment 8480893 [details] [diff] [review]
> [buildbot-configs] buildbot_flamekk
> 
> Review of attachment 8480893 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> probably need to adjust try slaves below as well?

Are you talking about this section in b2g_config.py?

######## try
# Try-specific configs
# This is a path, relative to HGURL, where the repository is located
# HGURL  repo_path should be a valid repository
BRANCHES['try']['repo_path'] = 'try'

I didn't see the original flame or flame_eng builds there - would we need to add them all? I'm not entirely sure what that does or if it's needed.
Flags: needinfo?(catlee)
Created attachment 8480980 [details] [diff] [review]
[buildbot-configs] buildbot_flamekk_debug

Small followup - lightsofapollo also requested a debug version of flame-kk_eng. Looks like all this requres is another copy in b2g_config.py with a --debug arg so mozharness will enable B2G_DEBUG in the environment.
Attachment #8480980 - Flags: review?(catlee)

Comment 34

3 years ago
(In reply to Nick Thomas [:nthomas] from comment #31)
> Hi Alexander, at the moment we are getting started with KitKat for flame,
> and this bug is about standing up builds on the Mozilla build infrastucture.
> At the end of it we'll have builds for QA to use, and hopefully daily
> updates of gecko+gaia for interested people like yourself. But the base
> image from Thundersoft will need to be released by them, and I don't have
> any information on when or if that will happen.

So sending (or giving access to) the already avalaible v165 base image from the link above to i.e. me is a problem? I don't see that (as long as you don't handle the source..).
(By the way - I don't need the daily builds from you, I would do them myself on demand as soon as I have the binary blobs.)
The v123 one was also published by you: https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame#Updating_your_Flame%27s_software. This could take a while if we wait for Thundersoft.. .

But you're right the bug is about building the -kk on Mozilla's infrastructure. Sorry if that created any inconvenience. Propably I should have created a separate "bug". (It was my first Bugzilla comment, have to get used to it.. .) But with the link here and only access needed I thought its a good place to ask (I know how to extract the files from the system ext4 sparse image).

Comment 35

3 years ago
(In reply to Nick Thomas [:nthomas] from comment #8)
> (In reply to Tony Chung [:tchung] from comment #0)
> > The link to base image v165 is at:
> > https://drive.google.com/a/mozilla.com/file/d/0B7_yuXt7x6y4NE95TXVzY1NJbHc/
> > edit?usp=sharing
> 
> Could someone either convert this to a tarball of backup-flame/, or confirm
> that 
>   https://github.com/mozilla-b2g/device-flame/blob/master/extract-files.sh
> will pull the right files if I use it (after flashing the image on my
> device).

I would do:
simg2img system.img system.raw
sudo mount -t ext4 -o loop sys.raw sys/
and then copy the contents of sys/system/ to backup-flame/system/
inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/85740fcec8e4
(Reporter)

Comment 37

3 years ago
(In reply to Alexander Stadler from comment #34
> So sending (or giving access to) the already avalaible v165 base image from
> the link above to i.e. me is a problem? I don't see that (as long as you
> don't handle the source..).
> (By the way - I don't need the daily builds from you, I would do them myself
> on demand as soon as I have the binary blobs.)
> The v123 one was also published by you:
> https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/
> Flame#Updating_your_Flame%27s_software. This could take a while if we wait
> for Thundersoft.. .

Hi Alexander,  
thank you for inquiring, and showing great interest!   v123 image has actually cleared our legal agreement for redistribution by Mozilla/Thundersoft to the public.  But v165 (the Kk one), has not gone through that step yet, which is why we can't publicly redistribute it.   I do apologize for the inconvenience and trust me when i say that i wish we could be handing our contributors the needed tools like Flame images as soon as we can.  As soon as we can update the image to the public, we will update that MDN site.  thanks for your patience and please continue to contribute where you can!

Comment 38

3 years ago
(In reply to Tony Chung [:tchung] from comment #37)
> (In reply to Alexander Stadler from comment #34

Thanks for your response!
Is there a supposed timeframe for v165 clearance?
Wouldn't it be easier if only distributing the needed files or the system folder instead the whole image? (Publishing a whole installable OS surely should be considered more carefully, as it has a much wider userbase, and so also would need more thorough testing than binary blobs I think.) So shouldn't this task be split into two? Because this issue will repeat and doesn't it slow down development if you need to wait for whole os releases just to be able to use updated drivers (also internally).
Or do I have to get one of you ;-)? Because in my opinion public is much more than handing it over to a named user for testing, so i.e. to me. No gain for anyone if only your QA can and has to test. But you surely are aware of that.. .
https://hg.mozilla.org/mozilla-central/rev/85740fcec8e4
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
(In reply to Nick Thomas [:nthomas] from comment #26)
> re updates, perhaps we should be submitting into balrog with flame-kk (this
> may just work, haven't checked), and devices querying with %PRODUCT% of
> flame-kk (harder!). In the meantime we could leave nightly builds off.

This part of the update URL comes from PRODUCT_DEVICE in https://github.com/mozilla-b2g/device-flame/blob/master/flame.mk (you can see the full URL specification at http://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#568. Changing PRODUCT_DEVICE would be the easiest and clearest way to do this. Perhaps we should always append some Android version string to it?

I suggest we take this to another bug though.
Flags: needinfo?(bhearsum)
Oops, should have marked this [leave open], since we still need to land the mozharness & buildbot-configs changes.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: NPOTB → NPOTB [leave open]
From IRC, it sounds like we're ok wrt try in the config:

21:03:31 <catlee-away> I'd copy flame's behaviour
21:03:38 <catlee-away> if flame isn't there, don't worry baout flame-kk
Flags: needinfo?(catlee)
Comment on attachment 8480256 [details] [diff] [review]
[mozharness] b2b_bumper config

checked-in nthomas' mozharness patch: https://hg.mozilla.org/build/mozharness/rev/36c0d9e32c68
Attachment #8480256 - Flags: checked-in+
patch(es) in production :)
I think all that's left here is to land the two buildbot-configs patches (assuming the other one gets r+'d). nthomas, can you land those?
Flags: needinfo?(nthomas)
Forgot to say that sources.xml was generated in b2g-inbound (I think correctly) - just waiting for the merge to m-c.
(Reporter)

Comment 47

3 years ago
Hey guys, when this is all done, would the builds location be at: https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/?   or someplace else?
(Assignee)

Comment 48

3 years ago
Tony, that's right. We'll get a new set of directories in there using 'flame-kk' instead of 'flame' in the name.
Status: REOPENED → ASSIGNED
Flags: needinfo?(nthomas)
(Assignee)

Comment 49

3 years ago
Created attachment 8482044 [details] [diff] [review]
[buildbotcustom] Add more shortening and mix well

Builder names like b2g_mozilla-b2g32_v2_0_flame-kk_eng-debug_dep are over the 30 character limit, so we need more options to shrink the name.
Attachment #8482044 - Flags: review?(catlee)
(Assignee)

Comment 50

3 years ago
Created attachment 8482049 [details] [diff] [review]
[buildbot-configs] Combined patch

This combines the two earlier configs patches (attachments 8480893 & 8480980) with some tweaks:
* excludes m-b2g30_v1_4, no request for builds there
* adds explicit nightly disabling to commented mozilla-aurora block, and to mozilla-b2g32_v2_0  (hopefully we'll swap this to True later, and it will be obvious where to do so then)
* on the debug build, swaps to periodic rather than on every push (matches emulator-kk-debug)

It yields new builders for branches b2g-i, m-i, m-c, m-b2g32_v2_0, fx-team, graphics, jamun, cypress, cedar, pine, graphics, ash, maple, oak, and gum, like so:

b2g_<branch>_flame-kk_periodic
b2g_<branch>_flame-kk_eng_dep
b2g_<branch>_flame-kk_eng-debug_periodic
Attachment #8480893 - Attachment is obsolete: true
Attachment #8480980 - Attachment is obsolete: true
Attachment #8480980 - Flags: review?(catlee)
Attachment #8482049 - Flags: review?(catlee)
(Assignee)

Comment 51

3 years ago
FYI, we're going to have conflicts with patches in bug 1029851, so landing this may be a little bumpy and require some checks after merge day.
(Assignee)

Comment 52

3 years ago
Created attachment 8482083 [details] [diff] [review]
[mozilla-b2g32_v2_0]  In-tree for 2.0 builds

For config.json - different update channel and l10n repos, from merging the difference in flame configs into flame-kk. Tooltool manifest is a direct copy.
Attachment #8482083 - Flags: review?(catlee)

Updated

3 years ago
Attachment #8482044 - Flags: review?(catlee) → review+
Comment on attachment 8482049 [details] [diff] [review]
[buildbot-configs] Combined patch

Review of attachment 8482049 [details] [diff] [review]:
-----------------------------------------------------------------

::: mozilla/b2g_config.py
@@ +1428,5 @@
>  BRANCHES['mozilla-central']['platforms']['wasabi']['enable_nightly'] = True
>  BRANCHES['mozilla-central']['platforms']['flame']['enable_nightly'] = True
>  BRANCHES['mozilla-central']['platforms']['flame_eng']['enable_nightly'] = True
> +BRANCHES['mozilla-central']['platforms']['flame-kk']['enable_nightly'] = False
> +BRANCHES['mozilla-central']['platforms']['flame-kk_eng']['enable_nightly'] = False

do you need flame-kk_eng-debug here too?
Attachment #8482049 - Flags: review?(catlee) → review+

Updated

3 years ago
Attachment #8482083 - Flags: review?(catlee) → review+
(Reporter)

Comment 54

3 years ago
Hi nick, Catlee, 
any more progress and ETA on this landing?   waiting for these builds on a daily basis now.  (and now we're on mozilla-aurora, we'll need 2.1 there landed)
Flags: needinfo?(nthomas)
Flags: needinfo?(catlee)
(Assignee)

Comment 55

3 years ago
Tony, just need to land things at this point, and have TBPL deploy their support (gave them a nudge).
Flags: needinfo?(nthomas)
(Assignee)

Comment 56

3 years ago
Comment on attachment 8482044 [details] [diff] [review]
[buildbotcustom] Add more shortening and mix well

https://hg.mozilla.org/build/buildbotcustom/rev/a94a28a36c3f
Attachment #8482044 - Flags: checked-in+
(Assignee)

Comment 57

3 years ago
Comment on attachment 8482083 [details] [diff] [review]
[mozilla-b2g32_v2_0]  In-tree for 2.0 builds

https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/9651864ff035
Attachment #8482083 - Flags: checked-in+
(Assignee)

Comment 58

3 years ago
Comment on attachment 8482049 [details] [diff] [review]
[buildbot-configs] Combined patch

(In reply to Chris AtLee [:catlee] from comment #53)
> > +BRANCHES['mozilla-central']['platforms']['flame-kk']['enable_nightly'] = False
> > +BRANCHES['mozilla-central']['platforms']['flame-kk_eng']['enable_nightly'] = False
> 
> do you need flame-kk_eng-debug here too?

I left it out because False is the default for nightlies. The non-debug builds will get switched to True later.

Merged to current code and landed on default:
https://hg.mozilla.org/build/buildbot-configs/rev/f3a499341fb0

Will go live on the next reconfig, so I'm gambling that TBPL will be updated first. If not we can hide on TBPL.
Attachment #8482049 - Flags: checked-in+
(Assignee)

Comment 59

3 years ago
Comment on attachment 8480880 [details] [diff] [review]
[m-c] flamekk

Landed at comment #36.
Attachment #8480880 - Flags: checked-in+
Merged to production, and deployed.
(In reply to Nick Thomas [:nthomas] from comment #57)
> Comment on attachment 8482083 [details] [diff] [review]
> [mozilla-b2g32_v2_0]  In-tree for 2.0 builds
> 
> https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/9651864ff035

Flame-KK builds on b2g32 are all dying with the error in the log below. I've hidden them for now.
https://tbpl.mozilla.org/php/getParsedLog.php?id=47406078&tree=Mozilla-B2g32-v2.0
catlee pointed out that config.json has a stray comma. Remove it:
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/2537ab191112
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #62)
> catlee pointed out that config.json has a stray comma. Remove it:
> https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/2537ab191112

Builds are green again. Unhidden on b2g32.
(Assignee)

Comment 64

3 years ago
Thanks for the fix Ryan. As well as being green we're uploading sane sized files to sensible locations.

Still to do:
* get update query different for flame-kk, see comment #40, will file a dep bug
* turn on nightly builds on b2g32, m-a, m-c
Flags: needinfo?(catlee)
(Assignee)

Updated

3 years ago
Depends on: 1063237
(Assignee)

Comment 65

3 years ago
BTW, retention for flame-kk tinderbox-builds is the same as flame, ie 12 weeks.
Assignee: mshal → nthomas
(Reporter)

Comment 66

3 years ago
Hey guys, how close are we on this?  will we be seeing nightly builds by tomorrow?
(Assignee)

Comment 67

3 years ago
We have tinderbox-builds already, eg
https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/b2g-inbound-flame-kk/
https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/b2g-inbound-flame-kk-eng/
https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/b2g-inbound-flame-kk-eng-debug/

Nightlies are blocked on bug 1063237, unless we want to disable the updater or something.
See Also: → bug 1064765
(Reporter)

Comment 68

3 years ago
(In reply to Nick Thomas [:nthomas] from comment #26)
> re updates, perhaps we should be submitting into balrog with flame-kk (this
> may just work, haven't checked), and devices querying with %PRODUCT% of
> flame-kk (harder!). In the meantime we could leave nightly builds off.

Per IRC discussion, QA is okay with decoupling the OTA portion for now just to trade off getting flame KK images available for 2.0 and 2.1.   (2.1 higher priority is that matters).   but we'd still want bug 1063237, landed as soon as possible; pending the dependencies in the other bug.

Updated

3 years ago
Blocks: 1067871

Updated

3 years ago
Blocks: 1067875
(Assignee)

Comment 69

3 years ago
tchung, should we be updating the base image from v165 to something more recent ?
Flags: needinfo?(tchung)
(Reporter)

Comment 70

3 years ago
(In reply to Nick Thomas [:nthomas] from comment #69)
> tchung, should we be updating the base image from v165 to something more
> recent ?

Yes!  there is a 2.0 image now called v180.  Please use this one.
https://intranet.mozilla.org/QA/B2G_Tips_and_Tricks#latest_OEM_KitKat_Base_Image_:_v180
Flags: needinfo?(tchung)
(Assignee)

Comment 71

3 years ago
Created attachment 8492844 [details] [diff] [review]
[gecko] Update to v180 image

v180 notes:
* d/l and flash onto flame
* extract with steps in comment #20, modified by comment #21
* compress: cd ../../..; tar -vcJf backup-flame.tar.xz backup-flame/
* upload to tooltool (https://wiki.mozilla.org/ReleaseEngineering/Applications/Tooltool#How_to_upload_to_tooltool)

NB: the v180 image is an engineering build, I hope that's going to work for a non-eng build.
Attachment #8492844 - Flags: review?(bhearsum)
(Assignee)

Comment 72

3 years ago
Created attachment 8492845 [details] [diff] [review]
[buildbot-configs] Enable flame-kk nightlies, disable flame nightlies on b2g32 and newer

Change in builders:
< b2g_mozilla-central_flame_nightly ScriptFactory
< b2g_mozilla-central_flame_eng_nightly ScriptFactory
< b2g_mozilla-b2g32_v2_0_flame_nightly ScriptFactory
< b2g_mozilla-b2g32_v2_0_flame_eng_nightly ScriptFactory
< b2g_mozilla-aurora_flame_nightly ScriptFactory
< b2g_mozilla-aurora_flame_eng_nightly ScriptFactory
--
> b2g_mozilla-central_flame-kk_nightly ScriptFactory
> b2g_mozilla-central_flame-kk_eng_nightly ScriptFactory
> b2g_mozilla-b2g32_v2_0_flame-kk_nightly ScriptFactory
> b2g_mozilla-b2g32_v2_0_flame-kk_eng_nightly ScriptFactory
> b2g_mozilla-aurora_flame-kk_nightly ScriptFactory
> b2g_mozilla-aurora_flame-kk_eng_nightly ScriptFactory

Deployment strategy
* create a rule for product=B2G, buildTarget=flame, buildID < [last nightly], which points at the current dated blob (one per branch, higher priority than existing rule for branch)
* land + deploy this patch
Attachment #8492845 - Flags: review?(bhearsum)
Comment on attachment 8492844 [details] [diff] [review]
[gecko] Update to v180 image

Review of attachment 8492844 [details] [diff] [review]:
-----------------------------------------------------------------

I can't imagine why this wouldn't work with user builds. AFAIK, eng vs user is mostly Gaia differences.
Attachment #8492844 - Flags: review?(bhearsum) → review+
Comment on attachment 8492845 [details] [diff] [review]
[buildbot-configs] Enable flame-kk nightlies, disable flame nightlies on b2g32 and newer

Review of attachment 8492845 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Nick Thomas [:nthomas] from comment #72)
> Deployment strategy
> * create a rule for product=B2G, buildTarget=flame, buildID < [last
> nightly], which points at the current dated blob (one per branch, higher
> priority than existing rule for branch)
> * land + deploy this patch

Sounds good to me. At some point we'll probably want to figure out a retirement strategy for rules such as this.
Attachment #8492845 - Flags: review?(bhearsum) → review+
Comment on attachment 8492845 [details] [diff] [review]
[buildbot-configs] Enable flame-kk nightlies, disable flame nightlies on b2g32 and newer

Review of attachment 8492845 [details] [diff] [review]:
-----------------------------------------------------------------

Hmm, you're not actually flipping plain flame to false here. r=me as long as you do that when you land.
Duplicate of this bug: 1071162
(Assignee)

Comment 77

3 years ago
You're right. Change of plan anyway, we have to support both for a while. :-(
(Assignee)

Comment 78

3 years ago
Created attachment 8493422 [details] [diff] [review]
[tools] balrog submission to separate blob for kitkat

Put on your hack-sensitive sunglasses ...

* both JB and KK query with 'flame' for build target
* JB have '(SDK 18)' or less in OS_VERSION, KK have '(SDK 19)'
* so we have to use a rule to point at different blobs

* at balrog submission, create blobs named like B2G-mozilla-aurora-kitkat-nightly-latest, with this content:
{
  "platforms": {
    "flame-kk": {
      "locales": {
        "en-US": {
          "buildID": "20140922073433",
          "platformVersion": "34.0a2",
          "displayVersion": "34.0a2",
          "appVersion": "34.0a2",
          "completes": [
            {
              "fileUrl": "http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-aurora/b2g-flame-gecko-update.mar",
              "from": "*",
              "hashValue": "4aa636b407f2800173305697...",
              "filesize": 70981888
            }
          ]
        }
      }
    },
    "flame": {
      "alias": "flame-kk"
    }
  },
  "hashFunction": "sha512",
  "name": "B2G-mozilla-aurora-kitkat-nightly-latest",
  "schema_version": 3
}
* the alias handles the disconnect between target at build and query time
* tested in staging for kitkat case, should be no-change for everything else

When we turn off JB builds we can revert the cli.py hunk, modify the SDK 19 specific rule to be for 18 and lower and point at the last update.
Attachment #8493422 - Flags: review?(bhearsum)
(Assignee)

Comment 79

3 years ago
Comment on attachment 8492844 [details] [diff] [review]
[gecko] Update to v180 image

https://hg.mozilla.org/integration/b2g-inbound/rev/eae3a4ef42fc
https://hg.mozilla.org/releases/mozilla-aurora/rev/48a77e1433c3
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/ac23a3d2b027
Attachment #8492844 - Flags: checked-in+
Comment on attachment 8493422 [details] [diff] [review]
[tools] balrog submission to separate blob for kitkat

Review of attachment 8493422 [details] [diff] [review]:
-----------------------------------------------------------------

Looks fine to me for a temporary hack. I can't figure out why we can't also back out the platforms.py part of this when JB goes away, though. At that point, won't kitkat be using B2G-mozilla-aurora-nightly-latest, which will only have "flame" in it?
Attachment #8493422 - Flags: review?(bhearsum) → review+
https://hg.mozilla.org/mozilla-central/rev/eae3a4ef42fc
(Assignee)

Comment 82

3 years ago
Comment on attachment 8493422 [details] [diff] [review]
[tools] balrog submission to separate blob for kitkat

https://hg.mozilla.org/build/tools/rev/9832742ed555

(In reply to Ben Hearsum [:bhearsum] from comment #80)
> Looks fine to me for a temporary hack. I can't figure out why we can't also
> back out the platforms.py part of this when JB goes away, though. At that
> point, won't kitkat be using B2G-mozilla-aurora-nightly-latest, which will
> only have "flame" in it?

The target in the b2g build system is flame-kk, which passes right through to platform name in the blob. We could modify that before calling the submitter, or leave the mapping part in.
Attachment #8493422 - Flags: checked-in+
(Assignee)

Comment 83

3 years ago
Comment on attachment 8492845 [details] [diff] [review]
[buildbot-configs] Enable flame-kk nightlies, disable flame nightlies on b2g32 and newer

Default + production:
https://hg.mozilla.org/build/buildbot-configs/rev/1017dcbb4a69
https://hg.mozilla.org/build/buildbot-configs/rev/8df139e015cf

Deployed to masters. And I've locked the updates for m-c, m-a, and m-b2g32 to the 2014092304020x nightlies (last one before this change), as a precaution.
Attachment #8492845 - Flags: checked-in+
(Assignee)

Updated

3 years ago
Depends on: 1072048
(Assignee)

Comment 84

3 years ago
Status update - I ran nightlies on m-a rev 96e15bbed7ab, but the machines didn't free enough space before hand, bug 1072048 to fix that up. 

The regular 4pm nightlies may avoid that fate, some have completed, eg
 https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-aurora-flame-kk/

NB: OTA is not yet configured for flame-kk, flame jb updates are frozen at 2014092304020x.
(Assignee)

Comment 85

3 years ago
Status
* nightlies worked at 4pm
* for non-eng builds:
** set up rules in balrog for kk updates on all three branches, verified m-c and m-a work, m-a and m-b2g32 should work after next nightly
** verified flame-jb builds are still pointed to flame-jb builds, unfroze updates
** no updates supported for eng builds

* builds can be found in these directories:
master/2.2
 https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-central-flame-kk/
 https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-central-flame-kk-eng/
2.1
 https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-aurora-flame-kk/
 https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-aurora-flame-kk-eng/
2.0
 https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-b2g32_v2_0-flame-kk/
 https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-b2g32_v2_0-flame-kk-eng/

So I think we're done. Lets cover any other issues in followup bugs, including any transition strategy for JB users, and turning off JB builds.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago3 years ago
Resolution: --- → FIXED
(Assignee)

Updated

3 years ago
Blocks: 1072111
(Reporter)

Comment 86

3 years ago
Super duper thanks for this, Nick and Ben!   i went ahead and full flashed a build, and it's working great for me so far.   Next time you're in town, drinks are on me!
status-b2g-v2.0: --- → fixed
status-b2g-v2.1: --- → fixed
status-b2g-v2.2: --- → fixed
Whiteboard: NPOTB [leave open]
Something here landed in production today: https://wiki.mozilla.org/ReleaseEngineering/Maintenance#Reconfigs_.2F_Deployments
(Assignee)

Comment 88

3 years ago
Not actually, the reconfig script just doesn't know how do deal with changes that got transplanted to production already.
(Reporter)

Updated

3 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.