Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by JeremyRand):

 > Maybe having this ticket a parent and the respective approaches child
 tickets seems to be the cleanest one?

 Sounds good to me.  I've just created a child ticket for the x86_64 build
 arch.  @holin Feel free to create a child ticket for your work with arm64
 build arch.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by gk):

 Replying to [comment:42 JeremyRand]:
 > This issue is becoming confusing to follow due to the existence of two
 different patches (ARM target with x86 host, versus ARM target with ARM
 host).  May I request that this issue be split into 2 issues?  Both
 patches are independently useful, and I think they should both be merged
 when complete (regardless of which is completed first).  Having 2 separate
 issues for them makes it easier to follow the discussion, and allows the
 issues to be independently closed as fixed whenever the respective patches
 are merged.  (I don't particularly care which patch is assigned to a new
 issue, or if both patches are assigned to a new issue and this issue
 becomes a parent/metaissue.)

 That's a good point. I am fine either way. Maybe having this ticket a
 parent and the respective approaches child tickets seems to be the
 cleanest one?

 [snip]

 > I also now have an ESR 68 patch at https://notabug.org/JeremyRand/tor-
 browser-build/src/armhf-esr68-draft .  It doesn't build yet, and I suspect
 that rebasing it against a newer version of `tor-browser-build` master
 branch is likely to fix a lot of the build issues I'm running into.  I get
 the impression that `tor-browser-build` was in a pretty bad state at the
 point I rebased against, which was August 8.  (Georg, can you confirm that
 the August 8 version of `tor-browser-build` master branch is expected to
 have a lot of problems?)

 Yeah, sorry for the inconvenience. We were barely able to have everything
 ready for having some sort of nightly builds for Linux available at that
 time and just had switched over to esr68. `master` should be in much
 better shape now than it had been at that time.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by JeremyRand):

 Correction: ESR 68 patch is at https://notabug.org/JeremyRand/tor-browser-
 build/src/armhf-esr68 (`armhf-esr68` branch).  The `armhf-esr68-draft`
 branch I linked earlier is unstable and may contain untested patches.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by JeremyRand):

 This issue is becoming confusing to follow due to the existence of two
 different patches (ARM target with x86 host, versus ARM target with ARM
 host).  May I request that this issue be split into 2 issues?  Both
 patches are independently useful, and I think they should both be merged
 when complete (regardless of which is completed first).  Having 2 separate
 issues for them makes it easier to follow the discussion, and allows the
 issues to be independently closed as fixed whenever the respective patches
 are merged.  (I don't particularly care which patch is assigned to a new
 issue, or if both patches are assigned to a new issue and this issue
 becomes a parent/metaissue.)

 Meanwhile, updated ESR 60 patch (this is the "ARM target with x86 host"
 patch) at https://notabug.org/JeremyRand/tor-browser-build/src/armhf-esr60
 .  This is tested to build a Tor Browser binary that runs fine on my Asus
 C201, and is based on `tor-browser-build` master branch as of circa a week
 before Tor migrated to ESR 68.  I've done a lot of cleanup of the code, so
 hopefully this will be a lot easier to review than my previous patches.
 Still not yet in a state where I'd recommend considering it for merging.
 In particular, I haven't yet resolved Georg's concern about the network
 being enabled for the Firefox and Tor build containers.

 I also now have an ESR 68 patch at https://notabug.org/JeremyRand/tor-
 browser-build/src/armhf-esr68-draft .  It doesn't build yet, and I suspect
 that rebasing it against a newer version of `tor-browser-build` master
 branch is likely to fix a lot of the build issues I'm running into.  I get
 the impression that `tor-browser-build` was in a pretty bad state at the
 point I rebased against, which was August 8.  (Georg, can you confirm that
 the August 8 version of `tor-browser-build` master branch is expected to
 have a lot of problems?)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by gk):

 FWIW: We are mostly done with our switch to Firefox 68 ESR toolchain-wise
 which might cause additional work to be done for this bug. `master` as of
 commit 2d3e92fc4f3e7961a469d5f0a50ebc9b067c08cc should have all the
 necessary changes. We don't expect huge changes anymore for the ESR
 68-based Tor Browser cycle.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by leshik):

 Thanks for your great effort!

 Tried `8.0.3` on `armhf` and then `8.5.4` on both `armhf` and `arm64` (on
 `RPi 3B+`). It works fine (but I only used the `tor` proxy part, not the
 browser.)

 What else is left that prevents this work from being merged upstream?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by holin):

 I tested 8.5.1 with my changes and subsequent armhf builds appear to have
 identical SHA-256 sums, all languages.

 My arm tree assumes an arm64 builder host right now, but still supports
 building on armhf. It would be slightly cleaner (esp. projects
 /debootstrap-image) if armhf stuff was cleared out, and, I'll probably do
 that because building rust is way too unpredictable on 32-bit builder
 host. 64-bit built armhf binary seems to behave fine, and the above
 reproducibility was tested with 64-bit builder.

 Compared to my first 8.0 tree, I added gnu triplets to all targets, and I
 think having them would also be beneficial for cross building. The
 triplets could replace the arch variable as far as I can see.

 Cross building would seem to be much cleaner done if the build host had
 debian stretch base because of better apt multiarch support, but I haven't
 really done anything substantial towards cross building yet. Arm64 would
 likely require debian stretch level glibc regardless of how it's built.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by gk):

 Replying to [comment:37 holin]:
 > Replying to [comment:33 gk]:
 > > Replying to [comment:31 holin]:
 > > > My maint-8.0-armhf branch is now a bit cleaner and the x86 stuff
 should build like it did originally without the arm changes interfering.
 > > >
 > > > I also uploaded a set of binaries to
 > > > https://sourceforge.net/projects/tor-browser-ports/
 > > > in case there's someone who'd like to test it out. So far, I've only
 tested basic functionality on an ARM laptop running Debian stretch.
 > > >
 > > > Going forward, I'll probably import the changes over to master and
 try to get nightly to build. However, in the grand scheme of things, Rust
 and Firefox are heavy beasts and, I think, assuming tor project even
 considers native build an option, supporting 32-bit build platforms is not
 the way to go unless the said behemoths suddenly lose some serious weight.
 > >
 > > Yes, building on 32-bit is going to be harder an harder which is the
 reason why Mozilla and we cross-compile our Linux 32-bit builds. So, while
 I have the feeling that building natively would be easier here, it's not
 the way we can go I think (while likely switch to Rust 1.33 for Firefox
 ESR 68 and Firefox itself gets larger and not smaller).
 > >
 > > However, it would be interesting to see how this would look like
 cleaned up a bit against our brand new `maint-8.5` branch, which e.g.
 ships binutils 2.31.1. If you want to look at getting nightly builds going
 see my previous comment for the snowflake situation.
 > >
 > > Is the result you get reproducible?
 >
 > Playing catch-up, I haven't really checked reproducibility. What would
 be the best way to do that? I don't really have an armada of ARM machines
 with different setups here..

 I think comparing the SHA-256 of subsequent builds on the same machine
 would be a good first test.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by holin):

 Replying to [comment:33 gk]:
 > Replying to [comment:31 holin]:
 > > My maint-8.0-armhf branch is now a bit cleaner and the x86 stuff
 should build like it did originally without the arm changes interfering.
 > >
 > > I also uploaded a set of binaries to
 > > https://sourceforge.net/projects/tor-browser-ports/
 > > in case there's someone who'd like to test it out. So far, I've only
 tested basic functionality on an ARM laptop running Debian stretch.
 > >
 > > Going forward, I'll probably import the changes over to master and try
 to get nightly to build. However, in the grand scheme of things, Rust and
 Firefox are heavy beasts and, I think, assuming tor project even considers
 native build an option, supporting 32-bit build platforms is not the way
 to go unless the said behemoths suddenly lose some serious weight.
 >
 > Yes, building on 32-bit is going to be harder an harder which is the
 reason why Mozilla and we cross-compile our Linux 32-bit builds. So, while
 I have the feeling that building natively would be easier here, it's not
 the way we can go I think (while likely switch to Rust 1.33 for Firefox
 ESR 68 and Firefox itself gets larger and not smaller).
 >
 > However, it would be interesting to see how this would look like cleaned
 up a bit against our brand new `maint-8.5` branch, which e.g. ships
 binutils 2.31.1. If you want to look at getting nightly builds going see
 my previous comment for the snowflake situation.
 >
 > Is the result you get reproducible?

 Playing catch-up, I haven't really checked reproducibility. What would be
 the best way to do that? I don't really have an armada of ARM machines
 with different setups here..

 Regarding the arch naming, I think either using the gnu-triplet or osname
 + whatever the os calls the archs would be best. In case of linux, using
 debian's naming would make sense to me. I changed the naming to linux-
 armhf in my tree.

 I've updated my changes to maint-8.5 and also added arm64 / aarch64
 support. The arm64 port is sketchy because it would not build on jessie's
 glibc (some problem with limited TLS slots) and, on the other hand,
 stretch does not include hardening-wrapper anymore. The whole hardening-
 wrapper thing, though, should imho be replaced with a local project that
 could use apt in debian's recommended way to set the flags. Anyway, as a
 consequence, arm64 build does not have hardening right now.

 I had to change a few more projects because you (upstream) had gotten rid
 of a generic linux target and replaced that with separate i686 and amd64
 targets, so the arm archs had to have their own bits there as well.

 My maint-8.5 changes for armhf and arm64 are at:
 https://notabug.org/holin/tor-browser-build/src/maint-8.5-arm

 Binaries still at:
 https://sourceforge.net/projects/tor-browser-ports/

 I'll keep on uploading binaries of releases to sourceforge, as time
 permits, until official releases become available.

 I've also briefly looked at adding a ppc64 (big endian) port, but looks
 like firefox is in a sorry state on powerpc right now.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by gk):

 Replying to [comment:35 JeremyRand]:
 > Hi @gk, thank you for the review.
 >
 > > 1) We should start to get the compiler related things right. I don't
 understand why you need to add a gcc-cross project in addition to the gcc
 project. Cross-compiling GCC so it is usable for a given target should
 just get included in the gcc project both in its config and build file I
 think.
 >
 > The reasoning here was that building a GCC cross-compiler is somewhat
 more complex than building a non-cross GCC, because with a non-cross-
 compiler, the C/C++ standard libraries shipped with Debian are sufficient,
 whereas building a cross-compiler requires building the C/C++ standard
 libraries from source.  I therefore suspected that patching the gcc
 project to build the C/C++ standard libraries would be considered too
 invasive, and I instead opted for adding a gcc-cross project so that, if
 it broke anything, the breakage would be isolated to the linux-arm target
 instead of all linux targets.  I intended to submit a follow-up patch that
 made all linux targets use gcc-cross once that code had gotten some more
 testing by the community.  That said, if you're comfortable simply adding
 that functionality to the gcc project, then I have no objection to doing
 so as part of this patch rather than as a follow-up patch later.  (Who
 knows, building the standard C/C++ library from source might yield
 improvements in reproducibility and resistance to supply-chain attacks, so
 it may be a good thing.)

 No, this approach makes sense. Maybe the project could be more
 descriptive, though, like `gcc-armhf`.

 [snipping the remaining items due to current lack of time; I hope you can
 make progress without all questions resolved in them, though]

 > Okay, sounds good.  Do you prefer GCC 7.4.0 or 7.3.0?  My patch switches
 to 7.3.0 since that was the one that someone from the Mozilla Bugzilla
 thread said definitely worked.  I'd have no objection to trying 7.4.0, or
 8, if you want that (though since I haven't tested those versions, I have
 no idea whether it will introduce new bugs).

 I think we'll go with 8.3.0 for esr68 (I hope to land this change for
 esr60 already soon).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by JeremyRand):

 Hi @gk, thank you for the review.

 > 1) We should start to get the compiler related things right. I don't
 understand why you need to add a gcc-cross project in addition to the gcc
 project. Cross-compiling GCC so it is usable for a given target should
 just get included in the gcc project both in its config and build file I
 think.

 The reasoning here was that building a GCC cross-compiler is somewhat more
 complex than building a non-cross GCC, because with a non-cross-compiler,
 the C/C++ standard libraries shipped with Debian are sufficient, whereas
 building a cross-compiler requires building the C/C++ standard libraries
 from source.  I therefore suspected that patching the gcc project to build
 the C/C++ standard libraries would be considered too invasive, and I
 instead opted for adding a gcc-cross project so that, if it broke
 anything, the breakage would be isolated to the linux-arm target instead
 of all linux targets.  I intended to submit a follow-up patch that made
 all linux targets use gcc-cross once that code had gotten some more
 testing by the community.  That said, if you're comfortable simply adding
 that functionality to the gcc project, then I have no objection to doing
 so as part of this patch rather than as a follow-up patch later.  (Who
 knows, building the standard C/C++ library from source might yield
 improvements in reproducibility and resistance to supply-chain attacks, so
 it may be a good thing.)

 > 2) Why do we have a var/linux-cross + a var/linux-arm target? It seems
 it would be worthwhile to stick to the OS-arch pattern and if we think we
 want to generate a more abstract target later on that's easily doable
 (like we have e.g. var/linux and var/linux-x86_64 defined already to have
 the option to apply general things to all the Linux arches and have arch-
 specific things, though)

 The motivation here was so that the x86 targets could use gcc rather than
 gcc-cross; see above.  Given that you're okay with moving the gcc-cross
 changes into gcc, I'm pretty sure we can get rid of the linux-cross
 target.

 > 3) Allowing networking during the build part does not fly. What are the
 needs for that?

 I agree that this is a very bad thing and isn't mergeable.  The motivation
 here is that Firefox requires some libraries (for the target arch) which
 tor-browser-build doesn't currently build from source; tor-browser-build
 instead installs the -dev package from Debian.  Unfortunately, the armhf
 versions of some of those -dev packages conflict with critical libraries
 for the x86_64 arch (I seem to recall that apt-get would uninstall the
 x86_64 C/C++ standard libraries in order to install those armhf -dev
 packages).  So, as a workaround, I used "apt-get download" in the build
 script to obtain the armhf packages without installing them, and then
 extract them to a folder that I pointed the Firefox configure script to.
 Using apt-get download inside the build script was not intended to be a
 final solution, it was simply the easiest way to continue making progress
 at making it build at all, and I intended to find a better solution prior
 to a merge.

 Anyway, I *think* a suitable way to do this would be for the container-
 image project to support downloading packages via apt-get download without
 installing them.  Then it could expose their paths to the Firefox build
 script via an rbm variable or an env variable, and Firefox's build script
 could extract them without needing to run apt-get download inside the
 Firefox build script.  Do you think this is the right way to do it, or is
 there another approach you'd prefer?  (I've never done any hacking on the
 container-image project, so it might take me some time to get this
 working, but I'm reasonably confident I can do it.)

 One other suitable way to do this would be for rbm to support "apt-get
 download" as a way of getting input files, similar to "git clone" and
 HTTP(S) downloads as are already supported.  Is adding this to rbm
 feasible?  (Maybe it's already supported and I just never ran across that
 functionality?)  If we can do that, that may be better than messing with
 container-image, since that way we avoid needing to create a new image
 that 

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by gk):

 I wonder, generally, whether we should call the OS-arch combination
 `linux-armhf` here instead of just `linux-arm`, following Debian
 (especially as we might want to support 64-bit as well in the future).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

 * keywords:  tbb-rbm, TorBrowserTeam201904R => tbb-rbm,
   TorBrowserTeam201904
 * status:  new => needs_revision


Comment:

 Replying to [comment:31 holin]:
 > My maint-8.0-armhf branch is now a bit cleaner and the x86 stuff should
 build like it did originally without the arm changes interfering.
 >
 > I also uploaded a set of binaries to
 > https://sourceforge.net/projects/tor-browser-ports/
 > in case there's someone who'd like to test it out. So far, I've only
 tested basic functionality on an ARM laptop running Debian stretch.
 >
 > Going forward, I'll probably import the changes over to master and try
 to get nightly to build. However, in the grand scheme of things, Rust and
 Firefox are heavy beasts and, I think, assuming tor project even considers
 native build an option, supporting 32-bit build platforms is not the way
 to go unless the said behemoths suddenly lose some serious weight.

 Yes, building on 32-bit is going to be harder an harder which is the
 reason why Mozilla and we cross-compile our Linux 32-bit builds. So, while
 I have the feeling that building natively would be easier here, it's not
 the way we can go I think (while likely switch to Rust 1.33 for Firefox
 ESR 68 and Firefox itself gets larger and not smaller).

 However, it would be interesting to see how this would look like cleaned
 up a bit against our brand new `maint-8.5` branch, which e.g. ships
 binutils 2.31.1. If you want to look at getting nightly builds going see
 my previous comment for the snowflake situation.

 Is the result you get reproducible?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
+
 Reporter:  mttp|  Owner:  (none)
 Type:  project | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by gk):

 Replying to [comment:26 JeremyRand]:
 > (My current code is still at ​https://notabug.org/JeremyRand/tor-
 browser-build/src/armhf-esr60 (the armhf-esr60 branch); and docs are still
 at ​https://wiki.raptorcs.com/wiki/Porting/Tor_Browser .)

 I skimmed the changes on the branch, nice work! A couple of high-level
 comments:

 1) We should start to get the compiler related things right. I don't
 understand why you need to add a `gcc-cross` project in addition to the
 `gcc` project. Cross-compiling GCC so it is usable for a given target
 should just get included in the `gcc` project both in its `config` and
 `build` file I think.

 2) Why do we have a `var/linux-cross` + a `var/linux-arm` target? It seems
 it would be worthwhile to stick to the OS-arch pattern and if we think we
 want to generate a more abstract target later on that's easily doable
 (like we have e.g. `var/linux` and `var/linux-x86_64` defined already to
 have the option to apply general things to all the Linux arches and have
 arch-specific things, though)

 3) Allowing networking during the build part does not fly. What are the
 needs for that?

 4) FTE is going away soon, just ignore it (and set the `fteproxy` switch
 in `rbm.conf` in the meantime). It's fine to ignore snowflake for now,
 too. There is a `snowflake` switch you can set in `rbm.conf` as well.

 5) Could you clean up your patches substantially and reorder them, so that
 you maybe have patches per project? It's hard to give more fine-grained
 feedback otherwise.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
+
 Reporter:  mttp|  Owner:  (none)
 Type:  project | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by holin):

 My maint-8.0-armhf branch is now a bit cleaner and the x86 stuff should
 build like it did originally without the arm changes interfering.

 I also uploaded a set of binaries to
 https://sourceforge.net/projects/tor-browser-ports/
 in case there's someone who'd like to test it out. So far, I've only
 tested basic functionality on an ARM laptop running Debian stretch.

 Going forward, I'll probably import the changes over to master and try to
 get nightly to build. However, in the grand scheme of things, Rust and
 Firefox are heavy beasts and, I think, assuming tor project even considers
 native build an option, supporting 32-bit build platforms is not the way
 to go unless the said behemoths suddenly lose some serious weight.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
+
 Reporter:  mttp|  Owner:  (none)
 Type:  project | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by gk):

 * keywords:  tbb-rbm => tbb-rbm, TorBrowserTeam201904R


Comment:

 Marking this for review for April to give feedback on the patches (thanks
 for the work on this bug!). But I'll won't have time for that until Tor
 Browser 8.5 will be out.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by holin):

 I did a quick (in coding, not in building) port of the maint-8.0 branch to
 armhf. Can "make release-linux-arm" and the resulting package appears to
 work. Build time is huge on a 4-core 4 GB arm laptop, probably 30-40 hours
 or so.

 Some ugly amd64->armhf changes were required where something like a
 "native" arch would be a better solution.

 Rust build seems like something that's very shaky on 32-bit platforms in
 general, armhf included.

 Haven't checked yet how much could be merged with JeremyRand's work, but
 I'm sure quite a bit.

 Code at:
 https://notabug.org/holin/tor-browser-build (maint-8.0-armhf branch)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by JeremyRand):

 > Would future native builds then have to utilize the cross-toolchain
 (instead of the native toolchain currently used) to achieve
 reproducibility across different host/target combinations?

 @c6h12o6 I suspect that you'd need to use something like the "gcc-cross"
 project in my branch regardless of whether you're doing a cross-compile,
 if you want reproducible builds for non-cross build and cross builds.
 Which basically means you'd be building the C/C++ standard library from
 source rather than using the Debian-packaged one; I don't think there are
 any other major differences between the gcc and gcc-cross in my branch.  I
 only made it a separate project because I didn't want the patch to get too
 invasive; a subsequent patch could replace all usage of gcc with gcc-
 cross.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by c6h12o6):

 Would future native builds then have to utilize the cross-toolchain
 (instead of the native toolchain currently used) to achieve
 reproducibility across different host/target combinations?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by JeremyRand):

 (My current code is still at ​https://notabug.org/JeremyRand/tor-browser-
 build/src/armhf-esr60 (the armhf-esr60 branch); and docs are still at
 ​https://wiki.raptorcs.com/wiki/Porting/Tor_Browser .)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by JeremyRand):

 I've updated my rbm descriptors for (32-bit) ARM.  Currently all projects
 that typically are built for GNU/Linux targets are built for linux-arm,
 with the exception of fteproxy and snowflake (and their exclusive
 dependencies).  Since fteproxy and snowflake are optional components of
 Tor Browser, my inclination is to wait until the rest of this code is
 merged by Tor before I try to make fteproxy and/or snowflake build (they
 both seem more annoying to build than most of the other projects).

 The resulting Tor Browser binaries appear to work fine in my testing on my
 Asus C201 (I connected to Tor without bridges, navigated to a JS-heavy
 website, used that website for a few minutes, and exited); I didn't try
 using the pluggable transports.  There are a couple of minor bugs in the
 shell script that launches Tor Browser (I need to patch out the SSE2 check
 and make it set LD_LIBRARY_PATH), which should be easy for me to fix.

 So, at this point, the focus is shifting from "make it run on ARM" to
 "start cleaning up the code in order to make it possible to merge".  There
 are a number of things I want to do to improve code quality; the most
 obvious ones are (1) remove all the commented out code that's leftover
 from me throwing things at the build system to see what stuck; and (2)
 improve the abstraction, so that things that apply to any GNU/Linux cross-
 compiled target are cleanly separated from things that are specific to
 32-bit ARM.  If anyone wants to start looking at my code and suggest other
 things that I should clean up prior to a merge, by all means feel free.
 Or feel free to wait a few weeks for me to get the initial stages of
 cleanup out of the way; either way works for me.

 Regarding @c6h12o6's comment: I do not see cross-compiling as a competitor
 to having non-x86 rbm hosts; I see them as orthogonal.  My ultimate goal
 here is for rbm hosts using the set of {x86, ARM, and POWER} to all be
 able to reproduce the same hashes for targets within the set of {x86, ARM,
 and POWER}.  There's no reason why that shouldn't be possible, modulo
 compiler bugs and rbm descriptor bugs that should be fixed.  I personally
 find implementing cross-compile support to be easier given my skill set,
 and it seems like a good first step (hence it's what I'm implementing),
 but I would be highly supportive of efforts to add non-x86 rbm host
 support in addition to cross-compile support.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by c6h12o6):

 When relying on cross-compilation we won't have builds that are
 reproducible on the target platform. Don't get me wrong - first of all I'd
 like to see an official Tor Browser for ARM, but I don't think it's
 future-proof to focus on the cross-compilation approach.
 (JFYI: https://notabug.org/hashashini/tor-browser-build)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by gk):

 Replying to [comment:21 gk]:
 > Replying to [comment:20 JeremyRand]:
 > > Updated my rbm descriptors for ARM to work with ESR 60.
 https://notabug.org/JeremyRand/tor-browser-build/src/armhf-esr60 (the
 armhf-esr60 branch).  Docs still at
 https://wiki.raptorcs.com/wiki/Porting/Tor_Browser .  One noteworthy thing
 is that, due to what is probably
 https://bugzilla.mozilla.org/show_bug.cgi?id=1452128 , I needed to upgrade
 to gcc 7.3.0 / binutils 2.29.1.  I don't know if that's a dealbreaker for
 Tor (and I haven't carefully tested whether the upgrade breaks anything on
 non-ARM platforms).  Can anyone from Tor comment on whether the specific
 gcc / binutils versions used by Tor Browser were chosen for a particular
 reason, and whether upgrading them would be considered if it's the most
 straightforward way to get ARM to work?
 >
 > Thanks for working on the ARM port, really appreciated! Updating GCC to
 7.3.0 is probably no problem.

 That's now #29335 and will happen in a couple of weeks once we start with
 the 9.0 alpha series and is the last missing piece as we already bumped
 binutils to 2.31.1.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by peredor):

 * cc: peredor (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by gk):

 Replying to [comment:20 JeremyRand]:
 > Updated my rbm descriptors for ARM to work with ESR 60.
 https://notabug.org/JeremyRand/tor-browser-build/src/armhf-esr60 (the
 armhf-esr60 branch).  Docs still at
 https://wiki.raptorcs.com/wiki/Porting/Tor_Browser .  One noteworthy thing
 is that, due to what is probably
 https://bugzilla.mozilla.org/show_bug.cgi?id=1452128 , I needed to upgrade
 to gcc 7.3.0 / binutils 2.29.1.  I don't know if that's a dealbreaker for
 Tor (and I haven't carefully tested whether the upgrade breaks anything on
 non-ARM platforms).  Can anyone from Tor comment on whether the specific
 gcc / binutils versions used by Tor Browser were chosen for a particular
 reason, and whether upgrading them would be considered if it's the most
 straightforward way to get ARM to work?

 Thanks for working on the ARM port, really appreciated! Updating GCC to
 7.3.0 is probably no problem. Binutils 2.29.1 is trickier, though, as with
 binutils 2.26 we have a hard to fix reproducibility issue on Windows which
 currently prevents upgrading (see: #26148). We could think about using
 2.29.1 just for ARM as a workaround (in case there are no reproducibility
 issues involved here and the Mozilla bug does not get fixed meanwhile)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by JeremyRand):

 Updated my rbm descriptors for ARM to work with ESR 60.
 https://notabug.org/JeremyRand/tor-browser-build/src/armhf-esr60 (the
 armhf-esr60 branch).  Docs still at
 https://wiki.raptorcs.com/wiki/Porting/Tor_Browser .  One noteworthy thing
 is that, due to what is probably
 https://bugzilla.mozilla.org/show_bug.cgi?id=1452128 , I needed to upgrade
 to gcc 7.3.0 / binutils 2.29.1.  I don't know if that's a dealbreaker for
 Tor (and I haven't carefully tested whether the upgrade breaks anything on
 non-ARM platforms).  Can anyone from Tor comment on whether the specific
 gcc / binutils versions used by Tor Browser were chosen for a particular
 reason, and whether upgrading them would be considered if it's the most
 straightforward way to get ARM to work?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by boklm):

 Replying to [comment:18 JeremyRand]:

 > All that said, if anyone would like to play with it, the source code is
 at https://notabug.org/JeremyRand/tor-browser-build/src/armhf (it's in the
 armhf branch), and some random documentation is at
 https://wiki.raptorcs.com/wiki/Porting/Tor_Browser .  I've successfully
 run the resulting Firefox binary on my Asus C201 Chromebook (running
 Debian Stretch) and it works fine.

 It looks like there is still a lot left to do, but very nice work!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by JeremyRand):

 I've been working on rbm descriptors for building for ARM target, and I
 successfully built Tor's Firefox fork with rbm.  Caveats:

 * Code is very messy (e.g. commented out code everywhere), I need to clean
 it up a lot.
 * Still based on the ESR 52 version of Tor Browser; making ESR 60 work
 will mean figuring out how to get Rust to build (see next item).
 * The only rbm project I've tried to build is Firefox and its
 dependencies; it's unclear how much work will be involved in building the
 other projects (e.g. tor, the Go projects, and the Rust projects).
 * The workarounds for missing target libraries (i.e. using apt-get to
 download armhf packages and extracting them to a prefix directory) are
 kind of weird, maybe there's a simpler approach than what I did?
 * I want to generalize the cross-compiling stuff some more, so that in the
 future we could add aarch64, ppc64be, and ppc64le targets without code
 duplication.  Right now the cross-compiling stuff is hardcoded for armhf,
 which is great for a proof-of-concept but not a good idea to consider
 merging.
 * I haven't tested build reproducibility.  I don't expect any problems
 here, but it's too early to be confident.

 All that said, if anyone would like to play with it, the source code is at
 https://notabug.org/JeremyRand/tor-browser-build/src/armhf (it's in the
 armhf branch), and some random documentation is at
 https://wiki.raptorcs.com/wiki/Porting/Tor_Browser .  I've successfully
 run the resulting Firefox binary on my Asus C201 Chromebook (running
 Debian Stretch) and it works fine.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by intrigeri):

 * cc: intrigeri (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by boklm):

 * cc: boklm (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+-
 Reporter:  mttp  |  Owner:
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by gk):

 Replying to [comment:12 arma]:
 > Is the issue that we don't have the build farm infrastructure? Or does
 it not build? Or does it build, but not reproducibly?

 Definitely the first. But we need to write Gitian descriptors for building
 for ARM first and I suspect there are a bunch of our myriad of components
 that are trickier to cross-compile than others. And, yes, I assume there
 will be reproducibility issues. In short: I guess this will be a non-
 trivial amount of work.

 That said: I'd be happy if a cypherpunk would show up trying to do this
 and would help them getting this done.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+-
 Reporter:  mttp  |  Owner:
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * cc: arma (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+-
 Reporter:  mttp  |  Owner:
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 This weekend I ran into a person who was trying to hack his Firefox on arm
 (raspberry pi) to do the things Tor Browser does. It sure would be better
 if we had even unofficial builds, and even if it's only whichever arm arch
 is easier (maybe that's armv8?).

 Is the issue that we don't have the build farm infrastructure? Or does it
 not build? Or does it build, but not reproducibly?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+-
 Reporter:  mttp  |  Owner:
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by c6h12o6):

 Successful compilation of Tor Browser on ASUS C201 running libreboot[1]
 and Debian Stretch with mainline kernel[2] following
 
https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#BuildingJustFirefox
 took estimated 2h.

 Please reconsider officially supporting this architecture, we'd really
 appreciate if we were able to use Tails[3] on such a fast and affordable
 device we can trust that much.

 [1] https://libreboot.org/docs/hcl/c201.html
 [2] linux-image-armmp-lpae, cf.
 https://wiki.debian.org/InstallingDebianOn/Asus/C201#Mainline_Linux_Kernel
 [3] cf. https://labs.riseup.net/code/issues/10972

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs