Re: [b2g] Release candidates

[Chris Mills]

On 8 Aug 2014, at 06:32, Marek Raida  wrote:

> Thank you for your reply. It is new and interesting fact for me, that Flame 
> is not to be fully supported for lower than v2.0 OS, so I can stop reporting 
> bugs on 1.3 and focus on 2.0 instead. Well, once I'll be able to flash it to 
> my device, that's it :-(
> However, what you're saying is in minor contradiction to what Chris writes on 
> linked Flame page - you're providing binaries for latest builds on FTP, even 
> for v1.4
> But if it is recommended to rather avoid 1.4 on Flame, perhaps Chris can 
> mention it there, make it not so obvious option to try 1.4.
> For most people, trying the next major release is tempting because of higher 
> stability, but as you say, not so in case of Flame and v1.4

Yes - I’d love clarification on this, as it is different to what I thought was 
the case ;-)
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Release candidates

[Marek Raida]

Thank you for your reply. It is new and interesting fact for me, that Flame is 
not to be fully supported for lower than v2.0 OS, so I can stop reporting bugs 
on 1.3 and focus on 2.0 instead. Well, once I'll be able to flash it to my 
device, that's it :-(
However, what you're saying is in minor contradiction to what Chris writes on 
linked Flame page - you're providing binaries for latest builds on FTP, even 
for v1.4
But if it is recommended to rather avoid 1.4 on Flame, perhaps Chris can 
mention it there, make it not so obvious option to try 1.4.
For most people, trying the next major release is tempting because of higher 
stability, but as you say, not so in case of Flame and v1.4

Marek
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Flame phone documentation, running adb as root

[Marek Raida]

well, yes. I'm on Windows with Cygwin and flashing v123 image works perfectly. 
However, my next attemt to flash nightly fails again and I no not know why. 
Perhaps someone with deeper understanding will, after look to the logcat 
outputs, tell me.
In the meanwhile, I'll try to laborate with the flashing script a bit more...
Marek
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Gaia and b2g-inbound closed

[Nick Thomas]

Both are open again.

On 8/08/14 7:28 am, Ryan VanderMeulen wrote:
> Due to the ongoing problems with hg.mozilla.org today, all trees are 
> currently closed, including Gaia.
> 
> Bug 1040308 tracks the issue. Apologies for the inconvenience.
> 
> -Ryan
> 

___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] does any dual-sim phone exists with firefox os support?

[Lachlan]

i have used the flame as my primary phone since it was released. (i got the
the day before the official release date whenever that was.)

the default 1.3 software is atrocious and buggy but i'm currently running
the 2.0 prerelease firmware. Now it's much more usable day to day.

the things i miss most from android are my bank's android app, my private
email server can't be added because it's a class 1 certificate and the
firefox account sync doesn't seem to actually sync anything to the browser
in 2.0. 2.0 added a lot of missing features i needed.

Other than that i don't really miss anything. it only cost 195AUD and i
rate it as good as a 400-500 dollar android phone easily.


On 8 August 2014 08:08,  wrote:

> On Friday, August 8, 2014 12:12:07 AM UTC+3, John Ford wrote:
> > The flame reference device has dual sims but not LTE.
> >
> >
> https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame
>
> Thank you, didn't see this one. It looks like a nice device. But do you
> think android OS can be installed on it if it turns out to be not yet
> usable as a primary phone.
> I see one large show stopper to me:
> https://bugzilla.mozilla.org/show_bug.cgi?id=932267
>
> But still I'd like a device that can be loaded with firefox os when it is
> ready for my usage and I can report bugs and test so it becomes usable
> sooner.
> ___
> 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] Engineering Mode (aka "service menu")

[Paul Theriault]

On 7 Aug 2014, at 9:38 pm, Adrian Custer  wrote:

> On 8/7/14 12:56 AM, Paul Theriault wrote:
> > So to summarise the security requirements &properties here:
> >
> > - Engineering mode will be disabled until the dialer (or other
> > certified app) initiates the special web activity - Even with
> > engineering mode enabled, only an app with the certified
> > “engineering-mode” (or similar) permission can access the API which
> > can be extended by the vendor
> >
> > I’d make a couple notes here: - There is no reason for side loaded
> > apps to have this permission, and its present a very real threat of
> > local privilege escalation,  so we should explicitly prevent side
> > loading apps which have access to these APIs (perhaps so long as the
> > devtools.debugger.forbid-certified-apps pref is true, so engineering
> > build phones can still access them). - The dialer should take observe
> > lock state - we need to prevent enabling engineering mode from the
> > dialer presented by the lockscreen ( i think your patch does this
> > already though since it only changes the dialer, not the lockscreen
> > dialer)
> >
> > We should also provide security guidance to Partners implementing
> > engineering mode functionality to reduce the risk of security issues
> > here.
> >
> > Does that sound reasonable?
> >
> > - Paul
> 
> 
> Hey Paul,
> 
> you write 'there is no reason' and then think of a reason and provide an 
> exception for that reason 'perhaps so long as'. This reveals you are trying 
> to work quickly and so are not setting up a clear framework for thinking, 
> presumably because you do not need to. For me this is difficult since I 
> personally cannot reason this way when thinking about a 'very real threat’.

The threat I am concerned about here is an attacker with physical access to the 
device side loading an app with the engineering mode permission. Hopefully 
vendors will secure their engineering mode APIs, but I am assuming the worst 
case scenario here and access to engineering mode implies full control of the 
phone. Its not clear form my comment, but amongst other things, that preference 
I mention controls whether or not you can attach a debugger to certified apps. 
My logic is that there is no point preventing side loading of apps with 
engineering mode permission, if you can just attach the debugger to the system 
app, grant the permission and then use the API (which is what is possible if 
devtools.debugger.forbid-certified-apps is set to false). 

> 
> Does the FirefoxOS team, or its security sub-group have a pre-defined set of 
> users and their needs used for the security analysis of FirefoxOS? I would 
> expect a list of strawman users whose conflicting needs are defined and 
> agreed about, so that these needs can be reasoned about effectively, 
> something like:
> 
>  Dad   Jose --- Just a user, wants all the 'security' he can get
>  Student   Kate --- Builds apps, so needs to side load apps
>  Developer Luna --- Needs root for debugging and flashing
>  Engineer  Mani --- needs root and low level engineering access
>  HackerNuro --- wants full control
> 
> i.e. j,k,l,m,n with (mostly) increasing levels of access needs.
> 
> If there is such a list, I would be interested to read it so that I could 
> contextualize these security discussions in the context of the impacts on 
> these different classes of users.

There isn’t as far as I am aware. Typically the discussions have been focused 
on balancing developer needs (“Luna") vs those of regular users (i.e. your 
‘dad' user above).  I’m not sure we have the in between case well 
characterised, but its probably something that could do with attention.

- Paul


> 
> Thanks,
>  ~adrian



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Release candidates

[Asa Dotzler]

On 8/5/14, 3:23 AM, Marek Raida wrote:

Hi there,
as a fresh new owner of Flame device, I'd like to participate in testing "almost 
finished, I believe" 1.4 version of FFOS.
But I see only some nightly builds ( 
http://ftp.mozilla.org/pub/mozilla.org/b2g/ ), but nothing like Release 
Candidates, Beta or Alpha versions, which are standardized for Desktop/Android 
Firefoxes.
So my questions are:
- if I want to test latest build/RC of v1.4 for Flame, where should I get it?
- is there plan to make B2G similar to other Firefox products (Aurora, Beta 
etc.)
- I know that bugfixing is hard, but still, according to 
https://wiki.mozilla.org/Release_Management/B2G_Landing is 1st September date 
when we could expect 1.4 release? Or sooner, later?

Cheers,
Marek



We're not developing v1.4 for the Flame or any other QC chipset devices.

You can get the latest from master/mozilla-central (2.1) by following 
instructions at 
https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame


Alternatively, you can compile any of the branches you like, for 
example, 2.0 or even the unsupported 1.4 but we're not providing 
binaries for those.


- A

___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] does any dual-sim phone exists with firefox os support?

[akostadinov]

On Friday, August 8, 2014 12:12:07 AM UTC+3, John Ford wrote:
> The flame reference device has dual sims but not LTE.
> 
> https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame

Thank you, didn't see this one. It looks like a nice device. But do you think 
android OS can be installed on it if it turns out to be not yet usable as a 
primary phone.
I see one large show stopper to me: 
https://bugzilla.mozilla.org/show_bug.cgi?id=932267

But still I'd like a device that can be loaded with firefox os when it is ready 
for my usage and I can report bugs and test so it becomes usable sooner.
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Enabling Voice Input in Open Web / Firefox OS

[sandip . kamat]

Thanks, That sounds great. Please follow the dependency tree in 

https://bugzilla.mozilla.org/show_bug.cgi?id=1032964

We are adding dependent bugs in there for now. Some may be up for grabs if you 
can.

Sandip

On Tuesday, August 5, 2014 4:12:13 PM UTC-7, rab...@gmail.com wrote:
> If help is needed I can contribute for Phase 2. One of my application also 
> needs speech support hence I was interested in this bug and also had a chat 
> with Andre (in another forum where I was seeking information about this bug). 
> Didn't know about this group.
> 
> I have some relevant experience for Phase 2 I believe. 
> 
> 
> 
> Please let me know how I can contribute.
> 
> 
> 
> On Tuesday, 1 July 2014 15:46:26 UTC-4, Sandip Kamat  wrote:
> 
> > "Many Voices, One Mozilla"
> 
> > 
> 
> > 
> 
> > 
> 
> > Hi All,
> 
> > 
> 
> > 
> 
> > 
> 
> > Here is the summary of high level draft plans we are beginning with for 
> > enabling Voice Input in Open Web / Firefox OS. One of our Firefox OS 
> > contributors Andre Natal (Brazil community) has done lots of preparatory 
> > work and is currently continuing on a GSOC (Google Summer of Code) project 
> > around this. The proposed 2 phases of the plan are in email below.
> 
> > 
> 
> > 
> 
> > 
> 
> > Please note the releases and estimates marked below are *all tentative* 
> > (will change) and will be refined over next several months. We will 
> > continue adding updates here:
> 
> > 
> 
> > 
> 
> > Wiki
> 
> > 
> 
> > https://wiki.mozilla.org/SpeechRTC_-_Speech_enabling_the_open_web
> 
> > 
> 
> >  Bugzilla
> 
> > 
> 
> > Bug 1032964 - [B2G][SpeechRTC][User Story]: Enabling Voice input in Firefox 
> > OS
> 
> > 
> 
> > 
> 
> > Trello board to track status: 
> 
> > 
> 
> > https://trello.com/b/UWXblmKb/webspeech-api
> 
> > 
> 
> > 
> 
> > 
> 
> > Github: 
> 
> > 
> 
> > https://github.com/andrenatal/gecko-dev
> 
> > 
> 
> > 
> 
> > 
> 
> > There is lots to do here and we are just starting, so if you are 
> > interested, pls watch this wiki and help with the dependent bug# being 
> > added to the meta-bug above. This kind of project could use great community 
> > participation with contributing code, collecting / testing voice samples 
> > with various accents (Remember "many voices, One Mozilla") to improve the 
> > acoustic / language models, creating fun gamifications to achieve that and 
> > yes, we would need tons & tons of testing! 
> 
> > 
> 
> > 
> 
> > Regards,
> 
> > 
> 
> > Sandip
> 
> > 
> 
> > Sandip Kamat | Product Management, Firefox OS | Mozilla Corporation 
> 
> > ska...@mozilla.com, @sankam
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > Subject: Re: Planning SpeechRTC integration for FxOS
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > Thanks for joining the kickoff meeting. Here is the current proposal and 
> > next steps. We will have a regular (frequency tbd) cadence of meetings on 
> > this.
> 
> > 
> 
> > 
> 
> > Propose to approach in 2 phases
> 
> > Phase 1 - Grammar based Voice Command appSimilar to this Nuance app: 
> > https://www.youtube.com/watch?v=p0majfIEIR8&noredirect=1
> 
> > Needs Web Speech API implementationCurrent App level solutions present in 
> > marketplace (Andre N)Voicity (uses pocketSphinx AM, custom LM, Verbio 
> > decoder) (https://www.youtube.com/watch?v=cjjFvyH3kdc)Offline recognition 
> > on Peak (https://www.youtube.com/watch?v=FXKXhrRDEb8)Phase 2 - Free Speech 
> > (closer to Apple Siri experience)"Vaani" App - Virtual Assistant with free 
> > speechWeb Speech API implementation enhancementsNeed to benchmark decoder 
> > options & select solution, several decisions pending 
> 
> > Current App Crab (uses decoder from Nuance Ndev mobile - dev edition) 
> > (https://www.youtube.com/watch?v=pnCRH-Iznrc)
> 
> > Next Steps
> 
> > Andre will finish most of phase 1 as a part of Google summer of code 
> > project. Olli Pettay helping him. Needs support from CJ Ku's team to finish 
> > gecko porting.Create Test scripts to test SpeechAPI (Andre, Clint). If that 
> > works well, we could declare support for SpeechAPI in version 2.x. The 
> > other implementation in phase 1 can be targeted for later version 
> > 2.x.Finalize AM/LM/decoder strategies and rocketbar integration for phase 
> > 2. Create release plan for phase 2 after some assessment of 
> > efforts.Strategy on Back end server (Build vs license vs hybrid). Work with 
> > services/Mark Mayo's team. (had a Call with Bill Maggs)

___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Flame phone documentation, running adb as root

[Armen Zambrano G.]

I believe I've had the same issue as you.
I needed to flash the base image and then it worked.

Are you ever in a good state?
Or only after you try flashing?
It seems that after flashing the base image (v123) you are back to a
good state, however, I don't want to assume so.

NOTE: I don't know much about this but I can try to help.

On 14-08-07 11:37 AM, Marek Raida wrote:
> I'm trying to make it working on Windows wit Cygwin, so far without success...
> 
> I created issue https://bugzilla.mozilla.org/show_bug.cgi?id=1050282
> with a lot of log attachments and I do hope that someone will be able to 
> help/advise me...
> 
> Script I'm using is here: 
> https://github.com/Mozilla-TWQA/B2G-flash-tool/pull/240
> 
> Once it is working Chris can update its page and extends Windows support.
> Fortunately, recovery 123 utility works great, I've used it more than three 
> times today and it saved my ass ;-)
> 

___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Flash Firefox OS on Tablet

[Joe Cheng]

Agree with Josh
and also if you are trying to fix things on specific branches, approvals will 
be needed to uplift (which may not be granted all the time)
Sticking with m-c/master seems like a better way forward for tablets (for now)

Re,
Joe Cheng
——
Mozilla Corp.
jch...@mozilla.com

On Aug 6, 2014, at 5:55 AM, Josh Smith  wrote:

> Unfortunately, no.  A good deal of 1.4 bugs are fixed in 2.0 or 2.1.
> 
> - Josh
> 
> 
> On Wed, Aug 6, 2014 at 12:13 AM, KAMI911 KAMI911  wrote:
> Hi,
> 
> Is it worth to report bugs against version 1.4?
> 
>  
> 
> Üdvözlettel / Best Regards:
> 
> Kálmán (KAMI) Szalai
> 
> 
> 2014-08-03 20:11 GMT+02:00 adit bharadwaj :
> hey, 
> http://openmoz.wordpress.com/2014/07/13/flash-firefox-os-2-1-into-your-tablet/
> 
> following is best link for flashing the flatfish tablet. 
> but 2.1 wid good interface has many disadvantages.. video and camera crashes 
> and its unstable.. so u can go for it but i prefer u to stay at 1.4 till 
> stable version come.
> 
> regards,
> Adit Bharadwaj
> 
> On Aug 3, 2014 10:52 PM, "Jonathan Querubina"  wrote:
> Hi Guys,
> 
> Is there a good tutorial on Flashing the Tablet (FLATFISH_123456) using a 
> Mac? I would like to upgrade to FOS 2.x!
> 
> Thanks
> ___
> 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
> 
> 
> 
> ___
> 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

___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] does any dual-sim phone exists with firefox os support?

[John Ford]

The flame reference device has dual sims but not LTE.

https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame

John


On Aug 7, 2014, at 1:09 PM, akostadi...@gmail.com wrote:

> $subject
> 
> I'm trying to find a new device and wanted to try firefox os but need 
> dual-sim.
> 
> LTE availability is preferable.
> 
> Thank you
> ___
> 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] does any dual-sim phone exists with firefox os support?

[akostadinov]

$subject

I'm trying to find a new device and wanted to try firefox os but need dual-sim.

LTE availability is preferable.

Thank you
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] caldav and SSL autosigned. Fail

[moony]

For "unknown error" (certificate error) in Caldav (etc.?)

Originally Posted by doragasu (forum.xda-developers.com) 
Just launch the browser and input your server's URL. Then you will be warned 
about the not valid cert, add a permanent exception and that's all, now 
calendars should sync over HTTPS.
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] App signing strategy: support developer signature

[rtilder]

On Friday, August 1, 2014 2:34:05 AM UTC-7, Stéphanie Ouillon wrote:
> 
> If we're to support developer signing, we can imagine several models:
> 
> 1) handling multiple signatures: the app is signed twice, once by the
> developer and once by the Marketplace (e.g.: having two manifest files
> in META-INF signed by each key)
> 
> 2) the app is signed once by the developer key
> 
> 3) the app is signed once by a developer key which is trusted and signed
> by Mozilla
> 

I don't think the 3rd option is viable for process and possibly liability 
reasons(but IANAL).  Mozilla would effectively have to implement a certain 
minimum degree of process as a certificate authority to verify developers' 
certificates.

The 2nd option seems counter productive.

The 1st option seems to be the most correct.  I am uncertain how well the 
client side signature verification in b2g(or any other implementation) will 
handle multiple parallel signatures.

Three rough todos I can think of off the top of my head:

- Possibly need to modify the signing service to ignore existing .MF and .SF 
files in META-INF.  I can't recall if it does this already

- Tweak the Marketplace logic to verify that checksums of any existing 
manifests match what freshly generated checksums before signing with 
Marketplace cert.

- Tweak the client verification code to find the signature file that uses the 
Mozilla Marketplace certificate and only verify those signatures.  
Alternatively: tweak the logic so that it validates all signatures it finds but 
fail if it doesn't find one that is issued by the hardcoded Marketplace cert.

The work on the signing service side shouldn't be too extensive.  I can't speak 
to the amount of effort necessary on the client side.

--Ryan
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Enabling Voice Input in Open Web / Firefox OS

[rabimba]

If help is needed I can contribute for Phase 2. One of my application also 
needs speech support hence I was interested in this bug and also had a chat 
with Andre (in another forum where I was seeking information about this bug). 
Didn't know about this group.
I have some relevant experience for Phase 2 I believe. 

Please let me know how I can contribute.

On Tuesday, 1 July 2014 15:46:26 UTC-4, Sandip Kamat  wrote:
> "Many Voices, One Mozilla"
> 
> 
> 
> Hi All,
> 
> 
> 
> Here is the summary of high level draft plans we are beginning with for 
> enabling Voice Input in Open Web / Firefox OS. One of our Firefox OS 
> contributors Andre Natal (Brazil community) has done lots of preparatory work 
> and is currently continuing on a GSOC (Google Summer of Code) project around 
> this. The proposed 2 phases of the plan are in email below.
> 
> 
> 
> Please note the releases and estimates marked below are *all tentative* (will 
> change) and will be refined over next several months. We will continue adding 
> updates here:
> 
> 
> Wiki
> 
> https://wiki.mozilla.org/SpeechRTC_-_Speech_enabling_the_open_web
> 
>  Bugzilla
> 
> Bug 1032964 - [B2G][SpeechRTC][User Story]: Enabling Voice input in Firefox OS
> 
> 
> Trello board to track status: 
> 
> https://trello.com/b/UWXblmKb/webspeech-api
> 
> 
> 
> Github: 
> 
> https://github.com/andrenatal/gecko-dev
> 
> 
> 
> There is lots to do here and we are just starting, so if you are interested, 
> pls watch this wiki and help with the dependent bug# being added to the 
> meta-bug above. This kind of project could use great community participation 
> with contributing code, collecting / testing voice samples with various 
> accents (Remember "many voices, One Mozilla") to improve the acoustic / 
> language models, creating fun gamifications to achieve that and yes, we would 
> need tons & tons of testing! 
> 
> 
> Regards,
> 
> Sandip
> 
> Sandip Kamat | Product Management, Firefox OS | Mozilla Corporation 
> ska...@mozilla.com, @sankam
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Subject: Re: Planning SpeechRTC integration for FxOS
> 
> 
> 
> 
> 
> Thanks for joining the kickoff meeting. Here is the current proposal and next 
> steps. We will have a regular (frequency tbd) cadence of meetings on this.
> 
> 
> Propose to approach in 2 phases
> Phase 1 - Grammar based Voice Command appSimilar to this Nuance app: 
> https://www.youtube.com/watch?v=p0majfIEIR8&noredirect=1
> Needs Web Speech API implementationCurrent App level solutions present in 
> marketplace (Andre N)Voicity (uses pocketSphinx AM, custom LM, Verbio 
> decoder) (https://www.youtube.com/watch?v=cjjFvyH3kdc)Offline recognition on 
> Peak (https://www.youtube.com/watch?v=FXKXhrRDEb8)Phase 2 - Free Speech 
> (closer to Apple Siri experience)"Vaani" App - Virtual Assistant with free 
> speechWeb Speech API implementation enhancementsNeed to benchmark decoder 
> options & select solution, several decisions pending 
> Current App Crab (uses decoder from Nuance Ndev mobile - dev edition) 
> (https://www.youtube.com/watch?v=pnCRH-Iznrc)
> Next Steps
> Andre will finish most of phase 1 as a part of Google summer of code project. 
> Olli Pettay helping him. Needs support from CJ Ku's team to finish gecko 
> porting.Create Test scripts to test SpeechAPI (Andre, Clint). If that works 
> well, we could declare support for SpeechAPI in version 2.x. The other 
> implementation in phase 1 can be targeted for later version 2.x.Finalize 
> AM/LM/decoder strategies and rocketbar integration for phase 2. Create 
> release plan for phase 2 after some assessment of efforts.Strategy on Back 
> end server (Build vs license vs hybrid). Work with services/Mark Mayo's team. 
> (had a Call with Bill Maggs)
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

[b2g] Release candidates

[Marek Raida]

Hi there,
as a fresh new owner of Flame device, I'd like to participate in testing 
"almost finished, I believe" 1.4 version of FFOS.
But I see only some nightly builds ( 
http://ftp.mozilla.org/pub/mozilla.org/b2g/ ), but nothing like Release 
Candidates, Beta or Alpha versions, which are standardized for Desktop/Android 
Firefoxes.
So my questions are:
- if I want to test latest build/RC of v1.4 for Flame, where should I get it?
- is there plan to make B2G similar to other Firefox products (Aurora, Beta 
etc.)
- I know that bugfixing is hard, but still, according to 
https://wiki.mozilla.org/Release_Management/B2G_Landing is 1st September date 
when we could expect 1.4 release? Or sooner, later?

Cheers,
Marek
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Flame phone documentation, running adb as root

[Marek Raida]

I'm trying to make it working on Windows wit Cygwin, so far without success...

I created issue https://bugzilla.mozilla.org/show_bug.cgi?id=1050282
with a lot of log attachments and I do hope that someone will be able to 
help/advise me...

Script I'm using is here: 
https://github.com/Mozilla-TWQA/B2G-flash-tool/pull/240

Once it is working Chris can update its page and extends Windows support.
Fortunately, recovery 123 utility works great, I've used it more than three 
times today and it saved my ass ;-)
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

[b2g] Resolution change in firefox OS for S2.

[testtradingtest]

I am running Firefox OS in my S2 device. I checked that we can set different 
screen resolution for Firefox OS simulator by passing --screen option to 
b2g-bin with profile.

Is it possible that the same thing we can do with my S2 phone. I mean can we 
change the resolution to 240x320 in S2, so that other area became empty. 
I tried adding --screen parameter in gecko/gaia/b2g-run.c file in execle with 
profile option, but it didn't worked. Is there any other way to do that.
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Flame phone documentation, running adb as root

[Chris Mills]

Ok, instructions now updated and polished:

https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame

This now works really nicely on Mac and Linux. Although I have to ask, will 
this work on Windows?

cc’ing Jason, as I know he has tested most of this stuff on Windows. Jason - 
have you tested the most recent Flame nightly update instructions on Windows?

Chris Mills
   Senior tech writer || Mozilla
developer.mozilla.org || MDN
   cmi...@mozilla.com || @chrisdavidmills



On 7 Aug 2014, at 20:43, Chris Mills  wrote:

> Heh - now I feel silly. You are right Ryan, it was a permissions issue. chmod 
> 777 on the shallow_flash.sh file made it work without needing sudo…phew!
> 
> Ok, back to the article to do some more updates.
> 
> Chris Mills
>   Senior tech writer || Mozilla
> developer.mozilla.org || MDN
>   cmi...@mozilla.com || @chrisdavidmills
> 
> 
> 
> On 7 Aug 2014, at 19:22, J. Ryan Stinnett  wrote:
> 
>> I don't recall ever having to use "sudo" when flashing a device from
>> OS X, so I am a bit unsure why a few people have found that they need
>> it suddenly.
>> 
>> Chris, perhaps the permissions on those scripts aren't set correctly?
>> If you do "ls -l shallow_flash.sh", what do you get back?
>> 
>> - Ryan
>> 
>> On Thu, Aug 7, 2014 at 3:16 AM, Julien Wajsberg  
>> wrote:
>>> I really think we should try to do it without using sudo.
>>> 
>>> I don't know enough of MacOS X to know how to make it see the device, but
>>> I'm sure there is a solution like udev on LInux.
>>> 
>>> How does it work for other devices?
>>> 
>>> Le 07/08/2014 09:29, Chris Mills a écrit :
>>> 
 Hi there!
 
 I’ve now investigated the supplied instructions in the Flame article[1],
 tested them thoroughly, and updated them to make them clearer and more
 complete.
 
 Josh was right about needing to mention sudo: when I didn’t run flash.sh
 with sudo, the flash script seemed to fail to see the device, so it didn’t
 work; it just sat there saying “waiting for device”. When I did use sudo, 
 it
 worked fine.
 
 Then when I ran shallow_flash.sh without using sudo, it gave me a
 “permission denied” error. When I did use use sudo, that error went away.
 
 However, I am still stuck on that bit. The current text includes the
 following instruction:
 
 "5. To install the build on your phone download the shallow flash script
 and run it like this:
 
 sudo ./shallow_flash.sh -g/path/to/gaia.zip
 -G/path/to/b2g-XX.XX.en-US.android-arm.tar.gz”
 
 I’ve got shallow_flash.sh, gaia.zip and
 b2g-34.0a1.en-US.android-arm.tar.gz downloaded into the same directory. I
 then go into that directory in terminal and run the above command, and it
 gives me the message "sudo: ./shallow_flash.sh: command not found”.
 
 How do I fix this? ;-)
 
 Chris Mills
   Senior tech writer || Mozilla
 developer.mozilla.org || MDN
   cmi...@mozilla.com || @chrisdavidmills
 
 
 [1]
 https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame
 
 On 6 Aug 2014, at 20:34, Dave Hylands  wrote:
 
> I'm a little confused by some of your statments.
> 
> Whether you flash the base image as the root user or as a regular user
> will have NO impact on how adbd runs on the phone.
> 
> Running commands using sudo on the build machine only affects access to
> the devices on the build machine.
> 
> "adb root" relaunches the adbd on the phone under the root user (if the
> phone is configured to allow it).
> 
> Dave Hylands
> 
> 
> From: "Josh Aas" 
> To: dev-b2g@lists.mozilla.org
> Sent: Wednesday, August 6, 2014 9:15:36 AM
> Subject: [b2g] Flame phone documentation, running adb as root
> 
> I got a Flame phone and wanted to update it to 2.0 nightly so I could
> test/dogfood. Last week I couldn't figure out how to do that via the Flame
> home page, but someone has since added instructions. Thanks to whoever did
> that!
> 
> 
> https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame
> 
> One issue with the instructions, though, at least on OS X - they only
> really work if both flash steps are run as root (sudo). Flashing the base
> doesn't require root, but the flash to 2.0 nightly requires the adb daemon
> to be running as root, and if you didn't flash the base as root adb will 
> not
> be running as root. You'll need to do "adb kill-server", which most people
> won't know how to do. If you didn't run the base flash as root, and you
> figured out how to kill the adb server, you then need to run the second
> flash as root to get adb to start as root. We should either recommend that
> people run the flash commands as root (prefix "sudo"), or explain how to 
> get
> adb running as root first.
> 
> Other than th

Re: [b2g] Flame phone documentation, running adb as root

[Chris Mills]

Heh - now I feel silly. You are right Ryan, it was a permissions issue. chmod 
777 on the shallow_flash.sh file made it work without needing sudo…phew!

Ok, back to the article to do some more updates.

Chris Mills
   Senior tech writer || Mozilla
developer.mozilla.org || MDN
   cmi...@mozilla.com || @chrisdavidmills



On 7 Aug 2014, at 19:22, J. Ryan Stinnett  wrote:

> I don't recall ever having to use "sudo" when flashing a device from
> OS X, so I am a bit unsure why a few people have found that they need
> it suddenly.
> 
> Chris, perhaps the permissions on those scripts aren't set correctly?
> If you do "ls -l shallow_flash.sh", what do you get back?
> 
> - Ryan
> 
> On Thu, Aug 7, 2014 at 3:16 AM, Julien Wajsberg  wrote:
>> I really think we should try to do it without using sudo.
>> 
>> I don't know enough of MacOS X to know how to make it see the device, but
>> I'm sure there is a solution like udev on LInux.
>> 
>> How does it work for other devices?
>> 
>> Le 07/08/2014 09:29, Chris Mills a écrit :
>> 
>>> Hi there!
>>> 
>>> I’ve now investigated the supplied instructions in the Flame article[1],
>>> tested them thoroughly, and updated them to make them clearer and more
>>> complete.
>>> 
>>> Josh was right about needing to mention sudo: when I didn’t run flash.sh
>>> with sudo, the flash script seemed to fail to see the device, so it didn’t
>>> work; it just sat there saying “waiting for device”. When I did use sudo, it
>>> worked fine.
>>> 
>>> Then when I ran shallow_flash.sh without using sudo, it gave me a
>>> “permission denied” error. When I did use use sudo, that error went away.
>>> 
>>> However, I am still stuck on that bit. The current text includes the
>>> following instruction:
>>> 
>>> "5. To install the build on your phone download the shallow flash script
>>> and run it like this:
>>> 
>>> sudo ./shallow_flash.sh -g/path/to/gaia.zip
>>> -G/path/to/b2g-XX.XX.en-US.android-arm.tar.gz”
>>> 
>>> I’ve got shallow_flash.sh, gaia.zip and
>>> b2g-34.0a1.en-US.android-arm.tar.gz downloaded into the same directory. I
>>> then go into that directory in terminal and run the above command, and it
>>> gives me the message "sudo: ./shallow_flash.sh: command not found”.
>>> 
>>> How do I fix this? ;-)
>>> 
>>> Chris Mills
>>>Senior tech writer || Mozilla
>>> developer.mozilla.org || MDN
>>>cmi...@mozilla.com || @chrisdavidmills
>>> 
>>> 
>>> [1]
>>> https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame
>>> 
>>> On 6 Aug 2014, at 20:34, Dave Hylands  wrote:
>>> 
 I'm a little confused by some of your statments.
 
 Whether you flash the base image as the root user or as a regular user
 will have NO impact on how adbd runs on the phone.
 
 Running commands using sudo on the build machine only affects access to
 the devices on the build machine.
 
 "adb root" relaunches the adbd on the phone under the root user (if the
 phone is configured to allow it).
 
 Dave Hylands
 
 
 From: "Josh Aas" 
 To: dev-b2g@lists.mozilla.org
 Sent: Wednesday, August 6, 2014 9:15:36 AM
 Subject: [b2g] Flame phone documentation, running adb as root
 
 I got a Flame phone and wanted to update it to 2.0 nightly so I could
 test/dogfood. Last week I couldn't figure out how to do that via the Flame
 home page, but someone has since added instructions. Thanks to whoever did
 that!
 
 
 https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame
 
 One issue with the instructions, though, at least on OS X - they only
 really work if both flash steps are run as root (sudo). Flashing the base
 doesn't require root, but the flash to 2.0 nightly requires the adb daemon
 to be running as root, and if you didn't flash the base as root adb will 
 not
 be running as root. You'll need to do "adb kill-server", which most people
 won't know how to do. If you didn't run the base flash as root, and you
 figured out how to kill the adb server, you then need to run the second
 flash as root to get adb to start as root. We should either recommend that
 people run the flash commands as root (prefix "sudo"), or explain how to 
 get
 adb running as root first.
 
 Other than this, the page's information is much better than before. Still
 could be better organized, though.
 
 ___
 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
>>> 
>>> ___
>>> dev-b2g mailing list
>>> dev-b2g@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-b2g
>> 
>> 
>> ___
>> dev-b2g mailing list
>> dev

Re: [b2g] ZTE OPEN C Roms & CW Recovery .50

[bobla71]

2014. július 6., vasárnap 7:28:10 UTC+2 időpontban vamp...@gmail.com a 
következőt írta:
> On Saturday, July 5, 2014 1:29:08 PM UTC-4, vampirefo wrote:
> 
> > Here are some Firefox Roms, I have uploaded as well as .50 CWM recovery.
> 
> > 
> 
> > 
> 
> > 
> 
> > https://drive.google.com/folderview?id=0B_6NtXCtTLkHeGgzcDVwWnZWR2c&usp=sharing
> 
> 
> 
> I have uploaded kitkat rooted with gapps if you guys want to try it, you have 
> to run unlock tool first and then use fastboot to boot the recovery, 
> 
> place kitkat_signed.zip on sdcard and install via custom recovery, once 
> installed, when you try to boot back to system, you will be asked two 
> questions answer no to both.

Could you tell how to install kitkat in VERY details ? I'm new in this 
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Adding APN in Gaia

[Andreas Gal]

Feel free to add a patch for a build step that merges a local database in 
addition to apns_conf.xml and then add the APN in that local database.

Thanks!

Andreas

On Aug 5, 2014, at 7:13 AM, Safwan Rahman  wrote:

> Hi,
> As there many APN of different operators listed in apns_conf.xml Databse (1). 
> In the Database some operators APN is missing. I would like to add more APN 
> into the Database. For adding some more APN into the database, a bug was 
> filled. But, it seems that it needed to be add in AOSP first then need to 
> pull from there. I would like to know, without adding it into AOSP. is it 
> possible to add APN into our database?
> 
> I have seen another bug similar to this where APN of Canadian operator was 
> added into the Database.(3) So can I follow the same method to modify the 
> database and add the Bangladeshi Operator APN also?
> 
> Regards
> Safwan
> 
> 1. 
> https://github.com/mozilla-b2g/gaia/blob/master/shared/resources/apn/apns_conf.xml
> 2. https://bugzilla.mozilla.org/show_bug.cgi?id=1011584
> 3. https://bugzilla.mozilla.org/show_bug.cgi?id=807312
> ___
> 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

[b2g] Gaia and b2g-inbound closed

[Ryan VanderMeulen]

Due to the ongoing problems with hg.mozilla.org today, all trees are currently 
closed, including Gaia.

Bug 1040308 tracks the issue. Apologies for the inconvenience.

-Ryan
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Engineering Mode (aka "service menu")

[Jonas Sicking]

On Thu, Aug 7, 2014 at 8:43 AM, Ehsan Akhgari  wrote:
> On 2014-08-02, 8:05 PM, Jonas Sicking wrote:
>>
>> Hi All,
>>
>> We have many times debated how to handle engineering mode. Various
>> partners have so far been adding in custom solutions on their own
>> branches, but it would be good to find a better solution.
>>
>> Below is one proposed solution, though I'm definitely open to other
>> ones. However the goals I'd like to accomplish are:
>>
>> A) The commands that can be triggered in the service menu is going to
>> be fairly OEM specific and not something that makes sense to build
>> into Gecko as cross-device-cross-device code.
>> B) The smaller Gecko/Gaia changes needed by OEMs the better. This is
>> to simplify porting the implementation forward to future FirefoxOS
>> releases.
>> C) We would like to one day be able to roll out updates to phones
>> without requiring OEMs to reapply their own changes to the updated
>> release.
>> D) The back-end of the service menu needs to be at least partially
>> implemented in C++. I.e. some of the commands that can be triggered
>> can't be implemented using the currently exposed APIs, even including
>> certified APIs.
>> F) The service menu UI should be implemented as a separate FirefoxOS
>> HTML app. I.e. we don't want to use some other rendering mechanism
>> than what we already have. And we don't want to have to add a lot of
>> engineering mode code to any of the normal gaia apps.
>> G) There shouldn't need to be a user visible icon on the home screen
>> for launching engineering mode.
>> H) It would be ideal, though not strictly required, if it was possible
>> to launch engineering mode by using a key combination in the dialer
>> app since this is how OEMs are used to doing it today.
>>
>> Based on that I recommend the following setup:
>>
>> 1) Add a gaia-setting for "key combination in dialer that triggers
>> service mode".
>> 2) Change the dialer app to read this setting and wait for the correct
>> key combination to be triggered.
>> 3) When the combination has been hit, let the dialer app launch an
>> activity called "internal-system-engineering-mode".
>> 4) Change web activities to enforce that activity names starting with
>> "internal-system-" can only be initiated and handled by certified
>> apps.
>> 5) Add a XPCOM interface and an XPCOM contract-id for engineering
>> mode. The interface would have functions for
>> getValue/setValue/message. See below
>> 6) Create a certified-only WebAPI which handles the IPC and security
>> checks to enable an app to use the above XPCOM interface.
>>
>> The XPCOM interface would look something like:
>>
>> // Implemented by engineering-mode library
>> interface nsIEngineeringMode
>> {
>>DOMString getValue(in DOMString name);
>>void setValue(in DOMString name, in DOMString value);
>>void setMessageHandler(in nsIEngineeringModeMessageHandler handler);
>> }
>>
>> interface nsIEngineeringModeMessageHandler
>> {
>>void handleMessage(DOMString message);
>> }
>>
>> and the contract id would be something like
>> "@mozilla.org/b2g/engineering-mode;1"
>>
>>
>> And the WebAPI would look something like
>>
>> interface EngineeringMode {
>
>
> Small nit: This needs to derive from EventTarget, obviously!

Yes.

>>Promise getValue(DOMString name);
>>void setValue(DOMString name, DOMString value);
>
>
> Shouldn't setValue return a Promise instead?  I can imagine that the
> services app may want to wait until a specific setValue call to finish
> successfully before proceeding further.

My thinking was to keep things simple. The code can always send a
message once a 'set' succeeds.

But it might make sense as a convenience to make
EngineeringMode.setValue reject a promise if the
nsIEngineeringMode.setValue function returns an error nsresult.

/ Jonas
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Flame phone documentation, running adb as root

[J. Ryan Stinnett]

I don't recall ever having to use "sudo" when flashing a device from
OS X, so I am a bit unsure why a few people have found that they need
it suddenly.

Chris, perhaps the permissions on those scripts aren't set correctly?
If you do "ls -l shallow_flash.sh", what do you get back?

- Ryan

On Thu, Aug 7, 2014 at 3:16 AM, Julien Wajsberg  wrote:
> I really think we should try to do it without using sudo.
>
> I don't know enough of MacOS X to know how to make it see the device, but
> I'm sure there is a solution like udev on LInux.
>
> How does it work for other devices?
>
> Le 07/08/2014 09:29, Chris Mills a écrit :
>
>> Hi there!
>>
>> I’ve now investigated the supplied instructions in the Flame article[1],
>> tested them thoroughly, and updated them to make them clearer and more
>> complete.
>>
>> Josh was right about needing to mention sudo: when I didn’t run flash.sh
>> with sudo, the flash script seemed to fail to see the device, so it didn’t
>> work; it just sat there saying “waiting for device”. When I did use sudo, it
>> worked fine.
>>
>> Then when I ran shallow_flash.sh without using sudo, it gave me a
>> “permission denied” error. When I did use use sudo, that error went away.
>>
>> However, I am still stuck on that bit. The current text includes the
>> following instruction:
>>
>> "5. To install the build on your phone download the shallow flash script
>> and run it like this:
>>
>> sudo ./shallow_flash.sh -g/path/to/gaia.zip
>> -G/path/to/b2g-XX.XX.en-US.android-arm.tar.gz”
>>
>> I’ve got shallow_flash.sh, gaia.zip and
>> b2g-34.0a1.en-US.android-arm.tar.gz downloaded into the same directory. I
>> then go into that directory in terminal and run the above command, and it
>> gives me the message "sudo: ./shallow_flash.sh: command not found”.
>>
>> How do I fix this? ;-)
>>
>> Chris Mills
>> Senior tech writer || Mozilla
>> developer.mozilla.org || MDN
>> cmi...@mozilla.com || @chrisdavidmills
>>
>>
>> [1]
>> https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame
>>
>> On 6 Aug 2014, at 20:34, Dave Hylands  wrote:
>>
>>> I'm a little confused by some of your statments.
>>>
>>> Whether you flash the base image as the root user or as a regular user
>>> will have NO impact on how adbd runs on the phone.
>>>
>>> Running commands using sudo on the build machine only affects access to
>>> the devices on the build machine.
>>>
>>> "adb root" relaunches the adbd on the phone under the root user (if the
>>> phone is configured to allow it).
>>>
>>> Dave Hylands
>>>
>>>
>>> From: "Josh Aas" 
>>> To: dev-b2g@lists.mozilla.org
>>> Sent: Wednesday, August 6, 2014 9:15:36 AM
>>> Subject: [b2g] Flame phone documentation, running adb as root
>>>
>>> I got a Flame phone and wanted to update it to 2.0 nightly so I could
>>> test/dogfood. Last week I couldn't figure out how to do that via the Flame
>>> home page, but someone has since added instructions. Thanks to whoever did
>>> that!
>>>
>>>
>>> https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame
>>>
>>> One issue with the instructions, though, at least on OS X - they only
>>> really work if both flash steps are run as root (sudo). Flashing the base
>>> doesn't require root, but the flash to 2.0 nightly requires the adb daemon
>>> to be running as root, and if you didn't flash the base as root adb will not
>>> be running as root. You'll need to do "adb kill-server", which most people
>>> won't know how to do. If you didn't run the base flash as root, and you
>>> figured out how to kill the adb server, you then need to run the second
>>> flash as root to get adb to start as root. We should either recommend that
>>> people run the flash commands as root (prefix "sudo"), or explain how to get
>>> adb running as root first.
>>>
>>> Other than this, the page's information is much better than before. Still
>>> could be better organized, though.
>>>
>>> ___
>>> 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
>>
>> ___
>> 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
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Announcing the WebIDE Monitor

[Jan Keromnes]

+dev-webapps on :digitarald's suggestion.

On Thu 07 Aug 2014 05:08:02 PM CEST, Jan Keromnes wrote:

We landed a data tool inside WebIDE called the Monitor.

It can track the memory footprint (USS) of apps in a Firefox OS device.
It's also easy to create your own graphs, by sending it data from the
device itself or your computer.

More info: https://developer.mozilla.org/docs/Tools/WebIDE/Monitor

:janx
___
dev-developer-tools mailing list
dev-developer-to...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-developer-tools

___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Engineering Mode (aka "service menu")

[Ehsan Akhgari]

On 2014-08-02, 8:05 PM, Jonas Sicking wrote:

Hi All,

We have many times debated how to handle engineering mode. Various
partners have so far been adding in custom solutions on their own
branches, but it would be good to find a better solution.

Below is one proposed solution, though I'm definitely open to other
ones. However the goals I'd like to accomplish are:

A) The commands that can be triggered in the service menu is going to
be fairly OEM specific and not something that makes sense to build
into Gecko as cross-device-cross-device code.
B) The smaller Gecko/Gaia changes needed by OEMs the better. This is
to simplify porting the implementation forward to future FirefoxOS
releases.
C) We would like to one day be able to roll out updates to phones
without requiring OEMs to reapply their own changes to the updated
release.
D) The back-end of the service menu needs to be at least partially
implemented in C++. I.e. some of the commands that can be triggered
can't be implemented using the currently exposed APIs, even including
certified APIs.
F) The service menu UI should be implemented as a separate FirefoxOS
HTML app. I.e. we don't want to use some other rendering mechanism
than what we already have. And we don't want to have to add a lot of
engineering mode code to any of the normal gaia apps.
G) There shouldn't need to be a user visible icon on the home screen
for launching engineering mode.
H) It would be ideal, though not strictly required, if it was possible
to launch engineering mode by using a key combination in the dialer
app since this is how OEMs are used to doing it today.

Based on that I recommend the following setup:

1) Add a gaia-setting for "key combination in dialer that triggers
service mode".
2) Change the dialer app to read this setting and wait for the correct
key combination to be triggered.
3) When the combination has been hit, let the dialer app launch an
activity called "internal-system-engineering-mode".
4) Change web activities to enforce that activity names starting with
"internal-system-" can only be initiated and handled by certified
apps.
5) Add a XPCOM interface and an XPCOM contract-id for engineering
mode. The interface would have functions for
getValue/setValue/message. See below
6) Create a certified-only WebAPI which handles the IPC and security
checks to enable an app to use the above XPCOM interface.

The XPCOM interface would look something like:

// Implemented by engineering-mode library
interface nsIEngineeringMode
{
   DOMString getValue(in DOMString name);
   void setValue(in DOMString name, in DOMString value);
   void setMessageHandler(in nsIEngineeringModeMessageHandler handler);
}

interface nsIEngineeringModeMessageHandler
{
   void handleMessage(DOMString message);
}

and the contract id would be something like
"@mozilla.org/b2g/engineering-mode;1"


And the WebAPI would look something like

interface EngineeringMode {


Small nit: This needs to derive from EventTarget, obviously!


   Promise getValue(DOMString name);
   void setValue(DOMString name, DOMString value);


Shouldn't setValue return a Promise instead?  I can imagine that 
the services app may want to wait until a specific setValue call to 
finish successfully before proceeding further.



   attribute EventHandler onmessage;
}

partial interface Navigator {
   readonly attribute EngineeringMode engineeringMode;
}



Once we have this, it means that OEMs could implement engineering mode
by simply dropping a shared library in the Gecko profile which
implements the needed backend. Then preinstall a certified app which
handles the internal-system-engineering-mode webactivity. This app
could then use any existing certified API as well as new
EngineerinMode API, to implement the service menu.

Obviously this app would be marked as hidden as to prevent it from
showing up on the homescreen.


The rest looks great to me!

Cheers,
Ehsan

___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

[b2g] Announcing the WebIDE Monitor

[Jan Keromnes]

We landed a data tool inside WebIDE called the Monitor.

It can track the memory footprint (USS) of apps in a Firefox OS device.
It's also easy to create your own graphs, by sending it data from the 
device itself or your computer.


More info: https://developer.mozilla.org/docs/Tools/WebIDE/Monitor

:janx
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

[b2g] 08/07/2014 Flame Gaia-ui Automation v2.0 Mozilla RIL Build 38/38 smoketests, 79/82 non-smoketests

[Viorela Ioia]

*Smoketests:*
*
Test failures - 0 replicable manually:*

 * None

*Expected failures / disabled tests:*

 * [Disabled] test_setup_and_send_active_sync_email.py - *Bug 1028192*
    -Problems
   with ActiveSync accounts
 * [Disabled] test_receive_active_sync_email.py - *Bug 1028192*
    -Problems
   with ActiveSync accounts

*
Non-smoketests - 1***replicable manually*:**

Test failures:*

 * [Not reproducible manually] test_cost_control_reset_wifi.py -
   *Bug 1046131* 
   -[v2.0] Investigate intermittent failure in
   test_cost_control_reset_wifi.py
 * [Reproducible manually] test_persona_app.py -
   https://github.com/mozilla/personatestuser.org/issues/44
 * [Not reproducible manually] test_settings_power_save_mode.py -
   unable to reproduce the failure locally by running the automated
   test or manually; from the jenkins screenshot it looks like the
   power save mode checkbox was not toggled; the tests still under
   investigation.

*Expected failures / disabled tests:*

 * [Disabled] test_settings_sim_manager.py - Disabled because run the
   device with 1 SIM only
 * [Disabled] test_gallery_view.py - *Bug 1042032*
    -Phone
   reports that it's in portrait mode

*Build under test:
*Gaia  8cc28fd31905a0ea2b2e15d13e80a0eab2feb1ba
Gecko https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/25980b5120b0
BuildID   20140807000201
Version   32.0
ro.build.version.incremental=109
ro.build.date=Mon Jun 16 16:51:29 CST 2014
B1TC00011220
*

Summary:*
Smoketests:
38 tests ran in 2174 seconds.
38 passed, 89 skipped, 0 failed, 0 errors.
0 expected failures, 0 unexpected passes.

Non-smoketests:
82 tests ran in 4069 seconds.
79 passed, 45 skipped, 0 failed, 3 errors.
0 expected failures, 0 unexpected passes.



___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

[b2g] 08/07/2014 Flame Gaia-ui Automation v2.1 Mozilla RIL Build 39/40 smoketests, 79/84 non-smoketests

[Robert Chira]

*Smoketests:*
*
Test failures -  0 replicable manually:*

 * [Not Reproducible manually] test_play_3gp_video - *Bug 1024517*
    -[Flame]
   Investigate Video app test failures

*Expected failures / disabled tests:*

 * [Disabled] test_setup_and_send_active_sync_email.py - *Bug 1028192*
    -Problems
   with ActiveSync accounts
 * [Disabled] test_receive_active_sync_email.py - *Bug 1028192*
    -Problems
   with ActiveSync accounts

*Non-smoketests - 2***replicable manually*:**

Test failures:*

 * [Reproducible manually] test_import_contacts_from_gmail - The fix
   from *Bug 1048141*
    was not
   included inthe current build
 * [Not Reproducible manually] test_find_next_previous_station -
   *Bug 1000863* 
   -Investigate test_fmradio_find_stations.py failure
 * [Reproducible manually] test_persona_standard_sign_in -
   https://github.com/mozilla/personatestuser.org/issues/44
 * [Not Reproducible manually] test_connect_to_wifi_via_settings_app -
   *Bug 1050245* 
   -[v2.1] fix test_connect_to_wifi_via_settings_app failure
 * [Not Reproducible manually] test_settings_root_items - *Bug 1050231*
    -[v2.1] Fix
   test_settings_root_items failure

*Expected failures / disabled tests:*

 * [Disabled] test_settings_sim_manager.py - Disabled because run the
   device with 1 SIM only


*Build under test:
*
Device firmware (date) 23 Jul 2014 07:25:46
Device firmware (incremental) eng.cltbld.20140723.102536
Device firmware (release) 4.3
Device identifier flame
Gaia date 06 Aug 2014 13:50:48
Gaia revision 079c5f85875b
Gecko build 20140807040201
Gecko revision afcb3af79d09
Gecko version 34.0a1
*

Summary:*
Smoketests:
40 tests ran in 2308 seconds.
39 passed, 89 skipped, 0 failed, 1 errors.
0 expected failures, 0 unexpected passes.

Non-smoketests:
84 tests ran in 4453 seconds.
79 passed, 45 skipped, 0 failed, 5 errors.
0 expected failures, 0 unexpected passes.
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

[b2g] Fwd: Flash Firefox OS on Tablet

[Josh Smith]

Forwarding Stephen's message.

- Josh


-- Forwarded message --
From: Stephen Murphy 
Date: Thu, Aug 7, 2014 at 4:40 AM
Subject: Re: [b2g] Flash Firefox OS on Tablet
To: Josh Smith 


Ensure you flash your bootloader BEFORE flashing the 2.x image
https://wiki.mozilla.org/FirefoxOS/TCP/Flashing_the_Flatfish_bootloader


On 6 August 2014 13:55, Josh Smith  wrote:

> Unfortunately, no.  A good deal of 1.4 bugs are fixed in 2.0 or 2.1.
>
> - Josh
>
>
> On Wed, Aug 6, 2014 at 12:13 AM, KAMI911 KAMI911 
> wrote:
>
>> Hi,
>>
>> Is it worth to report bugs against version 1.4?
>>
>>
>>
>> Üdvözlettel / Best Regards:
>>
>> Kálmán (KAMI) Szalai
>>
>>
>> 2014-08-03 20:11 GMT+02:00 adit bharadwaj :
>>
>>> hey,
>>>
>>> http://openmoz.wordpress.com/2014/07/13/flash-firefox-os-2-1-into-your-tablet/
>>>
>>> following is best link for flashing the flatfish tablet.
>>> but 2.1 wid good interface has many disadvantages.. video and camera
>>> crashes and its unstable.. so u can go for it but i prefer u to stay at 1.4
>>> till stable version come.
>>>
>>> regards,
>>> Adit Bharadwaj
>>> On Aug 3, 2014 10:52 PM, "Jonathan Querubina" 
>>> wrote:
>>>
 Hi Guys,

 Is there a good tutorial on Flashing the Tablet (FLATFISH_123456) using
 a Mac? I would like to upgrade to FOS 2.x!

 Thanks
 ___
 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
>>>
>>>
>>
>> ___
>> 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
>
>
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Engineering Mode (aka "service menu")

[Adrian Custer]

On 8/7/14 12:56 AM, Paul Theriault wrote:
> So to summarise the security requirements &properties here:
>
> - Engineering mode will be disabled until the dialer (or other
> certified app) initiates the special web activity - Even with
> engineering mode enabled, only an app with the certified
> “engineering-mode” (or similar) permission can access the API which
> can be extended by the vendor
>
> I’d make a couple notes here: - There is no reason for side loaded
> apps to have this permission, and its present a very real threat of
> local privilege escalation,  so we should explicitly prevent side
> loading apps which have access to these APIs (perhaps so long as the
> devtools.debugger.forbid-certified-apps pref is true, so engineering
> build phones can still access them). - The dialer should take observe
> lock state - we need to prevent enabling engineering mode from the
> dialer presented by the lockscreen ( i think your patch does this
> already though since it only changes the dialer, not the lockscreen
> dialer)
>
> We should also provide security guidance to Partners implementing
> engineering mode functionality to reduce the risk of security issues
> here.
>
> Does that sound reasonable?
>
> - Paul


Hey Paul,

you write 'there is no reason' and then think of a reason and provide an 
exception for that reason 'perhaps so long as'. This reveals you are 
trying to work quickly and so are not setting up a clear framework for 
thinking, presumably because you do not need to. For me this is 
difficult since I personally cannot reason this way when thinking about 
a 'very real threat'.



Does the FirefoxOS team, or its security sub-group have a pre-defined 
set of users and their needs used for the security analysis of 
FirefoxOS? I would expect a list of strawman users whose conflicting 
needs are defined and agreed about, so that these needs can be reasoned 
about effectively, something like:


  Dad   Jose --- Just a user, wants all the 'security' he can get
  Student   Kate --- Builds apps, so needs to side load apps
  Developer Luna --- Needs root for debugging and flashing
  Engineer  Mani --- needs root and low level engineering access
  HackerNuro --- wants full control

i.e. j,k,l,m,n with (mostly) increasing levels of access needs.

If there is such a list, I would be interested to read it so that I 
could contextualize these security discussions in the context of the 
impacts on these different classes of users.


Thanks,
  ~adrian
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

[b2g] 08/07/2014 Dolphin 1.4 Mozilla RIL Smoke Test Results - 48/48 tests passed, 0 blocker

[Peipei Cheng]

48 out of 48 tests passed for the 2014-08-07 Dolphin V1.4 Mozilla RIL
Build.

Mozilla RIL Build Smoketest Results:

Moztrap test result link:  
https://moztrap.mozilla.org/results/cases/?filter-run=4957

Moztrap test run link:  https://moztrap.mozilla.org/runtests/run/4957/env/27895/

 

New Bugs Breaking the Smoketests:

None was found.

Existing Bugs Breaking the Smoketests:

None was found.

New Issues Not Breaking the Smoketests:

None was found.

Tests Were Performed With:

BuildID:*20140807000201*

Gaia:*e9dce1f60f729e228810f751417681b5ff937b6b*

Gecko:https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/*89a8a24a8b1b*

Build Location:
https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-b2g30_v1_4-dolphin/2014/08/2014-08-07-00-02-01/

1 reboot

0 crashes

Sincerely,

Mozilla QA Team

___

Qa-b2g mailing list

qa-...@mozilla.org

https://mail.mozilla.org/listinfo/qa-b2g

___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Re: [b2g] Flame phone documentation, running adb as root

[Julien Wajsberg]

I really think we should try to do it without using sudo.

I don't know enough of MacOS X to know how to make it see the device, 
but I'm sure there is a solution like udev on LInux.


How does it work for other devices?

Le 07/08/2014 09:29, Chris Mills a écrit :

Hi there!

I’ve now investigated the supplied instructions in the Flame article[1], tested 
them thoroughly, and updated them to make them clearer and more complete.

Josh was right about needing to mention sudo: when I didn’t run flash.sh with 
sudo, the flash script seemed to fail to see the device, so it didn’t work; it 
just sat there saying “waiting for device”. When I did use sudo, it worked fine.

Then when I ran shallow_flash.sh without using sudo, it gave me a “permission 
denied” error. When I did use use sudo, that error went away.

However, I am still stuck on that bit. The current text includes the following 
instruction:

"5. To install the build on your phone download the shallow flash script and 
run it like this:

sudo ./shallow_flash.sh -g/path/to/gaia.zip 
-G/path/to/b2g-XX.XX.en-US.android-arm.tar.gz”

I’ve got shallow_flash.sh, gaia.zip and b2g-34.0a1.en-US.android-arm.tar.gz 
downloaded into the same directory. I then go into that directory in terminal and 
run the above command, and it gives me the message "sudo: ./shallow_flash.sh: 
command not found”.

How do I fix this? ;-)

Chris Mills
Senior tech writer || Mozilla
developer.mozilla.org || MDN
cmi...@mozilla.com || @chrisdavidmills


[1] https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame

On 6 Aug 2014, at 20:34, Dave Hylands  wrote:


I'm a little confused by some of your statments.

Whether you flash the base image as the root user or as a regular user will 
have NO impact on how adbd runs on the phone.

Running commands using sudo on the build machine only affects access to the 
devices on the build machine.

"adb root" relaunches the adbd on the phone under the root user (if the phone 
is configured to allow it).

Dave Hylands


From: "Josh Aas" 
To: dev-b2g@lists.mozilla.org
Sent: Wednesday, August 6, 2014 9:15:36 AM
Subject: [b2g] Flame phone documentation, running adb as root

I got a Flame phone and wanted to update it to 2.0 nightly so I could 
test/dogfood. Last week I couldn't figure out how to do that via the Flame home 
page, but someone has since added instructions. Thanks to whoever did that!

https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame

One issue with the instructions, though, at least on OS X - they only really work if both flash 
steps are run as root (sudo). Flashing the base doesn't require root, but the flash to 2.0 nightly 
requires the adb daemon to be running as root, and if you didn't flash the base as root adb will 
not be running as root. You'll need to do "adb kill-server", which most people won't know 
how to do. If you didn't run the base flash as root, and you figured out how to kill the adb 
server, you then need to run the second flash as root to get adb to start as root. We should either 
recommend that people run the flash commands as root (prefix "sudo"), or explain how to 
get adb running as root first.

Other than this, the page's information is much better than before. Still could 
be better organized, though.

___
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

___
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] Flame phone documentation, running adb as root

[Chris Mills]

Hi there!

I’ve now investigated the supplied instructions in the Flame article[1], tested 
them thoroughly, and updated them to make them clearer and more complete.

Josh was right about needing to mention sudo: when I didn’t run flash.sh with 
sudo, the flash script seemed to fail to see the device, so it didn’t work; it 
just sat there saying “waiting for device”. When I did use sudo, it worked fine.

Then when I ran shallow_flash.sh without using sudo, it gave me a “permission 
denied” error. When I did use use sudo, that error went away.

However, I am still stuck on that bit. The current text includes the following 
instruction:

"5. To install the build on your phone download the shallow flash script and 
run it like this:

sudo ./shallow_flash.sh -g/path/to/gaia.zip 
-G/path/to/b2g-XX.XX.en-US.android-arm.tar.gz”

I’ve got shallow_flash.sh, gaia.zip and b2g-34.0a1.en-US.android-arm.tar.gz 
downloaded into the same directory. I then go into that directory in terminal 
and run the above command, and it gives me the message "sudo: 
./shallow_flash.sh: command not found”.

How do I fix this? ;-)

Chris Mills
   Senior tech writer || Mozilla
developer.mozilla.org || MDN
   cmi...@mozilla.com || @chrisdavidmills


[1] https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame

On 6 Aug 2014, at 20:34, Dave Hylands  wrote:

> I'm a little confused by some of your statments.
> 
> Whether you flash the base image as the root user or as a regular user will 
> have NO impact on how adbd runs on the phone.
> 
> Running commands using sudo on the build machine only affects access to the 
> devices on the build machine.
> 
> "adb root" relaunches the adbd on the phone under the root user (if the phone 
> is configured to allow it).
> 
> Dave Hylands
> 
> 
> From: "Josh Aas" 
> To: dev-b2g@lists.mozilla.org
> Sent: Wednesday, August 6, 2014 9:15:36 AM
> Subject: [b2g] Flame phone documentation, running adb as root
> 
> I got a Flame phone and wanted to update it to 2.0 nightly so I could 
> test/dogfood. Last week I couldn't figure out how to do that via the Flame 
> home page, but someone has since added instructions. Thanks to whoever did 
> that!
> 
> https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame
> 
> One issue with the instructions, though, at least on OS X - they only really 
> work if both flash steps are run as root (sudo). Flashing the base doesn't 
> require root, but the flash to 2.0 nightly requires the adb daemon to be 
> running as root, and if you didn't flash the base as root adb will not be 
> running as root. You'll need to do "adb kill-server", which most people won't 
> know how to do. If you didn't run the base flash as root, and you figured out 
> how to kill the adb server, you then need to run the second flash as root to 
> get adb to start as root. We should either recommend that people run the 
> flash commands as root (prefix "sudo"), or explain how to get adb running as 
> root first.
> 
> Other than this, the page's information is much better than before. Still 
> could be better organized, though.
> 
> ___
> 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

___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g