Releases/Thunderbird 17.0.2esr/BuildNotes

From MozillaWiki
< Releases
Revision as of 15:41, 7 January 2013 by Bhearsum (talk | contribs)
Jump to navigation Jump to search

Build 1

Checklist

Notes

  • Submitted to ship-it-dev.allizom.org
  • Rail reviewed + ran release runner.
  • Release sanity failed, complaining about mozconfigs:
2013-01-04 15:47:25,315 : INFO : Comparing thunderbird mozconfigs to nightly mozconfigs...
2013-01-04 15:47:27,749 : ERROR : found in mail/config/mozconfigs/macosx-universal/esr but not in mail/config/mozconfigs/macosx-universal/nightly: export MOZ_ESR=1
2013-01-04 15:47:30,044 : ERROR : found in mail/config/mozconfigs/win32/esr but not in mail/config/mozconfigs/win32/nightly: export MOZ_ESR=1
2013-01-04 15:47:32,342 : ERROR : found in mail/config/mozconfigs/linux64/esr but not in mail/config/mozconfigs/linux64/nightly: export MOZ_ESR=1
2013-01-04 15:47:34,864 : ERROR : found in mail/config/mozconfigs/linux32/esr but not in mail/config/mozconfigs/linux32/nightly: export MOZ_ESR=1
2013-01-04 15:47:34,864 : ERROR : Error verifying mozconfigs

This is due to the mozconfig patch from bug 811770. Standard8 was long gone, so I did the simple thing and put 'export MOZ_ESR=1' into the nightly mozconfigs (https://hg.mozilla.org/releases/comm-esr17/rev/2afbc44b8134). I updated the submission to ship-it, and the release started fine after that.

Fix failed tagging

Tagging failed when trying to push to hg because the path to the ssh key was wrong due to the mock switch. This patch was landed and buildbot-configs was retagged to fix: https://bug815763.bugzilla.mozilla.org/attachment.cgi?id=698068. After that, rebuilt the tagging builder. After it completed, forced source, en-US builds, and bouncer submitter (because tagging downstreams don't fire correctly after a rebuild.

Because of rebuilding tag instead of re-doing sendchanges, all repacks are failing because "script_repo_revision" isn't set. These can be fixed by forcing the failed builders and setting a "script_repo_revision" property to the release tag (eg, FIREFOX_18_0_RELEASE). I've done this for all failed repacks that I've seen. (Though, some have additional problems, see below for details).

Win32 build failed

Win32 build failed with what looks like a path-length-too-long problem ("bad file number"). I couldn't figure out what to shorten in the directory path that didn't seem incredibly risky to do. Not sure what to do here. The nightly build dir has 13 chars in it ("tb-c-esr17-w32") and the release one has 21 ("tb-rel-c-esr17-w32-bld").

Attempt #1: Shorten "esr" to "e". Landed this patch: https://hg.mozilla.org/build/buildbotcustom/rev/34f58aaf3ad7, reconfiged the build masters, and rebuilt the win32_build. Trying this first because I'm scared of wide sweeping changes if I touch the tb- prefix or other parts of the path. Checked some logs after restarting the build and noticed that it didn't even shorten the path. No idea way.

Attempt #2: Hardcode a very short directory name for this specific builder: https://hg.mozilla.org/build/buildbotcustom/rev/6c60d3bc6fd7. I verified that this actually shortened the path with dump-master.py. I then pushed the patch, retagged, reconfiged the build masters, and restarted the build. In the logs I see " in dir e:\builds\moz2_slave\zzz\build", so if the path length is the problem, this should fix the issue.

Attempt #2 succeeded. Had to do the script_repo_revision fix for the subsequent repacks, just like the other platforms.

Linux repacks failed

Linux repacks failing with "cannot create executable" during configure. I suspect this is related to mock, wasn't able to look into it. Catlee and jhopkins landed this patch and retriggered the builds to fix them: https://hg.mozilla.org/build/buildbot-configs/rev/e8b7870b1d96

Build 2

Checklist