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
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
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.
(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+
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.
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
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.
Status: NEW → RESOLVED
Last Resolved: 6 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
status-firefox18: --- → fixed
status-firefox19: --- → fixed
status-firefox20: --- → fixed
Comment on attachment 688415 [details] [diff] [review] use MOZ_CHROME_MULTILOCALE like mobile/android I think others have verified this. Thanks Axel!
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
status-b2g18: --- → fixed
You need to log in before you can comment on or make changes to this bug.