Bug 1175606 burned Talos because "Non-local network connections are disabled and a connection attempt to tracking.services.mozilla.com (52.10.204.176) was made.": https://bugzilla.mozilla.org/show_bug.cgi?id=1175606#c17 We need to update the prefs to match what we do for tests in-tree: http://mxr.mozilla.org/mozilla-central/source/testing/profiles/prefs_general.js#91

We need to land this update to talos prefs ASAP so that we can land Bug 1175606 in time to ride the trains to 42. I've reproduced the crash without my patch applied (and that it's fixed with it applied) by running: talos --develop --executablePath /fx-team/objdir.noindex/dist/Nightly.app/Contents/MacOS/firefox --activeTests tresize

Copied from http://mxr.mozilla.org/mozilla-central/source/testing/profiles/prefs_general.js#91

Joel / William - just a heads up about this change. Is there any reason we can't land some pref changes and then bump talos.json? I see quite a few commits [0] since the last talos.json bump on 08-01 [1] [0]: http://hg.mozilla.org/build/talos/ [1]: https://hg.mozilla.org/mozilla-central/filelog/d6ea652c579992daa9041cc9718bb7c6abefbc91/testing/talos/talos.json

I was going to update talos and have a try run with all the latest: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8d79187e347f if you want, when that is green we can land and update. If this is on Beta, we need to talk, otherwise aurora/central are just fine. Speaking of which, would there be an issue with this on Aurora?

(In reply to Joel Maher (:jmaher) from comment #4) > I was going to update talos and have a try run with all the latest: > https://treeherder.mozilla.org/#/jobs?repo=try&revision=8d79187e347f > > if you want, when that is green we can land and update. If this is on Beta, > we need to talk, otherwise aurora/central are just fine. > > Speaking of which, would there be an issue with this on Aurora? Thanks for the response! My plan will be to push to talos and then create a try push with the updated talos.json. If that looks good, we'll push the update to fx-team. This doesn't need any uplift, it's just going on central.

(In reply to Joel Maher (:jmaher) from comment #4) > Speaking of which, would there be an issue with this on Aurora? It doesn't need to be uplifted, but it wouldn't hurt to be uplifted if it happened to be for some reason (it's just overriding some safe browsing style prefs for Tracking Protection that will never be used on anything pre-42)

Landed in talos: https://hg.mozilla.org/build/talos/rev/c7446ecc3bfb

Try push with the updated talos.json: https://treeherder.mozilla.org/#/jobs?repo=try&revision=60b6d44a881d

Try push with the offending patch from Bug 1175606 applied: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2a29513c92b

Hey Brian, when you have a moment go ahead and set the point value.

So.. apparently this is burning Windows T-E10s with what looks like an infrastructure issue: https://treeherder.mozilla.org/#/jobs?repo=fx-team&revision=7fe4321e40bc. I'm guessing it's due to one of the pushes since the last talos bump on 8-1 and not due to this simple pref change, but it's hard to say for sure since my try runs didn't include T-E10s (and in fact I don't know how to include them with the try syntax). My best idea as a workaround is to branch talos from d44548b8feb9 (last known good rev) and apply 2181cef265e7 (our pref-change rev) on top of that.

(In reply to Brian Grinstead [:bgrins] from comment #14) > So.. apparently this is burning Windows T-E10s with what looks like an > infrastructure issue: > https://treeherder.mozilla.org/#/jobs?repo=fx-team&revision=7fe4321e40bc. > > I'm guessing it's due to one of the pushes since the last talos bump on 8-1 > and not due to this simple pref change, but it's hard to say for sure since > my try runs didn't include T-E10s (and in fact I don't know how to include > them with the try syntax). > > My best idea as a workaround is to branch talos from d44548b8feb9 (last > known good rev) and apply 2181cef265e7 (our pref-change rev) on top of that. Talking with :philor, we decided the best thing to do was back out this bump commit. Apparently there isn't a way to run T-E10s on try and I don't know enough about this problem to make a good decision. Joel, a couple of things we discussed were to branch talos as outlined above or just say hide WinXP e10s until we can figure it out. Or maybe the failure will be immediately obvious to you. Is there any possible way you could give some guidance on this before the merge on Monday? Thanks!

Backed out the bump in https://hg.mozilla.org/integration/fx-team/rev/222f1e42ebd9

I am fine hiding winxp e10s if that is needed, we just enabled this yesterday, so hiding them for another week if needed isn't a big deal. It fails fast which is good, so less concern on tying up machines for 1 hour just for a failure. I have a couple ideas of the problem, but it will take some debugging.