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

RESOLVED FIXED in Firefox 47

Status

()

Firefox
Build Config
P3
normal
RESOLVED FIXED
6 years ago
2 years ago

People

(Reporter: bhearsum, Assigned: mshal)

Tracking

unspecified
Firefox 47
Points:
---

Firefox Tracking Flags

(firefox47 fixed)

Details

(Whiteboard: [l10n])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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

Updated

6 years ago
Whiteboard: [l10n]

Updated

6 years ago
Assignee: nobody → coop
Priority: -- → P3

Updated

6 years ago
Status: NEW → ASSIGNED
Priority: P3 → P2

Comment 1

6 years ago
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

5 years ago
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.
Assignee: coop → joey
Status: ASSIGNED → NEW
Component: Release Engineering → Build Config
Priority: P2 → P3
Product: mozilla.org → Firefox
QA Contact: release → build.config
Version: other → unspecified
Things have changed a lot in 4 years, it might just work now. Mike, would you mind checking it?
Flags: needinfo?(mshal)
(Assignee)

Comment 4

2 years ago
Sure, I'll take a look.
Assignee: joey → mshal
Flags: needinfo?(mshal)
(Assignee)

Comment 5

2 years ago
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
Attachment #8716485 - Flags: review?(mh+mozilla)
(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.
Attachment #8716485 - Flags: review?(mh+mozilla) → review+

Comment 7

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

Comment 8

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/e5947801f271
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox47: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 47
You need to log in before you can comment on or make changes to this bug.