Closed Bug 798255 Opened 12 years ago Closed 12 years ago

Firefox net / stub installer for localized builds

Categories

(Firefox :: Installer, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 19
Tracking Status
firefox18 --- fixed

People

(Reporter: Pike, Assigned: robert.strong.bugs)

References

Details

(Whiteboard: [stub=])

Attachments

(2 files, 2 obsolete files)

We have a stub installer for en-US from bug 322206, but I don't see them built for l10n repacks. They're not on ftp, and I don't see trace of them in the repack log either.
Correct. We are getting the en-US done first and will take care of this after I have some breathing room.
No longer depends on: StubInstaller
Whiteboard: [stub+]
Not blocking for deployment, although we need to do this to deploy with localized builds.
Whiteboard: [stub+] → [stub=]
Attached patch patch rev1 (obsolete) — Splinter Review
Kyle, it isn't clear to me where the best place to do this is so if I am way off be nice. :)
Attachment #670724 - Flags: review?(khuey)
Comment on attachment 670724 [details] [diff] [review] patch rev1 Review of attachment 670724 [details] [diff] [review]: ----------------------------------------------------------------- I'm not familiar enough with l10n installers to review this.
Attachment #670724 - Flags: review?(khuey)
Comment on attachment 670724 [details] [diff] [review] patch rev1 Mike, bsmedberg suggested that you might be able to review this. Thanks!
Attachment #670724 - Flags: review?(mh+mozilla)
Comment on attachment 670724 [details] [diff] [review] patch rev1 Review of attachment 670724 [details] [diff] [review]: ----------------------------------------------------------------- This seems hackish, but i guess this is good enough. I'd like Pike to take a look, though.
Attachment #670724 - Flags: review?(mh+mozilla)
Attachment #670724 - Flags: review?(l10n)
Attachment #670724 - Flags: review+
I won't have time for a thorough review anytime soon, sorry.
Attachment #670724 - Flags: review?(benjamin)
Maybe Benjamin Smedberg can review this
Attachment #670724 - Flags: review?(benjamin) → review+
Pushed to mozilla-inbound https://hg.mozilla.org/integration/mozilla-inbound/rev/cd08e1a21a4c If there are improvements wanted please file new bugs
Attachment #670724 - Flags: review?(l10n)
Backed out for orange: https://hg.mozilla.org/integration/mozilla-inbound/rev/4741e1875d1b Sample of orange: https://tbpl.mozilla.org/php/getParsedLog.php?id=16175781&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=16175742&tree=Mozilla-Inbound { cp: target `19.0a1-stub.exe' is not a directory chmod: cannot access `e:/builds/moz2_slave/m-in-w64/build/obj-firefox/browser/locales/../../dist/win64-x86_64/x-test/Nightly': No such file or directory chmod: cannot access `Setup': No such file or directory chmod: cannot access `19.0a1-stub.exe': No such file or directory program finished with exit code 2 elapsedTime=32.346000 }
Looks like the file name needs to be quoted.
Attached patch patch rev2 (obsolete) — Splinter Review
I was able to run the extra checks performed on the build system (didn't know there was a MOZ_PKG_PRETTYNAMES verification build step) and was able to fix up the patch. I'm running it through try https://tbpl.mozilla.org/?tree=Try&rev=5e50ea16aff5
Assignee: nobody → robert.bugzilla
Attachment #670724 - Attachment is obsolete: true
Status: NEW → ASSIGNED
(In reply to Robert Strong [:rstrong] (do not email) from comment #12) > Created attachment 672208 [details] [diff] [review] > patch rev2 > > I was able to run the extra checks performed on the build system (didn't > know there was a MOZ_PKG_PRETTYNAMES verification build step) and was able > to fix up the patch. I'm running it through try > https://tbpl.mozilla.org/?tree=Try&rev=5e50ea16aff5 This works locally for me but for some reason the try build didn't get the quoting.
Status: ASSIGNED → NEW
I don't recall the exact when-which, but there is a pattern on when to use ESCAPE_WILDCARD, http://mxr.mozilla.org/mozilla-central/search?string=ESCAPE_WILDCARD. Maybe this is a spot.
This could also be related to bug 794472, which i'm going to land today.
Attached patch patch rev3Splinter Review
I'm an ID10T. Not sure if the patch in bug 794472 made a difference but I should have realized that the dir might not exist yet. https://tbpl.mozilla.org/?tree=Try&rev=5c0e1bdaa82f
Attachment #672208 - Attachment is obsolete: true
Attachment #673319 - Flags: review?(mh+mozilla)
Comment on attachment 673319 [details] [diff] [review] patch rev3 Review of attachment 673319 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/locales/Makefile.in @@ +66,5 @@ > $(NSINSTALL) -D $(STAGEDIST)/uninstall; \ > cp ../installer/windows/l10ngen/helper.exe $(STAGEDIST)/uninstall; \ > $(RM) $(_ABS_DIST)/l10n-stage/setup.exe; \ > cp ../installer/windows/l10ngen/setup.exe $(_ABS_DIST)/l10n-stage; \ > + $(NSINSTALL) -D $(_ABS_DIST)/$(PKG_INST_PATH); \ For good measure, you may want to quote the path here too.
Attachment #673319 - Flags: review?(mh+mozilla) → review+
Thanks for the review!
Attachment #673937 - Flags: review+
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → Firefox 19
Keywords: verifyme
QA Contact: jsmith
Comment on attachment 673937 [details] [diff] [review] patch - updated to comments [Approval Request Comment] Bug caused by (feature/regressing bug #): Stub installer - Bug 322206 User impact if declined: No localized builds for the stub installer until Firefox 19 Testing completed (on m-c, etc.): Tested locally and the l10n checks in the build system pass Risk to taking this patch (and alternatives if risky): little and it can be easily backed out String or UUID changes made by this patch: None
Attachment #673937 - Flags: approval-mozilla-aurora?
Comment on attachment 673937 [details] [diff] [review] patch - updated to comments Since it passes l10n build checks, we can try this out on Aurora (18) and back out later if anything unexpected regresses.
Attachment #673937 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Definitely a lot of problems with this patch. I'm finding the l10n stub builds on http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central-l10n/ and http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora-l10n/, however, such problems seen so far include: - The stub installer l10n executables are not signed builds in each directory. This is different behavior than what's seen with the full installer l10n executables, as they are signed builds - The stub installer l10n builds on the central and aurora directories are using wrong artwork, wrong release channels, etc. This doesn't make sense, as these l10n stub executables should be for nightly and aurora for latest-mozilla-central and latest-mozilla-aurora respectively. Instead, I'm getting 16.02 release stub executables in each directory - None of these stub executables appear to have localized strings at all. All of the wording shown is in english. Brian - Any ideas? What's going on here?
Flags: needinfo?(netzen)
Keywords: verifyme
Whiteboard: [stub=] → [stub=], [qa verification failed]
It sounds like 2 problems. (In reply to Jason Smith [:jsmith] from comment #24) > - The stub installer l10n executables are not signed builds in each > directory. This is different behavior than what's seen with the full > installer l10n executables, as they are signed builds I'm setting this too. I think RelEng needs to sign the stub because the full alongside the stub is being signed correctly. > - The stub installer l10n builds on the central and aurora directories are > using wrong artwork, wrong release channels, etc. This doesn't make sense, > as these l10n stub executables should be for nightly and aurora for > latest-mozilla-central and latest-mozilla-aurora respectively. I'm seeing this for both full installers and stub installers. I tested with the French builds. I think this is an l10n problem in general and not specific to the stub work here. The branding is always Firefox specific. > Instead, I'm > getting 16.02 release stub executables in each directory If I go to file properties on the stub itself says 18.0a2. But when I install from the stub on these localized builds I'm seeing the same thing with 16. Sounds like the same problem as above. The branding is Firefox so it grabs the Firefox full installer when downloading. > - None of these stub executables appear to have localized strings at all. > All of the wording shown is in english. The wording on the installers themselves are localized (checked with French builds). I think the download link it is pointing to is not yet correct though. So again I think this is the same problem.
Flags: needinfo?(netzen)
Bug 804090 is the branding bug. The localization is due to the lcale not being localized on aurora yet. Look at the ar locale to see a localized stub that also happens to be RTL. The signing will need to be worked out though I am not familiar with how we accomplish that for l10n, etc. I suspect someone from releng can help out with that.
It may be best to post a separate bug for RelEng to investigate signing the new stub l10n executables. And for the second bug, Rob gave the link. Most of the symptoms you mentioned, other than signing, would be fixed by that bug.
Sounds good. I've filed bug 806280 for the l10n signed builds.
Depends on: 806280
Whiteboard: [stub=], [qa verification failed] → [stub=], [qa verification blocked]
Depends on: 804090
Keywords: verifyme
Whiteboard: [stub=], [qa verification blocked] → [stub=]
Keywords: verifyme
QA Contact: jsmith
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: