These tests were switched on in bug 600838 for Linux and Windows, but not Mac for some reason. I can't find a documented reason as to why not, so we should try turning them on and see what happens! This should be a simple addition of the l10n_check_test flag in config.py, like this: http://hg.mozilla.org/build/buildbot-configs/file/tip/mozilla/config.py#l448
The simple answer is that the test fails: + cd universal/firefox/Nightly.app/Contents/MacOS /bin/sh: line 0: cd: universal/firefox/Nightly.app/Contents/MacOS: No such file or directory make: *** [/builds/slave/m-cen-osx64/build/obj-firefox/i386/browser/locales/../../dist/l10n-stage/firefox/Nightly.app/Contents/MacOS] Error 1 (from http://dev-master01.build.scl1.mozilla.com:8044/builders/OS%20X%2010.6.2%20mozilla-central%20build/builds/0/steps/make%20l10n%20check%20pretty/logs/stdio) I don't think this is on us to fix, frankly, but I'll do a little digging/comparison against Linux to see how hard it would be to fix.
I did some quick digging. STAGEPATH adds "universal/", and gets set here: https://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/installer/packager.mk#45 ...but it seems like the en-US dmg is being unpacked into firefox/Nightly.app rather than universal/firefox/Nightly.app in an earlier step. This causes |make l10n-check MOZ_PKG_PRETTYNAMES=1| to fail. |make l10n-check| is failing on a missing target error that I haven't been able to pinpoint. I don't really have the Makefile chops to track this further (or at least not in a timely manner. Reassigning to Joey to have a look. If we end up making any changes here, we'll need to test to make sure the following still work: * |make l10n-check| with and without MOZ_PKG_PRETTYNAMES=1 (obviously) * |make package| for en-US Mac nightly builds * release packaging for en-US Mac builds * nightly repacks for l10n * release repacks I'm willing to help test these variants in staging if we can unravel the Makefile changes required.
Things have changed a lot in 4 years, it might just work now. Mike, would you mind checking it?
Sure, I'll take a look.
Created attachment 8716485 [details] [diff] [review] 0001-Bug-700997-enable-l10n-check-on-mac.patch So it is still broken - there are two issues: 1) The STAGEPATH=universal/ issue described in #c1 / #c2 still exists 2) _BINPATH is not the correct place to find omni.ja files. I'm not sure what the missing target issue described in #c2 is, but one would see a "no rule to make target" error if l10n-check is run without a corresponding 'make package' (with or without prettynames). This patch fixes the issues as follows: 1a) Add UNIVERSAL_BINARY= to the installers-x-test call, so that STAGEPATH remains unset for the INNER_MAKE_PACKAGE definition. Otherwise the packaging step fails. 1b) Remove $(STAGEPATH) from the unpack.py & final test lines, since the universal/ path doesn't exist. 2) Replace _BINPATH with _RESPATH so that unpack.py finds the omni.ja files. Otherwise we don't pull out update.locale and the final test will fail. l10n-check remains disabled on cross-mac builds since we don't have hdiutil there (I don't think?) https://treeherder.mozilla.org/#/jobs?repo=try&revision=db7e12ebcb70&selectedJob=16419911
(In reply to Michael Shal [:mshal] from comment #5) > l10n-check remains disabled on cross-mac builds since we don't have hdiutil > there (I don't think?) We don't, but we could use the `dmg` tool we use to build DMGs there to unpack.