Hey Paul, This is completely orthogonal to the current discussion, I think it might be better served on it's on thread.
Having said that, the reason why you're running into issues is that the image is way bigger than the system partition. You either need to make the build smaller ie not run the spark distro and possibly other tweaks or change the partition size which requires vendor support. On Tue, Sep 15, 2015 at 11:19 AM, Paul Aguilar < [email protected]> wrote: > Hi guys! > > I'm having a lot of troubles compiling for old devices like Hamachi, Inari > and Keon. > > I guess is related with this thread. > > I did this thread on bugzilla some days ago before this thread in the > mailinglist: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1204283 > > So if any one can help, thanks! > > Regards! > > Paul Aguilar > > > From: [email protected] > > Date: Tue, 15 Sep 2015 19:48:23 +0200 > > Subject: Re: Do we still care about 256MiB devices? > > To: [email protected] > > CC: [email protected]; [email protected]; [email protected] > > > > > On Tue, Sep 15, 2015 at 6:32 PM, Naoki Hirata <[email protected]> > wrote: > > > > > > I believe we still do care. > > > > > > Running Engineering build will make some difference as the 319 MB > takes into account the camera but not Marionette (adb + devtools) which the > engineering build runs. > > > > > > Having said that we run automation tests through jenkins, I'll check > with mwargers in regards to the issue to see if he already filed a bug or > not. > > > > > > Yes, we're running the Gaia UI tests with the 319MB configuration and > > we have various tests that are failing (intermittently) and disabled > > because they just don't work with 319MB: > > 1172167 [Flame][Cards View] Cards view loses the list of recently opened > apps > > 1176502 Failure in test_homescreen_column_layout.py on the Flame > > device, because Settings app gets killed > > 1178859 test_browser_bookmark.py: "IOError: Connection to Marionette > > server is lost." > > 1181344 [Window Management] Settings will be a blank white screen when > > returning from the "Built-in Keyboard" settings > > 1188080 test_rocketbar_offline_behavior.py: "NoSuchWindowException: None" > > 1189262 Failure in test_browser_share_link.py using Flame 319MB > > 1204280 [Flame] Intermittent failure in test_sms_contact.py in > > tap_send_sms using Flame 319MB > > 1188603 [Settings][Ringtones] Share activity closes when attempting to > > add custom ringtone > > > > I think these bugs need to be fixed, because they stand for lost > > functionality in those low memory conditions. > > > > All the bugs currently out there, regarding supporting 319MB memory > > configuration: > > > https://bugzilla.mozilla.org/buglist.cgi?list_id=12549261&status_whiteboard_type=allwordssubstr&query_format=advanced&status_whiteboard=[319MB-Flame-Support] > > > > Regards, > > Martijn > > > > > > > > > > > > > We still have not resolved the series of initial bugs going into > 2.5/3.0: > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1155854 > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1162535 > > > > > > On Tue, Sep 15, 2015 at 2:13 AM, Ting-Yu Chou <[email protected]> > wrote: > > >> > > >> A bit off-topic. > > >> > > >> Raptor [1] just records a serious memory regression though, not sure > is it related to the issue you see. > > >> > > >> Ting > > >> > > >> [1] > http://raptor.mozilla.org/#/dashboard/script/apps-memory.js?device=flame-kk&branch=master&memory=319 > > >> > > >> On Tue, Sep 15, 2015 at 4:56 PM, Gabriele Svelto <[email protected]> > wrote: > > >>> > > >>> I was doing some testing in the past few days on a Flame using the > > >>> 319MiB memory switch and found that our core apps are now almost > > >>> unusable on it. Opening a single app seems to end up killing the > > >>> homescreen and keeping two open at the same time is almost > impossible. > > >>> > > >>> So I've got two questions: the first one is, did we significantly > > >>> regress memory consumption again? Or is it just gecko having grown > > >>> significantly in the past few weeks making our minimum process size > > >>> larger? The second question is obviously: do we still care about > 256MiB > > >>> devices? Because if we still do then it looks like we're not in a > good > > >>> spot for a 2.5 release running on those. If we don't care I suppose > it's > > >>> fine though we should still keep our memory consumption under > control. > > >>> If we move our minimum to 512MiB we'll have plenty of room and this > > >>> might cause us to regress even further almost without noticing (*). > > >>> > > >>> I'm running an engineering build BTW, but I don't think this should > make > > >>> much of a difference. > > >>> > > >>> Gabriele > > >>> > > >>> *) Unless the screen has a rather high resolution, in which case > 512MiB > > >>> might still yield only a small amount of usable memory for apps as > most > > >>> of it will go to the framebuffer and accompanying structures (layers > & co). > > >>> > > >>> > > >>> _______________________________________________ > > >>> dev-fxos mailing list > > >>> [email protected] > > >>> https://lists.mozilla.org/listinfo/dev-fxos > > >>> > > >> > > >> > > >> _______________________________________________ > > >> dev-fxos mailing list > > >> [email protected] > > >> https://lists.mozilla.org/listinfo/dev-fxos > > >> > > > > > > > > > _______________________________________________ > > > dev-fxos mailing list > > > [email protected] > > > https://lists.mozilla.org/listinfo/dev-fxos > > > > > _______________________________________________ > > dev-fxos mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-fxos >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
