Hi!
I think the best list to discuss Tor Browser build problems is the
tbb-dev(a)lists.torproject.org list, so I'm anwsering there.
On Fri, 15 Nov 2019, Thomas Klausner wrote:
> Hi!
>
> I wanted to build firefox-tor-browser-68.2.0esr-9.0-1-build2
> (torbrowser 9.0.1) on NetBSD from the source tarball, but I stumbled
> over a couple problems.
>
> The first one, .mozconfig contains --disable-eme but configure doesn't like it:
>
> mozbuild.configure.options.…
[View More]InvalidOptionError: --disable-eme is not available in this configuration
>
> Is this a NetBSD-specific issue or more general?
In our linux, windows, macOS .mozconfigs we have the line:
ac_add_options --disable-eme
But I don't remember seeing this error, so it looks NetBSD-specific.
> The second one:
>
> --- begin ---
> The error occurred while processing the following file:
>
> /scratch/security/tor-browser/work/firefox-tor-browser-68.2.0esr-9.0-1-build2/browser/extensions/moz.build
>
> The underlying problem is we referenced a path that does not exist. That path is:
>
> /scratch/security/tor-browser/work/firefox-tor-browser-68.2.0esr-9.0-1-build2/browser/extensions/tor-launcher/moz.build
>
> Either create the file if it needs to exist or do not reference it.
> --- end ---
>
>
> The directory browser/extensions/tor-launcher does not exist in the
> tarball, which looks like a problem with the tarball to me.
This is a change from this ticket:
https://trac.torproject.org/projects/tor/ticket/28044
So you can either download tor-launcher, and extract it under
browser/extensions, renaming the tor-launcher-$version directory to
tor-launcher:
https://dist.torproject.org/torbrowser/9.0.1/src-tor-launcher-0.2.20.2.tar.…https://dist.torproject.org/torbrowser/9.0.1/src-tor-launcher-0.2.20.2.tar.…
Or you can build without tor-launcher by adding "ac_add_options --disable-tor-launcher"
to the .mozconfig.
Nicolas
[View Less]
Hi everyone,
Here's a plan for experimenting with moving Tor Browser from ESRs to
mozilla-central. Why try this? There are several reasons I can think
of:
* There is no mobile Firefox ESR. In order to keep mobile Tor Browser
secure, we would either need to constantly monitor for security fixes
and apply backports. It will be simpler to follow the Mozilla release
cycle.
* Tor Browser will receive all security patches and security features
from Mozilla, not simply those deemed important enough …
[View More]to backport to
the last ESR.
* Closer collaboration between Mozilla and the Tor Browser team will
be possible, because everyone will be focused on the same codebase.
For example, non-urgent patches can land directly on mozilla-central,
bypassing tor-browser.git altogether, and those patches will be
deployed to Tor Browser faster than they would have been on an
ESR-only schedule. Mozilla will provide expert review of patches.
Also, some non-urgent patches by Tor Browser may be written by Mozilla
engineers.
* The Tor Browser development process will be smoother and more
gradual. Instead of rebasing and patch-fixing sprints ahead of each
ESR, we can automatically rebase patches every night, and fix any
patch whenever its rebase fails. (The total rebase effort should be
approximately the same as before.)
* Patches that frequently break because they live on "hot code" can be
identified and uplifted.
* We'll need to continuously monitor the mozilla codebase for new
features that could harm privacy. That's potentially difficult, but by
focusing on Mozilla's current work, we can hopefully stop patches that
affect privacy before they land.
Here's how I envision the new rebase process:
* An automated script rebases all tor browser patches every night
against mozilla-central, mozilla-beta, mozilla-stable and mozilla-esr.
An email alert will be sent if the rebase of any patch fails. (I have
a prototype script that does the basic rebasing -- it found that
~40/140 patches from our ESR-52 branch could be auto-rebased onto
mozilla-central without any intervention.)
* Any failed patches will need to be manually fixed up promptly so
that the automated rebase can resume.
* Diagnostic Tor Browser bundles will be built against the latest
rebase branches. We can also run regression tests.
So how do we ramp up this experiment?
1. 2018-1-1 to 2017-2-22: Rebase tor-browser.git patches manually on
top of Firefox 59-beta. (We have to do this anyway.)
2. 2017-2-22 to 2018-3-13: Activate a script that rebases Tor Browser
patches nightly onto mozilla-(central, beta, stable, esr).
3. 2018-03-13 to 2018-05-07: Create nightly Tor Browser bundle builds
based on nightly rebases.
At this point, we can evaluate whether we would like to transition to
releasing Tor Browser alphas based on the mozilla-beta branch.
Switching Tor Browser stable to mozilla-stable can happen sometime
after that.
How does this sound? Interested to hear what you think.
Thanks,
Arthur
[View Less]