Releases/Firefox 3.5.2/BuildNotes
Build Engineers
nthomas, bhearsum
Signed-off Revision(s)
Build1: 7a9fe7dfac8a
Tags
On releases/mozilla-1.9.1:
Build # | Tag | Changeset |
1 | GECKO1912_20090729_RELBRANCH | 7a9fe7dfac8a |
FIREFOX_3_5_2_BUILD1, FIREFOX_3_5_2_RELEASE | Was:b8dbd5ab1647 Became:d57f05bcdbe1 |
Build data
Type | Build ID | Build machine |
[Windows installer/zip] | ||
[Mac compressed] | ||
[Linux compressed] |
Notes
Build 1
- Cleaned up previous releases' build dirs
- l10n-changesets updated in bug 505129
- Land version bump, reconfig production-master
- Kick-off automation:
buildbot sendchange --username=nthomas --master=localhost:9010 --branch=releases/mozilla-1.9.1 -m "Firefox 3.5.2 build1" goforit
Tag
No problems with tag (see below for where it got moved)
Source
No problems
Build/Repack
Had to remove en-US.xpi manually from stage FIXME No problems generating en-US builds, but linux locales started failing in the make_installers_locale step after generating tar.bz2 and complete.mar:
/tools/python/bin/python ../../tools/update-packaging/generatesnippet.py \ --mar-path=/builds/moz2_slave/linux_repack/build/mozilla-1.9.1/dist/update \ --application-ini-file=/builds/moz2_slave/linux_repack/build/mozilla-1.9.1/dist/l10n-stage/firefox/application.ini \ --locale=or \ --product=Firefox \ --download-base-URL= \ --verbose /tools/python/bin/python: can't open file '../../tools/update-packaging/generatesnippet.py': [Errno 2] No such file or directory
This is fallout from a bad merge in bug 489313, as generatesnippet.py did not land on mozilla-1.9.1. Mac also hit it because it's not platform-dependent.
Recovery
- did a no-op reconfig on master to prevent win32 repacks from starting
- Fix was landed on the relbranch and default, and the two tags moved up to d57f05bcdbe1
- automation patched to disable tag and en-US builds
- cleaned up mac and linux slaves of repack dirs and source
- submitted another sendchange
Mac repacks were broken because of bug 489313. Root cause hasn't been determined yet, see below for fixup.
mac repack rerun
- Backed out bug 489313 on the release branch and moved the _BUILD1 and _RELEASE tags up.
- cleaned up the macosx_repack slave
- Deleted all l10n builds in .../build1/mac and ../build1/update/mac on stage.
- Landed this patch, updated the master and reconfiged
- Did another sendchange
no problems with the re-run still need to regenerate asc files for them
win32 repack rerun
Don't need to land anything in mozilla-1.9.1 because the backout we did for mac will suffice
- cleaned up the win32_repack slaves
- Moved all l10n builds in .../build1/unsigned/win32, .../build1/unsigned/update/win32, .../build1/update/win32, .../build1/win32 to ~ffxbld/3.5.2-busted/
- Landed this patch, updated the master and reconfiged
- did another sendchange
- temporarily enabled some extra slaves (up to slave16) for win32 repacks to speed things up
- this ended up backfiring a little after removing them from the l10n slaves list before they finished building - it cause the builds running on slave11 and slave14 to hang, and they had to be kicked through manually
Sign
- Kicked off new signing on cm-keymaster01 and old style on keymaster at the same time
- new signing bailed out at verify-asc because SUMS files were not signed, but verify-asc thought they should be (FIXME). we were trying to push out signed *SUMS files this time. to save time but since we've never done it in the past, just pushed things along with unsigned *SUMS files by running the 'fake-upload' and then 'postsign' targets
signing # 2
Had to resign after win32 l10n builds were regenerated. sign-release.py was called directly to add -p argument, then worked through the following makefile targets. asc files for linux and mac were replaced.
L10nVerify
After redoing macosx locales: PASS. All locales with real changes have an updated l10n-changesets revision (got that list by doing 'hg diff -r FIREFOX_3_5_1_RELEASE -r FIREFOX_3_5_2_RELEASE mozilla2/l10n-changesets)
After redoing win32 locales:
Generate updates and push betatest snippets
- Update generation had 'WARNING' messages about not being able to find application.ini on Mac. This comes from get_buildid in make_incremental_updates.py, but we never actually use the output of that function which makes this a superfluous message. Noticed it in the 3.0.12 logs, too. bug 507405
- updates were stopped midstream after the mac problem was discovered and re-kicked with 'force build' after mac builds were fixed. this caused the 'diff patcher config' step to turn red because it expected diff output, but the config had already been bumped.
- no real problems
Update verify
- win32 update verify logs showed that the helper.exe in the installers, and the helper.exe in the MARs was different. this is also fallout from bug 489313, just like the mac problems