Last Comment Bug 817197 - Packaging support for multi-locale gecko
: Packaging support for multi-locale gecko
Status: RESOLVED FIXED
:
Product: Firefox OS
Classification: Client Software
Component: GonkIntegration (show other bugs)
: unspecified
: All All
: P1 normal (vote)
: B2G C2 (20nov-10dec)
Assigned To: Axel Hecht [:Pike]
:
Mentors:
Depends on: 796051
Blocks: 812831 812833 812836 818907
  Show dependency treegraph
 
Reported: 2012-11-30 15:47 PST by Axel Hecht [:Pike]
Modified: 2012-12-13 19:38 PST (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
+
fixed
fixed
fixed
fixed


Attachments
use MOZ_CHROME_MULTILOCALE like mobile/android (887 bytes, patch)
2012-12-04 12:42 PST, Axel Hecht [:Pike]
mh+mozilla: review+
Details | Diff | Review

Description Axel Hecht [:Pike] 2012-11-30 15:47:45 PST
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 Doug Turner (:dougt) 2012-12-03 10:33:15 PST
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.
Comment 2 Ben Hearsum (:bhearsum) 2012-12-03 13:26:45 PST
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
Comment 3 Ben Hearsum (:bhearsum) 2012-12-03 13:28:58 PST
Fixing deps. Bugs are hard.
Comment 4 Axel Hecht [:Pike] 2012-12-04 11:30:18 PST
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
Comment 5 Axel Hecht [:Pike] 2012-12-04 12:42:42 PST
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.
Comment 6 Aki Sasaki [:aki] 2012-12-04 13:46:13 PST
(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 Chris Lee [:clee] 2012-12-04 18:28:14 PST
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.
Comment 8 Axel Hecht [:Pike] 2012-12-05 00:21:30 PST
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.
Comment 9 Axel Hecht [:Pike] 2012-12-05 15:33:53 PST
To clarify, Aki, I'm waiting with landing this for your feedback.
Comment 10 Aki Sasaki [:aki] 2012-12-05 16:02:17 PST
Yeah, this is taking me longer than expected.
Will this break something, or should we land and fix if an issue comes up?
Comment 11 Axel Hecht [:Pike] 2012-12-05 16:15:31 PST
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.
Comment 12 Axel Hecht [:Pike] 2012-12-05 16:15:50 PST
s/If/Once/, too
Comment 13 Aki Sasaki [:aki] 2012-12-05 16:16:39 PST
Thanks!  Still working on code to use this, which should let me verify once it's closer to completion.
Comment 14 Axel Hecht [:Pike] 2012-12-06 06:57:19 PST
Thanks, the tests didn't trigger, but the builds passed, so I pushed to inbound.

https://hg.mozilla.org/integration/mozilla-inbound/rev/b1e281b6c558
Comment 15 Aki Sasaki [:aki] 2012-12-06 15:25:47 PST
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 16 Ben Hearsum (:bhearsum) 2012-12-07 05:39:16 PST
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.
Comment 17 Ed Morley [:emorley] 2012-12-07 06:36:24 PST
https://hg.mozilla.org/mozilla-central/rev/b1e281b6c558
Comment 18 Axel Hecht [:Pike] 2012-12-12 15:22:56 PST
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
Comment 19 Aki Sasaki [:aki] 2012-12-12 15:25:24 PST
Comment on attachment 688415 [details] [diff] [review]
use MOZ_CHROME_MULTILOCALE like mobile/android

I think others have verified this.
Thanks Axel!
Comment 20 Aki Sasaki [:aki] 2012-12-12 15:26:09 PST
We will need this on b2g18 though.
Comment 21 Axel Hecht [:Pike] 2012-12-12 15:35:49 PST
(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.
Comment 22 Ben Hearsum (:bhearsum) 2012-12-13 06:04:39 PST
(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

Note You need to log in before you can comment on or make changes to this bug.