Nobody's been able to figure out why, but since 19 merged to beta, the Android mochitests and talos time out starting up, while the reftests and crashtests and jsreftests succeed. The only apparent difference in the logs is that mochitests and talos pass a URL to open in the commandline, ... org.mozilla.beta http://..., while the reftest harness does not, it just opens org.mozilla.beta and (handwaving) it knows what to load. Since we've already got several pushes to beta, and people show no sign of stopping just because Android tests aren't actually running, the tree is closed.
wesj was looking into this earlier this evening. Any updates Wes?
Also including Clint, who should be back tomorrow :), and should be able to help us get some eyes on
Nothing interesting to report. I can't reproduce the failures on my devices. I pushed a few things to try to see if this is caused by the version/branding bumps. There are odd things in some of the logs (one mentioned fennec_aurora and one has failures in a lot of reflection methods), but they seem to be semi-random. joduin hinted maybe they were happening in Aurora (but just not being noticed?). I couldn't find them in Aurora builds I checked though. Still poking around looking for a good lead.
Running the mochitests on beta on my nexus one show a prompt to share my location with google. The test has stalled while waiting for a reply. I assume it will hit the 2400 seconds timeout and be killed like the runs on tbpl. I have not noticed the location sharing prompt before.
I noticed Google started asking for geo location on search results yesterday too. I ran (some) mochitests locally and didn't see any prompt here, but maybe I should try running a larger set. Why would we be loading Google searches during tests? I guess if you pass in a search term as a url we might, but the urls look fine in the logs. And why would that only affect beta...
we are not loading our profile, so the url we are loading is '-no-remote -profile /mnt/sdcard/tests http://mochi.test:8888/tests/...' and this translates into a search on google since we load a default profile.
Assignee: wjohnston → jmaher
Status: NEW → ASSIGNED
Attachment #699242 - Flags: review?(blassey.bugs)
Attachment #699242 - Flags: review?(blassey.bugs) → review+
fixed an extra parenthesis and bumped the version. Tested this locally and it works great.
Attachment #699251 - Flags: review?(blassey.bugs) → review+
Comment on attachment 699251 [details] [diff] [review] use the VIEW intent for either fennec or firefox products (1.1) [Triage Comment] Pre-approving for beta since this is impacting our beta 1 go. Please land asap.
Attachment #699251 - Flags: approval-mozilla-beta+
Pushed to beta (I changed the version number change slightly?) https://hg.mozilla.org/releases/mozilla-beta/rev/e7cc9405b1f3
Comment on attachment 699251 [details] [diff] [review] use the VIEW intent for either fennec or firefox products (1.1) Since this landed on central/beta, assuming this is needed for aurora as well.
What still needs to happen here? The talos tests are still busted...
(In reply to Alex Keybl [:akeybl] from comment #12) > What still needs to happen here? The talos tests are still busted... bug 828021
we need to resolve bug 828752 in order to fix the few remaining tests on firefox-beta.
Well, that and some sort of miracle to make ts not crash so much (29 out of 31 runs on the tip push), but given how Android is, that's no tree-blocker, and everything else is fine now. Reopened.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
This appears to be fixed, is there any other action required here?
I assumed a resolved->fixed was all we needed to do.
Why is this bugging me about an unlanded aurora 20 bug status? This has been resolved for weeks.
Because it thinks you need to use your approval-aurora on attachment 699251 [details] [diff] [review] by landing it on aurora, so we don't get the exact same thing when 20 merges to beta and starts building firefox instead of fennec.
well, it is a sutagent change and that is not related to the branches we run on, so whatever I did for this bug has nothing to do with specific branches. Is there a way to clear this flag or tell some unknown magical system to ignore this bug?
So the in-tree sutagent doesn't do anything, and there wasn't actually any point in landing https://hg.mozilla.org/releases/mozilla-beta/rev/e7cc9405b1f3?
correct. The in tree sutagent is so folks can build on their own if they want it locally. The SUTAgent is managed as a whole (not per branch) across the tegras and pandas.
So if someone builds 19, will they get a working sutagent because it knows about firefox and not just fennec, or will they get a broken non-working sutagent because 1.13 is too old and broken to actually work, even against 19? If someone builds 20 today, will they get a working sutagent, or is the code that's on aurora right now too old and broken? And the key question, after we merge 20 to beta, and change the default branding, will someone who is doing exactly the right thing, building just like the tree does with firefox branding, get a broken sutagent because it doesn't know about firefox, and would they get a working sutagent if that attachment landed on aurora and this bug got marked as status-firefox20: fixed?
this was only approved for aurora because initially folks thought that the sutagent was branch specific. If somebody were to build sutagent from Firefox 18 it will have the same problem as well. I have yet to find a developer who has installed sutagent unless I have specfically asked them to. If we were to replicate automation, you will see that the sutagent comes from a different location (we don't publish it from the build), and all the other tools used for automation are not branch specific.
The m-c changeset was never pasted in the bug. For posterity: https://hg.mozilla.org/mozilla-central/rev/2ac1e848a23d
Target Milestone: mozilla19 → mozilla21
You need to log in before you can comment on or make changes to this bug.