Bug#458153 tracked powering off this obsolete l10n xserve, as well as deleting some obsolete l10n VMs. What should we do with this idle intel-based xserve? Its currently got 10.4 installed, but we'll probably need to cleanup/reimage it anyway, to have any confidence of whats running on it after all these years, so not sure it matters whats actually on it right now. Pushing this to Future while we figure out where we need this most. To start discussions rolling, I'll propose that we re-image from one of the existing 10.5 intel-based xserves in the moz2 pool-of-slaves, and add it there as a build+unittest machine. Any other suggestions?

No other suggestions, so lets use this as a build+unittest machine. I'm taking this, and plan to reimage this machine the same way we did bm-xserve16->22.

I assume there is nothing on this machine that needs to be backed up. However, please correct me if I'm missing something, ok?

Recall that this is an older Intel xserve, and Phong has had trouble trying to put the image from the newer xserves on them.

Glad it worked even if we don't know why the cloning is inconsistent. We'll have to figure out what needs doing from https://wiki.mozilla.org/ReferencePlatforms/Mac-10.5 still, as the bm-xserve16 image is quite old and doesn't contain any unittest tweaks (like additional fonts).

(In reply to comment #4) > Glad it worked even if we don't know why the cloning is inconsistent. We'll > have to figure out what needs doing from > https://wiki.mozilla.org/ReferencePlatforms/Mac-10.5 > still, as the bm-xserve16 image is quite old and doesn't contain any unittest > tweaks (like additional fonts). Lukas/Catlee: when you were rolling out the build-and-unittest consolidation work, did you refresh the bm-xserve16 ref image, or is this out of date?

(In reply to comment #5) > (In reply to comment #4) > Lukas/Catlee: when you were rolling out the build-and-unittest consolidation > work, did you refresh the bm-xserve16 ref image, or is this out of date? Lukas/Catlee: gentle ping? Hoping to confirm one-way-or-another if imaging from bm-xserve16 is ok, or do we need to reimage from bm-xserve22 as wiki doc says? (Putting this back in the pool, as I wont get time to do this before vacations this week.)

I don't recall what needed to be done, if anything, to bm-xserve16 in particular. I remember two issues on the Macs that we did run into: - Correct fonts being installed. We fixed this by doing an rsync from one of the other machines - Dock size being too large. This was fixed by the workaround mentioned in bug #470420

Nick kindly volunteered to do this.

I've worked through the Ref Platform doc https://wiki.mozilla.org/ReferencePlatforms/Mac-10.5 to bring this up to date. In particular I had to * update to XCode 3.1 (updated doc with sha1sum) * put chown_revert/root in ~/bin (updated doc for new location) * Added hg.m.o to list of sites to accept ssh fingerprint * Remove /tools/buildbot and buildbot-trunk; pull buildbot 0.7.9 from hg and install * Copy in missing fonts from bm-xserve16 * Set the dock size * Create autoconf symlink Also running mercurial 1.2.1 to test that, and rejigged the ref doc to be more in the style of Linux & Windows (better history, what's on the image, what you have to do). This box is running on staging now (config change was done on bug bug 480203). Still need to set the slave-start-on-boot stuff from bug 428124.

Buildbot start on boot is setup now. This box is pretty much ready to go over to production, it's failing some unit tests but in the same ways as other staging boxes and otherwise green.

This machines has mercurial 1.2.1 (instead of 0.9.5 of the older builders). Bug 488580 for the general upgrade.

Comment on attachment 372747 [details] [diff] [review] Add bm-xserve12 to production master committed changeset 1094:9cda46e58802 including a fix to the staging config where I'd missed the debug case, which catlee spotted. Reconfig'd production-master so that bm-xserve12 can go to production when it's finished on the try server.

This machine went over to try to help clear the backlog and then into the main moz2 pool.