User Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20100101 Firefox/17.0 (Beta/Release) Build ID: 20100101 Steps to reproduce: We are trying to update the Tor Browser to ESR24 which is built deterministically. While doing so we noticed that the omni.ja in /browser has different SHA256 sums in different builds. It turned out that the browser.manifest contains entries in different order in some builds. We worked around this problem in ESR17 by patching link-manifests.py but that is not available anymore since bug 780561 landed. I tried to reproduce the differences by running JarMaker.py by hand but that did not work. Actual results: The order of the content in browser.manifest files was different. Expected results: The order of the content in browser.manifest files should always have been the same.
I'm sure we have a bug on file for that already. Not for the order, though, which would be fixed as a side effect. An easy workaround in esr (since we're not going to fix that there) is to build with -j1.
This is very much related to bug 924187
(In reply to Mike Hommey [:glandium] from comment #1) > I'm sure we have a bug on file for that already. Not for the order, though, > which would be fixed as a side effect. > > An easy workaround in esr (since we're not going to fix that there) is to > build with -j1. Can you think of any less easy workarounds here? Building with -j4 takes already several hours for all our bundles. Thus, I'd rather like avoiding -j1...
It seems sorting myregister in JarMaker.py's updateManifest() helps, nevermind then.
While the bug mentions browser.manifest, this is an issue for XPCOM manifests as well. I've been wanting to tackle XPCOM manifest generation/buildlist.py foo now that we're in a moz.build world and we know the set of input manifest files at config time. There is work around bug 924617 to change how JarMaker.py works. It's all leading to a moz.build-driven jar.mn processing world. We should be able to bake determinism into that.
Created attachment 8388463 [details] [diff] [review] Generate browser.manifest deterministically I finally extracted the fix out of our ESR 24 repo and applied it to m-c for review. This covers only the browser.manifest case which bit us in the past.
Created attachment 8392759 [details] [diff] [review] patch with updated commit message Thanks for the review. I just updated the commit message (it references the bug number now as well).