1426943 - All Android non-debug builds are going to permafail when Gecko 59 merges to Beta on 2018-01-11

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

Right now, the only Android test coverage I have for uplift simulations is on debug, so a quick fix for this would be greatly appreciated since there's only one week to the merge once we all return from the break.

Regression from bug 1414390?

https://treeherder.mozilla.org/logviewer.html#?job_id=153157494&repo=try

ERROR: The following duplicated files are not allowed:
defaults/pref/mobile-l10n.js

Comment 1

[Axel Hecht [:Pike]]

To add some findings:

mobile-l10n.js is 0 bytes. So is toolkit/content/XPCNativeWrapper.js after stripping comments.

So the two conflict on md5 hashes, and the latter is whitelisted in mobile/android/installer/allowed-dupes.mn.

gandalf, my memory confuses me after the black-out:

Is it OK for that file to be empty? If so, we should white-list it, or, if it's OK for it to be non-existent, maybe figure out a way for it to not be built at all.

I'm a little surprised as to that not kicking us on central, though.

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 59 since this blocks the merge.

Comment 3

[Liz Henry (:lizzard) (relman/hg->git project)]

On second thought let's mark this as a blocking bug for 59 so I won't lose sight of it in the next week.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Adding a comment to the file fixes it.
https://hg.mozilla.org/try/rev/dc340de0192f0d199046a529f17ca306f07eb4a0

Maybe a bit verbose, but I'm open to suggestions :)

Comment 5

[Ryan VanderMeulen [:RyanVM]]

I got an IRC r+ from nalexander for the comment I used in the Try push, so I'll just push that as-is. We might still want to consider filing a follow-up bug for not including empty files in the duplicate file check during packaging, though.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ae7ee4a95caa
Add a comment to mobile-l10n.js so it doesn't generate a clashing hash during packaging. r=nalexander

Comment 7

[Zibi Braniecki [:zbraniecki][:gandalf]]

> Is it OK for that file to be empty? If so, we should white-list it, or, if it's OK for it to be non-existent, maybe figure out a way for it to not be built at all.

I was hoping we can remove it. Is that possible?

Comment 8

[Eliza Balazs [:ebalazs_]]

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

Comment 9

[Axel Hecht [:Pike]]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #7)
> > Is it OK for that file to be empty? If so, we should white-list it, or, if it's OK for it to be non-existent, maybe figure out a way for it to not be built at all.
> 
> I was hoping we can remove it. Is that possible?

"It's just code", I'm not sure how much work that is, and where, though. Runtime should be OK, IIRC, we just iterate over all files we find on startup. So that'd be more of a build and repack question.

Comment 10

[Zibi Braniecki [:zbraniecki][:gandalf]]

Filed bug 1428099 to handle the removal of mobile-l10n.js