staging run of release l10n repacks with omnijar

RESOLVED FIXED

Status

Release Engineering
General
--
major
RESOLVED FIXED
7 years ago
4 years ago

People

(Reporter: Benjamin Smedberg, Assigned: bhearsum)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 beta5+)

Details

(Reporter)

Description

7 years ago
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?

Comment 1

7 years ago
We're ready to test this. How should we proceed?

Comment 2

7 years ago
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.
(Assignee)

Comment 4

7 years ago
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.
Summary: Staging run of nightly and release l10n repacks with omnijar → Staging run of release l10n repacks with omnijar
(Reporter)

Updated

7 years ago
blocking2.0: --- → beta5+
Real nightlies said no. :-(
Severity: normal → major
Summary: Staging run of release l10n repacks with omnijar → Staging run of nightly and release l10n repacks with omnijar

Comment 6

7 years ago
The issues found last night have fixes. Will be able to stage something or are we going to try it on m-c again?
(Assignee)

Comment 7

7 years ago
I'll try to do a nightly staging run today. Can someone create a user repository with the code you want built?
Assignee: nobody → bhearsum
(Assignee)

Comment 8

7 years ago
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.
Summary: Staging run of nightly and release l10n repacks with omnijar → staging run of release l10n repacks with omnijar

Comment 10

7 years ago
Yep, nightlies are fine.
(Assignee)

Comment 11

7 years ago
Starting on a staging release run now, will report results back as soon as I have them.
(Assignee)

Comment 12

7 years ago
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.
(Assignee)

Comment 13

7 years ago
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.
(Assignee)

Comment 14

7 years ago
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.

Updated

7 years ago
Depends on: 592369

Updated

7 years ago
Depends on: 592457

Comment 15

7 years ago
(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?

Comment 17

7 years ago
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.
(Assignee)

Comment 19

7 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Depends on: 592574
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.