Firefox net / stub installer for localized builds

RESOLVED FIXED in Firefox 18

Status

()

defect
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Pike, Assigned: rstrong)

Tracking

Trunk
Firefox 19
x86
Windows 7
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(firefox18 fixed)

Details

(Whiteboard: [stub=])

Attachments

(2 attachments, 2 obsolete attachments)

Reporter

Description

7 years ago
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=]
Posted 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+
Reporter

Comment 7

7 years ago
I won't have time for a thorough review anytime soon, sorry.
Maybe Benjamin Smedberg can review this

Updated

7 years ago
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
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.
Posted 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
Reporter

Comment 14

7 years ago
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.
Posted 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+
https://hg.mozilla.org/mozilla-central/rev/6bd81cee2f5f
Status: NEW → RESOLVED
Closed: 7 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.