[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #27443 [Applications/Tor Browser]: Update Firefox RBM config and build for Android
#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs