Re: [b2g] Understanding production vs engineering builds
Hi Ryan, all, Sorry for taking so long to respond on this one. Since this sounds like a .userconfig thing, I’ve created a new section here: https://developer.mozilla.org/en-US/Firefox_OS/Customization_with_the_.userconfig_file#Creating_different_build_types I’ve taken some of Dave’s excellent advice from the thread and converted it into a description of the different variants, and also linked some of the existing content from that article together a bit better. I’ve also included link to the make option reference so it is easy to find and reference, and also called out build time-equivalent make options where I know them. Does this look ok? Please suggest or add more details as you deem necessary. Chris Mills Senior tech writer || Mozilla developer.mozilla.org || MDN cmi...@mozilla.com || @chrisdavidmills On 25 Sep 2014, at 04:26, J. Ryan Stinnett jry...@gmail.com wrote: Chris - I think it would be helpful to document the difference between the variants, maybe with a table or something. This is something I found quite confusing when getting started with the project. I wasn't sure where to best put this info on MDN. Is there an existing page this would fit into, or should I dump it into it's own page? - Ryan On Fri, Sep 12, 2014 at 3:15 AM, Dave Hylands dhyla...@mozilla.com wrote: You can somewhat control things by changing the VARIANT (when build for a real device/emulator) https://developer.mozilla.org/en-US/Firefox_OS/Customization_with_the_.userconfig_file There are 3 variants: VARIANT=user VARIANT=userdebug VARIANT=eng The eng variant puts the apps in /data and includes many more apps than user/userdebug. user/userdebug puts apps in /system The eng and userdebug variants have marionetter enabled by default, so you can run tests The user and userdebug variants have the updater enabled, so you can do over-the-air (OTA/FOTA) updates. make production in gaia sets PRODUCTION=1 user and user-debug both imply PRODUCTION=1 when building locally for a real device/emulator). make production is really a way to build a user version of gaia for use with nightly or B2G-desktop. Specifying VARIANT is the way to do this when building for a device/emulator Dave Hylands From: Sam Penrose spenr...@mozilla.com To: dev-b2g@lists.mozilla.org, dev-g...@lists.mozilla.org, Christopher Mills cmi...@mozilla.com Sent: Thursday, September 11, 2014 3:29:52 PM Subject: [b2g] Understanding production vs engineering builds We recently ran into an FxOS bug that only appeared on production builds: https://bugzilla.mozilla.org/show_bug.cgi?id=1058978#c12 I could not find documentation specifying the differences between engineering and production builds of Gecko and Gaia, and more importantly how to control them. Does such documentation exist? If not, where should I request it? Are the underlying controls independent, and if not should they be? For example, make production in Gaia wants to install on device: is there a way to create a production Gaia target without installing it on device? I routinely run custom B2G builds with custom Gaia builds -- are the production vs engineering settings for Gecko and Gaia independent, or are there known restrictions in how I can mix and match them? Thanks, Sam ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g ___ dev-gaia mailing list dev-g...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-gaia ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Understanding production vs engineering builds
On Thu, Sep 25, 2014 at 10:30 AM, Chris Mills cmi...@mozilla.com wrote: Does this look ok? Please suggest or add more details as you deem necessary. Looks good to me! Thanks Chris. - Ryan ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Getting B2G crash reports doc on MDN (attn Chris)
Hi Chris/et al, Twice this week we've been asked in IRC about getting crash reports from Firefox OS device. Most of our contributors are used to just doing about:crashes but this isn't supported on Firefox OS. It made me realise we don't have any of this documented on MDN. The best info we have in public is here (and even it is a bit outdated): https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#Crashes Chris can you start the page where it is most appropriate, link us to it and we'll contribute? (There are some desktop firefox crash reporting pages - I'm not sure where to put the Firefox OS one). Thanks, Zac ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Getting B2G crash reports doc on MDN (attn Chris)
Hi Zac! See this page: https://developer.mozilla.org/en-US/Firefox_OS/Debugging/Firefox_OS_crash_reporting I have added in a bunch of details that I thought relevant, but I’m sure there is more to add and improvements to make. Some questions: 1. When using the About Crashes app, I - advised that they use the ADB Helper addon, instead of typing the port forwarding command each time. - added in instructions for WebIDE as well as app manager - added in an instruction on how to enable certified app debugging, as About Crashes is a certified app 2. In the Getting crash ids from the command line” section, I could get either of the commands to work, even after installing busybox. It just gave me a directory not found error. I guess I just need to correct reports directory 3. In the How to Force a crash” section, I am not sure I’ve got these instructions right. I say this because when I forced the crash, it bricked my device and I had to recover it ;-) Chris Mills Senior tech writer || Mozilla developer.mozilla.org || MDN cmi...@mozilla.com || @chrisdavidmills On 25 Sep 2014, at 10:56, Zac Campbell zcampb...@mozilla.com wrote: Hi Chris/et al, Twice this week we've been asked in IRC about getting crash reports from Firefox OS device. Most of our contributors are used to just doing about:crashes but this isn't supported on Firefox OS. It made me realise we don't have any of this documented on MDN. The best info we have in public is here (and even it is a bit outdated): https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#Crashes Chris can you start the page where it is most appropriate, link us to it and we'll contribute? (There are some desktop firefox crash reporting pages - I'm not sure where to put the Firefox OS one). Thanks, Zac ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Getting B2G crash reports doc on MDN (attn Chris)
Note that if someone could fix bug 908896 we'll have the equivalent of about:crashes on device! Fabrice On 09/25/2014 06:48 AM, Chris Mills wrote: Hi Zac! See this page: https://developer.mozilla.org/en-US/Firefox_OS/Debugging/Firefox_OS_crash_reporting I have added in a bunch of details that I thought relevant, but I’m sure there is more to add and improvements to make. Some questions: 1. When using the About Crashes app, I - advised that they use the ADB Helper addon, instead of typing the port forwarding command each time. - added in instructions for WebIDE as well as app manager - added in an instruction on how to enable certified app debugging, as About Crashes is a certified app 2. In the Getting crash ids from the command line” section, I could get either of the commands to work, even after installing busybox. It just gave me a directory not found error. I guess I just need to correct reports directory 3. In the How to Force a crash” section, I am not sure I’ve got these instructions right. I say this because when I forced the crash, it bricked my device and I had to recover it ;-) Chris Mills Senior tech writer || Mozilla developer.mozilla.org || MDN cmi...@mozilla.com || @chrisdavidmills On 25 Sep 2014, at 10:56, Zac Campbell zcampb...@mozilla.com wrote: Hi Chris/et al, Twice this week we've been asked in IRC about getting crash reports from Firefox OS device. Most of our contributors are used to just doing about:crashes but this isn't supported on Firefox OS. It made me realise we don't have any of this documented on MDN. The best info we have in public is here (and even it is a bit outdated): https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#Crashes Chris can you start the page where it is most appropriate, link us to it and we'll contribute? (There are some desktop firefox crash reporting pages - I'm not sure where to put the Firefox OS one). Thanks, Zac ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g -- Fabrice Desré b2g team Mozilla Corporation ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Getting B2G crash reports doc on MDN (attn Chris)
Yes I suspect that busybox advice is either outdated or on longer recommended. I've never used that tool. I also think that we should push the getting crash ids from command line up to the top as it's the most basic advice for a novice or dogfooder (ie not an internal developer) who has experienced a crash. I can't speak for the forcing a crash but it sounds like it might be outdated too. At least now we'll have this info indexed on MDN. On 25/09/14 14:48, Chris Mills wrote: Hi Zac! See this page: https://developer.mozilla.org/en-US/Firefox_OS/Debugging/Firefox_OS_crash_reporting I have added in a bunch of details that I thought relevant, but I’m sure there is more to add and improvements to make. Some questions: 1. When using the About Crashes app, I - advised that they use the ADB Helper addon, instead of typing the port forwarding command each time. - added in instructions for WebIDE as well as app manager - added in an instruction on how to enable certified app debugging, as About Crashes is a certified app 2. In the Getting crash ids from the command line” section, I could get either of the commands to work, even after installing busybox. It just gave me a directory not found error. I guess I just need to correct reports directory 3. In the How to Force a crash” section, I am not sure I’ve got these instructions right. I say this because when I forced the crash, it bricked my device and I had to recover it ;-) Chris Mills Senior tech writer || Mozilla developer.mozilla.org || MDN cmi...@mozilla.com || @chrisdavidmills On 25 Sep 2014, at 10:56, Zac Campbell zcampb...@mozilla.com wrote: Hi Chris/et al, Twice this week we've been asked in IRC about getting crash reports from Firefox OS device. Most of our contributors are used to just doing about:crashes but this isn't supported on Firefox OS. It made me realise we don't have any of this documented on MDN. The best info we have in public is here (and even it is a bit outdated): https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#Crashes Chris can you start the page where it is most appropriate, link us to it and we'll contribute? (There are some desktop firefox crash reporting pages - I'm not sure where to put the Firefox OS one). Thanks, Zac ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Problem in WIFI
HI Team, I am not very sure about the problem but I would like to tell it, it seems to be very important issue. In our office we have a WIFI connection where each and every user will be authenticating with his username and password. I guess the protocol used for this is 802.1 EAP. In Firefox OS right from Firefox OS 1.1 I am not able to see this WIFI name itself. While we have another type of WIFI where there is common password. I am able to see only this WIFI and its protocol is like WPA2PSK or WPA/WPA2PSK. It will be really greatful if any can help in this solution. Because I can access first type easily than second type. PS:- I am not sure to mail exactly so sent to all.. Sorry if mis-communicated. Thank you -- Web is open so Code is poetry Firefox for Deskop https://affiliates.mozilla.org/referral/63354/ Firefox Marketplace https://affiliates.mozilla.org/referral/63355/ App Reviewer Firefox for Android http://affiliates.mozilla.org/link/banner/3166 http://about.me/viswaprasathks [image: Viswaprasath Ks on about.me] Viswaprasath Ks about.me/viswaprasathks ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Please update your Flame to the new base image
And compared to v123 which run easily on Windows, now you have to use Cygwin and have adb+fastboot in path, but then everything is ok, but it could be a trouble for someone... ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Settings API queries fail after inner-window-destroyed
Looking at Bug 1070066 today, I found an interesting issue. Pretty much everywhere in gaia, it's assumed that the settings API will never fail on a query call. There's lots of calls to mozSettings.createLock().get()/set() that just expect to get back a DOMRequest no matter what. The problem in bug 1070066 is that the call screen app closes itself before all of its callbacks are done, meaning that settings API calls are made after inner-window-destroyed. These fail in what look like settings issues, which it partially is, since the settings API is trying to create a DOMRequest with no window. This was true for the old API, and is true for the new one too. If we don't have a window, you're not getting back a DOMRequest. You're getting an exception. Unfortunately, in terms of bug 1070066, it's getting fixed by things like bug 1068109, where we just put in a 2 second wait for UX reasons that also happens to fix this. Great bandaid, and needed for UX, not actually a fix for the API problem. So, we need to figure out what to do here. Almost all settings API calls in gaia are queries chained to createLock(), which means there's no error checking, and they'll throw exceptions, possibly leading to odd state issues like Bug 1070066. I've filed bug 1073259 to at least make the errors more descriptive, though they'll also look even more like settings errors so I look forward to lots more bugs filed against me. Going forward, what should we do here? Document better and try to wrap all current instances in try/catch? Return fake DOMRequest-like objects that instantly fail? ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Settings API queries fail after inner-window-destroyed
On Thu, Sep 25, 2014 at 6:08 PM, Kyle Machulis kmachu...@mozilla.com wrote: Looking at Bug 1070066 today, I found an interesting issue. Pretty much everywhere in gaia, it's assumed that the settings API will never fail on a query call. There's lots of calls to mozSettings.createLock().get()/set() that just expect to get back a DOMRequest no matter what. The problem in bug 1070066 is that the call screen app closes itself before all of its callbacks are done, meaning that settings API calls are made after inner-window-destroyed. These fail in what look like settings issues, which it partially is, since the settings API is trying to create a DOMRequest with no window. This was true for the old API, and is true for the new one too. If we don't have a window, you're not getting back a DOMRequest. You're getting an exception. Unfortunately, in terms of bug 1070066, it's getting fixed by things like bug 1068109, where we just put in a 2 second wait for UX reasons that also happens to fix this. Great bandaid, and needed for UX, not actually a fix for the API problem. So, we need to figure out what to do here. Almost all settings API calls in gaia are queries chained to createLock(), which means there's no error checking, and they'll throw exceptions, possibly leading to odd state issues like Bug 1070066. I've filed bug 1073259 to at least make the errors more descriptive, though they'll also look even more like settings errors so I look forward to lots more bugs filed against me. Going forward, what should we do here? Document better and try to wrap all current instances in try/catch? Return fake DOMRequest-like objects that instantly fail? ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g Why are we running callbacks after the app has closed anyways? - Kyle ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Settings API queries fail after inner-window-destroyed
On Thu, Sep 25, 2014 at 6:08 PM, Kyle Machulis kmachu...@mozilla.com wrote:
Return fake DOMRequest-like objects that instantly fail?
I favor this, although not sure what is meant by fake vs. just a real
DOMRequest that doesn’t do anything special/will not call onsuccess,
just onerror.
Expressing the failure via an onerror call would match what I would
expect from promise-like code: any operation that is async should get
an object that captures the result of the operation, and handle the
success or errors as functions. For DOMRequest, it is attaching .on*
properties, for promises it is passing functions to .then().
This also means the error handling is just in one place, the .onerror.
Instead of needing to manage a try{} around the acquisition of the
DOMRequest and then in the .onerror.
James
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
