|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
Created attachment 8770985 [details] chrome.manifest The multi build of Fennec has the same 29 lines duplicated about 75 times in chrome.manifest. See the attached file.
nalexander said to copy you because this would happen with multilocale desktop as well.
(In reply to Mike Kaply [:mkaply] from comment #1) > nalexander said to copy you because this would happen with multilocale > desktop as well. Just putting note on record: there is no multi-locale build on desktop, only single locale builds and language packs.
Comment on attachment 8854171 [details] Bug 1286853 - Don't put overrides in locale specific jar files. https://reviewboard.mozilla.org/r/126138/#review128714 I think that this achieves your goal, but isn't there a bug in the chrome manifest processing code here? Either we should accept repeated manifest entries and reduce duplicates to a single entry, or we should complain in the face of duplicates. Do you have an opinion on what is better? I'll flag glandium with the same question.
Attachment #8854171 - Flags: review?(nalexander) → review-
glandium: do you have an opinion on https://bugzilla.mozilla.org/show_bug.cgi?id=1286853#c4? Is there a use for repeated manifest entries? Is this just an oversight?
Oddly buildlist.py says that it does take care of duplicates https://dxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/action/buildlist.py#21 def addEntriesToListFile(listFile, entries): """Given a file |listFile| containing one entry per line, add each entry in |entries| to the file, unless it is already present.""" That's what jar.py uses internally.
Are these artifact builds? Artifact builds may be using a different code path for this. If not artifact builds, then that shouldn't be happening in the first place, and that's what should be fixed.
No, this is our regular build. Because the multilocale stuff is run as subsequent build requests, each l10n build appends it's information to the end of chrome.manifest. Incidentally, this explains why addEntriesToListFile isn't helping here. It doesn't go back through the already written file. This attachment https://bug1286853.bmoattachments.org/attachment.cgi?id=8770985 Is chrome.manifest as we ship it today.
> It doesn't go back through the already written file. Sure it does, that's its whole purpose.
> Sure it does, that's its whole purpose. Even if it's a brand new open of an existing file (versus the same file). If so, this is just a bug in addEntriesToListFile, because we're definitely getting duplicates.
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → INACTIVE
Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Resolution: INACTIVE → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.