The remaining omnijar code for Firefox, bug 556644, will probably land today or tomorrow, but not turned on by default. Before or as we flip the switch to turn it on by default, I want to get some of the riskier bits of releng-related work tested: * nightly l10n repacks * release l10n repacks (Axel says these use a different codepath than nightlies) * partial and complete updates * partial and complete localized updates I'm happy to land the final "turn on omnijar" patch in some repository (e10s, or one of the twigs). I don't know exactly the best way to get these codepaths tested: maybe a dry-run beta4?
We're ready to test this. How should we proceed?
removed-files.in should be updated once more before testing. Turning on sync and tabcandy added a bunch of new files which will end up in the omnijar.
Saw that as well and agree wholeheartedly.
omnijar was turned on on trunk, so the real nightlies are the test ground, wheee! still should do a staging release well before b5, though.
Real nightlies said no. :-(
The issues found last night have fixes. Will be able to stage something or are we going to try it on m-c again?
I'll try to do a nightly staging run today. Can someone create a user repository with the code you want built?
Axel just told me I'm too late, and that they failed again. I suggest that we block turning it on in nightlies on getting a successful staging run done.
It's been on in nightlies for a while now, and AFAIK the nightly repacks are fine. We still need to validate the release repacks, though.
Yep, nightlies are fine.
Starting on a staging release run now, will report results back as soon as I have them.
The first repacks have gone green (32-bit Linux), so so far so good. I need to see the rest of the platforms, and get as far as updates and update_verify to declare things 100% ready. It's late in the day already, and won't be able to finish this until tomorrow morning.
So far so good. Repacks on all platforms succeeded, signing succeeded. I've put the de builds for all platforms here for someone to take a look at: http://people.mozilla.org/~bhearsum/misc/Firefox%204.0%20Beta%205%2032-bit%20de.dmg http://people.mozilla.org/~bhearsum/misc/Firefox%204.0%20Beta%205%2064-bit%20de.dmg http://people.mozilla.org/~bhearsum/misc/Firefox%20Setup%204.0%20win32%20de.exe http://people.mozilla.org/~bhearsum/misc/firefox-4.0b5.de.i686.tar.bz2 http://people.mozilla.org/~bhearsum/misc/firefox-4.0b5.tar.bz2 (64-bit linux) Running l10n verify / updates / update_verify now.
Update generation went without a hitch. Update verify had lots of spew, most of it ignorable, but one major item of concern: - On Windows l10n builds, omni.jar differed between a b4 build that was updated with a complete MAR and the one found in the installer. This happens because the complete MAR on Windows is built out of the .zip, not the installer (bug 313956). The implications of shipping with this are that partial updates would always fail for anyone who installed their current build through the installer. The next update for these people would successfully apply the partial update. I don't think we should ship this problem. Here's the details of the ignorable spew - removed-files.in needs to be updated (bug 592314) - Lots of empty directory differences: Contents of source/firefox/defaults dir only in source or target 1382789 4 drwxr-xr-x 2 cltbld cltbld 4096 Aug 31 09:58 source/firefox/defaults/pref 1382796 4 drwxr-xr-x 2 cltbld cltbld 4096 Aug 31 09:58 source/firefox/defaults/autoconfig 1382781 4 drwxr-xr-x 3 cltbld cltbld 4096 Aug 31 09:58 source/firefox/defaults/profile 1382785 4 drwxr-xr-x 2 cltbld cltbld 4096 Aug 31 09:58 source/firefox/defaults/profile/chrome Contents of source/firefox/modules dir only in source or target 1382708 4 drwxr-xr-x 6 cltbld cltbld 4096 Aug 31 09:58 source/firefox/modules/services-sync 1382709 4 drwxr-xr-x 2 cltbld cltbld 4096 Aug 31 09:58 source/firefox/modules/services-sync/type_records 1382736 4 drwxr-xr-x 2 cltbld cltbld 4096 Aug 31 09:58 source/firefox/modules/services-sync/engines 1382717 4 drwxr-xr-x 2 cltbld cltbld 4096 Aug 31 09:58 source/firefox/modules/services-sync/ext 1382723 4 drwxr-xr-x 2 cltbld cltbld 4096 Aug 31 09:58 source/firefox/modules/services-sync/base_records 1382703 4 drwxr-xr-x 2 cltbld cltbld 4096 Aug 31 09:58 source/firefox/modules/tabview Contents of source/firefox/res dir only in source or target 1382648 4 drwxr-xr-x 2 cltbld cltbld 4096 Aug 31 09:58 source/firefox/res/dtd 1382665 4 drwxr-xr-x 2 cltbld cltbld 4096 Aug 31 09:58 source/firefox/res/fonts 1382675 4 drwxr-xr-x 2 cltbld cltbld 4096 Aug 31 09:58 source/firefox/res/html 1382640 4 drwxr-xr-x 2 cltbld cltbld 4096 Aug 31 09:58 source/firefox/res/entityTables As well as defaults, modules, and res. That's normal when we remove a directory, though. The $locale.jar was noted as missing.
(In reply to comment #14) > - On Windows l10n builds, omni.jar differed between a b4 build that was updated > with a complete MAR and the one found in the installer. This happens because > the complete MAR on Windows is built out of the .zip, not the installer (bug > 313956). The implications of shipping with this are that partial updates would > always fail for anyone who installed their current build through the installer. > The next update for these people would successfully apply the partial update. I > don't think we should ship this problem. > Fixes for the .chk and omni.jar timestamp problems has landed. We want partial updates fixed, right? I'll land these patches on the beta5 branch later tonight if that's alright. nthomas mentioned the locale jar isn't getting removed. I think we can take care of that issue later since it isn't getting loaded and is a side-effect of bug 579178, not omnijar.
Nothing here requires a respin, right?
The two fixes have been landed on the beta5 branch.
(In reply to comment #16) AIUI no, but it would make b6 a smoother if they were ride-alongs for a respin. To sum up where I got to after looking at l10n and update verification tests: * both issues affect windows only * the chk files differing between en-US and locales (bug 592457) should not cause any issues. They should still be valid checksum files for verifying the NSS DLLs for FIPS mode, they just differ from the en-US copies. We force those files on updates, so there should be no issues updating to, or from, 4.0b4/5. * omni.jar differing between installer and complete mar (bug 592369) is a trivial difference in the timestamps of the files inside the jar, not the content of the files. It may cause some issues for updates. A 4.0b4 user updating to b5 will update to b6 without issue. Anyone installing 4.0b5 build1 will have a different omni.jar and will fail to apply the partial update to 4.0b6, failing over to the complete. We could force omni.jar in the partial to b6, at the cost of a 3 to 4MB larger partial for _all_ users; or let anyone installing win32 b5 fail over to the complete. We can't offer different updates to those users, no way to distinguish them via the AUS query.
I think we're all done with this bug. The three dep bugs were found between this and the real run of beta 5. We should do a full beta 6 staging run well in advance of that release, too.