#27443: Update Firefox RBM config and build for Android -------------------------------------------------+------------------------- Reporter: sisbell | Owner: tbb- | team Type: defect | Status: | needs_revision Priority: Very High | Milestone: Component: Applications/Tor Browser | Version: Severity: Normal | Resolution: Keywords: tbb-rbm, tbb-mobile, TBA-a2, | Actual Points: TorBrowserTeam201811 | Parent ID: #26693 | Points: Reviewer: | Sponsor: -------------------------------------------------+-------------------------
Comment (by gk): Replying to [comment:62 sisbell]: > Replying to [comment:61 gk]: > > Replying to [comment:57 gk]: > > > Okay, I spent quite some time to set up infrastructure to be able to compare a non-failing build with a build one by disabling piece-by-piece parts of the toolchain we built. It turns out that just using the Rust compiler is causing all the errors for me. That is: once I use rustup everything is fine (all other things being equal). > > > > > > I'll double-check that as I am not sure yet why the non-rust files should be affected but that's what my testing currently gives me. > > > > Confirmed. Just switching back to the pre-built 1.30 and leaving all other things the same gets rid of all the errors seen in comment:47. > > So I'm able to successfully build tor-browser with NDK 16 and Rust 1.28.0, which is what Mozilla is using to build firefox 63. It seems Mozilla is using NDK r17b and *API level* 16 in Firefox 63, no? See: https://bugzilla.mozilla.org/show_bug.cgi?id=1482330. > Android APK installs and runs. Is there any objection to using this configuration? Well, it seems we tested the last alpha releases with NDK r15c. So, I am very reluctant to change that unless it is really needed. And, in fact, that does not seem to be the case for me as I can compile Firefox for mobile fine by just bumping the Rust version to 1.28.0 and leaving the NDK version alone. Or are you indicating that a Tor Browser for Android compiled that way is encountering runtime issues (admittedly I did not test that)? So, hopefully, that leaves the question what to do with the Rust version. I guess due to sysrqb's build script we have been using whatever Rust version was stable once we released a new Tor Browser for Mobile, so switching to 1.28.0 does not sound problematic from that perspective. However, there are two reasons which make me hesitate: 1) It adds complexity for our (alpha) build process as all the other alpha bundles get compiled with 1.26.1. 2) There is the risk we introduce new, uncaught reproducibility issues while we seem to have a good understanding about the problems in 1.26.1 (see the long story on that in #26475). So, I try to pin down this week what exactly got fixed in 1.28.0. Ideally, it's a small patch we can backport for 1.26.1. If so, then that's the thing we should do. If not, or if the bisecting takes too long (I already encountered a bunch of bustage while trying to figure out the nightly version first, that fixed the problem), then we should go with 1.28.0 for this release and think about a better fix for the upcoming alpha releases. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27443#comment:63> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs