Earlier today a Gentoo developer dropped into #developers an grumbled about his build giving him official Firefox branding. I was all "lol ur build scripz are teh brok noob!" and shoo'd him away. A problem like that implies either the person building make some mistake, or we did something stupid. And since we _never_ do something stupid I spun up a build to check. Ahem. Aaaanyway. My build from tip of hg://hg.mozilla.org/releases/mozilla-beta with a minimal mozconfig (just enabling debug and setting an objdir) gives me a build with offical artwork. Sigh. This is a problem on our end and should be fixed. :( This does raise the question of what the branding _should_ be. Ideally we'd have a nice generic "browser" branding, ala bug 682415. In the meantime we should revert back to using the previous "Aurora" branding (or even Nightly).
Just to be clear: this is about for the branding of builds people make themselves from the defaults. Official beta builds from Mozilla should have official branding, just as final releases do.
Looks like this was "broken" by: https://hg.mozilla.org/releases/mozilla-beta/rev/72896fd70ab8 which was in itself a bustage fix to a previous change made during the merge: https://hg.mozilla.org/releases/mozilla-beta/rev/e499e965029b Short term fix is to just revert to using the Aurora or Nightly branding as the default for beta. The confvars.sh value isn't particularly important, since the release configs used for the builds shipped from the beta branch use the --enable-official-branding flag - it just affects what someone gets when they pull beta and build with a default config. Bug 659552 tracks fixing beta builds to have a suitable default branding that isn't confusing.
Created attachment 601114 [details] [diff] [review] patch I went with "Nightly", since that's the default on trunk.
Created attachment 601117 [details] [diff] [review] m-c patch to add a clarifying comment
Comment on attachment 601114 [details] [diff] [review] patch "Anarchy" (original reporter of this bug) mentioned on IRC that mozilla-release is also affected. I think we'll want to land this there as well, just to avoid any future confusion (e.g. from Linux distros pulling mozilla-release code and generating their own builds). It has no impact on our release builds, since this is fallback that is overridden by our passing of --enable-official-branding.
Comment on attachment 601114 [details] [diff] [review] patch ESR is affected as well. Branch approval flag triagers: ping me on IRC if you need additional information. Just to recap: - this doesn't affect our release builds in any way (they use the --enable-official-branding flag which overrides this default). There's no risk to our releases, but even if it did somehow manage to break something we'd notice it right away (the branding would be wrong). - this affects people pulling code from these repos and building them with the default configuration (no --enable-official-branding flag specified). They're getting builds branded "Firefox" when they should be getting a build with unencumbered branding ("Nightly").
For background here, I was using a script provided to me for the merge process which apparently took a hammer to some of these files, thus causing the breakage in https://hg.mozilla.org/releases/mozilla-beta/rev/72896fd70ab8 and the followup band-aid in https://hg.mozilla.org/releases/mozilla-beta/rev/e499e965029b.
Comment on attachment 601114 [details] [diff] [review] patch [Triage Comment] Approving for release as well for those pulling/building off of m-r in the future, since this wouldn't affect the builds coming out of RelEng.
https://hg.mozilla.org/releases/mozilla-beta/rev/a8aa6864a320 https://hg.mozilla.org/releases/mozilla-release/rev/0bf1cadfb004 https://hg.mozilla.org/releases/mozilla-esr10/rev/64e2d498a321
https://hg.mozilla.org/integration/mozilla-inbound/rev/428268749ad0 I also clobbered beta/release/ESR, given the change of branding.
Verified that after the patch landed the branding for the mozilla-esr10 is the "Nightly" branding. Marking as Verified on firefox-esr10.