Closed Bug 632793 Opened 9 years ago Closed 7 years ago
signing scripts should support signing partner repacks after the fact
Currently, the signing scripts have a "previously signed" mode that allows us to sign locales after the fact. This works fine for normal, unmodified repacks, but doesn't work in a case where we're signing a localized partner repack after the fact. Because we only unpack and cache "firstLocale" in previously signed mode, we still end up resigning all the localized bits of the partner repack, because only the en-US binaries are in the cache. Ideally, "previously signed" mode should detect which locales it needs to unpack and cache prior to starting to sign things.
Until this is fixed, the best way to sign partner repacks after the fact is to rebuild the cache one by one, by calling sign-release.py with --first-locale $locale --keep-cache, for each $locale that has a partner repack that needs signing. Once that's done, you can sign them with --keep-cache. bug 632627 and the 3.6.14 build notes have a concrete example of this (https://wiki.mozilla.org/Releases/Firefox_3.6.14/BuildNotes). Realistically this is low priority because it's rare that we'll hit it, and there's a workaround.
Priority: -- → P3
8 years ago
No longer blocks: 627271
8 years ago
Component: Release Engineering → Release Engineering: Releases
QA Contact: release → bhearsum
found in triage - I think this actually lives in the new "RelEng:Automation" component.
Component: Release Engineering: Releases → Release Engineering: Automation
QA Contact: bhearsum → catlee
Mass move of bugs to Release Automation component.
Component: Release Engineering: Automation (General) → Release Engineering: Automation (Release Automation)
We don't use these signing scripts anymore.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.