Closed Bug 806280 Opened 7 years ago Closed 7 years ago

l10n stub installers on latest-mozilla-aurora-l10n and latest-mozilla-central-l10n need to be signed builds

Categories

(Release Engineering :: General, defect, P1, major)

Tracking

(firefox18+ verified, firefox19+ verified)

VERIFIED FIXED
Tracking Status
firefox18 + verified
firefox19 + verified

People

(Reporter: jsmith, Assigned: rail)

References

Details

Attachments

(1 file)

In checking the l10n stub installer builds being served on each l10n directory for aurora and nightly, I noticed that the stub installer builds are not signed, even the full installer builds are signed. We need to be consistent in making sure that the stub installer builds are also getting signed for the various l10n stub installer builds in the Aurora and Nightly directories respectively.
Blocks: 798255
Tacking on tracking 18 and 19 because we need signed l10n builds.
Assignee: nobody → catlee
It'd be great to get this working on the order of days, since QA has called this out as a test day blocker (and I tend to agree). Since we'd like to get a test day in place before FF18 (along with the l10n stub) moves to Beta mid-November, a hard deadline would probably be a week from today. Jason - let me know if that lines up with your expectations.
Assignee: catlee → rail
(In reply to Alex Keybl [:akeybl] from comment #2)
> It'd be great to get this working on the order of days, since QA has called
> this out as a test day blocker (and I tend to agree). Since we'd like to get
> a test day in place before FF18 (along with the l10n stub) moves to Beta
> mid-November, a hard deadline would probably be a week from today. Jason -
> let me know if that lines up with your expectations.

Yup, that aligns with my understanding.
Severity: normal → major
Priority: -- → P1
I found a couple other issue with l10n repacks. :/

The following locales still use Firefox branding instead of Nightly.

 be
 bn-IN
 el
 en-GB
 eo
 gd
 lv
 nb-NO
 pa-IN
 ro
 te
 th
 tr
 zh-TW

At the same time the properly branded locales are around 600k vs 200k.
That's bug 804090, which _should_ be fixed for today's stub installers off of m-c.
(In reply to Chris AtLee [:catlee] from comment #5)
> That's bug 804090, which _should_ be fixed for today's stub installers off
> of m-c.

Yeah, looks like the locales with not nightly branding are built yesterday.

In any case, the bump in the file size sucks. :/

Anyways, I'm testing a fix for the initial issue ATM.
It turns out that we sign the stub.exe file (http://hg.mozilla.org/mozilla-central/file/7a52ba9b1542/toolkit/mozapps/installer/windows/nsis/makensis.mk#l75
) after we copy it to $(DIST)/... (http://hg.mozilla.org/mozilla-central/file/7a52ba9b1542/toolkit/mozapps/installer/windows/nsis/makensis.mk#l69), what works fine for en-US builds.

L10N repacks for windows have a hook to remove some localizable files from $(DIST) and copy the regenerated ones over:
http://hg.mozilla.org/mozilla-central/file/7a52ba9b1542/browser/locales/Makefile.in#l65

The solution here is signing stub.exe file exactly the same way as we sign setup.exe here:
http://hg.mozilla.org/mozilla-central/file/7a52ba9b1542/toolkit/mozapps/installer/windows/nsis/makensis.mk#l55

I tested the patch in staging and l10n repack went fine, just need to confirm that the patch doesn't break the en-US build:
https://tbpl.mozilla.org/?tree=Try&rev=c72dec600eb8
Attachment #677121 - Flags: review?(ted)
Attachment #677121 - Flags: review?(catlee)
(In reply to Rail Aliiev [:rail] from comment #7)
> I tested the patch in staging and l10n repack went fine, just need to
> confirm that the patch doesn't break the en-US build:
> https://tbpl.mozilla.org/?tree=Try&rev=c72dec600eb8

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/raliiev@mozilla.com-c72dec600eb8/try-win32/firefox-19.0a1.en-US.win32.installer-stub.exe looks fine to me.
Comment on attachment 677121 [details] [diff] [review]
sign stub.exe inplace

Looks good to me.
Attachment #677121 - Flags: review?(catlee) → review+
Attachment #677121 - Flags: review?(ted) → review+
Is this RESOLVED FIXED since there's a check in or is there more work to be done here?
(In reply to Jason Smith [:jsmith] from comment #11)
> Is this RESOLVED FIXED since there's a check in or is there more work to be
> done here?

I think we need to uplift this to aurora as well. Let me nomnomnom it. :)
Comment on attachment 677121 [details] [diff] [review]
sign stub.exe inplace

The patch is a blocker for l10n stub deployment. Would be great to uplift it to aurora.

Bug caused by (feature/regressing bug #): initial implementation
User impact if declined: all l10n stub installer consumers
Testing completed (on m-c, etc.): tested on m-c
Risk to taking this patch (and alternatives if risky): low
String or UUID changes made by this patch: None
Attachment #677121 - Flags: approval-mozilla-aurora?
Comment on attachment 677121 [details] [diff] [review]
sign stub.exe inplace

[Triage Comment]
Thanks for fixing! I believe l10n stub testing will now be unblocked.
Attachment #677121 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Keywords: verifyme
QA Contact: jsmith
Status: RESOLVED → VERIFIED
Keywords: verifyme
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.