The default bug view has changed. See this FAQ.

Packaging support for multi-locale gecko

RESOLVED FIXED in Firefox 18

Status

Firefox OS
GonkIntegration
P1
normal
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: Pike, Assigned: Pike)

Tracking

unspecified
B2G C2 (20nov-10dec)
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed, firefox20 fixed, b2g18 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
Now that we have the chrome-% target from bug 796051, investigate if we need packaging updates.

Comparing mobile/android/installer/Makefile.in to b2g/installer/Makefile.in:

diff -u mobile/android/installer/Makefile.in b2g/installer/Makefile.in 
--- mobile/android/installer/Makefile.in	2012-10-22 04:49:48.000000000 -0600
+++ b2g/installer/Makefile.in	2012-11-29 12:55:22.000000000 -0700
@@ -8,12 +8,6 @@
 VPATH     = @srcdir@
 
 include $(DEPTH)/config/autoconf.mk
-
-# overwrite mobile-l10n.js with a matchOS=true one for multi-locale builds
-ifeq ($(AB_CD),multi)
-PREF_JS_EXPORTS = $(srcdir)/mobile-l10n.js
-endif
-
 include $(topsrcdir)/config/rules.mk
 
 MOZ_PKG_REMOVALS = $(srcdir)/removed-files.in
@@ -23,10 +17,10 @@
 MOZ_NONLOCALIZED_PKG_LIST = \
 	xpcom \
 	browser \
-	mobile \
+	b2g \
 	$(NULL)
 
-MOZ_LOCALIZED_PKG_LIST = $(AB_CD) multilocale
+MOZ_LOCALIZED_PKG_LIST = $(AB_CD)
 
 DEFINES += \
 	-DAB_CD=$(AB_CD) \
@@ -44,6 +38,15 @@
 include $(topsrcdir)/ipc/app/defs.mk
 DEFINES += -DMOZ_CHILD_PROCESS_NAME=$(MOZ_CHILD_PROCESS_NAME)
 
+# Set MSVC dlls version to package, if any.
+ifdef WIN32_REDIST_DIR
+DEFINES += -DMOZ_MSVC_REDIST=$(_MSC_VER)
+endif
+
+ifdef ENABLE_MARIONETTE
+DEFINES += -DENABLE_MARIONETTE=1
+endif
+
 ifdef MOZ_PKG_MANIFEST_P
 MOZ_PKG_MANIFEST = package-manifest
 endif
@@ -61,21 +64,13 @@
 endif
 DEFINES += -DBINPATH=$(BINPATH)
 
-ifdef ENABLE_MARIONETTE
-DEFINES += -DENABLE_MARIONETTE=1
+ifneq (,$(filter WINNT Darwin Android,$(OS_TARGET)))
+DEFINES += -DMOZ_SHARED_MOZGLUE=1
 endif
 
 ifdef MOZ_PKG_MANIFEST_P
-$(MOZ_PKG_MANIFEST): $(MOZ_PKG_MANIFEST_P) $(GLOBAL_DEPS)
+$(MOZ_PKG_MANIFEST): $(MOZ_PKG_MANIFEST_P) FORCE
 	$(PYTHON) $(topsrcdir)/config/Preprocessor.py $(DEFINES) $(ACDEFINES) $< > $@
-ifdef MOZ_CHROME_MULTILOCALE
-	printf "\n[multilocale]\n" >> $@
-	for LOCALE in en-US $(MOZ_CHROME_MULTILOCALE) ;\
-	do \
-	  printf "$(BINPATH)/chrome/$$LOCALE$(JAREXT)\n" >> $@; \
-	  printf "$(BINPATH)/chrome/$$LOCALE.manifest\n" >> $@; \
-	done
-endif
 
 GARBAGE += $(MOZ_PKG_MANIFEST)
 endif


I'd need help with someone that understands how we package up the builds we put on ftp.

Comment 1

4 years ago
It is hard to know if this is something that blocks or not, or is a dup.  Please renom if this is really something that would block us from shipping v.1.
blocking-basecamp: ? → -
Axel and I talked through how the Gecko parts of multilocale for B2G are going to work today, and based on that it's my understanding that this bug is needed for that. Re-nom'ing and marking as blocking those builds:
15:43 <@Pike> so I bet that for those we'll need to port packaging goop from mobile/android/installer into b2g/installer, and pass in the the MULTI_LOCALE variable on the b2g packaging step
blocking-basecamp: - → ?
Depends on: 812833, 812836
Fixing deps. Bugs are hard.
Blocks: 812833, 812836
No longer depends on: 812833, 812836
(Assignee)

Comment 4

4 years ago
Seems that we need this, at least for desktop.

I have a patch in the works which is porting over what we're doing for android, and I also got a slightly better idea of how we're doing this to begin with.

There's a caveat in porting the mobile stuff at least for OSX, as the source dir for the packager is dist/B2G.app and not dist/bin, which doesn't affect android, apparently. For now, I suggest to put that on to the automation, as you just need to 'make -C b2g/app' to copy stuff over to dist/B2G.app

The resulting build scheme looks like:

MOZ_CHROME_MULTILOCALE env is set to a list of locales, say 'es-ES pt-BR'.

make -f client.mk as usual
cd builddir/b2g/locales
for loc in $MOZ_CHROME_MULTILOCALE; do
  make merge-$loc LOCALE_MERGEDIR=$PWD/merge-$loc
  make chrome-$loc LOCALE_MERGEDIR=$PWD/merge-$loc
done
cd ../app
make
cd ../..
make package
Assignee: nobody → l10n
Summary: Packaging support for multi-locale gecko needed? → Packaging support for multi-locale gecko
(Assignee)

Comment 5

4 years ago
Created attachment 688415 [details] [diff] [review]
use MOZ_CHROME_MULTILOCALE like mobile/android

This ports over a few things from mobile/android/installer to b2g/installer.

Slight mods:

I'm not explicitly adding 'en-US' to MOZ_CHROME_MULTILOCALE, that seems to be done in mozharness for mobile already.

As mentioned in my comment before, for at least OSX desktop, we need to insert a make -C b2g/app to get things from dist/bin into dist/X.app.

I was only able to test this on OSX, my machine is crawl-slow to begin with, trying to do full builds on VMs is a no-go, sadly. It'd be great if bhearsum or aki could help out with testing this.

Suggested testing:

Get a french l10n-central, copy over mobile/overrides to b2g/chrome/overrides, build, merge-fr, chrome-fr, make -C app, make package, select french on first run, open firefox and load foo.tld, which should show a french error message.
Attachment #688415 - Flags: review?(mh+mozilla)
Attachment #688415 - Flags: feedback?(bhearsum)
Attachment #688415 - Flags: feedback?(aki)

Comment 6

4 years ago
(In reply to Axel Hecht [:Pike] from comment #5)
> I was only able to test this on OSX, my machine is crawl-slow to begin with,
> trying to do full builds on VMs is a no-go, sadly. It'd be great if bhearsum
> or aki could help out with testing this.
> 
> Suggested testing:
> 
> Get a french l10n-central, copy over mobile/overrides to
> b2g/chrome/overrides, build, merge-fr, chrome-fr, make -C app, make package,
> select french on first run, open firefox and load foo.tld, which should show
> a french error message.

I'll try to give this a shot.

Comment 7

4 years ago
This is a blocker from the product perspective to support locale packaging for gecko.  Can we map this to the local selected by the user on the Gaia end?  

Let me know if I'm misunderstanding something here if this doesn't make sense.
(Assignee)

Comment 8

4 years ago
Yes, and the mapping already works. We did that in bug 796079.

Doing so restartless doesn't work 100%, I'll file a bug on that once we have public builds which can reproduce. Seems to be some gaia-side cache. I'd not block on that one, unless it manifests elsewhere.
Attachment #688415 - Flags: review?(mh+mozilla) → review+

Updated

4 years ago
Blocks: 818560

Updated

4 years ago
No longer blocks: 818560
blocking-basecamp: ? → +
(Assignee)

Comment 9

4 years ago
To clarify, Aki, I'm waiting with landing this for your feedback.

Comment 10

4 years ago
Yeah, this is taking me longer than expected.
Will this break something, or should we land and fix if an issue comes up?
(Assignee)

Comment 11

4 years ago
I don't think it can break something, pushed to a limited try to confirm, https://tbpl.mozilla.org/?tree=Try&rev=5d2b1c7436b1. If that passes, I'd be for landing and fixing.
(Assignee)

Comment 12

4 years ago
s/If/Once/, too

Comment 13

4 years ago
Thanks!  Still working on code to use this, which should let me verify once it's closer to completion.
(Assignee)

Comment 14

4 years ago
Thanks, the tests didn't trigger, but the builds passed, so I pushed to inbound.

https://hg.mozilla.org/integration/mozilla-inbound/rev/b1e281b6c558
(Assignee)

Updated

4 years ago
Blocks: 818907
Blocks: 812831

Comment 15

4 years ago
Trying to verify on windows, and when I launch it says

Firefox can't establish a connection to the server at system.gaiamobile.org:8080

which I suspect will stay broken since our staging slaves can't contact the outside world.
Comment on attachment 688415 [details] [diff] [review]
use MOZ_CHROME_MULTILOCALE like mobile/android

I'm taking myself off of this because Aki is the one verifying that the build system works.
Attachment #688415 - Flags: feedback?(bhearsum)
https://hg.mozilla.org/mozilla-central/rev/b1e281b6c558
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Assignee)

Comment 18

4 years ago
Uplifted to aurora and beta, I didn't do the merge to b2g-18. Fwiw, I need them on beta as that's where the localizers find their strings, and for l10n of b2g, those should really be the same.

https://hg.mozilla.org/releases/mozilla-aurora/rev/0b62d54f320f
https://hg.mozilla.org/releases/mozilla-beta/rev/263214638d26
status-firefox18: --- → fixed
status-firefox19: --- → fixed
status-firefox20: --- → fixed

Comment 19

4 years ago
Comment on attachment 688415 [details] [diff] [review]
use MOZ_CHROME_MULTILOCALE like mobile/android

I think others have verified this.
Thanks Axel!
Attachment #688415 - Flags: feedback?(aki)

Comment 20

4 years ago
We will need this on b2g18 though.
(Assignee)

Comment 21

4 years ago
(In reply to Aki Sasaki [:aki] from comment #20)
> We will need this on b2g18 though.

I read the 18 comments that sheriffs would do the merges from beta to 18, and didn't want to mess with it. I know it's suboptimal today.
(In reply to Axel Hecht [:Pike] from comment #21)
> (In reply to Aki Sasaki [:aki] from comment #20)
> > We will need this on b2g18 though.
> 
> I read the 18 comments that sheriffs would do the merges from beta to 18,
> and didn't want to mess with it. I know it's suboptimal today.

I'm planning to turn on gecko multilocale for most builds this morning. This will be a clean merge if somebody does do a beta -> b2g18 merge, so I pushed this patch:
https://hg.mozilla.org/releases/mozilla-b2g18/rev/37677c99c170
Whiteboard: [status-b2g18:fixed]
status-b2g18: --- → fixed
Whiteboard: [status-b2g18:fixed]
You need to log in before you can comment on or make changes to this bug.