Closed Bug 817197 Opened 12 years ago Closed 12 years ago

Packaging support for multi-locale gecko

Categories

(Firefox OS Graveyard :: GonkIntegration, defect, P1)

defect

Tracking

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

RESOLVED FIXED
B2G C2 (20nov-10dec)
blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- fixed
firefox20 --- fixed
b2g18 --- fixed

People

(Reporter: Pike, Assigned: Pike)

References

Details

Attachments

(1 file)

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.
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
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
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)
(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.
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.
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+
Blocks: 818560
No longer blocks: 818560
blocking-basecamp: ? → +
To clarify, Aki, I'm waiting with landing this for your feedback.
Yeah, this is taking me longer than expected.
Will this break something, or should we land and fix if an issue comes up?
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.
s/If/Once/, too
Thanks!  Still working on code to use this, which should let me verify once it's closer to completion.
Thanks, the tests didn't trigger, but the builds passed, so I pushed to inbound.

https://hg.mozilla.org/integration/mozilla-inbound/rev/b1e281b6c558
Blocks: 818907
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
Closed: 12 years ago
Resolution: --- → FIXED
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 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)
We will need this on b2g18 though.
(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]
Whiteboard: [status-b2g18:fixed]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: