Re: [b2g] Flame phone documentation, running adb as root
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] Release candidates
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] Release candidates
On 8 Aug 2014, at 06:32, Marek Raida marek.ra...@gmail.com 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
Le 08/08/2014 07:32, Marek Raida a écrit : 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 For sure we won't fix new bugs in v1.3, v1.4 (unless they are severe), but we will for v2.0. So reporting bugs for v2.0 is what makes the most sense right now. -- Julien ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] 08/08/2014 Dolphin 1.4 Mozilla RIL Smoke Test Results - 48/48 tests passed, 0 blocker
48 out of 48 tests passed for the 2014-08-08 Dolphin V1.4 Mozilla RIL Build. Mozilla RIL Build Smoketest Results: Moztrap test result link: https://moztrap.mozilla.org/results/cases/?filter-run=4972 Moztrap test run link: https://moztrap.mozilla.org/runtests/run/4972/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:*20140808000201* Gaia:*2b2849a61cd38e909ed1c3e4586d104bc96f7001* Gecko:https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/*d1d01a4ee4c3* Build Location: https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-b2g30_v1_4-dolphin/2014/08/2014-08-08-00-02-01/ 0 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] Versioning mozilla-b2g/B2G
Thank you - that sounds great! :-) On 05/08/2014 19:26, John Ford wrote: I've been thinking of a way to fix this but haven't written the proposal out. The end result would have all the scripts move into repo managed git repositories and have the actual B2G.git repository turn into a script that has enough to bootstrap repo. I hope to have this written up this week. John On Aug 5, 2014, at 9:10 AM, Chris Atlee cat...@mozilla.com mailto:cat...@mozilla.com wrote: On 13:22, Tue, 05 Aug, Ed Morley wrote: The repo mozilla-b2g/B2G is currently not handled by the B2G bumper bot (script that uses a set of templates in the b2g-manifest repo to update the manifests in the gecko repo) - and so: a) It becomes hard for people to land backwards incompatible changes to mozilla-b2g/B2G if they also require changes to repos that _are_ tracked by the bumper bot (eg 1047350). b) No commit is displayed on TBPL/treeherder, which makes the root cause of failures due to changes to this repo harder to find (eg bug 1048819). The solution is to add B2G bumper bot support for this repo - which means the B2G build will only use the revision listed in the manifest inside the relevant gecko repository, and not just silently pull master. With this there are two options: 1) Have the B2G bumper bot follow master of mozilla-b2g/B2G for all branches, including mozilla-b2g30_v1_4, ... 2) Create v2.x, v1.x branches on mozilla-b2g/B2G (the same gonk-misc, ...), and have legacy branches such as mozilla-b2g30_v1_4 follow v1.4 etc. #2 would be the ideal solution, since it solves both (a) and (b) above, whereas #1 would only solve (b). Are there any objections to doing #2? There's currently no place to record this branch/revision. B2G is not tracked by any of the device manifests, and the current directory structure has the B2G checkout being outside of any of the repositories tracked by the device manifests. Where do you propose we track the B2G repo branch/commit? ___ dev-b2g mailing list dev-b2g@lists.mozilla.org mailto: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] Proposal: Manage B2G.git scripts in a versioned repo
Hello, Thanks for putting work into the build system. On 8/5/14 4:51 PM, John Ford wrote: ...snip... My plan is to: 1) create b2g-scripts repository, containing the B2G.git/scripts directory 2) create b2g-tools repository, containing the B2G.git/tools directory 3) move all scripts in the root of B2G.git into b2g-scripts 4) use repo file copy operations (like we do for the root Makefile) to copy those scripts back into the root of the source tree 5) remove the device configuration part of config.sh 6) create a new script, config-device.sh in b2g-scripts that has the device configuration steps. 7) have config.sh call config-device.sh after the source tree is initialized ...snip... Please let me know if you have any thoughts on this issue. ...snip... In step 3, is there any chance the scripts could be segregated or at least given a name which suggests where they apply? The current B2G has scripts that run for backup, for the build, at runtime for performance and some I did not take the time to decipher. We would all benefit from having the purpose of the scripts self-evident either by their name or location. Why step 4? Why allow any scripts in the root of the workspace? Is this merely to avoid having to clean them up, because they 'belong' to other folk, or for some technical reason? Given that 'repo' is a tool to enable everyone to have a build system which is also a developer workspace, proper etiquette (and good working habits) would be to keep this directory CLEAN. Ideally, the working directory would go from 1. empty (or with a single bootstrap script) 2. filled with B2G contents 3. additionally with source code directories 4. additionally with build directories and then alternate between 3 (after a clean) and 4 (after a build) with edits to source all in the directories from steps 2 or 3. All files in the root directory would be a developer's own files they use for their own work. The B2G build system, built on repo, is totally complex and not yet documented; keeping the layout clean can only help. I would propose ruthlessly moving all the scripts into a b2g-scripts/unsorted/ directory and require those who use such scripts to give them some attention. This would include a clear name (as per the previous paragraph), proper copyright and licensing info, a link to documentation if any, and contact info for issues. Steps 5-7 begin a cleanup of the build scripts themselves a much bigger topic. cheers, ~adrian ___ 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
After flashing the base image, adb will wind up being disabled by default. So you'll need to go into Settings and turn it back on (IIRC it's the checkbox called Remote Debugging) in Settings-Device Information-More Information-Developer Dave Hylands - Original Message - From: Marek Raida marek.ra...@gmail.com To: mozilla-dev-...@lists.mozilla.org Sent: Thursday, August 7, 2014 10:20:00 PM Subject: Re: [b2g] Flame phone documentation, running adb as root 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 ___ 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
I'm sure I did it, checked it twice. Some other ideas, please? After flashing the base image, adb will wind up being disabled by default. So you'll need to go into Settings and turn it back on (IIRC it's the checkbox called Remote Debugging) in Settings-Device Information-More Information-Developer ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] ZTE Open C: Can't see own phone number on FFOS 2.1 build, for sending to others.
On Wednesday, August 6, 2014 3:44:53 AM UTC-4, Julien Wajsberg wrote: Le 06/08/2014 09:29, Rewarp a �crit : In Settings Devices, it says number unknown. That said, how would I go about sending my phone number and contact to another phone via FFOS? Knowing your own number depends on your SIM, looks like your SIM doesn't have this information. As far as I know, we don't have the functionality to send your own number/contact to another phone, but this would be a welcome addition. Can you please file a bug (I guess it could be in FirefoxOS/Gaia::Contacts)? Thanks ! -- Julien My ZTE Open C using straight talk sim card displays the phone number. ___ 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
What script are you running that's failing? If it's a bash script, could you add a line near the top (after the #!/bin/bash line) that just has: set -x on it, and then run the script and send us the output? Dave Hylands - Original Message - From: Marek Raida marek.ra...@gmail.com To: mozilla-dev-...@lists.mozilla.org Sent: Friday, August 8, 2014 8:33:13 AM Subject: Re: [b2g] Flame phone documentation, running adb as root I'm sure I did it, checked it twice. Some other ideas, please? After flashing the base image, adb will wind up being disabled by default. So you'll need to go into Settings and turn it back on (IIRC it's the checkbox called Remote Debugging) in Settings-Device Information-More Information-Developer ___ 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] Proposal: Manage B2G.git scripts in a versioned repo
Hi Adrian, Thank you for your response. I'll respond inline. John On Aug 8, 2014, at 6:10 AM, Adrian Custer a...@pocz.org wrote: In step 3, is there any chance the scripts could be segregated or at least given a name which suggests where they apply? The current B2G has scripts that run for backup, for the build, at runtime for performance and some I did not take the time to decipher. We would all benefit from having the purpose of the scripts self-evident either by their name or location. We could give them different names in the b2g-scripts repository and copy them into the root of the tree using repo with their current name. Why step 4? Why allow any scripts in the root of the workspace? Is this merely to avoid having to clean them up, because they 'belong' to other folk, or for some technical reason? Nope, it's not to avoid any work and actually increases the complexity of this project. The main reason to leave them there is that they are the known and documented interface points to the build system. Breaking people's workflow and all of our build documentation is a big deal. Doing it the way that I have proposed lets us compartmentalize these changes. We can fix the source management separate to changing the build system interfaces. Implementing my plan means that we get all the wins of having a managed B2G.git repository without the churn of changing documentation and mind share of developers. This change will also make it a lot easier to deploy future changes to the B2G.git scripts because we'll get B2G updates on every source tree update instead of when someone remembers to run 'git pull origin/master' in their B2G.git clone. Given that 'repo' is a tool to enable everyone to have a build system which is also a developer workspace, proper etiquette (and good working habits) would be to keep this directory CLEAN. Ideally, the working directory would go from 1. empty (or with a single bootstrap script) 2. filled with B2G contents 3. additionally with source code directories 4. additionally with build directories and then alternate between 3 (after a clean) and 4 (after a build) with edits to source all in the directories from steps 2 or 3. All files in the root directory would be a developer's own files they use for their own work. The B2G build system, built on repo, is totally complex and not yet documented; keeping the layout clean can only help. I think this is a style issue. I won't stop you from proposing this change, I just don't think we should tie it in with the separate proposal to fix the source management aspects of B2G.git. I would propose ruthlessly moving all the scripts into a b2g-scripts/unsorted/ directory and require those who use such scripts to give them some attention. This would include a clear name (as per the previous paragraph), proper copyright and licensing info, a link to documentation if any, and contact info for issues. Steps 5-7 begin a cleanup of the build scripts themselves a much bigger topic. Steps 5-7 don't clean up the scripts, it does just enough to split config.sh into the source management component and device configuration component. Overall, I think this change will make cleaning up B2G.git scripts significantly easier in the future. cheers, ~adrian ___ 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?
On 08/07/2014 08:15 PM, Lachlan wrote: my private email server can't be added because it's a class 1 certificate I'm not sure how standard the classes are, but if you have a valid SSL certificate for a domain and trying to connect using that domain, it should work. For example, the StartSSL Free certificates which they dub Class 1 will absolutely work. The two most common errors I have seen that cause trouble are: - Trying to connect to the server using the wrong domain. If your certificate is only valid for mail.example.com but you also have aliases imap.example.com and smtp.example.com, then you want to avoid the aliases and use mail.example.com for both the IMAP and SMTP server. - Server misconfiguration resulting in the server only providing the certificate and not the certificate chain. The easiest way to validate your certificate is to use an online checker. I've found http://www.sslshopper.com/ssl-checker.html to be the most useful for IMAP servers for the top Google search results, there are probably better ones out there, but many only will do port 443 and some fail to tell you if the certificate chain is missing. (NB: I would not use them for buying certs; there are cheaper/free certs/referrals out there.) Type in mail.example.com:993 to check your IMAPS port, etc. Alternately, if you have the openssl tool installed on your machine, you can run a command like the following to help figure out what is wrong with your server configuration. Note that paths for CApath may vary; I am doing this on an Ubuntu machine with the packages openssl and ca-certificates installed: openssl s_client -CApath /etc/ssl/certs -connect MAIL.EXAMPLE.COM:993 /dev/null For example, running against my test server at clicky.visophyte.org, the results I get are as follows. The most important thing is the Verify return code at the bottom, but the validation of the certificate at the chain will also indicate relevant errors. (And if there's only one certificate listed, the chain is definitely missing!) CONNECTED(0003) depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root verify return:1 depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority verify return:1 depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA verify return:1 depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = clicky.visophyte.org verify return:1 --- Certificate chain 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=clicky.visophyte.org i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root --- Server certificate -BEGIN CERTIFICATE- MIIFYTCCBEmgAwIBAgIQKfuLhI2PRMcAt9Bz3rrHEzANBgkqhkiG9w0BAQsFADCB kDELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxNjA0BgNV BAMTLUNPTU9ETyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD QTAeFw0xNDA4MDMwMDAwMDBaFw0xNzA4MDIyMzU5NTlaMFgxITAfBgNVBAsTGERv bWFpbiBDb250cm9sIFZhbGlkYXRlZDEUMBIGA1UECxMLUG9zaXRpdmVTU0wxHTAb BgNVBAMTFGNsaWNreS52aXNvcGh5dGUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAzXwUdeMkuXCQuRwb1LlPIPKihVCSLxIUqyEIuzoJEYjx2ack W+GV2rQI83m0JPtHjn2ocVwK8jTKs4v2gNV6+UJaEpuFYKdzzkaVT7g2VMgan0zO nieobUkwqaFfj9jdUmVC4jgBfzTvVI1DbYPV6/LSUP/zN3Js133nX5V4DF+uEOfN EfGOa3KEvlvPYA/AwqgeIVN6KQL9E8UTp911tJDQeaigV0N4vOcaoga+zyWDkNbz r7U04kqjK+s8ZNcZPebhbtNsDwGGnkF1JceGo788ossptXyYCUAuCtM0vKRq3JRZ sN01fnmgp9mfq2LaPmYkbADDvrJSkH+eJJwpMQIDAQABo4IB7DCCAegwHwYDVR0j BBgwFoAUkK9qOpRaC9iQ6hJWc99DtDoo2ucwHQYDVR0OBBYEFL0arGW1F94uhP5j ZMZPoYSvgJI0MA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQW MBQGCCsGAQUFBwMBBggrBgEFBQcDAjBQBgNVHSAESTBHMDsGDCsGAQQBsjEBAgED BDArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzAI BgZngQwBAgEwVAYDVR0fBE0wSzBJoEegRYZDaHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNybDCB hQYIKwYBBQUHAQEEeTB3ME8GCCsGAQUFBzAChkNodHRwOi8vY3J0LmNvbW9kb2Nh LmNvbS9DT01PRE9SU0FEb21haW5WYWxpZGF0aW9uU2VjdXJlU2VydmVyQ0EuY3J0 MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wOQYDVR0RBDIw MIIUY2xpY2t5LnZpc29waHl0ZS5vcmeCGHd3dy5jbGlja3kudmlzb3BoeXRlLm9y ZzANBgkqhkiG9w0BAQsFAAOCAQEAiijxT84dynAsJEYAwI6fMpAYhbUZoQtW8D5T
[b2g] FYI: [Planned Maintenance Notification] August 9th - Tree Closing Maintenance Window
FYI - some significant network work will be performed during our regular Tree Closing Window (TCW) Saturday, Aug 9, 0900-1200 PT (details below) We are going to not formally close the trees, but there will likely be delays (from auto retry) and some jobs might need to be manually retriggered. Please take this into consideration, and be prepared to do extra monitoring of any jobs you start which will be active during the TCW. Thanks! Original Message Subject:[Planned Maintenance Notification] August 9th - Tree Closing Maintenance Window Date: Fri, 08 Aug 2014 17:49:32 - From: m...@mozilla.com To: infra-...@mozilla.com Short Summary: Mozilla IT will have a network maintenance window on Saturday, August 9th, from 0900-1200 PDT. During this window we will be implementing network improvements to improve long-term stability and performance in both our PHX1 and SCL3 datacenters. Brief network interruptions and reduced network performance may be experienced during this window. 1048340 - master tracking bug 1046119 - complete removal of graceful-restart 1046122 - complete next-hop-self project 1046123 - delete the deprecated group from fw1.releng.scl3 1046129 - remove 63.245.214.0/23 from fw1.scl3 to border[12].scl3 1046132 - remove default routes from border routers after next-hop-self project is complete 1046133 - delete unused static routes for decomm'ed data centers 1046136 - remove load-balancing from network configurations Mozilla IT Outage Notification: -- Issue Status: Upcoming Bug IDs: 1048340 Start Date:2014-08-09 Start Time:09:00 PDT Site: All datacenters Services: Impact of Work:Brief network interruptions and reduced network performance for services hosted in the SCL3 and PHX1 datacenters. If you have any questions or concerns please address them to incide...@mozilla.com -- m...@mozilla.com - m...@mozilla.com ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Proposal: Manage B2G.git scripts in a versioned repo
Hey John, Sounds like a good plan. I'm not familiar with repo file operations and couldn't find any documentation on this. If I wanted to make a change to the flash.sh script, can I edit the copy in the B2G directory? Or do I have to edit the one in b2g-scripts? Would it be possible to have the script in B2G be symlinks rather than copies (at least for linux)? Dave Hylands - Original Message - From: John Ford jhf...@mozilla.com To: dev-b2g@lists.mozilla.org Sent: Tuesday, August 5, 2014 12:51:52 PM Subject: Proposal: Manage B2G.git scripts in a versioned repo [bcc: dev-gaia] Hi, We store Firefox OS source code in various git repositories. We use the 'repo' tool written for the Android project to manage all of these repositories other than the top level B2G.git repository. B2G.git has a few helper scripts to simplify setting up a tree, building a tree as well as other tasks. A problem we have is that the B2G.git repository needs to be updated separately from the repo-managed repositories. Because B2G.git changes infrequently, it's often not updated and that can lead to unexplained breakage for developers. We and our partners have a lot of infrastructure in continuous integration systems which can't easily make full use of the tools stored in B2G.git without a lot of special code. My proposal is to move nearly all of the scripts and tools in B2G.git into a repo managed repository. The only things left in B2G.git would be a modified config.sh script and the repo stub script. I have a plan which should maintain the existing workflow while also letting people use the standard repo work flow. My plan is to: 1) create b2g-scripts repository, containing the B2G.git/scripts directory 2) create b2g-tools repository, containing the B2G.git/tools directory 3) move all scripts in the root of B2G.git into b2g-scripts 4) use repo file copy operations (like we do for the root Makefile) to copy those scripts back into the root of the source tree 5) remove the device configuration part of config.sh 6) create a new script, config-device.sh in b2g-scripts that has the device configuration steps. 7) have config.sh call config-device.sh after the source tree is initialized I will use Git history editing facilities to ensure that both b2g-scripts and b2g-tools maintain their respective histories. Once this is done, you would still be able to set up a fresh tree with the existing method: $ git clone https://github.com/mozilla-b2g/B2G.git $ cd B2G $ ./config.sh emulator $ ./build.sh This will continue to work as expected and will give the same entry points into the build system as we have now. Additionally, a new optional method matching the standard way of using repo is available: $ mkdir B2G $ cd B2G $ repo init -u http://github.com/mozilla-b2g/b2g-manifest.git -m emulator.xml $ repo sync $ ./config-device.sh emulator Please let me know if you have any thoughts on this issue. I would like to make sure that there is consensus about these changes before I start because testing will take some time. I will be doing as much as possible using scripts to make sure that the changes are repeatable and easy to verify. Thanks, John ___ 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] Proposal: Manage B2G.git scripts in a versioned repo
Hi Dave, Thanks! The file operations that I'm referring to is the copyfile node for projects in the manifest files. This node tells repo to copy a file during its sync operation. This is a true copy and not a symlink or hard link. The nice thing is that repo makes the copy read only, which should remind you not to edit that copy. To edit the file you would have to edit the one in b2g-scripts then run repo sync. I could write a simple script which parses the manifest and does the copy operations again without having to do a full repo sync operation. We could add symlink/hard link support to repo, but because we use the upstream copy of repo, we'd be dependent on Google accepting the patch. Forking repo does not seem like a good idea, given that one of our goals here is to increase interoperability with our partners and that would decrease it. Does that address your concerns? John On Aug 8, 2014, at 12:22 PM, Dave Hylands dhyla...@mozilla.com wrote: Hey John, Sounds like a good plan. I'm not familiar with repo file operations and couldn't find any documentation on this. If I wanted to make a change to the flash.sh script, can I edit the copy in the B2G directory? Or do I have to edit the one in b2g-scripts? Would it be possible to have the script in B2G be symlinks rather than copies (at least for linux)? Dave Hylands From: John Ford jhf...@mozilla.com To: dev-b2g@lists.mozilla.org Sent: Tuesday, August 5, 2014 12:51:52 PM Subject: Proposal: Manage B2G.git scripts in a versioned repo [bcc: dev-gaia] Hi, We store Firefox OS source code in various git repositories. We use the 'repo' tool written for the Android project to manage all of these repositories other than the top level B2G.git repository. B2G.git has a few helper scripts to simplify setting up a tree, building a tree as well as other tasks. A problem we have is that the B2G.git repository needs to be updated separately from the repo-managed repositories. Because B2G.git changes infrequently, it's often not updated and that can lead to unexplained breakage for developers. We and our partners have a lot of infrastructure in continuous integration systems which can't easily make full use of the tools stored in B2G.git without a lot of special code. My proposal is to move nearly all of the scripts and tools in B2G.git into a repo managed repository. The only things left in B2G.git would be a modified config.sh script and the repo stub script. I have a plan which should maintain the existing workflow while also letting people use the standard repo work flow. My plan is to: 1) create b2g-scripts repository, containing the B2G.git/scripts directory 2) create b2g-tools repository, containing the B2G.git/tools directory 3) move all scripts in the root of B2G.git into b2g-scripts 4) use repo file copy operations (like we do for the root Makefile) to copy those scripts back into the root of the source tree 5) remove the device configuration part of config.sh 6) create a new script, config-device.sh in b2g-scripts that has the device configuration steps. 7) have config.sh call config-device.sh after the source tree is initialized I will use Git history editing facilities to ensure that both b2g-scripts and b2g-tools maintain their respective histories. Once this is done, you would still be able to set up a fresh tree with the existing method: $ git clone https://github.com/mozilla-b2g/B2G.git $ cd B2G $ ./config.sh emulator $ ./build.sh This will continue to work as expected and will give the same entry points into the build system as we have now. Additionally, a new optional method matching the standard way of using repo is available: $ mkdir B2G $ cd B2G $ repo init -u http://github.com/mozilla-b2g/b2g-manifest.git -m emulator.xml $ repo sync $ ./config-device.sh emulator Please let me know if you have any thoughts on this issue. I would like to make sure that there is consensus about these changes before I start because testing will take some time. I will be doing as much as possible using scripts to make sure that the changes are repeatable and easy to verify. Thanks, John ___ 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] accessing the real SD card via DeviceStorage on newer devices
Hey all,
is there a way to access the actual SD card on newer devices using
navigator.getDeviceStorage('')?
While older devices had /sdcard (or really /mnt/sdcard) to access the
external SD card, the trend seems to be to have that location reference
built in ROM and have a secondary location for the SD card. For example,
the TCP tablet has:
root@android:/ # df
Filesystem Size Used Free Blksize
/dev 797M32K 797M 4096
/mnt/secure797M 0K 797M 4096
/mnt/asec 797M 0K 797M 4096
/mnt/obb 797M 0K 797M 4096
/system 1G 172M 1G 4096
/cache 1G 102M 1G 4096
/data 126M89M36M 4096
/mnt/sdcard 9G84M 9G 4096
/mnt/secure/asec 9G84M 9G 4096
/mnt/extsd 29G 4G25G 32768
where the /mnt/sdcard is some internal block of memory and the
/mnt/extsd is the 32GB SD card in the card slot.
Gaia seems to be aware of these two spaces and may be using them for
different purposes since I have :
root@android:/ # ls /mnt/sdcard/
DCIM
Documents
LOST.DIR
...
root@android:/ # ls /mnt/extsd/
DCIM
LOST.DIR
Music
Pictures
...
although maybe I added the directories by hand to the external SD card,
I don't remember. The music app can access the music files on the card
though, not sure how.
The doc page
https://developer.mozilla.org/en-US/docs/Web/API/Navigator.getDeviceStorage
does not mention anything.
thanks for any info,
~adrian
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] accessing the real SD card via DeviceStorage on newer devices
There may be multiple storage areas.
You can call navigator.getDeviceStorages(type) to get back an array of all of
storage areas.
Each storage area will have a name, retrievable using .storageName attribute.
If there is more than one storage area, then the internal one will be named
'sdcard' and the physical storage are will be called something else (sometimes,
it's extsdcard, sometimes its sdcard1).
navigator.getDeviceStorage() returns the storage area whose .default attribute
is true. This is controlled by the user in Settings-Media Storage-Default
media location (way down at the bottom). If you call addNamed and pass in a
relative path, then it will be stored on the default storage area. The
onsuccess callback will get the fully qualified name (for example
/sdcard/filename) where the file was actually stored.
The names of files on the sdcard storage area will be /sdcard/path/filename,
and the names of files on the sdcard1 storage area will be
/sdcard1/path/filename
Note that the /sdcard and /sdcard1 are storage names. Their actual mount points
on the system are determined via vold and/or /system/etc/volume.cfg file).
DeviceStorage transparently maps the storageName into the actual mountPoint (so
you don't need the mount point if you're just accessing the files through
device storage)
If you want to determine the mount point to examine the filesystem from an adb
shell, then you can determine the vold mount points by using the command:
adb shell vdc volume list (requires a root shell)
On the flame, you'll see something like:
110 0 sdcard /storage/sdcard 4
110 0 sdcard1 /storage/sdcard1 4
200 0 Volumes listed.
For volumes which aren't managed by vold (the sdcard volume on a nexus 4/5 are
examples of this), the mount point is found in /system/etc/volume.cfg
With the engineering builds, there is a ds-test app (gaia/dev_apps/ds-test)
which I use for testing things on device storage.
Dave Hylands
- Original Message -
From: Adrian Custer a...@pocz.org
To: Moz dev-b2g list dev-b2g@lists.mozilla.org
Sent: Friday, August 8, 2014 5:06:41 PM
Subject: [b2g] accessing the real SD card via DeviceStorage on newer devices
Hey all,
is there a way to access the actual SD card on newer devices using
navigator.getDeviceStorage('')?
While older devices had /sdcard (or really /mnt/sdcard) to access the
external SD card, the trend seems to be to have that location reference
built in ROM and have a secondary location for the SD card. For example,
the TCP tablet has:
root@android:/ # df
Filesystem Size Used Free Blksize
/dev 797M 32K 797M 4096
/mnt/secure 797M 0K 797M 4096
/mnt/asec 797M 0K 797M 4096
/mnt/obb 797M 0K 797M 4096
/system 1G 172M 1G 4096
/cache 1G 102M 1G 4096
/data 126M 89M 36M 4096
/mnt/sdcard 9G 84M 9G 4096
/mnt/secure/asec 9G 84M 9G 4096
/mnt/extsd 29G 4G 25G 32768
where the /mnt/sdcard is some internal block of memory and the
/mnt/extsd is the 32GB SD card in the card slot.
Gaia seems to be aware of these two spaces and may be using them for
different purposes since I have :
root@android:/ # ls /mnt/sdcard/
DCIM
Documents
LOST.DIR
...
root@android:/ # ls /mnt/extsd/
DCIM
LOST.DIR
Music
Pictures
...
although maybe I added the directories by hand to the external SD card,
I don't remember. The music app can access the music files on the card
though, not sure how.
The doc page
https://developer.mozilla.org/en-US/docs/Web/API/Navigator.getDeviceStorage
does not mention anything.
thanks for any info,
~adrian
___
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
