798255 - Firefox net / stub installer for localized builds

Status: RESOLVED FIXED

(Firefox :: Installer, defect)

Description

[Axel Hecht [:Pike]]

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.

Comment 1

[Robert Strong (they/them - no direct email)]

Correct. We are getting the en-US done first and will take care of this after I have some breathing room.

Comment 2

[Jason Smith [:jsmith]]

Not blocking for deployment, although we need to do this to deploy with localized builds.

Comment 3

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

Kyle, it isn't clear to me where the best place to do this is so if I am way off be nice. :)

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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.

Comment 5

[Robert Strong (they/them - no direct email)]

Comment on attachment 670724 [details] [diff] [review]
patch rev1

Mike, bsmedberg suggested that you might be able to review this. Thanks!

Comment 6

[Mike Hommey [:glandium]]

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.

Comment 7

[Axel Hecht [:Pike]]

I won't have time for a thorough review anytime soon, sorry.

Comment 8

[Robert Strong (they/them - no direct email)]

Maybe Benjamin Smedberg can review this

Comment 9

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-inbound
https://hg.mozilla.org/integration/mozilla-inbound/rev/cd08e1a21a4c

If there are improvements wanted please file new bugs

Comment 10

[Daniel Holbert [:dholbert]]

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
}

Comment 11

[Mike Hommey [:glandium]]

Looks like the file name needs to be quoted.

Comment 12

[Robert Strong (they/them - no direct email)]

Attachment: 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

Comment 13

[Robert Strong (they/them - no direct email)]

(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.

Comment 14

[Axel Hecht [:Pike]]

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.

Comment 15

[Mike Hommey [:glandium]]

This could also be related to bug 794472, which i'm going to land today.

Comment 16

[Robert Strong (they/them - no direct email)]

Attachment: patch rev3

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

Comment 17

[Mike Hommey [:glandium]]

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.

Comment 18

[Robert Strong (they/them - no direct email)]

Attachment: patch - updated to comments

Thanks for the review!

Comment 19

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-inbound
https://hg.mozilla.org/integration/mozilla-inbound/rev/6bd81cee2f5f

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/6bd81cee2f5f

Comment 21

[Robert Strong (they/them - no direct email)]

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

Comment 22

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 23

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-aurora
https://hg.mozilla.org/releases/mozilla-aurora/rev/578577f79163

Comment 24

[Jason Smith [:jsmith]]

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?

Comment 25

[Brian R. Bondy [:bbondy]]

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.

Comment 26

[Robert Strong (they/them - no direct email)]

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.

Comment 27

[Brian R. Bondy [:bbondy]]

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.

Comment 28

[Jason Smith [:jsmith]]

Sounds good. I've filed bug 806280 for the l10n signed builds.