Closed Bug 1085759 Opened 5 years ago Closed 5 years ago

Update base image for flame-kk builds to v188-1

Categories

(Release Engineering :: General, defect, P2)

x86
All
defect

Tracking

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

RESOLVED FIXED
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed
b2g-v2.2 --- fixed

People

(Reporter: nthomas, Assigned: nthomas)

References

()

Details

(Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2280] , NPOTB)

Attachments

(1 file)

tchung, flame-kk builds are currently on v180. Is v188 ready/good enough to replace it ?
Flags: needinfo?(tchung)
(In reply to Nick Thomas [:nthomas] from comment #0)
> tchung, flame-kk builds are currently on v180. Is v188 ready/good enough to
> replace it ?

not yet.  lets hold off a little longer, because rumor is the GA version is coming soon for the flame.  I give it a week.
Flags: needinfo?(tchung)
Ok, waiting for more info.
Summary: Update base image for flame-kk builds to v188 → Update base image for flame-kk builds
Hi Tony and Nick:

Just would like to hear your view, do you think it might be a good idea to update pvt once there is a new SW base released from vendor? Meaning we update to v184/v188 once get it, despite the quality (of course we still expect certain level quality at this stage) and QA test progress?

The pro I see is, we can keep status of pvt and base image aligned, so avoid unnecessary confusion when people see different behavior between based image and pvt full image.

Of course the con/risk is we might downgrade pvt SW quality if vendor does it in base image.

So to me it's a selection that which one we would like to prioritize, pvt SW quality/stability, or the consistency of pvt and base image. How do you think?

btw what's the "GA version" you mentioned, Tony?
I'd defer to Tony/QA for most of this. 

For us it's not too much work to update the base image, but we can't promise same day as the request. We can definitely support updating more rapidly than we are now, but hopefully not more than one/twice a week. It would also be possible to make this self-serve for a developer or someone else in the B2G org to do.
Thanks Thomas, in this stage I would say "at most" we might need to update it once a week, and in fact I expect much lower frequency. (maybe twice 2 month or even fewer)

@Tony: would you share your view? I discussed this with some people in TPE and we tend to prioritize the consistency of vendor's base image and pvt SW (after all Flame is more like a development device, than a consumer product), but also would like to hear the opinion from quality before any conclusion.
Flags: needinfo?(tchung)
Duplicate of this bug: 1088814
hi guys, sorry for the late ping.  since my initial "hold off" note till now, a lot of offline discussion happened.  As of this moment, i think we should go ahead and put in v188-1 (UserDebug image) as part of the builds.

There are some specifics that Shawn has brought up (see bug 1088814 to start), that would require the backup files to be updated as part of the build.   ni? on shawn to make sure those files are clear what is needed if we are to repackage v188 and full flashing would cover.  

Once we get that list from Shawn, i am giving the green light for releng to continue this work.
Flags: needinfo?(tchung)
Flags: needinfo?(shuang)
Flags: needinfo?(nthomas)
Nick knows how to update backup-flame folder for auto build system.
https://bugzilla.mozilla.org/show_bug.cgi?id=1088814#c1
The file lists depend on the script, "device/flame/extract-files.sh".

My intention is to:
1. Update v188 files into backup-flame folder for PVT build
2. Have a better way to indicate current PVT backup-flame folder is using which base image version. Maybe we can have a note into build manifest? (No-Jun mentioned in other mail thread, Bootloader value still said v188, this may confuse people, it doesn't reflect the fact they are using v180 older HAL files).
Flags: needinfo?(shuang)
Could we mark the base image library reversion somewhere?
Otherwise I need to compare the library binary size between pvt image and base image.
Hi Nick:

Per comment#7 and comment#8 I guess we are ready to update PVT w/ v188 SW, right? Would you help on that? 

Thank you.
Starting on this using UserDebug Image: v188-1.
Assignee: nobody → nthomas
Flags: needinfo?(nthomas)
Priority: -- → P2
This adds a 'comment' to the manifest, it's not on device but hopefully it helps people inspect quickly what is being used.

Doc:
 mkdir -p device/tcm
 cd device/tcm
 git clone https://github.com/mozilla-b2g/device-flame flame --branch kitkat
 cd flame
 ./extract-files.sh

 cd ../../..; tar -vcJf backup-flame.tar.xz backup-flame/
 mkdir upload
 mv backup-flame.tar.xz upload
 wget https://github.com/mozilla/build-tooltool/raw/master/tooltool.py
 chmod +x tooltool.py 
 ./tooltool.py distribute --folder upload \
   --message "Bug 1085759, update flame-kk to base v188-1" \
   --user nthomas --host tooltool-uploads.pub.build.mozilla.org \
   --path "/tooltool/uploads/nthomas/pvt"
Attachment #8512413 - Flags: review?(catlee)
Attachment #8512413 - Attachment description: [mozilla-inbound] Update to v188-1 → [b2g-inbound] Update to v188-1
Wesly, tchung - how far should this be uplifted ? All the way to 2.0, or stop at 2.1 ?
(In reply to Nick Thomas [:nthomas] from comment #13)
> Wesly, tchung - how far should this be uplifted ? All the way to 2.0, or
> stop at 2.1 ?

2.0, 2.1, and master is my opinion.   we will still have users on 2.0 that use the flame.
[Blocking Requested - why for this release]:

this is external tracking but needs to be blocking 2.1 because it is necessary for the correct testing enviroment on flame.
blocking-b2g: --- → 2.1?
Flags: needinfo?(bbajaj)
blocking-b2g: 2.1? → 2.1+
Flags: needinfo?(bbajaj)
Blocking as QA needs this to test correct 2.1 builds.
Attachment #8512413 - Flags: review?(catlee) → review+
Thanks Nick!   by the way, in comment 2, you alluded to showing others how to create self-serve builds like this.   Can we plan something like an education and releng handoff to b2g teams in the future?   I know james lal would be also interested in this discussion.
(In reply to Tony Chung [:tchung] from comment #18)
> Thanks Nick!   by the way, in comment 2, you alluded to showing others how
> to create self-serve builds like this.   Can we plan something like an
> education and releng handoff to b2g teams in the future?   I know james lal
> would be also interested in this discussion.

Anyone with a flame device and access to tooltool could follow the steps in comment #12. For access see
 https://wiki.mozilla.org/ReleaseEngineering/Applications/Tooltool#How_to_enable_a_user_to_run_tooltool_uploads_by_adding_him.2Fher_to_the_vpn_tooltooleditors_LDAP_group

Then you use the tooltool output to create the patch to b2g/config/flame-kk/releng-flame-kk.tt in the gecko repo.
Blocks: 1090850
Blocks: 1090813
This bug is causing multiple fails on Firefox OS and also breaking automation can we get this patch backed out.

See Bug 1090850 and Bug 1090813 for more info.
Flags: needinfo?(cbook)
We got the error in #21 by flashing our Flames using 'Images' type and using the B2G-flash-tool scripts.

It was replicated both manually and picked up by the device automation that test each build on b2g-i.
https://hg.mozilla.org/mozilla-central/rev/46d81f906852
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
and backed out per request in #21 and #22 in remote:   https://hg.mozilla.org/mozilla-central/rev/c6989e473f97
Status: RESOLVED → REOPENED
Flags: needinfo?(cbook)
Resolution: FIXED → ---
(In reply to Florin Strugariu [:Bebe] from comment #21)
> This bug is causing multiple fails on Firefox OS and also breaking
> automation can we get this patch backed out.
> 
> See Bug 1090850 and Bug 1090813 for more info.

Viral, are you aware of these problem? With pure v188 image and shallow flash gecko/gaia.
Flags: needinfo?(vwang)
I asked in the dep bugs, but should we backing out on 2.0 and 2.1 too ? Also need advice on how to fix this, outside my area of expertise.
This issue is also affecting v2.0 and v2.1, can we get a backout on those branches please?
Flags: needinfo?(cbook)
(In reply to Shawn Huang [:shawnjohnjr] from comment #25)
> (In reply to Florin Strugariu [:Bebe] from comment #21)
> > This bug is causing multiple fails on Firefox OS and also breaking
> > automation can we get this patch backed out.
> > 
> > See Bug 1090850 and Bug 1090813 for more info.
> 
> Viral, are you aware of these problem? With pure v188 image and shallow
> flash gecko/gaia.
looks like it relative to full flash, not only gecko/gaia flashing.
maybe we need to check the difference part of v188
Flags: needinfo?(vwang)
(In reply to Nick Thomas [:nthomas] from comment #26)
> I asked in the dep bugs, but should we backing out on 2.0 and 2.1 too ? Also
> need advice on how to fix this, outside my area of expertise.

viral, what can we do here?  this is a problem, and we need to resolve getting our mozilla images running v188 binaries working over a flame v188 base.

In the meantime, i'm going to advise QA to fall back to testing the current pvtbuilds (that have v180 binaries in them), and test them over a v180 flame base image.   Full flashing current pvtbuilds over v188 is giving us frankenbuilds that we need to stop doing.

or the other option is to shallow flash current pvtbuilds over V188.   which do you suggest is a more realistic solution for testing?
Blocks: 1034147
We're going to do a new m-c build, which will contain bug 1034147 and the v188 image, then tchung will run it through jenkins. If all is well we can land in b2g-i after that.
(In reply to Nick Thomas [:nthomas] from comment #31)
> We're going to do a new m-c build, which will contain bug 1034147 and the
> v188 image, then tchung will run it through jenkins. If all is well we can
> land in b2g-i after that.

I was able to test a m-c build from jenkins, which picked up the fix for bug 1034147.  the audio issues reported in bug 1088339, bug 1090813, and bug 1090850, seem to all be fixed now.  however, i can't get dialer to work, and it crashes when trying to dial a phone number.

I'm going to file another bug against the Dialer crash now, and mark it a Qablocker.  We'll need some investigation on why that's happening.   However, i did try full flashing yesterday's pvtbuild (which is agianst v180 bits, and the dialer works).   

I suggest we hold off on merging to b2g-i, until the dialer bug is fixed.  Will file now and add to this bug.
Blocks: 1092002
Filed bug 1092002 to track the dialer crash issue.
Blocks: 1080912
Depends on: 1091659
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2266]
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2266] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2275]
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2275] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2280]
Comment on attachment 8512413 [details] [diff] [review]
[b2g-inbound]  Update to v188-1

Updating checked-in flag for backouts in comment #24 and comment #29.
Attachment #8512413 - Flags: checked-in+ → checked-in-
Depends on: 1073335
Blocks: 1073335
No longer depends on: 1073335
Tony/Nick,

When do we expect this bug to be fixed. There is a 2.1 camera blocker (https://bugzilla.mozilla.org/show_bug.cgi?id=1080912) that has been uplifted/verified yet, because of this bug.

Thanks
Hema
Flags: needinfo?(tchung)
Flags: needinfo?(nthomas)
(In reply to Hema Koka [:hema] from comment #35)
> Tony/Nick,
> 
> When do we expect this bug to be fixed. There is a 2.1 camera blocker
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1080912) that has been
> uplifted/verified yet, because of this bug.
> 
> Thanks
> Hema

See https://bugzilla.mozilla.org/show_bug.cgi?id=1092002#c29 for the latest findings.   no ETA yet until we hear back from T2M about the kernel changes.
Flags: needinfo?(tchung)
Flags: needinfo?(nthomas)
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2280] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2280] , NPOTB
Depends on: 1102682
Should bug 1102972 block this bug?
Depends on: 1101417
It sounds like bug 1085759 has resolved this problem.  QA has done some thorough radio/telephony/other tests to validate a try build with these changes are working correctly.   Also, bug 1102682 is fixed and verified against the device.    With that, i suggest we reopen this bug and hopefully get pvtbuilds to work again with this fix.  

Thanks!
Flags: needinfo?(nthomas)
Flags: needinfo?(catlee)
slight correction :  bug 1092002 was fixed via kernel repo fix bug 1101417
Just a point of confirmation, can we make sure the builds for 2.0, 2.1, and m-c are all affected by this change?
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Summary: Update base image for flame-kk builds → Update base image for flame-kk builds to v188-1
Can we make sure we are in sync for our source code on this ?
Flags: needinfo?(vwang)
(In reply to Alexandre LISSY :gerard-majax from comment #42)
> Can we make sure we are in sync for our source code on this ?
Partner claimed they have updated for v188 with following list.
device/qcom/common
kernel/lk
kernel/msm
platform/hardware/qcom/camera
platform/hardware/qcom/display
platform/vendor/qcom/msm8610

I'm thinking there are still some missing like recovery still not update-to-date.
My device shows blue on screen if I flash recovery image built in local.
I'm still need to find out the difference to their formal release.

Since we only use kernel and libnfc-nci from partner now, we have no plan to verify the status of all repo :(
Flags: needinfo?(vwang)
Automated device tests are now full flashing with the pvtbuilds again.
Blocks: 1117859
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.