MozillaBuild 1.4 was just released and we should upgrade to it. I'll be rolling it out on the try slaves in an attempt to fix bug 496712. If that goes well (or maybe at the same time) we should deploy it on the moz2-win32* staging slaves and do a bunch of verification to make sure it doesn't regress anything. From there, we can roll it out in production.
9 years ago
a) Which slaves already have upgraded to mozilla-build1.4 - just the staging slaves and try slaves? b) I'm assuming we'll use opsi for this?
Only the try slaves have been upgraded. Yes, we'll use OSPI for it.
One thing to watch out for is the environment hard-coding in http://hg.mozilla.org/build/buildbotcustom/file/tip/env.py#l87 http://hg.mozilla.org/build/buildbotcustom/file/tip/env.py#l154 If MB 1.4 has updated the path, or added new env vars then we may need to update those those definitions.
Created attachment 394885 [details] diff vars-old.txt vars-new.txt This is a diff of 'export' from an MB1.2 slave and an MB1.4 slave taken from a new login via start-msvs8.bat Of interest: * In MB1.4 %INCLUDE% gets prepended with a couple of directories - I think that's OK since it's at the start * Same thing for %LIB% * %MSVCEXPROOTKEY% is added - can't see this harming anything * Some *SDK* adjustments - I think those are expected with the new MB and don't seem to be causing any problems. * %PATH% - lots of differences in ordering but nothing that looks like it would affect things ** emacs path difference ** all this stuff: "/d/mozilla-build/hg:/d/mozilla-build/python25/Scripts:/d/mozilla-build/kdiff3:/d/mozilla-build/vim/vim72" prepended before '.' in the MB1.4 one ** python24/scripts at the start of the MB1.4 one ** "/c/Program Files/Microsoft SDKs/Windows/v6.0A/bin" instead of "/d/sdks/v6.0/bin" in the new one - this one is concerning. I had a look at both of those directories and the files were not identical. I'll look into this some more tomorrow.
(In reply to comment #4) > ** "/c/Program Files/Microsoft SDKs/Windows/v6.0A/bin" instead of > "/d/sdks/v6.0/bin" in the new one - this one is concerning. I had a look at > both of those directories and the files were not identical. I'll look into this > some more tomorrow. I just spoke with Ted about this for some background. He says that the v6.0a SDK gets installed with vc2k8 and is probably just the v6.0 one plus fixes to make it work with vc2k8. Unless we see problems this PATH change is OK. More background is in https://bugzilla.mozilla.org/show_bug.cgi?id=428526
(In reply to comment #3) > One thing to watch out for is the environment hard-coding in > http://hg.mozilla.org/build/buildbotcustom/file/tip/env.py#l87 > http://hg.mozilla.org/build/buildbotcustom/file/tip/env.py#l154 > If MB 1.4 has updated the path, or added new env vars then we may need to > update those those definitions. Looks like the PATHs there were causing the buildsymbols failures we saw. I'll get a patch ready to update them.
Created attachment 395317 [details] [diff] [review] update buildbotcustom.env In my tests this fixes the buildsymbols errors. I'm going to run it for awhile more, though.
Attachment #395317 - Flags: review?(nthomas)
Comment on attachment 395317 [details] [diff] [review] update buildbotcustom.env changeset: 395:637a48dd9b6b
Attachment #395317 - Flags: checked-in+
Doing the rollout of this now.
This is rolled out all of the win32 slaves and the ref platform now. OPSI ftw!
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.