Releases/Thunderbird 17.0.2esr/BuildNotes

From MozillaWiki
Jump to: navigation, 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

Build 3

Because of bug 826567

Checklist

Notes

Had to backout all of the Mock stuff. This happened in the following revs:

Also had to set the relbranch for this release, so that we got the right revs:

After that, submitted to release runner, jhopkins reviewed it, and I ran release runner.

No updates

Noticed that updates never ran. Turns out this is because we didn't have the template block for partials set. bug 827458

Push to mirrors

Used "force build" to start the push to mirrors builder.

This should've happened automatically, filed bug 827858 for that.

Manually ready for releasetest / almost ready for release

Although "start_uptake_monitoring" ran, it never seemed to notice that this release had enough uptake to proceed. I'm guessing that this scheduler doesn't work correctly when there's no updates. FILEME. Also noticed that we don't get final verification builders when we have no updates FILEME.

Run postrelease

Used "force build" to run postrelease builder. To work around this, manually verified that we had enough uptake through bounceradmin.mozilla.com, then triggered "ready for releasetest testing" and "almost ready for release" builders. "ready for release" fired automatically after this.