l10n nightly builds are branded as Firefox and not Nightly, en-US nightlies are not affected

VERIFIED FIXED

Status

defect
VERIFIED FIXED
7 years ago
6 years ago

People

(Reporter: pascalc, Assigned: catlee)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(firefox18+ verified, firefox19+ verified)

Details

Attachments

(1 attachment)

Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121021030553

Nightly builds for locales are branded as Firefox (Firefox menu button, "about Firefox menu"...) instead of Nightly.

This is not profile related as I created new profiles to test. I tested French, Italian and English (US) builds, en-US builds are not affected.
I suspect that's the official-branding option in the l10n mozconfigs. See bugs 608004,558180
Blocks: 608004, 558180
More likely due to bug 791209 which was deployed last week.

Is the fix to remove "--enable-official-branding" from the mozconfigs?
Depends on: 791209
I guess we need something similar to en-US, l10n-nightly and l10n-release or so.
Duplicate of this bug: 805887
Blocks: 798255
Tacking on tracking 18 and 19 since this entirely blocks l10n stub installer testing and generally needs to be fixed.
(In reply to Jason Smith [:jsmith] from comment #5)
> Tacking on tracking 18 and 19 since this entirely blocks l10n stub installer
> testing and generally needs to be fixed.

While we don't have a hard timeline for l10n stub installers, this is still a test blocker and completely breaks our Nightly branding for a large portion of our users. Can we take next steps here?
Assignee: nobody → catlee
Comment on attachment 676584 [details] [diff] [review]
remove official branding from l10n mozconfigs

http://hg.mozilla.org/mozilla-central/rev/626b7ea149bc
Attachment #676584 - Flags: checked-in+
Comment on attachment 676584 [details] [diff] [review]
remove official branding from l10n mozconfigs

I've just checked the size of all localized win32 builds and it bumped from ~200k to ~600k what is a good sign of the fact that the bug is fixed. See https://bugzilla.mozilla.org/show_bug.cgi?id=806280#c4 why.

We need to uplift this to m-a.

Bug caused by (feature/regressing bug #): 
User impact if declined: localized builds have wrong branding
Testing completed (on m-c, etc.): fixed on m-c
Risk to taking this patch (and alternatives if risky): low
String or UUID changes made by this patch: None
Attachment #676584 - Flags: approval-mozilla-aurora?
Is this RESOLVED FIXED for trunk since there's a check in or is there more work to be done here? Just want to know if something is ready for verification.
Comment on attachment 676584 [details] [diff] [review]
remove official branding from l10n mozconfigs

[Triage Comment]
Approving in support of l10n stub installer testing ahead of the 18->Beta merge.
Attachment #676584 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/a6ce42903021
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Keywords: verifyme
QA Contact: jsmith
With apologies for not reading all the bug ... is there any action needed when we next merge form Aurora to Beta, or are the mozconfigs modified only used for nightly repacks ?
Comment on attachment 676584 [details] [diff] [review]
remove official branding from l10n mozconfigs

Review of attachment 676584 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/config/mozconfigs/macosx-universal/l10n-mozconfig
@@ +6,1 @@
>  fi

I'm seeing errors in tinderbox logs about this not being valid syntax, i.e., the empty command list after then.

Guess we should completely remove the conditional, or comment it out.

Not sure why some builds still pass, but bld-lion-r5-053 consistently fails on that error.
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.