Closed Bug 1426943 Opened 3 years ago Closed 3 years ago

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

Categories

(Core :: Internationalization, defect)

All
Android
defect
Not set
blocker

Tracking

()

VERIFIED FIXED
mozilla59
Tracking Status
firefox-esr52 --- unaffected
firefox57 --- unaffected
firefox58 --- unaffected
firefox59 blocking verified

People

(Reporter: RyanVM, Assigned: RyanVM)

References

Details

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
Flags: needinfo?(gandalf)
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.
Tracking for 59 since this blocks the merge.
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.
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 :)
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.
Assignee: nobody → ryanvm
Flags: needinfo?(gandalf)
Pushed by ryanvm@gmail.com:
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
> 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?
Flags: needinfo?(l10n)
https://hg.mozilla.org/mozilla-central/rev/ae7ee4a95caa
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
(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.
Flags: needinfo?(l10n)
Filed bug 1428099 to handle the removal of mobile-l10n.js
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.