With rust 1.8 we can support win32. Enable rust for official builds on that platform using that and later versions of the toolchain.
Turn this on now using a rustc 1.8 nightly build. Our policy is to limit ourselves to stable rust releases as much as possible, but win32 support only comes with 1.8. Using a nightly rustc is justified here because (a) any nightly-isms will be caught by builds on other platforms which can use stable rust. (b) Windows is our majority platform and more testing is good. (c) rustc 1.8 will move to beta March 3, giving us time to update before this rides the trains to dev edition.
Attachment #8719561 - Flags: review?(mshal)
Comment on attachment 8719561 [details] [diff] [review] Enable rust for win32 official builds Looks good. Do we want to make win64 consistent with win32 and enable it in beta+release mozconfigs? Then we could remove build/mozconfig.rust from the whitelist as well I believe.
Attachment #8719561 - Flags: review?(mshal) → review+
Wait, what? rust is enabled on beta/release?
(In reply to Mike Hommey [:glandium] from comment #4) > Wait, what? rust is enabled on beta/release? It is for linux/osx: c.f. Bug 1243363 -- and it either needs to be in whitelist in-tree *and* releng whitelists to not ride to beta, or needs to ride to beta with what we actually build in aurora/central (imo, relman can help determine alternate risk).
(In reply to Justin Wood (:Callek) from comment #5) > It is for linux/osx: c.f. Bug 1243363 -- and it either needs to be in > whitelist in-tree *and* releng whitelists to not ride to beta, or needs to > ride to beta with what we actually build in aurora/central (imo, relman can > help determine alternate risk). So there are out-of-tree consistency check on mozconfig variations? What's the procedure for updating those?
(In reply to Ralph Giles (:rillian) from comment #7) > (In reply to Justin Wood (:Callek) from comment #5) > > > It is for linux/osx: c.f. Bug 1243363 -- and it either needs to be in > > whitelist in-tree *and* releng whitelists to not ride to beta, or needs to > > ride to beta with what we actually build in aurora/central (imo, relman can > > help determine alternate risk). > > So there are out-of-tree consistency check on mozconfig variations? What's > the procedure for updating those? Same general process as in-tree. e.g. if it is truely intended to ignore something it can go there. The general idea of the whitelist is that only things that don't affect compilation and only things that are explicitly not riding trains (e.g. completely and utterly understood that it won't ride trains and can be disabled without breaking) should go in. https://dxr.mozilla.org/build-central/source/tools/buildbot-helpers/mozconfig_whitelist
I had to back this out because win32 spidermonkey builds (which only build when JS stuff gets touched by a patch) are failing like http://archive.mozilla.org/pub/spidermonkey/tinderbox-builds/mozilla-inbound-win32/mozilla-inbound_win32_spidermonkey-plain-bm91-build1-build7.txt.gz (Ctrl-f for `results: 1' and look above the second result for the errors) https://hg.mozilla.org/integration/mozilla-inbound/rev/e1d3af107ad1
INFO - Attempting to fetch from 'http://tooltool.pvt.build.mozilla.org/build/'... INFO - ...failed to fetch 'rustc-nightly-i686-pc-windows-msvc.tar.bz2' from http://tooltool.pvt.build.mozilla.org/build/ Dustin, any ideas? Is this a separate tooltool cache that need updating? The manifest entry from the log fetches fine from the https://api.pub.build.mozilla.org/tooltool/ endpoint on my machine, which is the same one the try builds used.
Flags: needinfo?(giles) → needinfo?(dustin)
I think I ran into the same problem with win32 builds and wound up just making the manifest entry public.
Hm, sounds like another new and different way that tooltool is invoked. Unless this was on beta. For some reason I don't really understand, for the last 4-5 releases beta has been using that ancient tooltool URL.
(In reply to Dustin J. Mitchell [:dustin] from comment #12) > Hm, sounds like another new and different way that tooltool is invoked. > Unless this was on beta. For some reason I don't really understand, for the > last 4-5 releases beta has been using that ancient tooltool URL. If I'm reading the buildbotcustom/misc.py code correctly, I believe spidermonkey builds use the same tooltool_url_list that beta/release builds use (defined in buildbot-configs/mozilla/production_config.py and staging_config.py). Can I just file a bug to point those to api.pub.build.mozilla.org/tooltool? Or are you saying there is a reason to keep it at tooltool.pvt.build.mozilla.org but you aren't sure what that is? This same thing bit me on staging, and I'm pretty sure beta builds will fail soon once some of our newer tooltool manifests get there.
Yeah, I don't really understand why this is difficult, but there's been a bug filed for every beta uplift which is invariably resolved with "oh, I guess we have to apply the same patch we applied at the last beta". I don't understand why it keeps getting un-applied. Anyway, tooltool.pvt.build.mozilla.org is dead and not being updated anymore, so anything using it should be changed.
Dustin, if uploads to the old endpoint are disabled, could you please copy a388df6ce743be521ba688132d06ba86d225673b53f71f9c7c0d3189adf16f553088d8d359f583f958e886583de9583df53873c85c34abf33b2d55ee7d807206 to the old endpoint so this can land? Releng was concerned about the risk of fixing this bug late in the beta cycle and wants to postpone until after uplift. We on the other hand, would really like to get some testing on this in 47 nightly.
NM, should be resolved by bug 1251328.
You need to log in before you can comment on or make changes to this bug.