Setup Windows Mobile trunk tinderbox

RESOLVED FIXED

Status

P2
normal
RESOLVED FIXED
11 years ago
5 years ago

People

(Reporter: dougt, Assigned: aki)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments, 9 obsolete attachments)

12.95 KB, patch
bhearsum
: review+
bhearsum
: checked-in+
Details | Diff | Splinter Review
24.26 KB, patch
bhearsum
: review+
bhearsum
: checked-in+
Details | Diff | Splinter Review
11.99 KB, patch
bhearsum
: review+
bhearsum
: checked-in+
Details | Diff | Splinter Review
21.82 KB, patch
bhearsum
: review+
bhearsum
: checked-in+
Details | Diff | Splinter Review
11.01 KB, patch
bhearsum
: review+
bhearsum
: checked-in+
Details | Diff | Splinter Review
1.72 KB, patch
bhearsum
: review+
Details | Diff | Splinter Review
(Reporter)

Description

11 years ago
I will set up temp tinderbox to work out the process.
OS: Mac OS X → Windows Mobile 6 Professional
Reassigning after  chat on irc.
Assignee: nobody → doug.turner
Assignee: doug.turner → nobody
Component: Build & Release → Release Engineering: Projects
QA Contact: build → release

Updated

11 years ago
Priority: -- → P3
Bug#460777 created two VMs for DougT and Blassey to experiment on. They've written up the steps needed to modify existing win32 ref images so they could support WinCE builds. See details at: https://wiki.mozilla.org/Mobile/Build/StepsToModifyRefVM
Depends on: 460777
Assignee: nobody → joduinn
Assignee: joduinn → nobody
Component: Release Engineering: Future → Release Engineering
Assignee: nobody → joduinn
Priority: P3 → P2
Brad did all his work in mobile-win32-experiment01, so I'm trying a clean setup in mobile-win32-experiment02. Most installed just fine into C, leaving 2.4gb free. Working through some questions with Brad.
(Assignee)

Updated

10 years ago
Assignee: joduinn → aki
(Assignee)

Comment 4

10 years ago
John -- let me know where you left off; I can work on this.
(Assignee)

Comment 5

10 years ago
I believe mobile-win32-experiment02 is set up (leaving the PATH setup to a buildbot step).  I was able to build xulrunner in /e/builds/moz2_slave/mozilla-central

The next steps would seem to be:

1) joduinn wants someone to verify that mobile-win32-experiment02 is set up correctly
2) determine what to do about mq.  if the patches are going to land soon, that's one solution; if we determine that enabling it on the win32 ref image is not harmful, that's another.
3) push changes to the ref image and existing win32 build slaves
4) get the builds going in staging
5) get the builds going in production
(Reporter)

Comment 6

10 years ago
1) how do I/blassey gain access to viewing mobile-win32-experiment02

2) i do not imagine that the MQ will go away any time soon.
I don't see how enabling MQ could be harmful
(Assignee)

Comment 8

10 years ago
Created attachment 358676 [details]
optimized mozconfig built from blassey's debug mozconfig

Looks like it's standard practice to check these into buildbot-configs... and there's a staging one.  I'm just wget'ing from people.m.c right now.
(Assignee)

Comment 9

10 years ago
Created attachment 358678 [details] [diff] [review]
working staging patch for wince builds

Currently, this can only build on mobile-win32-experiment02 as the appropriate changes haven't been applied to the pool/ref image.

I've successfully run this on staging; results are available on the MozillaTest tinderbox page (and the staging-master buildbot waterfall).  Builds are being pushed to staging-stage:

http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mobile-browser/
http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mobile-browser-wince-arm/

with timestamps in the directory name for tinderbox-builds.  The package is a tar.gz which doesn't seem right but is the default for the 'make package'.

I've also added the code to potentially upload the Nokia debs into a timestamped directory as well (bug 469294), but we won't see if it works until we debug the compilation timeout.

If this looks good, I'll create and attach a production patch.
(Assignee)

Comment 10

10 years ago
Also: I'm building in /e/builds/moz2_slave/mozilla-central because I found building in /e/builds/moz2_slave/mobile-wince-arm-dep/build/mozilla-central broke with a popup "memory could not be read" error during linking.  If there's a better directory to use I can change this.
(Assignee)

Comment 11

10 years ago
Created attachment 359205 [details] [diff] [review]
staging/production windows mobile tinderbox

I've moved the builds to /e/builds/mobile and create zip files instead of tar.gz files.  (When bug 474530 is fixed, we can create cab files as well.)

This patch will also create timestamped directories (bug 469294).  Tested on staging.
Attachment #358676 - Attachment is obsolete: true
Attachment #358678 - Attachment is obsolete: true
Attachment #359205 - Flags: review?(catlee)
Comment on attachment 359205 [details] [diff] [review]
staging/production windows mobile tinderbox

Don't want to step on Catlee's review now may be a good time to move this build logic into factory.py. Any chance you can do that?
Comment on attachment 359205 [details] [diff] [review]
staging/production windows mobile tinderbox

Yes, I would love to see this in its own factory.

Also, some minor style nits:
 - use spaces after commas in lists (e.g. ["mobile-linux-arm-dep","mobile-wince-arm-dep"] should be ["mobile-linux-arm-dep", "mobile-wince-arm-dep"])
 - there are a few instances where you're settings description = ['word1 word2'] as opposed to ['word1', 'word2'], is that on purpose?

Other than that, it looks good to me.
Comment on attachment 359205 [details] [diff] [review]
staging/production windows mobile tinderbox

On further thought, I agree with bhearsum; this is a good time to move this code into factory.py.
Attachment #359205 - Flags: review?(catlee) → review-
(Assignee)

Comment 15

10 years ago
Created attachment 359718 [details] [diff] [review]
MobileBuildFactory patch

I've created a factory for mobile builds in factory.py, as requested.
There isn't much shared between the linux-arm and wince-arm builds, but this will help prevent duplicate code in production/staging mobile_master.py.

Tested on staging for both linux and wince.  patch 1 of 2.
Attachment #359205 - Attachment is obsolete: true
Attachment #359718 - Flags: review?(bhearsum)
(Assignee)

Comment 16

10 years ago
Created attachment 359719 [details] [diff] [review]
buildbot-configs patch using MobileBuildFactory
Attachment #359719 - Flags: review?(bhearsum)

Updated

10 years ago
Attachment #359719 - Flags: review?(bhearsum) → review+
Comment on attachment 359719 [details] [diff] [review]
buildbot-configs patch using MobileBuildFactory

When we deploy this on production this will have to change. We keep MSVC and the SDKs on /d.

>+mk_add_options AR=@topsrcdir@/build/wince/tools/bin/arm-wince-lib
>+
>+ac_add_options --target=arm-wince
>+ac_add_options --enable-win32-target=WINCE
>+ac_add_options --enable-default-toolkit=cairo-windows
>+
>+ac_add_options --with-wince-sdk="c:/program files/windows mobile 6 sdk/pocketpc"

Same with this.


This looks great. I'm happy to see this file be cleaned up. On a side note, when are we going to deploy the win32 mobile ref platform stuff onto the rest of our machines?

Updated

10 years ago
Attachment #359718 - Flags: review?(bhearsum) → review-
Comment on attachment 359718 [details] [diff] [review]
MobileBuildFactory patch

>diff -r e9c504ba889e process/factory.py

>+class MobileBuildFactory(MozillaBuildFactory):
>+    def __init__(self, configRepoPath, mobileRepoPath, platform,
>+                 configSubDir, mozconfig, objdir="objdir",
>+                 stageUsername=None, stageSshKey=None, stageServer=None,
>+                 stageBasePath=None, stageGroup=None, packageGlob=None,
>+                 patchRepoPath=None, baseWorkDir='build',
>+                 scratchboxPath="/scratchbox/moz_scratchbox",
>+                 **kwargs):

I think it'd be much better to do this with subclassing. It's mostly ok how it is for now, but we're only going to be adding more platforms as time goes on and the 'if platform == blah' conditionals are going to get more complicated. You can probably do better argument validation that way, too. Eg, patchRepoPath can become required for win32, packageGlob can be set sanely by default, et. al.

>+        """
>+    mobileRepoPath: the path to the mobileRepo (mobile-browser)
>+    platform: the mobile platform (linux-arm, wince-arm)
>+    patchRepoPath: the path to the MQ repo, if any.  To be phased out.
>+    baseWorkDir: the path to the default slave workdir...
>+                 SBOX_HOME for linux, /e/builds/mobile for wince.

Why do you need to work outside of the builder's directory on windows? On Linux we only do it because we have to build inside of scratchbox. Unless there's no other way please don't reach outside of the builder's directory.

>+    scratchboxPath: the path to moz_scratchbox for linux-arm builds.
>+        """
>+        MozillaBuildFactory.__init__(self, **kwargs)
>+        self.platform = platform
>+        self.configRepository = self.getRepository(configRepoPath)
>+        self.mobileRepository = self.getRepository(mobileRepoPath)
>+        self.mobileBranchName = self.getRepoName(self.mobileRepository)
>+        self.configSubDir = configSubDir
>+        self.mozconfig = mozconfig
>+        self.scratchboxPath = scratchboxPath
>+        self.stageUsername = stageUsername
>+        self.stageSshKey = stageSshKey
>+        self.stageServer = stageServer
>+        self.stageBasePath = stageBasePath
>+        self.stageGroup = stageGroup
>+        self.packageGlob = packageGlob
>+        self.patchRepository = None
>+        if patchRepoPath:
>+            self.patchRepository = self.getRepository(patchRepoPath)
>+        self.baseWorkDir = baseWorkDir
>+        self.objdir = objdir
>+        self.mozconfig = 'configs/%s/%s/mozconfig' % (self.configSubDir,
>+                                                      self.mozconfig)
>+
>+        assert self.platform in ('linux-arm', 'wince-arm')
>+        if self.platform == 'linux-arm':
>+            self.addLinuxBuildSteps()
>+        elif self.platform == 'wince-arm':
>+            self.addWinceBuildSteps()
>+        self.addUploadSteps()
>+
>+    def addLinuxBuildSteps(self):
>+        self.baseWorkDir = '%s/build' % self.baseWorkDir
>+        self.addStep(ShellCommand,
>+            command = 'rm -f /tmp/*_cltbld.log',
>+            description=['removing', 'logfile'],
>+            descriptionDone=['removed', 'logfile'],
>+            haltOnFailure=False,
>+            flunkOnFailure=False,
>+            warnOnFailure=False

These are all false by default, just drop them from this and the other steps.

>+        self.addStep(ShellCommand,
>+            command=['hg', 'clone', self.configRepository, 'configs'],
>+            workdir=self.baseWorkDir,
>+            description=['checking', 'out', 'configs'],
>+            descriptionDone=['checked', 'out', 'configs'],
>+            haltOnFailure=True
>+        )

I see a lot of duplicated code related to checking out the source. Please factor it somewhere common.

>diff -r e9c504ba889e steps/transfer.py
>--- a/steps/transfer.py	Thu Jan 29 16:41:34 2009 +1300
>+++ b/steps/transfer.py	Fri Jan 30 00:20:31 2009 -0800
>@@ -121,19 +121,20 @@
>                                      sshKey=sshKey,
>                                      releaseToDated=releaseToDated,
>                                      releaseToLatest=releaseToLatest,
>                                      releaseToTinderboxBuilds=releaseToTinderboxBuilds,
>                                      tinderboxBuildsDir=tinderboxBuildsDir,
>                                      dependToDated=dependToDated,
>                                      uploadCompleteMar=uploadCompleteMar,
>                                      uploadLangPacks=uploadLangPacks)
> 
>-        assert platform in ('win32', 'linux', 'macosx')
>+        if (packageGlob == None):
>+            assert platform in ('win32', 'linux', 'macosx')

I realize this works, but it really doesn't make sense. Please pass in one of the existing platforms or add a new one.


I think this still requires a bit of work, but the core logic is all there.
(Assignee)

Comment 19

10 years ago
Created attachment 359976 [details] [diff] [review]
WinceBuildFactory/MaemoBuildFactory patch

> when are we going to deploy the win32 mobile ref platform stuff onto the rest
> of our machines?

The mobile team is working towards getting rid of the patch queue for various reasons.  One reason is there are objections to enabling mq on production build slaves.  Once the patchRepository goes away we can deploy the mobile sdk on our win32 slaves.  We can install on /d at that point unless there's something preventing us that I don't know about (joduinn?).

> I think it'd be much better to do this with subclassing.

Done.

> Why do you need to work outside of the builder's directory on windows?

I think (I may be wrong, but I strongly think) the following command is one character too long for Windows' fragile little mind:

/e/builds/moz2_slave/mobile-wince-arm-dep/mozilla-central/objdir/xulrunner/dist/sdk/bin/arm-wince-link [snip long cmdln argument list for legibility]

I say possibly one character because arm-wince-res and arm-wince-gcc commands finish successfully.  We're definitely within 7 characters of the limit, however, because moving /e/builds/moz2_slave to /e/moz2_slave fixes this.  Renaming the builddir from mobile-wince-arm-dep to wince-arm-dep also fixes this.

I'm doing the latter since it's less of a footprint (i.e. won't require changing the buildbot.tac on every single win32 build slave), and since 'wince' implies 'mobile'.  Moving moz2_slave to /e/moz2_slave could give us even more headroom if needed in the future.

> These are all false by default, just drop them from this and the other steps.

These were necessary for bare 'hg clone repository' commands; if the repository was previously cloned, this would error out and turn the tinderbox red.

However, by checking if the directory exists before running hg clone, the step no longer fails.  Removed.

> I see a lot of duplicated code related to checking out the source. Please
factor it somewhere common.

Done.  The patchRepository steps makes this a bit more complicated, but once the patch queue is retired we can remove that code.

> I realize this works, but it really doesn't make sense. Please pass in one of
> the existing platforms or add a new one.

I think it makes sense:  MozillaStageUpload only uses platform to hack a default packageGlob afaict.  But I'm not tied to it.  I'm passing win32 for wince-arm and linux for linux-arm now.

patch 1 of 2.
Attachment #359718 - Attachment is obsolete: true
Attachment #359976 - Flags: review?(bhearsum)
(Assignee)

Comment 20

10 years ago
Created attachment 359977 [details] [diff] [review]
buildbot-configs patch using WinceBuildFactory/MaemoBuildFactory
Attachment #359719 - Attachment is obsolete: true
Attachment #359977 - Flags: review?(bhearsum)
(In reply to comment #19)
> Created an attachment (id=359976) [details]
> WinceBuildFactory/MaemoBuildFactory patch
> 
> > when are we going to deploy the win32 mobile ref platform stuff onto the rest
> > of our machines?
> 
> The mobile team is working towards getting rid of the patch queue for various
> reasons.  One reason is there are objections to enabling mq on production build
> slaves.  Once the patchRepository goes away we can deploy the mobile sdk on our
> win32 slaves.  We can install on /d at that point unless there's something
> preventing us that I don't know about (joduinn?).
> 
Ok, that sounds fine. I totally agree w.r.t mq on production machines. We can leave the experimental VMs how they are, but we'll need to adjust the paths when we install VC on /d.

> I'm doing the latter since it's less of a footprint (i.e. won't require
> changing the buildbot.tac on every single win32 build slave), and since 'wince'
> implies 'mobile'.  Moving moz2_slave to /e/moz2_slave could give us even more
> headroom if needed in the future.
> 

Sounds good.

> > These are all false by default, just drop them from this and the other steps.
> 
> These were necessary for bare 'hg clone repository' commands; if the repository
> was previously cloned, this would error out and turn the tinderbox red.
> 
> However, by checking if the directory exists before running hg clone, the step
> no longer fails.  Removed.
> 
Yeah, sorry. I forgot to check ShellCommand/Mercurial when I was looking at defaults.


I'll review this patches shortly.
Comment on attachment 359976 [details] [diff] [review]
WinceBuildFactory/MaemoBuildFactory patch

Looks fine
Attachment #359976 - Flags: review?(bhearsum) → review+
Comment on attachment 359977 [details] [diff] [review]
buildbot-configs patch using WinceBuildFactory/MaemoBuildFactory

>+wince_arm_dep_factory = WinceBuildFactory(
>+    hgHost = HGHOST,
>+    repoPath = 'mozilla-central',
>+    configRepoPath = CONFIG_REPO_PATH,
>+    configSubDir = CONFIG_SUBDIR,
>+    mozconfig = "wince/mobile-browser/nightly",
>+    stageUsername = STAGE_USERNAME,
>+    stageGroup = STAGE_GROUP,
>+    stageSshKey = STAGE_SSH_KEY,
>+    stageServer = STAGE_SERVER,
>+    stageBasePath = STAGE_BASE_PATH,
>+    packageGlob = "xulrunner/dist/*.zip mobile/dist/*.zip",
>+    mobileRepoPath = 'mobile-browser',
>+    patchRepoPath = 'users/blassey_mozilla.com/wince-patches',
>+    platform = 'wince-arm',
>+    baseWorkDir = ".",
>+    buildToolsRepoPath = BUILD_TOOLS_REPO_PATH,
>+    buildSpace = 0

Any reason not to set a proper buildSpace value?

Looks fine otherwise.

Updated

10 years ago
Attachment #359977 - Flags: review?(bhearsum) → review+
Comment on attachment 359977 [details] [diff] [review]
buildbot-configs patch using WinceBuildFactory/MaemoBuildFactory

per IRC, we'll set buildSpace for the win32 builds when they move onto production machines
Comment on attachment 359976 [details] [diff] [review]
WinceBuildFactory/MaemoBuildFactory patch

changeset:   185:8a945f301a98
Attachment #359976 - Flags: checked‑in+
Comment on attachment 359977 [details] [diff] [review]
buildbot-configs patch using WinceBuildFactory/MaemoBuildFactory

changeset:   718:0271d3dc6863
Attachment #359977 - Flags: checked‑in+
(Assignee)

Comment 27

10 years ago
Created attachment 360181 [details] [diff] [review]
mozconfig: s/topsrcdir/TOPSRCDIR/g

Oops -- looks like my mozconfigs in the patch were slightly stale.

wince builds are now working successfully, with this patch.
Attachment #360181 - Flags: review?(bhearsum)

Updated

10 years ago
Attachment #360181 - Flags: review?(bhearsum) → review+
(Assignee)

Updated

10 years ago
Depends on: 478265
(Assignee)

Comment 28

10 years ago
Created attachment 362787 [details] [diff] [review]
VS9 buildbot configs patch

These patches do the following:

1) enable VS9 builds
2) disable patch queue steps
3) create and upload cab files
4) add a nightly scheduler

The build slaves list for production isn't complete; I think we should add to the list as we roll out VS9.  When VS9 is fully rolled out we can remove and nuke the experimental VMs.

Works in staging.  Patch one of two.
Attachment #360181 - Attachment is obsolete: true
Attachment #362787 - Flags: review?(bhearsum)
(Assignee)

Comment 29

10 years ago
Created attachment 362788 [details] [diff] [review]
VS9 buildbotcustom patch

Updates to factory.py
Attachment #362788 - Flags: review?(bhearsum)
Comment on attachment 362787 [details] [diff] [review]
VS9 buildbot configs patch

>diff -r 5bb75f072a3e mozilla2-staging/mobile_config.py

>+wince_dep_env = mobile_config.wince_arm_env.copy()
>+wince_dep_env['TOPSRCDIR'] = '/e/builds/moz2_slave/wince-arm-dep/mozilla-central'

Why are you setting this here and not in mobile_config.py?

This looks fine otherwise.

Updated

10 years ago
Attachment #362788 - Flags: review?(bhearsum) → review+
Comment on attachment 362788 [details] [diff] [review]
VS9 buildbotcustom patch

>diff -r 96bec7fadee3 process/factory.py

>@@ -2140,19 +2113,19 @@
>             username=self.stageUsername,
>             milestone=self.mobileBranchName,
>             remoteHost=self.stageServer,
>             remoteBasePath=self.stageBasePath,
>             platform=platform,
>             group=self.stageGroup,
>             packageGlob=self.packageGlob,
>             sshKey=self.stageSshKey,
>             uploadCompleteMar=False,
>-            releaseToLatest=True,
>+            releaseToLatest=self.nightly,
>             releaseToDated=False,

Please releaseToDated for nightlies, too. 

Glad to see the mq stuff being dropped - r=bhearsum with that change.
(Assignee)

Comment 32

10 years ago
Created attachment 362921 [details] [diff] [review]
VS9 buildbot configs patch 2

Moved the wince_dep_env and wince_nightly_env settings to mobile_config.py; otherwise unchanged.

For factory.py, releaseToDated=self.nightly would work.
Attachment #362787 - Attachment is obsolete: true
Attachment #362921 - Flags: review?(bhearsum)
Attachment #362787 - Flags: review?(bhearsum)

Updated

10 years ago
Attachment #362921 - Flags: review?(bhearsum) → review+
Comment on attachment 362788 [details] [diff] [review]
VS9 buildbotcustom patch

changeset:   199:337119db4774
Attachment #362788 - Flags: checked‑in+

Updated

10 years ago
Attachment #362921 - Flags: checked‑in+
Comment on attachment 362921 [details] [diff] [review]
VS9 buildbot configs patch 2

changeset:   954:a809f6525165
the master has been restarted for the two latest patches.
(Assignee)

Comment 36

10 years ago
Created attachment 363392 [details] [diff] [review]
nightly tinderbox, add moz2-win32-slave22/23, change mozconfig for dougt

Ok.  Things are looking good.

Doug just asked me to update the mozconfig.
Also, nightly builders aren't showing up on the Mobile tinderbox page.
Also also, I'm adding moz2-win32-slave22 and 23 to the list of wince builders since they have VS9 installed.

I think I'll close this bug after this patch goes through and open up another for pushing VS9 onto the rest of the win32 slaves... we may be able to roll out VS9 and the win32 reboot changes at the same time.
Attachment #363392 - Flags: review?(bhearsum)
Comment on attachment 363392 [details] [diff] [review]
nightly tinderbox, add moz2-win32-slave22/23, change mozconfig for dougt

Looks fine to me
Attachment #363392 - Flags: review?(bhearsum) → review+
(Assignee)

Updated

10 years ago
Depends on: 479515
(Assignee)

Comment 38

10 years ago
[14:24]	<ted>	aki: presumably, if you put your mozconfigs in hg in the buildbot-configs repo, developers can update them when needed
	which is the best option
[14:25]	<aki>	oh, ok
	they're there
[14:27]	<ted>	anyone with hg access can push to buildbot-configs

removing mozconfig.wince dependency.
No longer depends on: 479515
(Assignee)

Comment 39

10 years ago
Created attachment 363398 [details] [diff] [review]
as above, with win32 slave22+23 in prod config.py

we'll need to update BuildSlaves.py too.
Attachment #363392 - Attachment is obsolete: true
Attachment #363398 - Flags: review?(bhearsum)
(Assignee)

Comment 40

10 years ago
Comment on attachment 363398 [details] [diff] [review]
as above, with win32 slave22+23 in prod config.py

obsoleting; i'll add more slaves in the next patch.
Attachment #363398 - Attachment is obsolete: true
Attachment #363398 - Flags: review?(bhearsum)
(Assignee)

Comment 41

10 years ago
Created attachment 363726 [details] [diff] [review]
mobile_slaves + 10 vs9 slaves + above

Ok.  This patch:

 - adds moz2-linux-slave18 and 19 to the production pool (+ linux-arm builds) for bug 477182
 - adds moz2-win32-slave22 and 23 to the production pool (+ win32-arm builds) for bug 477178
 - pulls the mobile slave list from mobile_master.py to mobile_config.py.  This isn't anywhere near as complex as config.BRANCHES yet.  If/when we need to support multiple mobile branches and environments we'll probably need to go that route.
 - adds the 10 win32 build slaves that now have VS9 installed to the win32-arm pool.
 - adds the linux-arm and wince-arm nightly builds to the Mobile tinderbox waterfall.
 - updates the wince mozconfig per discussions on #mobile.
Attachment #363726 - Flags: review?(bhearsum)
Comment on attachment 363726 [details] [diff] [review]
mobile_slaves + 10 vs9 slaves + above

>diff -r 2f7bb2d3fef2 mozilla2-staging/mobile_config.py
>+    'wince-arm': [
>+        'mobile-win32-experiment01',
>+        'mobile-win32-experiment02',
>+        'moz2-win32-slave13',
>+        'moz2-win32-slave14',
>+        'moz2-win32-slave15',
>+        'moz2-win32-slave16',
>+        'moz2-win32-slave17',
>+        'moz2-win32-slave18',
>+        'moz2-win32-slave19',
>+        'moz2-win32-slave20',
>+        'moz2-win32-slave22',
>+        'moz2-win32-slave23',

I guess 21 and 1-12 aren't setup yet?
Comment on attachment 363726 [details] [diff] [review]
mobile_slaves + 10 vs9 slaves + above

As per IRC, the aforementioned slaves are not setup yet. r=bhearsum, in that case.
Attachment #363726 - Flags: review?(bhearsum) → review+
Comment on attachment 363726 [details] [diff] [review]
mobile_slaves + 10 vs9 slaves + above

changeset:   959:1feecd1ae3e4
Attachment #363726 - Flags: checked‑in+
Aki,

I've imported the two MSIs needed into the mofo repo for future usage:
Checking in wm6-pro-sdk.msi;
/mofo/ref-platforms/win32/wm6-pro-sdk.msi,v  <--  wm6-pro-sdk.msi
initial revision: 1.1
done
RCS file: /mofo/ref-platforms/win32/wm6.1-pro-images.msi,v
done
Checking in wm6.1-pro-images.msi;
/mofo/ref-platforms/win32/wm6.1-pro-images.msi,v  <--  wm6.1-pro-images.msi
initial revision: 1.1
done

I'm also in the process of downloading the VS2008 VM to one of our datastores (/vmfs/volumes/netapp-c-001/iso-images) for easier installation in the future.

I've updated the ref platform doc for both of these changes.
(Assignee)

Comment 46

10 years ago
Created attachment 364350 [details] [diff] [review]
add remaining moz2-win32 slaves; retire mobile-win32-experiment slaves

This should hopefully be the final patch.
Attachment #364350 - Flags: review+
(Assignee)

Updated

10 years ago
Attachment #364350 - Flags: review+ → review?(bhearsum)
(Assignee)

Comment 47

10 years ago
Comment on attachment 364350 [details] [diff] [review]
add remaining moz2-win32 slaves; retire mobile-win32-experiment slaves

oops.

Updated

10 years ago
Attachment #364350 - Flags: review?(bhearsum) → review+
Comment on attachment 364350 [details] [diff] [review]
add remaining moz2-win32 slaves; retire mobile-win32-experiment slaves

yay!
(Assignee)

Updated

10 years ago
Attachment #364350 - Flags: checked‑in+
(Assignee)

Comment 49

10 years ago
Comment on attachment 364350 [details] [diff] [review]
add remaining moz2-win32 slaves; retire mobile-win32-experiment slaves

Changeset:  964:3d87831f92d5
(Assignee)

Comment 50

10 years ago
done.
Status: NEW → RESOLVED
Last Resolved: 10 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.