700997 - l10n-check and l10n-check w/ MOZ_PKG_PRETTYNAMES=1 aren't running on mac builds

Status: RESOLVED FIXED

(Firefox Build System :: General, defect, P3)

Description

[[e-mail] (:bhearsum)]

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

Comment 1

[Chris Cooper [:coop] (he/him)]

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[2]: *** [/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.

Comment 2

[Chris Cooper [:coop] (he/him)]

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.

Comment 3

[Mike Hommey [:glandium]]

Things have changed a lot in 4 years, it might just work now. Mike, would you mind checking it?

Comment 4

[Michael Shal [:mshal]]

Sure, I'll take a look.

Comment 5

[Michael Shal [:mshal]]

Attachment: 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

Comment 6

[(not currently active) Ted Mielczarek]

(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.

Comment 7

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e5947801f271

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e5947801f271