Closed Bug 504150 (SM2.0b1) Opened 11 years ago Closed 11 years ago
tracking bug for build and release of Sea
Monkey 2 .0 Beta 1
No description provided.
Pushed shipped-locales as http://hg.mozilla.org/comm-central/rev/48147c4781e9 Locales that opted in and ready to go for official SM2.0b1: be ca cs de en-US es-AR es-ES fr gl lt nb-NO pl ru sk tr Opted in but orange, will release as "unifinished" or not at all: hu Green on dashboard but not opted in, will release as "unifinished" or not at all: pt-PT
Source revisions to build: http://hg.mozilla.org/comm-central/rev/48147c4781e9 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1e7c406956d3 http://hg.mozilla.org/dom-inspector/rev/ef29512d86ae http://hg.mozilla.org/venkman/rev/06ea5135b7f3 chatzilla CVS timestamp: 2009-07-16 00:00 Opted in L10n revisions are in http://hg.mozilla.org/build/buildbot-configs/file/f8f80f088dad/seamonkey/l10n-changesets Starting automated build process with those revisions within the next minutes.
Tagging is complete for all repos, source tarball is uploaded, Linux en-US build just completed, win32 build is in progress, Mac is waiting for a free buildslave as well as the 16 Linux L10n repacks that are scheduled now.
The win32 build timed out running client.py checkout, I had to try buildbot's "rebuild" function for it, it's waiting for a free slave now and I hope that rebuild still triggers the L10n builds. Meanwhile, the Mac build has finally been started and the Linux L10n repacks are done, all Linux builds are now available from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2.0b1-candidates/build1/linux-i686/
OK, both win32 and Mac failed on client.py checkout because I had never accepted the ssh keys for cvs.m.o on those machines but the release harness uses ssh for CVSROOT there. Restarted the release harness with tag and source dummied out and the scheduler modified to only schedule win32 and mac for build/repack, see http://hg.mozilla.org/build/buildbot-configs/rev/802911a61e28 for how I did that.
win32 build and L10n repacks completed, builds are up at http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2.0b1-candidates/build1/unsigned/win32/ and will be copied to the toplevel win32/ directory in the "fake signing" step as outlined in https://wiki.mozilla.org/SeaMonkey:Release_Automation#Signing mac completed compiling of the build only to get stuck in the "gather build properties" step, which is a routine step for any mercurial-based buildbot build usually and I'm completely surprised by this happening here, I've never seen it. This looks very much like a buildbot-internal thing on the master, the slave likely did never even get anything to do, and it's not even counted as an actual failure by buildbot itself. It even did - uselessly as en-US wasn't uploaded - schedule L10n repacks as if everything was successful. I'll restart the release harness once again and let it schedule mac build/repack only, I hope that helps.
mac build has restarted again, I hope it finishes now.
It did another restart, but when it ran on a different slaves, it worked flawlessly. Mac builds are on http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2.0b1-candidates/build1/mac/ and updates are in the updates directory and available on the betatest channel.
Pushing builds to releases/2.0b1 directory.
Website updates pushed.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.