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
