Closed
Bug 871080
Opened 12 years ago
Closed 12 years ago
mozbuild writing chrome.manifest incorrectly
Categories
(Firefox Build System :: General, defect)
Firefox Build System
General
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla24
People
(Reporter: jgriffin, Assigned: glandium)
References
Details
Attachments
(1 file)
mozbuild is writing chrome.manifest incorrectly in some cases.
B2G desktop builds get packaged so that each jar.mn file results in a separate .jar file, and the entries of all these are described in a chrome.manifest file.
For Marionette, jar.mn is here: http://mxr.mozilla.org/mozilla-central/source/testing/marionette/jar.mn
All these files get correctly packaged into marionette.jar. However, the chrome.manifest that's generated contains these lines:
resource specialpowers marionette/modules/
content marionette jar:marionette.jar!/content/
content specialpowers jar:marionette.jar!/content/
The 'resource' line is incorrect; it should read:
resource specialpowers jar:marionette.jar!/modules/
content marionette jar:marionette.jar!/content/
content specialpowers jar:marionette.jar!/content/
This error is preventing the related resource url's for MockFilePicker.jsm et al from being loaded, which in turn breaks Marionette on packaged B2G desktop builds.
Reporter | ||
Comment 1•12 years ago
|
||
This happens because code in JarFormatter.add_manifest (http://mxr.mozilla.org/mozilla-central/source/python/mozbuild/mozpack/packager/formats.py#176) relies on some non-deterministic ordering of entries in other manifests.
In this case, the JarMaker.py creates a marionette.manifest file during the build process which is written out in the order that entries happen to appear in the 'register' dict: http://mxr.mozilla.org/mozilla-central/source/config/JarMaker.py#287
JarFormatter.add_manifest processes these, and because the "resource" line accidentally appears first, it's chromepath hasn't already been added to self._chrome, and we don't get a correctly "jarized" entry in chrome.manifest.
I'm not sure how best to fix this though; one approach would be to use a list instead of a dict in JarMaker.py so that entries appear in source-manifest order.
Assignee | ||
Comment 2•12 years ago
|
||
Are you building with --enable-chrome-format=jar? no mozconfig in mozilla-central is, so i'm surprised you are.
Reporter | ||
Comment 3•12 years ago
|
||
This is how buildbot-produced B2G desktop builds get made. I'm not sure if that's intentional or not.
Reporter | ||
Comment 4•12 years ago
|
||
That entry doesn't appear in the mozconfig that gets used to make these: http://mxr.mozilla.org/mozilla-central/source/b2g/config/mozconfigs/linux64_gecko/nightly
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → mh+mozilla
Assignee | ||
Updated•12 years ago
|
Blocks: new-packager
Assignee | ||
Comment 5•12 years ago
|
||
Attachment #749166 -
Flags: review?(gps)
Comment 6•12 years ago
|
||
Comment on attachment 749166 [details] [diff] [review]
Send chrome manifest entries first to package formatters, before e.g. resource manifest entries
Review of attachment 749166 [details] [diff] [review]:
-----------------------------------------------------------------
::: python/mozbuild/mozpack/test/test_packager.py
@@ +179,2 @@
> ((os.path.join(curdir, 'foo', 'bar.manifest'), 1),
> 'add_manifest', ManifestResource('foo', 'bar', 'bar/')),
Please drop a comment in here noting the importance of order.
Attachment #749166 -
Flags: review?(gps) → review+
Assignee | ||
Comment 7•12 years ago
|
||
Comment 8•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
Updated•7 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•