Hi Naoki, thanks for reply. I'll create other thread for my issue, and yes, the problem is the size, but in my .userconfig I tried just with PRODUCTION=1 or VARIANT=user removing spark and all the extra stuffs and the image is still bigger than my system partition, I know the system is growing but what going happen with the old devices? just will forget?
Regards! Paul Aguilar Date: Tue, 15 Sep 2015 11:28:32 -0700 Subject: Re: Do we still care about 256MiB devices? From: nhir...@mozilla.com To: paul.aguilar.enriq...@hotmail.com CC: martijn.mart...@gmail.com; tc...@mozilla.com; gsve...@mozilla.com; dev-fxos@lists.mozilla.org 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 <paul.aguilar.enriq...@hotmail.com> 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: martijn.mart...@gmail.com > Date: Tue, 15 Sep 2015 19:48:23 +0200 > Subject: Re: Do we still care about 256MiB devices? > To: nhir...@mozilla.com > CC: tc...@mozilla.com; gsve...@mozilla.com; dev-fxos@lists.mozilla.org > > On Tue, Sep 15, 2015 at 6:32 PM, Naoki Hirata <nhir...@mozilla.com> 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 <tc...@mozilla.com> 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 <gsve...@mozilla.com> > >> 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 > >>> dev-fxos@lists.mozilla.org > >>> https://lists.mozilla.org/listinfo/dev-fxos > >>> > >> > >> > >> _______________________________________________ > >> dev-fxos mailing list > >> dev-fxos@lists.mozilla.org > >> https://lists.mozilla.org/listinfo/dev-fxos > >> > > > > > > _______________________________________________ > > dev-fxos mailing list > > dev-fxos@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-fxos > > > _______________________________________________ > dev-fxos mailing list > dev-fxos@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-fxos _______________________________________________ dev-fxos mailing list dev-fxos@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-fxos
_______________________________________________ dev-fxos mailing list dev-fxos@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-fxos
