[b2g] 04/08/2014 Hamachi Gaia-ui Automation v1.3 Mozilla RIL Build 122/126 tests
Hi all, Here is the automation report on Hamachi for today. Our build is stable, we had 2 failures though. One of the tests failed because of a known issue, which is still under investigation. See details in *Bug 991700* https://bugzilla.mozilla.org/show_bug.cgi?id=991700 The other failure was caused by the phone not being connected to network during the test run. Cheers, Viorela *Summary* 126 tests ran in 8635 seconds. 122 passed, 0 skipped, 0 failed, 2 errors. 2 expected failures, 0 unexpected passes. *Test failures:* test_browser_https_auth.py - From jenkins screenshot, it looks like the phone did not connect to network while running the test; We will log an issue if this happens on any other test run. test_dialer_airplane_mode.py - *Bug 991700* https://bugzilla.mozilla.org/show_bug.cgi?id=991700 -[v1.3] Fix test_dialer_airplane_mode.TestDialerAirplaneMode on v1.3 *Build under test: *Gaia 0a7a50129995f080c1df4d807a2334701701e8ed Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/e3fca8c23e1d BuildID 20140408004002 Version 28.0 ro.build.version.incremental=eng.tclxa.20131223.163538 ro.build.date=Mon Dec 23 16:36:04 CST 2013 *Expected fails:* test_settings_airplane_mode.py - *Bug 987145* https://bugzilla.mozilla.org/show_bug.cgi?id=987145 -Investigate failure in test_settings_airplane_mode.py test_import_contacts_from_gmail - *Bug 932804* https://bugzilla.mozilla.org/show_bug.cgi?id=932804 -Tapping on select all button doesn't work on Gmail or Outlook frame, before importing contacts *Disabled tests:* None ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
Hi, In case not every one knows, we are trying to keep a crashed app in task manager and restore it with the latest url. It’s implemented already, see https://bugzilla.mozilla.org/show_bug.cgi?id=935750 Someone call it ‘zombie app’, but I call this ‘suspending app’ to reflect it’s suspending. I am not familiar with how gecko implements session restore, but as James Burke said, it’d be easy to keep the state with url in system app and restore the url in the app resuming process. If people dislike to use pushState, and there’s an API for system app to invoke before suspending/resuming I’d like to implement that which should be easy with this feature. — Alive C. Kuo, Senior Software Engineer, Firefox OS, MoCo. Taipei Office al...@mozilla.com Thinker K.F. Li thin...@codemud.net 於 2014/3/28 上午7:20 寫道： From: Prateek Jadhwani prateekjadhw...@gmail.com Subject: Re: [b2g] Session Restoring of WebApps Date: Thu, 27 Mar 2014 18:51:13 -0400 Thinker, I would suggest making a library to do all that, and do all that stuff. I mean on the Gaia end, rather than going for B2G. And then, this library could be used by system app to do what you want to do. I would like to know your reasoning for creating an api in B2G rather than Gaia. Because I do agree with with Fabrice, creating an api just for this task might not be the proper way to achieve this goal. It might be a way, but not a proper one. I am not sure how the sysapp controls life-cycle of sessions in this way, a library, except you don't like the sysapp to control life-cycle of sessions. The api here is for customization of UX. If we all agree that life-cycle of sessions should not be a part of device's UX, then we don't need the api. ___ 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] How can I get a gaia including Simplified Chinese?
Hi, I git a gaia code from Github,and when I run it in the B2G Desktop Client,there is only Tradtional Chinese available and no any Chinese Inputer in the system.I saw some device like Geekphone has Simplified Chinese and could run Chinese Inputer.I want it running on my device,but I could not get a code with Simplified Chinese.So,what can I do? Thanks ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] a proposal on one tool to rule them all
[ Bcc'ing auto-tools, in case a-team peoples missed this ] Hi Dave, This sounds really cool. I suspect that posting this on dev.platform might yield more comments... personally I only have some minor comments which are hopefully still useful: On 04/07/2014 01:34 PM, Dave Huseby wrote: Here is what I'm thinking in rough priority order: 1. Unify event signaling for all sources of interesting events. Right now we have a bunch of interesting perf-related events (e.g. checkerboarding, memory pressures, zRAM caching, power consumption spikes, slow event handling, etc) that are reported in different ways. For instance, Ben Kelly showed us how to spot memory pressure events in the log output. We learned that the graphics pipeline knows when checkerboarding occurs and could report that. We saw how the powertool can see when power consumption spikes and could report it. zRAM caching events reported from B2G. RIL, WiFi, GPS, etc all reported from B2G in the logs. So I know there was an effort to add performance counters to marionette last year, which sounds similar to what you are talking about. I think we eventually abandoned that effort, for what reason I don't know. CC'ing mdas, who IIRC was working on it -- hopefully she can clarify. The first step I think we should take is figuring out a way to report interesting events via a unified mechanism. For events generated on the device, I think the Profiler::addMarker is the good way to go. Not only would it be a single, central reporting mechanism available from both C++ and JS, it would also get those events into the profiling capture buffer. The profiling capture mechanism has a small circular buffer for storing stack traces and markers. There's no reason we couldn't have a thread transmitting event markers back to the host over a socket in realtime. For events generated off of the device (e.g. powertool events, eideticker events, orangutan input driver events), they could also be reported over a socket to the event consumer. So for orangutan, the thing that counts the most is when we dispatch the event to the kernel subsystem to the device, not when we trigger the program off the device. Would it be possible for external programs like this to report something to gecko, then gecko would report them over the socket? I don't want to bikeshed the implementation too much, just curious about your thoughts here... 2. Build a single consumer of the event stream. Once we get event reporting over a socket, the next step is to build a centralized consumer of the events. NodeJS is probably a good choice for this tool. It should probably function as a daemon on the host machine and be capable of detecting devices and executing adb commands to set up the port forwarding automagically. The event consumer will listen on a single port--like a web server--and accept multiple incoming connections from event sources. So the way android port-forwarding works, it is currently possible for the host to connect to a tcp socket on the device easily over usb (this is how we do marionette), but not the reverse. So I suspect it would be easier for gecko to emit events over a socket, then have some process on the host hook into that. 3. Build a configurable dispatch mechanism for the event consumer. The last piece involves building a configurable dispatch mechanism for hooking up actions to certain events. The first--and maybe the only--action we will want is to gather the profiling data for the last N seconds whenever we see an interesting event. For instance, when I'm optimizing idle power draw, a power spike event from the powertool should trigger dumping the profiling data for the last N seconds. I'll also want the profiling data when I see a transient memory spikes and checkerboarding events, and... Now that I think about it, grabbing the profiler data in response to a marker added from JS would be tremendously helpful for debugging JS event ordering and dispatching issues (i.e. the gaia window manager). Proposal: To keep this simple enough that it could be implemented quickly, I propose a very simple event transmission mechanism. The data on the socket will flow in only one direction--from the event source to the consumer. Events will contain JSON encoded data: a timestamp with sub-ms resolution, a subject string, and a body string. The subject is what triggers an action, the body is used for any optional/extended data. We'll use TCP. So the ateam has been working on adding something called structured logging to all our frameworks, which uses a json protocol much like what you're describing. It would be great if you could use something similar here, so all the python tools we're creating for reading/parsing structured logs could be reused here. I believe we also have some existing javascript helper methods in the tree for creating these types of json messages. Here's a description of the format we're using:
Re: [b2g] a proposal on one tool to rule them all
Also possibly relevant: Andrew Halberstadt and Gareth Aye are currently working on a socket-based generic harness for Marionette-based tests. This will support structured logging. I think this could potentially act as the consumer for this event stream of interesting events. You might want to follow up with ahal on #ateam. Jonathan On 4/8/2014 9:40 AM, William Lachance wrote: [ Bcc'ing auto-tools, in case a-team peoples missed this ] Hi Dave, This sounds really cool. I suspect that posting this on dev.platform might yield more comments... personally I only have some minor comments which are hopefully still useful: On 04/07/2014 01:34 PM, Dave Huseby wrote: Here is what I'm thinking in rough priority order: 1. Unify event signaling for all sources of interesting events. Right now we have a bunch of interesting perf-related events (e.g. checkerboarding, memory pressures, zRAM caching, power consumption spikes, slow event handling, etc) that are reported in different ways. For instance, Ben Kelly showed us how to spot memory pressure events in the log output. We learned that the graphics pipeline knows when checkerboarding occurs and could report that. We saw how the powertool can see when power consumption spikes and could report it. zRAM caching events reported from B2G. RIL, WiFi, GPS, etc all reported from B2G in the logs. So I know there was an effort to add performance counters to marionette last year, which sounds similar to what you are talking about. I think we eventually abandoned that effort, for what reason I don't know. CC'ing mdas, who IIRC was working on it -- hopefully she can clarify. The first step I think we should take is figuring out a way to report interesting events via a unified mechanism. For events generated on the device, I think the Profiler::addMarker is the good way to go. Not only would it be a single, central reporting mechanism available from both C++ and JS, it would also get those events into the profiling capture buffer. The profiling capture mechanism has a small circular buffer for storing stack traces and markers. There's no reason we couldn't have a thread transmitting event markers back to the host over a socket in realtime. For events generated off of the device (e.g. powertool events, eideticker events, orangutan input driver events), they could also be reported over a socket to the event consumer. So for orangutan, the thing that counts the most is when we dispatch the event to the kernel subsystem to the device, not when we trigger the program off the device. Would it be possible for external programs like this to report something to gecko, then gecko would report them over the socket? I don't want to bikeshed the implementation too much, just curious about your thoughts here... 2. Build a single consumer of the event stream. Once we get event reporting over a socket, the next step is to build a centralized consumer of the events. NodeJS is probably a good choice for this tool. It should probably function as a daemon on the host machine and be capable of detecting devices and executing adb commands to set up the port forwarding automagically. The event consumer will listen on a single port--like a web server--and accept multiple incoming connections from event sources. So the way android port-forwarding works, it is currently possible for the host to connect to a tcp socket on the device easily over usb (this is how we do marionette), but not the reverse. So I suspect it would be easier for gecko to emit events over a socket, then have some process on the host hook into that. 3. Build a configurable dispatch mechanism for the event consumer. The last piece involves building a configurable dispatch mechanism for hooking up actions to certain events. The first--and maybe the only--action we will want is to gather the profiling data for the last N seconds whenever we see an interesting event. For instance, when I'm optimizing idle power draw, a power spike event from the powertool should trigger dumping the profiling data for the last N seconds. I'll also want the profiling data when I see a transient memory spikes and checkerboarding events, and... Now that I think about it, grabbing the profiler data in response to a marker added from JS would be tremendously helpful for debugging JS event ordering and dispatching issues (i.e. the gaia window manager). Proposal: To keep this simple enough that it could be implemented quickly, I propose a very simple event transmission mechanism. The data on the socket will flow in only one direction--from the event source to the consumer. Events will contain JSON encoded data: a timestamp with sub-ms resolution, a subject string, and a body string. The subject is what triggers an action, the body is used for any optional/extended data. We'll use TCP. So the ateam has been working on adding something called structured logging to all our frameworks, which
Re: [b2g] a proposal on one tool to rule them all
On 2014-04-08, 12:40 PM, William Lachance wrote: So I know there was an effort to add performance counters to marionette last year, which sounds similar to what you are talking about. I think we eventually abandoned that effort, for what reason I don't know. CC'ing mdas, who IIRC was working on it -- hopefully she can clarify. The performance counters in marionette was really just a data store, and doesn't sound like it's what you're looking for. It worked by asking marionette to store data by calling addPerfData(testsuite, testname, someNumericValue), and it'd accumulate all relevant data and would export them when you call getPerfData. The marionette server didn't do anything smart other than adding and the storing data the user submitted. Support for this was removed in https://bugzilla.mozilla.org/show_bug.cgi?id=865867 since there was no real use for them (it was originally a temporary measure) and it wasn't the appropriate place for metrics gathering. If you need to store data across webpages, marionette shouldn't be the tool for gathering that data since it's merely an automation driver. -- Malini Das ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] a proposal on one tool to rule them all
On Mon, Apr 7, 2014 at 10:34 AM, Dave Huseby dhus...@mozilla.com wrote: Thoughts? I would really like to get some feedback on this. If we think this is a good idea, it will dominate the perf dev-tools effort for the foreseeable future as it would be a tool useful for both Mozilla engineers (e.g. fxos-perf team, gaia team, etc) and 3rd party app developers. One thing that also might help make the whole perf capture easier to do today, without needing to expand the tooling: It would be nice to have a way to get symbols for use in the profile.sh workflow without needing to do a local build myself. Perhaps provide them as an option for engineering pvt builds. For some of us gaia developers, needing to maintain a local build of b2g on a laptop (plus the extra hitches if using latest OS X) means it is enough of a barrier that I have not done it recently, but at the same time have wanted to do some perf captures. James ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] error when I'm using ./configure.sh inari
This happens when the server runs an old git and the index-pack step takes too long to run. Nothing is sent to the client during this step so the connection times out. Newer git have a keep-alive mechanism in place instead. See more info at https://bugzilla.mozilla.org/show_bug.cgi?id=963469. The error is slightly different but I believe the cause is the same. There are two ways to fix it as far as I know: 1 Tell the server maintainers so they can either upgrade their git, extend the timeout or optimize the repo so the index-pack step is faster. 2 Make sure your local git process (the one fetching the repo) does NOT run with the '--no-progress' flag (more info at the URL above). If it has it, it is probably because you are piping the output to somewhere. See if it works when you don't and if you still need it piped you can probably force progress from the server (somehow) or you can use the linux program scripthttp://unixhelp.ed.ac.uk/CGI/man-cgi?script . Cheers, *Andreas Pehrson *--- Software Engineer (+47) 959 60 374 | pehr...@comoyo.com | www.comoyo.com On Tue, Apr 8, 2014 at 6:48 PM, Ángel Cruz bullg...@gmail.com wrote: Hi there... Some help with this please remote: Counting objects: 3769164, done. remote: Total 2895 (delta 1325), reused 2471 (delta 981) Receiving objects: 100% (2895/2895), 39.39 MiB | 278.00 KiB/s, done. remote: Compressing objects: 100% (755622/755622), done. Resolving deltas: 100% (1325/1325), completed with 409 local objects. From https://git.mozilla.org/releases/gaia 81f68c4..650e8c2 master - mozillaorg/master 225e9ae..100a159 v1.3 - mozillaorg/v1.3 9afe814..643f3e6 v1.3t - mozillaorg/v1.3t error: RPC failed; result=56, HTTP code = 20033 GiB | 36.00 KiB/s 44.00 KiB | 31.00 KiB/s fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed thanks -- ángel cruz GNU/Linux counter #50841 ~ happy hacking ___ 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] a proposal on one tool to rule them all
I'm wondering how much the devtools protocol would fit your need? (it is already used for any devtool feature and also partialy used in marionette) Also can't this be integrated into the existing profiler/cleopatra? Finally, there is various goals around Performance tooling in devtools group: https://wiki.mozilla.org/DevTools/Planning/Performance/Details Rob, What is the status/timeline for Performance tools? Can't we ship a naive timeline tool that connects to a device, and then let all platform experts that are willing to contribute here by putting any usefull probe they can think about? 2014-04-08 18:40 GMT+02:00 William Lachance wlacha...@mozilla.com: [ Bcc'ing auto-tools, in case a-team peoples missed this ] Hi Dave, This sounds really cool. I suspect that posting this on dev.platform might yield more comments... personally I only have some minor comments which are hopefully still useful: On 04/07/2014 01:34 PM, Dave Huseby wrote: Here is what I'm thinking in rough priority order: 1. Unify event signaling for all sources of interesting events. Right now we have a bunch of interesting perf-related events (e.g. checkerboarding, memory pressures, zRAM caching, power consumption spikes, slow event handling, etc) that are reported in different ways. For instance, Ben Kelly showed us how to spot memory pressure events in the log output. We learned that the graphics pipeline knows when checkerboarding occurs and could report that. We saw how the powertool can see when power consumption spikes and could report it. zRAM caching events reported from B2G. RIL, WiFi, GPS, etc all reported from B2G in the logs. So I know there was an effort to add performance counters to marionette last year, which sounds similar to what you are talking about. I think we eventually abandoned that effort, for what reason I don't know. CC'ing mdas, who IIRC was working on it -- hopefully she can clarify. The first step I think we should take is figuring out a way to report interesting events via a unified mechanism. For events generated on the device, I think the Profiler::addMarker is the good way to go. Not only would it be a single, central reporting mechanism available from both C++ and JS, it would also get those events into the profiling capture buffer. The profiling capture mechanism has a small circular buffer for storing stack traces and markers. There's no reason we couldn't have a thread transmitting event markers back to the host over a socket in realtime. For events generated off of the device (e.g. powertool events, eideticker events, orangutan input driver events), they could also be reported over a socket to the event consumer. So for orangutan, the thing that counts the most is when we dispatch the event to the kernel subsystem to the device, not when we trigger the program off the device. Would it be possible for external programs like this to report something to gecko, then gecko would report them over the socket? I don't want to bikeshed the implementation too much, just curious about your thoughts here... 2. Build a single consumer of the event stream. Once we get event reporting over a socket, the next step is to build a centralized consumer of the events. NodeJS is probably a good choice for this tool. It should probably function as a daemon on the host machine and be capable of detecting devices and executing adb commands to set up the port forwarding automagically. The event consumer will listen on a single port--like a web server--and accept multiple incoming connections from event sources. So the way android port-forwarding works, it is currently possible for the host to connect to a tcp socket on the device easily over usb (this is how we do marionette), but not the reverse. So I suspect it would be easier for gecko to emit events over a socket, then have some process on the host hook into that. 3. Build a configurable dispatch mechanism for the event consumer. The last piece involves building a configurable dispatch mechanism for hooking up actions to certain events. The first--and maybe the only--action we will want is to gather the profiling data for the last N seconds whenever we see an interesting event. For instance, when I'm optimizing idle power draw, a power spike event from the powertool should trigger dumping the profiling data for the last N seconds. I'll also want the profiling data when I see a transient memory spikes and checkerboarding events, and... Now that I think about it, grabbing the profiler data in response to a marker added from JS would be tremendously helpful for debugging JS event ordering and dispatching issues (i.e. the gaia window manager). Proposal: To keep this simple enough that it could be implemented quickly, I propose a very simple event transmission mechanism. The data on the socket will flow in only one direction--from the event source to the
Re: [b2g] a proposal on one tool to rule them all
Yes! Let's chat. I just started what is basically an event signaling mechanism over sockets just this past week. I'm building it with streaming test results/output in mind, but there is no reason the scope can't be expanded to other use cases too. The tool uses ZeroMQ which gives it some nice properties (e.g it'll work over ipc just as easily as tcp, clients/servers can join/leave at will without disrupting anything). I plan to use the data format and logging module defined here: http://mozbase.readthedocs.org/en/latest/mozlog_structured.html Again that's geared towards testing, but we can expand the spec to include e.g perf data too. So far I don't have too much, but if you want to look at what I've done, see: https://github.com/ahal/corredor - the consumer of data in your example https://github.com/ahal/corredor-js-client - the producer in your example My plan is to also write a python client (I called it client because in my mind I was thinking the consumer would actually be more of a server that launches clients and waits for results.. but I'm happy to rethink this). I'm excited someone else has been thinking about this and would love getting help on the design/direction of the project. -Andrew On 08/04/14 01:24 PM, Jonathan Griffin wrote: Also possibly relevant: Andrew Halberstadt and Gareth Aye are currently working on a socket-based generic harness for Marionette-based tests. This will support structured logging. I think this could potentially act as the consumer for this event stream of interesting events. You might want to follow up with ahal on #ateam. Jonathan On 4/8/2014 9:40 AM, William Lachance wrote: [ Bcc'ing auto-tools, in case a-team peoples missed this ] Hi Dave, This sounds really cool. I suspect that posting this on dev.platform might yield more comments... personally I only have some minor comments which are hopefully still useful: On 04/07/2014 01:34 PM, Dave Huseby wrote: Here is what I'm thinking in rough priority order: 1. Unify event signaling for all sources of interesting events. Right now we have a bunch of interesting perf-related events (e.g. checkerboarding, memory pressures, zRAM caching, power consumption spikes, slow event handling, etc) that are reported in different ways. For instance, Ben Kelly showed us how to spot memory pressure events in the log output. We learned that the graphics pipeline knows when checkerboarding occurs and could report that. We saw how the powertool can see when power consumption spikes and could report it. zRAM caching events reported from B2G. RIL, WiFi, GPS, etc all reported from B2G in the logs. So I know there was an effort to add performance counters to marionette last year, which sounds similar to what you are talking about. I think we eventually abandoned that effort, for what reason I don't know. CC'ing mdas, who IIRC was working on it -- hopefully she can clarify. The first step I think we should take is figuring out a way to report interesting events via a unified mechanism. For events generated on the device, I think the Profiler::addMarker is the good way to go. Not only would it be a single, central reporting mechanism available from both C++ and JS, it would also get those events into the profiling capture buffer. The profiling capture mechanism has a small circular buffer for storing stack traces and markers. There's no reason we couldn't have a thread transmitting event markers back to the host over a socket in realtime. For events generated off of the device (e.g. powertool events, eideticker events, orangutan input driver events), they could also be reported over a socket to the event consumer. So for orangutan, the thing that counts the most is when we dispatch the event to the kernel subsystem to the device, not when we trigger the program off the device. Would it be possible for external programs like this to report something to gecko, then gecko would report them over the socket? I don't want to bikeshed the implementation too much, just curious about your thoughts here... 2. Build a single consumer of the event stream. Once we get event reporting over a socket, the next step is to build a centralized consumer of the events. NodeJS is probably a good choice for this tool. It should probably function as a daemon on the host machine and be capable of detecting devices and executing adb commands to set up the port forwarding automagically. The event consumer will listen on a single port--like a web server--and accept multiple incoming connections from event sources. So the way android port-forwarding works, it is currently possible for the host to connect to a tcp socket on the device easily over usb (this is how we do marionette), but not the reverse. So I suspect it would be easier for gecko to emit events over a socket, then have some process on the host hook into that. 3. Build a configurable dispatch mechanism for the event consumer. The last piece
Re: [b2g] a proposal on one tool to rule them all
All that needed for that is to ship these builds without stripping the symbols (like we already do for mac/linux/fennec nightlies) and to modify profile.sh to support pulling all the information from the phone. On Tue, Apr 8, 2014 at 2:10 PM, James Burke jrbu...@gmail.com wrote: On Mon, Apr 7, 2014 at 10:34 AM, Dave Huseby dhus...@mozilla.com wrote: Thoughts? I would really like to get some feedback on this. If we think this is a good idea, it will dominate the perf dev-tools effort for the foreseeable future as it would be a tool useful for both Mozilla engineers (e.g. fxos-perf team, gaia team, etc) and 3rd party app developers. One thing that also might help make the whole perf capture easier to do today, without needing to expand the tooling: It would be nice to have a way to get symbols for use in the profile.sh workflow without needing to do a local build myself. Perhaps provide them as an option for engineering pvt builds. For some of us gaia developers, needing to maintain a local build of b2g on a laptop (plus the extra hitches if using latest OS X) means it is enough of a barrier that I have not done it recently, but at the same time have wanted to do some perf captures. James ___ 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] error when I'm using ./configure.sh inari
Hi there, My problem is with git://codeaurora.org/platform/external/libgsm https://bugzilla.mozilla.org/show_bug.cgi?id=993574 On Tue, Apr 8, 2014 at 1:55 PM, Andreas Pehrson pehr...@comoyo.com wrote: This happens when the server runs an old git and the index-pack step takes too long to run. Nothing is sent to the client during this step so the connection times out. Newer git have a keep-alive mechanism in place instead. See more info at https://bugzilla.mozilla.org/show_bug.cgi?id=963469. The error is slightly different but I believe the cause is the same. There are two ways to fix it as far as I know: 1 Tell the server maintainers so they can either upgrade their git, extend the timeout or optimize the repo so the index-pack step is faster. 2 Make sure your local git process (the one fetching the repo) does NOT run with the '--no-progress' flag (more info at the URL above). If it has it, it is probably because you are piping the output to somewhere. See if it works when you don't and if you still need it piped you can probably force progress from the server (somehow) or you can use the linux program script http://unixhelp.ed.ac.uk/CGI/man-cgi?script. Cheers, *Andreas Pehrson *--- Software Engineer (+47) 959 60 374 | pehr...@comoyo.com | www.comoyo.com On Tue, Apr 8, 2014 at 6:48 PM, Ángel Cruz bullg...@gmail.com wrote: Hi there... Some help with this please remote: Counting objects: 3769164, done. remote: Total 2895 (delta 1325), reused 2471 (delta 981) Receiving objects: 100% (2895/2895), 39.39 MiB | 278.00 KiB/s, done. remote: Compressing objects: 100% (755622/755622), done. Resolving deltas: 100% (1325/1325), completed with 409 local objects. From https://git.mozilla.org/releases/gaia 81f68c4..650e8c2 master - mozillaorg/master 225e9ae..100a159 v1.3 - mozillaorg/v1.3 9afe814..643f3e6 v1.3t - mozillaorg/v1.3t error: RPC failed; result=56, HTTP code = 20033 GiB | 36.00 KiB/s 44.00 KiB | 31.00 KiB/s fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed thanks -- ángel cruz GNU/Linux counter #50841 ~ happy hacking ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g -- ángel cruz GNU/Linux counter #50841 ~ happy hacking ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] a proposal on one tool to rule them all
Pulling from the phone probably won't be an option. unstripped libxul.so is about 700 Mb (for a non-debug emulator build). Most of our phones don't have enough space to store anything that big. We'd need to have these on a server someplace and be able to pull from the server. Dave Hylands - Original Message - From: Benoit Girard bgir...@mozilla.com To: James Burke jrbu...@gmail.com Cc: fxos-perf fxos-p...@mozilla.com, Dave Huseby dhus...@mozilla.com, dev-b2g@lists.mozilla.org Sent: Tuesday, April 8, 2014 11:43:39 AM Subject: Re: [b2g] a proposal on one tool to rule them all All that needed for that is to ship these builds without stripping the symbols (like we already do for mac/linux/fennec nightlies) and to modify profile.sh to support pulling all the information from the phone. On Tue, Apr 8, 2014 at 2:10 PM, James Burke jrbu...@gmail.com wrote: On Mon, Apr 7, 2014 at 10:34 AM, Dave Huseby dhus...@mozilla.com wrote: Thoughts? I would really like to get some feedback on this. If we think this is a good idea, it will dominate the perf dev-tools effort for the foreseeable future as it would be a tool useful for both Mozilla engineers (e.g. fxos-perf team, gaia team, etc) and 3rd party app developers. One thing that also might help make the whole perf capture easier to do today, without needing to expand the tooling: It would be nice to have a way to get symbols for use in the profile.sh workflow without needing to do a local build myself. Perhaps provide them as an option for engineering pvt builds. For some of us gaia developers, needing to maintain a local build of b2g on a laptop (plus the extra hitches if using latest OS X) means it is enough of a barrier that I have not done it recently, but at the same time have wanted to do some perf captures. James ___ 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
[b2g] Tarako v1.3t Smoke Test Results - 40/48 tests passed, 6 untested (Marketplace), 1 new blocker
0 out of 48 tests passed for the 2014-04-08 Tarako v1.3t Build. There is one new issue and one existing blocker that kept the smoketests from fully passing. Please note, there's going to be a new Marketplace app for Tarako which is planned to land April 16th thus all Marketplace tests are going to be skipped until then. Smoketest Results: Daily Smoke Test Logs: https://docs.google.com/a/qanalydocs.com/spreadsheet/ccc?key=0AjRc6aVFoOW9dGZLdVdiWGZLbVdORlFpUGt5XzZ3Zncusp=drive_web#gid=5 Moztrap link: https://moztrap.mozilla.org/runtests/run/3784/env/347/ Tests Were Performed With: Build ID: 20140408004001 Gecko: b850e0f09e61 Gaia: 643f3e6676cbb89c62708a9f7cbef2edc795a552 Base Image: sp8810 2 reboots 2 crashes: - bug https://bugzilla.mozilla.org/show_bug.cgi?id=976656 - bug https://bugzilla.mozilla.org/show_bug.cgi?id=989989 New Bugs Breaking the Smoketests: - [B2G][Tarako]Unable to proceed past the extension line when calling into the Mozilla conference line https://bugzilla.mozilla.org/show_bug.cgi?id=993564 Existing Bugs Breaking the Smoketests: - [Tarako] [B2G][First Time Experience] No FTE/FTU appears when device is reset or reflashed https://bugzilla.mozilla.org/show_bug.cgi?id=991304 - [Dialer][V1.3T] The caller and receiver cannot hear any voice https://bugzilla.mozilla.org/show_bug.cgi?id=988786 NOTE: I'm including this one as, while some of us have this working, others do not. We should know for sure tomorrow if this one is good or not. New Issues Not Breaking the Smoketests: - [B2G][Tarako]When in a phone call, the proximity sensor does not turn off the screen https://bugzilla.mozilla.org/show_bug.cgi?id=993518 - [B2G][Tarako][Contacts]Facebook toggle not properly displayed when no data or wifi connection available https://bugzilla.mozilla.org/show_bug.cgi?id=993531 Sincerely, Mozilla QA ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] 04/08/2014 Buri v1.4 MOZ RIL Smoke Test Results - 48/48 tests passed, no new blockers
48 out of 48 tests passed for the 2014-04-08 Buri v1.4.0 MOZ RIL Build. There are no major issues preventing smoketest from passing. MOZ RIL Build Smoketest Results: Daily Smoke Test Logs: https://docs.google.com/a/qanalydocs.com/spreadsheet/ccc?key=0AjRc6aVFoOW9dG9uS3lLNFRPZUtubVIzM2VKSjhqaXc#gid=14 Moztrap link: https://moztrap.mozilla.org/runtests/run/3783/env/347/ Tests Were Performed With: Build ID: 20140408000202 Gecko: 70b076fc7558 Gaia: 26983f356ecb1bcf30e862d334b5de790071803e Base Image: V1.2-device.cfg 0 reboots 0 crashes New Bugs Breaking the Smoketests: - None reported. Existing Bugs Breaking the Smoketests: - None reported. New Issues Not Breaking the Smoketests: - [B2G][Calendar] Multi-day event starting after 11 pm displays outside of borders in week and day view https://bugzilla.mozilla.org/show_bug.cgi?id=993677 Sincerely, Mozilla QA ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] gaia github-git.m.o syncing currently busted
This appears to be broken connectivity to github from the conversion machines. I have sent a message to github support about this. Builds and tests running in Releng infrastructure are currently using old revisions of gaia. I'm not sure if we're able to close the gaia trees, but it may be best. https://bugzilla.mozilla.org/show_bug.cgi?id=993632 ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] 04/08/2014 Buri Master/M-C Mozilla RIL Smoke Test Results - 41/48 tests passed, 5 new blockers
41 out of 48 tests passed for the 2014-01-08 Buri Master M-C Mozilla RIL Build. There are five new issues that kept the smoketests from fully passing. Mozilla RIL Build Smoketest Results: Daily Smoke Test Logs: https://docs.google.com/a/qanalydocs.com/spreadsheet/ccc?key=0AjRc6aVFoOW9dGZLdVdiWGZLbVdORlFpUGt5XzZ3Zncusp=drive_web#gid=0 Moztrap link: https://moztrap.mozilla.org/runtests/run/3782/env/347/ Tests Were Performed With: Build ID: 20140408040204 Gecko: 8883360b1edb Gaia: 1958454595b1fa0e061f0652ae965629993f5708 Base Image: V1.2-device.cfg 4 reboots 0 crashes New Bugs Breaking the Smoketests: - Call screen is not visible when making a call from the phone app https://bugzilla.mozilla.org/show_bug.cgi?id=993462 - [B2G][Dailer] No notification of incoming call when phone is on silent with vibration off https://bugzilla.mozilla.org/show_bug.cgi?id=993470 - [B2G][Bluetooth] Unable to pair devices. Attempting to pair closes Settings immediately. https://bugzilla.mozilla.org/show_bug.cgi?id=993713 - [B2G][Homescreen]Deleting an item from homescreen causes all other homescreen items to display inappropriately https://bugzilla.mozilla.org/show_bug.cgi?id=993682 - [B2G][Clock] Alarm set with clock app does not fire until user reopens clock app https://bugzilla.mozilla.org/show_bug.cgi?id=993732 Existing Bugs Breaking the Smoketests: - None reported. New Issues Not Breaking the Smoketests: - [B2G][Video] Videos will not play again after first playthrough https://bugzilla.mozilla.org/show_bug.cgi?id=993753 Sincerely, Mozilla QA ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Having problems running the flash.sh script - Galaxy tab p4wifi
Hello, I've been getting ERROR: Partition FACTORYFS does not exist in the
specified PIT. whenever I try to run the flash.sh script. The build was
successful so I'm just having trouble flashing it to the device. I'm trying to
get it to work on a Samsung Galaxy Tab 10.1 (p4wifi), so I'm using Heimdall to
flash it.
Here is a bigger readout of the terminal if it helps:
Initialising connection...
Detecting device...
Claiming interface...
Attempt failed. Detaching driver...
Claiming interface again...
Setting up interface...
Initialising protocol...
Protocol initialisation successful.
Beginning session...
Some devices may take up to 2 minutes to respond.
Please be patient!
Session begun.
Downloading device's PIT file...
PIT file download successful.
ERROR: Partition FACTORYFS does not exist in the specified PIT.
Ending session...
Rebooting device...
Releasing device interface...
Re-attaching kernel driver...
Heimdall flashing failed.
Make sure you have a line like
SUBSYSTEM==usb, ATTRS{idVendor}==04e8, MODE=0666
in /etc/udev/rules.d/android.rules
Please let me know what I can do to correct this error. I'm so close to getting
this working on my device!
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Resending: 04/08/14 Tarako v1.3t Smoke Test Results - 40/48 tests passed, 6 untested (Marketplace), 1 new blocker
John/QA Team, I see eight smoketest failing here but only three blockers listed. Can QA help identify the remaining bugs here ? Also, I've commented inline on the three smoketests bugs mentioned below. Thanks, Bhavana - Original Message - From: John Hammink jhamm...@mozilla.com To: dev-gaia dev-g...@lists.mozilla.org, dev-b2g dev-b2g@lists.mozilla.org Cc: b2g-release-drivers b2g-release-driv...@mozilla.org, B2G Internal b2g-inter...@mozilla.org Sent: Tuesday, April 8, 2014 3:57:00 PM Subject: Resending: 04/08/14 Tarako v1.3t Smoke Test Results - 40/48 tests passed, 6 untested (Marketplace), 1 new blocker 40 out of 48 tests passed for the 2014-04-08 Tarako v1.3t Build. There is one new issue and one existing blocker that kept the smoketests from fully passing. Please note, there's going to be a new Marketplace app for Tarako which is planned to land April 16th thus all Marketplace tests are going to be skipped until then. Smoketest Results: Daily Smoke Test Logs: https://docs.google.com/a/qanalydocs.com/spreadsheet/ccc?key=0AjRc6aVFoOW9dGZLdVdiWGZLbVdORlFpUGt5XzZ3Zncusp=drive_web#gid=5 Moztrap link: https://moztrap.mozilla.org/runtests/run/3784/env/347/ Tests Were Performed With: Build ID: 20140408004001 Gecko: b850e0f09e61 Gaia: 643f3e6676cbb89c62708a9f7cbef2edc795a552 Base Image: sp8810 2 reboots 2 crashes: - bug https://bugzilla.mozilla.org/show_bug.cgi?id=976656 - bug https://bugzilla.mozilla.org/show_bug.cgi?id=989989 New Bugs Breaking the Smoketests: - [B2G][Tarako]Unable to proceed past the extension line when calling into the Mozilla conference line https://bugzilla.mozilla.org/show_bug.cgi?id=993564 :hsinyi is investigating this. Existing Bugs Breaking the Smoketests: - [Tarako] [B2G][First Time Experience] No FTE/FTU appears when device is reset or reflashed https://bugzilla.mozilla.org/show_bug.cgi?id=991304 Issue fixed recently on the vendor side. - [Dialer][V1.3T] The caller and receiver cannot hear any voice https://bugzilla.mozilla.org/show_bug.cgi?id=988786 NOTE: I'm including this one as, while some of us have this working, others do not. We should know for sure tomorrow if this one is good or not. Sounds good, nothing actionable on the bug at the minute. New Issues Not Breaking the Smoketests: - [B2G][Tarako]When in a phone call, the proximity sensor does not turn off the screen https://bugzilla.mozilla.org/show_bug.cgi?id=993518 - [B2G][Tarako][Contacts]Facebook toggle not properly displayed when no data or wifi connection available https://bugzilla.mozilla.org/show_bug.cgi?id=993531 Sincerely, Mozilla QA ___ b2g-internal mailing list b2g-inter...@mozilla.org https://mail.mozilla.org/listinfo/b2g-internal ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Resending: 04/08/14 Tarako v1.3t Smoke Test Results - 40/48 tests passed, 6 untested (Marketplace), 1 new blocker
Looks like there are test cases getting skipped in the smoketest run. Let me look into this. - Original Message - From: Bhavana Bajaj bba...@mozilla.com To: John Hammink jhamm...@mozilla.com Cc: dev-gaia dev-g...@lists.mozilla.org, dev-b2g dev-b2g@lists.mozilla.org, b2g-release-drivers b2g-release-driv...@mozilla.org, B2G Internal b2g-inter...@mozilla.org Sent: Tuesday, April 8, 2014 10:28:24 PM Subject: Re: Resending: 04/08/14 Tarako v1.3t Smoke Test Results - 40/48 tests passed, 6 untested (Marketplace), 1 new blocker John/QA Team, I see eight smoketest failing here but only three blockers listed. Can QA help identify the remaining bugs here ? Also, I've commented inline on the three smoketests bugs mentioned below. Thanks, Bhavana - Original Message - From: John Hammink jhamm...@mozilla.com To: dev-gaia dev-g...@lists.mozilla.org, dev-b2g dev-b2g@lists.mozilla.org Cc: b2g-release-drivers b2g-release-driv...@mozilla.org, B2G Internal b2g-inter...@mozilla.org Sent: Tuesday, April 8, 2014 3:57:00 PM Subject: Resending: 04/08/14 Tarako v1.3t Smoke Test Results - 40/48 tests passed, 6 untested (Marketplace), 1 new blocker 40 out of 48 tests passed for the 2014-04-08 Tarako v1.3t Build. There is one new issue and one existing blocker that kept the smoketests from fully passing. Please note, there's going to be a new Marketplace app for Tarako which is planned to land April 16th thus all Marketplace tests are going to be skipped until then. Smoketest Results: Daily Smoke Test Logs: https://docs.google.com/a/qanalydocs.com/spreadsheet/ccc?key=0AjRc6aVFoOW9dGZLdVdiWGZLbVdORlFpUGt5XzZ3Zncusp=drive_web#gid=5 Moztrap link: https://moztrap.mozilla.org/runtests/run/3784/env/347/ Tests Were Performed With: Build ID: 20140408004001 Gecko: b850e0f09e61 Gaia: 643f3e6676cbb89c62708a9f7cbef2edc795a552 Base Image: sp8810 2 reboots 2 crashes: - bug https://bugzilla.mozilla.org/show_bug.cgi?id=976656 - bug https://bugzilla.mozilla.org/show_bug.cgi?id=989989 New Bugs Breaking the Smoketests: - [B2G][Tarako]Unable to proceed past the extension line when calling into the Mozilla conference line https://bugzilla.mozilla.org/show_bug.cgi?id=993564 :hsinyi is investigating this. Existing Bugs Breaking the Smoketests: - [Tarako] [B2G][First Time Experience] No FTE/FTU appears when device is reset or reflashed https://bugzilla.mozilla.org/show_bug.cgi?id=991304 Issue fixed recently on the vendor side. - [Dialer][V1.3T] The caller and receiver cannot hear any voice https://bugzilla.mozilla.org/show_bug.cgi?id=988786 NOTE: I'm including this one as, while some of us have this working, others do not. We should know for sure tomorrow if this one is good or not. Sounds good, nothing actionable on the bug at the minute. New Issues Not Breaking the Smoketests: - [B2G][Tarako]When in a phone call, the proximity sensor does not turn off the screen https://bugzilla.mozilla.org/show_bug.cgi?id=993518 - [B2G][Tarako][Contacts]Facebook toggle not properly displayed when no data or wifi connection available https://bugzilla.mozilla.org/show_bug.cgi?id=993531 Sincerely, Mozilla QA ___ b2g-internal mailing list b2g-inter...@mozilla.org https://mail.mozilla.org/listinfo/b2g-internal ___ b2g-internal mailing list b2g-inter...@mozilla.org https://mail.mozilla.org/listinfo/b2g-internal ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
