Closed Bug 384624 Opened 13 years ago Closed 13 years ago
Update the Windows refplatform
The Windows refplatform needs the following updates: 1) Use MozillaBuild instead of a bunch of custom packages All you should need at this point is MozillaBuild, MSVC, and the JDK 2) Perhaps upgrade to MSVC8SP1 We *might* want to update to MSVC8SP1. However, there are known performance issues in that configuration when building with PDBs enabled (which the tinderboxes do). MS has published a hotfix for this issue, but apparently IT has had trouble getting their hands on it: http://support.microsoft.com/kb/935225 Alternately, we could think about taking bug 382297, which according to vlad fixes the perf issue, but I'm worried about *that* breaking -jN builds and/or not working with the hotfix. I'm sorry I can't be more definitive about this :-( This should happen by Friday June 22 if it's going to make 1.9a6... and it probably should happen by then if we want this for 1.9 Random note, VC8SP1 has an updated version of the CRT, so we'll need to make sure that the CRT shipping is correct: I can't find WIN32_REDIST_DIR in the tinder-config, which confuses me a little bit: is it set in the tinderbox environment directly?
I'll be working with Ted on this this week.
Assignee: build → preed
Priority: -- → P1
Adding dependent bugs that are relevant to upgrading the win32 ref platform.
(In reply to comment #0) > 2) Perhaps upgrade to MSVC8SP1 > > We *might* want to update to MSVC8SP1. However, there are known performance > issues in that configuration when building with PDBs enabled (which the > tinderboxes do). MS has published a hotfix for this issue, but apparently IT > has had trouble getting their hands on it: > > http://support.microsoft.com/kb/935225 http://fs/public/IT/Microsoft/VS%20Hotfix/
No longer blocks: 385911
Just an update on this: I'm working through various issues related to how Windows updates Visual Studio. The main problem is that we originally designed these reference VMs to be small and very easy to move around, hence a 10 Gb disk with both Win2k3 and VS8. Lamentably, this is not enough space for Windows Update to update VS to SP1, so I'm doing some hackery with the reference images to get them updated. Windows update is chugging along right now with the new setup, so we'll see if it worked in about an hour or so... ;-)
So, I've got everything installed (MozillaBuild 1.1, etc.) on a VM that I'm cloning as fxnewref-win32-tbox. When that's cloned, we'll see if we can get it producing builds!
I've got it producing builds... but I'm playing with some of the mozconfigs settings... you can see the builds on the MozillaExperimental Tinderbox page: http://tinderbox.mozilla.org/showbuilds.cgi?tree=MozillaExperimental (The first build is extra-long because it was waiting for someone to accept an ssh key; clobber builds should not take that long in the future.)
Current issue: scp/ssh hangs on the new ref platform, so dep builds take five hours (the time it takes for ssh to completely time out). I'm working through why this might be with bsmedberg... and will hopefully have an update soon. Other than that, builds look good. I'll hook them up to the testing infra when we're over this hump.
Attachment #276549 - Flags: review?(rhelmer) → review+
Alright, I've got the Fx-Newref box and its associated bl-bldxp01 test machine pointing to the Firefox tinderbox page. I'm gonna switch to the Newref machines and idle the old Win32 machines tonight, so tomorrow's nightlies will be from the new ref platform. Yay?
Comment on attachment 276913 [details] [diff] [review] Nagios tree monitoring changes for bumping the ref platform does this line need to change too: bl-bldxp01|perf test|fx-win32-tbox ?
Attachment #276913 - Flags: review?(rhelmer) → review+
Comment on attachment 276913 [details] [diff] [review] Nagios tree monitoring changes for bumping the ref platform So it does. Looks like the linux lines are wrong, too. New patch coming up.
Attachment #276913 - Attachment is obsolete: true
Glancing through the Firefox trunk tinderbox page, it looks like everything went Ok last night, and bl-bldxp01 is picking up the test builds. I'm going to keep this bug open, however, because I noticed that the nightly build took about 5 hours to complete; this looks like ssh timing out (it didn't have aus2-staging's host key in its known_hosts file). I'm going to fix that now, and if tomorrow's nightly is OK, mark this fixed.
Comment on attachment 277012 [details] [diff] [review] Nagios tree monitoring changes for the bump, win32 + Linux looks good. btw why is it "fxnewref-win32-"? Is it over the char limit for some obscure bit of tinderbox or something? :)
Attachment #277012 - Flags: review?(rhelmer) → review+
So, it turns out that I just needed the win32 ones after all... I hadn't cvs up'd in awhile... so I just committed the win32 ones. (In reply to comment #15) > (From update of attachment 277012 [details] [diff] [review]) > looks good. btw why is it "fxnewref-win32-"? Is it over the char limit for some > obscure bit of tinderbox or something? :) It's even better than that! MSYS (I believe) grabs the hostname from the NetBIOS/NetBEUI (I believe that's the really old name for it) computer name in win32... and those--you guessed it--have a 15 character limit on them. What year is this again?
Depends on: 393262
Depends on: 387167
Update on this: looks like the Firefox build is going ok. I tried to deploy this for a XULRunner build, though, and it didn't build because I forgot to install the JDK. So, as far as Firefox is concerned, we're ok, but I'm going to add the JDK and set up a couple of things on the ref image (create a desktop icon, setup blat), and redeploy the Firefox build, renamed, which should also fix bug 387167. I'm expecting to make this switchover on either Wednesday or Thursday.
I think we can claim success on this.
Status: NEW → RESOLVED
Closed: 13 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.