... | ... | @@ -55,7 +55,7 @@ apt install libyaml-libyaml-perl libtemplate-perl libdatetime-perl \ |
|
|
libfile-copy-recursive-perl libfile-slurp-perl git uidmap
|
|
|
```
|
|
|
|
|
|
For other distros, please refer to your system's documentation for instructions on installing them.
|
|
|
For other distros, please refer to your system's documentation.
|
|
|
|
|
|
The final requirement is git, which is also called during the build steps, not only to fetch the tor-browser-build repository.
|
|
|
|
... | ... | @@ -77,7 +77,7 @@ Our build system checks the integrity of the code it downloads whenever possible |
|
|
|
|
|
Tor Browser has three release channels:
|
|
|
|
|
|
* stable (also called release in the code)
|
|
|
* stable (also called simply _release_ in the code)
|
|
|
* alpha
|
|
|
* nightly
|
|
|
|
... | ... | @@ -103,15 +103,15 @@ We have an additional configuration that we call _testbuild_. It can be based on |
|
|
The main difference with the base target is that desktop test builds are English-only (Tor Browser on desktop creates an installer for each language, which is time-consuming because of the compression).
|
|
|
|
|
|
The difference on Android is that while regular builds compile GeckoView for all architectures, testbuilds compile it only for the desired one.
|
|
|
This reduces the build time by half to 3 hours (or more) depending on the machine.
|
|
|
This reduces the build time by half to 3 hours (or more) depending on your machine.
|
|
|
|
|
|
# Running the build
|
|
|
|
|
|
## Git branches and tags
|
|
|
|
|
|
**Targets are not guaranteed to work in every possible git tree**. You should `git checkout` the correct branch/tag before starting a build.
|
|
|
**Targets are not guaranteed to succeed in every possible git tree**. You should `git checkout` the correct branch/tag before starting a build.
|
|
|
|
|
|
We run nightlies at the latest commit of the `master` branch, but they should generally run everywhere.
|
|
|
We run nightlies at the latest commit of the `master` branch, so they should run at every commit of the history.
|
|
|
|
|
|
Alphas are also based on `master`, but they are run on a specific annotated tag (we create it just before an alpha release).
|
|
|
The tag name usually has this format: `tbb-VVVV-buildN`, where `VVVV` is the version and `N` is the build number.
|
... | ... | @@ -136,11 +136,11 @@ The most likely to be changed settings are: |
|
|
|
|
|
## The actual build process
|
|
|
|
|
|
The makefile is very short, as it mainly contains calls to `rbm`, with the different targets set.
|
|
|
The makefile is very short, as it mainly contains calls to `rbm`, with different targets.
|
|
|
|
|
|
If you want to build Tor Browser without any changes, just call `make` with one of those targets (see above for more details on the targets).
|
|
|
If you want to build Tor Browser without any changes, just call `make` with one of those targets (see above for more details on their meaning).
|
|
|
|
|
|
Please notice that, for reproducibility purposes, we compile many of the tools we use, including GCC, Clang, Rust, Go, and others. Therefore, the first build will take a really long time. The following ones will be faster.
|
|
|
Please notice that, for reproducibility purposes, we compile many of the tools we use, including GCC, Clang, Rust, Go, and others. Therefore, the first build will take a really long time. The following ones will be faster because they will reuse all the artifacts that are up to date.
|
|
|
|
|
|
You can also call `rbm` directly to build only one component, for example:
|
|
|
|
... | ... | @@ -177,7 +177,7 @@ Also, you may want to adjust the directory to remove. |
|
|
|
|
|
The build archives/installers will be in one of these directories of `tor-browser-build`:
|
|
|
|
|
|
* `release`, `alpha:` here, you can find the installers of Tor Browser stable and alpha, respectively. They are organized by version, each of which has a `signed` and an `unsigned` subdirectory: you will find the installers created by you on the latter;
|
|
|
* `release`, `alpha`: here, you can find the installers of Tor Browser stable and alpha, respectively. They are organized by version, each of which has a `signed` and an `unsigned` subdirectory: you will find the installers created by you on the latter;
|
|
|
* `nightly`: here, you can find the installers for nightly builds grouped by date. Nightly builds are never signed;
|
|
|
* `testbuild`: here, you can find the installers created by the testbuilds. Testbuilds are neither signed nor versioned, they are only organized by platform, so if you run one, it will replace any already existing one for the same platform/architecture combination.
|
|
|
|
... | ... | @@ -186,7 +186,7 @@ In addition to that, you will notice that some other directories occupy a lot of |
|
|
* `git_clones`: as written above, `tor-browser-build` downloads the source code for all the components that it compiles, and, in the case of git repositories, it places them there. RBM manages these directories automatically, and usually you should not need to do anything there;
|
|
|
* `out`: this directory is used for artifacts (compilation output of a component), source code archives, precompiled dependencies downloaded from the Internet, and possibly other files.
|
|
|
|
|
|
Finally, `logs` contain the logs file, organized by project. By default, new builds append to the exiting logs, but this behavior can be customized.
|
|
|
Finally, `logs` contains the log files, organized by project. By default, new builds append to the exiting files, but this behavior can be customized.
|
|
|
|
|
|
### Verify it
|
|
|
|
... | ... | @@ -194,12 +194,14 @@ In the same directory as the installers, you will find the installer hashes. |
|
|
|
|
|
If you followed these instructions without changing anything, you should obtain the same hashes as our unsigned builds.
|
|
|
|
|
|
We sign and upload our `sha256sums-unsigned-build.txt`, so you can also download them, and run `sha256sum -c sha256sums-unsigned-build.txt` (and possibly, verifying their signatures first).
|
|
|
We sign and upload our `sha256sums-unsigned-build.txt`, so you can also download them, verify their signatures, and run `sha256sum -c sha256sums-unsigned-build.txt`.
|
|
|
|
|
|
Our signatures are detached, so if you used the same `make` target as us, you can also only download the signature, and it should match your `sha256sums-unsigned-build.txt`.
|
|
|
Our signatures are detached, so if you used the same `make` target as us, as an alternative you can also only download the signature, and it should match your `sha256sums-unsigned-build.txt`.
|
|
|
|
|
|
Otherwise, please check that you are using the correct hashes, and then consider contacting us, as we may treat your case as an issue.
|
|
|
|
|
|
For desktop builds, we produce also smaller, incremental archives (`make incrementals-{release,alpha,nightly}`): their hashes are in `sha256sums-unsigned-build.incrementals.txt`, instead, but they should match as well.
|
|
|
|
|
|
## Cleaning the artifacts
|
|
|
|
|
|
Since we often switch git branches, `make clean` tries to remove old artifacts in a smart way.
|
... | ... | @@ -241,7 +243,7 @@ Before starting using the debug shell, there are a couple of usually optional bu |
|
|
|
|
|
The first one is setting the `TERM` variable, possibly to match your current terminal (usually `xterm-256color` or `tmux-256color`, etc..).
|
|
|
|
|
|
Then, you will likely want to start bash because the default shell has limited capabilities for interactive sessions.
|
|
|
Then, you will likely want to start Bash because the default shell has limited capabilities for interactive sessions.
|
|
|
|
|
|
```shell
|
|
|
export TERM=xterm-256color
|
... | ... | @@ -249,7 +251,7 @@ bash |
|
|
```
|
|
|
|
|
|
`TERM` must be set to launch some building systems (notably, Firefox's one) and some other programs, such as nano.
|
|
|
In bullseye-based containers (and following versions), the terminal type influences bash, too, so setting it before launching the shell is better.
|
|
|
In bullseye-based containers (and following versions), the terminal type influences Bash, too, so setting it before launching the shell is better.
|
|
|
|
|
|
### What to do there
|
|
|
|
... | ... | |