Closed Bug 504150 (SM2.0b1) Opened 11 years ago Closed 11 years ago

tracking bug for build and release of SeaMonkey 2.0 Beta 1

Categories

(SeaMonkey :: Release Engineering, defect, critical)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.0b1

People

(Reporter: kairo, Assigned: kairo)

References

()

Details

No description provided.
Flags: blocking-seamonkey2.0b1+
Depends on: 504151
Depends on: 504152
Depends on: 504153
Depends on: 504155
Depends on: 504165
Depends on: 493451
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
Depends on: 504791
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.
It's released.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Component: Project Organization → Release Engineering
QA Contact: organization → release
You need to log in before you can comment on or make changes to this bug.