Linux 7.0a3 bundles are not reproducible anymore (omni.ja files differ)

There are differences in the omni.ja files if built in our Gitian environment. Noted first in comment:8:ticket:20426 it seems not to be rbm specific. I opened https://bugzilla.mozilla.org/show_bug.cgi?id=1356900 on Mozilla's side

added TorBrowserTeam201704 component::applications/tor browser ff52-esr owner::tbb-team priority::very high resolution::fixed severity::major sponsor::4 status::closed tbb-7.0-must-alpha type::defect labels

Hmm, why didn't you try ticket:20426#comment:15 for consistency with rbm?

Replying to cypherpunks:

Hmm, why didn't you try ticket:20426#comment:15 for consistency with rbm?

This is unrelated to this issue.

It seems we might want to disable startup cache generation like mozilla did: https://bugzilla.mozilla.org/show_bug.cgi?id=1351071

This patch applies correctly on our branch: https://github.com/mozilla/gecko-dev/commit/b7af545070788b5a50cb1752e878a1de79e37ed3.patch

I have started 2 builds in rbm with this patch to check if it removes the diff in omni.ja.

Replying to boklm:

I have started 2 builds in rbm with this patch to check if it removes the diff in omni.ja.

And the 2 linux64 builds produced the same bundle.

Replying to boklm:

Replying to cypherpunks:

Hmm, why didn't you try ticket:20426#comment:15 for consistency with rbm?

This is unrelated to this issue. Yes, it is just to reduce the diff. Mozillians mentioned that buildid could be the root cause. But deterministic mode for mozjar is a general solution. Of course, it's easier just to disable startup cache pre-compilation/pre-generation.

Thanks. This is commit ec0b55bdfb638c63f30116b19583456632ad708d on tor-browser-52.1.0esr-7.0-1 and will make it into the final 7.0a3.

Trac:
Status: new to closed
Resolution: N/A to fixed

closed

moved to tpo/applications/tor-browser#21960 (closed)