505565 - rollout MozillaBuild 1.4 across the win32 build machines

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[[e-mail] (:bhearsum)]

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.

Comment 1

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

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?

Comment 2

[[e-mail] (:bhearsum)]

Only the try slaves have been upgraded. Yes, we'll use OSPI for it.

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 4

[[e-mail] (:bhearsum)]

Attachment: 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.

Comment 5

[[e-mail] (:bhearsum)]

(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

Comment 6

[[e-mail] (:bhearsum)]

(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.

Comment 7

[[e-mail] (:bhearsum)]

Attachment: update buildbotcustom.env

In my tests this fixes the buildsymbols errors. I'm going to run it for awhile more, though.

Comment 8

[[e-mail] (:bhearsum)]

Comment on attachment 395317 [details] [diff] [review]
update buildbotcustom.env

changeset:   395:637a48dd9b6b

Comment 9

[[e-mail] (:bhearsum)]

Doing the rollout of this now.

Comment 10

[[e-mail] (:bhearsum)]

This is rolled out all of the win32 slaves and the ref platform now. OPSI ftw!