Revert MAR generation to old format for 56.0b1

RESOLVED WONTFIX

Status

Release Engineering
Releases
RESOLVED WONTFIX
7 months ago
6 months ago

People

(Reporter: catlee, Unassigned)

Tracking

unspecified
Dependency tree / graph

Firefox Tracking Flags

(firefox56+ wontfix, firefox57 unaffected)

Details

(Whiteboard: [qf:?])

(Reporter)

Description

7 months ago
We need to land patches to mozilla-beta after 56 merges to force it to generate old format MARs for 56.0b1.
This is because 55.0 and older clients expect the old compression. Once they have 56.0b1 they have an updater which knows the new compression, so 56.0b2 should generate mars for that. And we have a watershed so everyone updates old -> 56.0b1 -> glorious future. DevEd will need a watershed too, I expect.

And we'll need to do this for 56.0 on release too.
To do this the following from bug 1385780 will need to be backed out on beta and then relanded after the mar files are generated.

https://hg.mozilla.org/mozilla-central/rev/f632eede0f19
Update mar file generation scripts for lzma. r=bhearsum, r=rail, a=app_update_lzma
https://hg.mozilla.org/mozilla-central/rev/bbd46c077793
Update mar file generation scripts for lzma. r=bhearsum
https://hg.mozilla.org/mozilla-central/rev/7f9ed540c827
New mar convertor script to convert a mar file from bzip2 to lzma and from lzma to bzip2. r=bhearsum, a=app_update_lzma
https://hg.mozilla.org/mozilla-central/rev/87824406b9fe
sign mar files using the sha384 certificate. r=bhearsum, a=app_update_sha384
Would prefer to hold off on this until there's been a chance to clean up post-merge Beta a bit, but will definitely keep it on the radar to get done before Monday's 56.0b1 GTB.
status-firefox56: --- → affected
status-firefox57: --- → unaffected
tracking-firefox56: --- → ?
Yeah, was just about to post too, that I tried to backout these right after finishing the merge but ended up with various conflicts and refrained myself since that looked suspicious. 

For example https://hg.mozilla.org/releases/mozilla-beta/diff/f632eede0f19/tools/update-packaging/unwrap_full_update.pl is not the same https://hg.mozilla.org/releases/mozilla-beta/file/tip/tools/update-packaging/unwrap_full_update.pl so pretty sure there's some other stuff laying around.
The changesets listed in comment 2 are in the order they landed so they need to be backed out in reverse order like so
hg backout 87824406b9fe
hg backout 7f9ed540c827
hg backout bbd46c077793
hg backout f632eede0f19

I did this with my beta repo without issue and ran diff -rq against the beta and release repos' tools/update-packaging/ directories which showed the files were the same so it was successful.
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #5)
> The changesets listed in comment 2 are in the order they landed so they need
> to be backed out in reverse order like so
> hg backout 87824406b9fe
> hg backout 7f9ed540c827
> hg backout bbd46c077793
> hg backout f632eede0f19
> 
> I did this with my beta repo without issue and ran diff -rq against the beta
> and release repos' tools/update-packaging/ directories which showed the
> files were the same so it was successful.

Makes sense, mea culpa.

Comment 7

7 months ago
Track 56+ as this is needed for 56.0b1.
tracking-firefox56: ? → +
Do these changes need to be backed out, or could MAR_OLD_FORMAT just be set in appropriate mozconfigs for the first beta build?
As you found out the other day setting this in a mozconfig won't work.

Also see bug 1387231 for the current plan for beta 1 and 2
We are taking a different route and bug 1387231 supersedes this bug.
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WONTFIX
status-firefox56: affected → wontfix
You need to log in before you can comment on or make changes to this bug.