Closed Bug 1021807 Opened 6 years ago Closed 6 years ago
Latest nightly and tinderbox builds too large to flash on Hamachi
It appears we're unable to flash mozilla-central builds to Hamachi's again. Last good: application_buildid: 20140605183157 application_changeset: c08a299f2163 build_changeset: 2a165bebfa19b11b697837409f9550dd2917c46c gaia_changeset: 908f94fda04462001ece86e6b6c15ad8b05f7526 This has happened a number of times now. Can we somehow pick this up when we build, so that we don't have such downtime in test automation?
The last good build had the following free space after flashing: Filesystem Size Used Free Blksize /dev 90M 48K 90M 4096 /mnt/asec 90M 0K 90M 4096 /mnt/obb 90M 0K 90M 4096 /system 200M 198M 1M 4096 /data 161M 1M 159M 4096 /persist 4M 908K 3M 4096 /cache 40M 1M 38M 4096
User Story: (updated)
(In reply to Dave Hunt (:davehunt) from comment #0) > This has happened a number of times now. Can we somehow pick this up when we > build, so that we don't have such downtime in test automation? Yes, bug 1020050 is meant to address just that.
See Also: → 1020050
b2g-inbound Regression Window: Last Working Environmental Variables: Device: Buri Build ID: 20140604233716 Gaia: a24a43bd0124f5ba49833aa30a44424dd18cef38 Gecko: 37a23a635be0 Version: 32.0a1 Firmware Version: v1.2device.cfg First Broken Environmental Variables: Device: Buri BuildID: 20140605000718 Gaia: ad3fd209ffed635bdc650e400687514258e3860e Gecko: 8fbf24c24b71 Version: 32.0a1 Firmware Version: v1.2device.cfg Last Working Gaia / First Broken Gecko: Issue Does NOT reproduce. Build successfully flashes to device. Gaia: a24a43bd0124f5ba49833aa30a44424dd18cef38 Gecko: 8fbf24c24b71 Last Working Gecko / First Broken Gaia: Issue DOES reproduce. Build fails to flash to device. Gaia: ad3fd209ffed635bdc650e400687514258e3860e Gecko: 37a23a635be0 Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/a24a43bd0124f5ba49833aa30a44424dd18cef38...ad3fd209ffed635bdc650e400687514258e3860e
I need a backout of all 4 patches linked here.
Hey all, I think that the big problems are the images in `apps/collection/collections/` so ... if we need to backout the patches I think we need to backout only Bug 1020134 the others are only few small images. Patryk?
Flags: needinfo?(pivanov) → needinfo?(padamczyk)
(In reply to Pavel Ivanov [:ivanovpavel] from comment #6) > Hey all, > I think that the big problems are the images in > `apps/collection/collections/` so ... if we need to backout the patches I > think we need to backout only Bug 1020134 the others are only few small > images. Patryk? Okay, sounds good.
Let me know what I can do... we can "compress" certain assets further if needed. But I also want to make sure we are only including graphics needed for the image... ie. We are NOT including @1.5x graphics / wallpapers in the Hamachi image correct?
Flags: needinfo?(padamczyk) → needinfo?(pivanov)
blocking-b2g: 2.0? → 2.0+
Component: General → Gaia::Homescreen
Yep, I think that we don't include the @1.5x images however, the image is big ... and maybe this is because we have a lot of new wallpapers there ... I think they are few megabytes ... not sure what we can do ... maybe Vivien can help us here?
Flags: needinfo?(pivanov) → needinfo?(21)
Whiteboard: [fromAutomation] → [fromAutomation][systemsfe]
Also why did the auto_flash_from_pvt allowed to flash this?
Can we flash a production build, or are they totally hosed also? It seems like instead of backing patches out we may instead want to make a more simple customization for hamachis with less assets (maybe no wallpapers), and maybe even less apps.
Backout of bug 1020134 https://github.com/crdlc/gaia/commit/ad83bab6e5fd681548e3915a41dff4f8378a7793 I think we need to implement some code in build time to copy only the specific wallpapers for a target device instead of all of them. Maybe this can be done here bug 1020152 Albert, could we copy only the collection folders that are pre-installed by OEMs? and also within those folders the specific wallpaper for the target device? Thanks Albert
Closing as fixed via backout. If the backout in comment 13 isn't enough to resolve the problem, then please reopen. We should file a followup though for what Kevin & Cristian is describing above to ensure that Hamachi's eng build size drops down significantly.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
(In reply to Pavel Ivanov [:ivanovpavel] from comment #9) > Yep, I think that we don't include the @1.5x images however, the image is > big ... and maybe this is because we have a lot of new wallpapers there ... > I think they are few megabytes ... not sure what we can do ... maybe Vivien > can help us here? In order to help I need to understand what is the total size of the 70 new wallpapers that we are trying to add to the build. Also is it a |PRODUCTION=1| build or a eng build ? (there are more apps installed in the later case). And what is the size of the profile/ generated for the hamachi build with / without the wallpapers. If the difference is small we can probably found some spaces somewhere. If the difference is big, we need to do more drastic changes :/
You need to log in before you can comment on or make changes to this bug.