GitLab

This includes:

 - Remove some obsolete information (e.g. we don't customize
   search engines anymore).
 - Group together related information.
 - Add information that could be useful to the Tor Browser team.

As demonstrated by #17005#note-11, the reader may follow the "Build the website
in Linux" section when using Tails, instead of the one that would work for
them ("Build the website in Tails").

Six months after the Buster release, it should be safe to assume the reader runs
Stretch (oldstable) or newer.

For details, see #16315.

Thanks!

The code had two problems:

 - For the "torproject" archive, it was checking the "stable" suite,
   which we don't track anymore.

 - For the "debian-security" archive, it was checking the stretch/updates
   suite, which we don't track anymore.

… both spotted by kibi during the 4.2 release process.

Thankfully, our build system can build from a tag, as long as
the corresponding version is marked as released in the changelog.

We need the smartcard later this, to sign the UDFs.

In the general case this is not needed, but we've just hit a corner
case where the lack of this harmed us, so better safe than sorry.

The previous command wrote the absolute path of each IUK in $IUK_HASHES, which
would later break at the copy-iuks-to-rsync-server-and-verify stage.

It's easy to overlook it, and some later steps might fail depending on
which parts are run in parallel, possibly in different terminals.

If we're keeping this old entry, let's be explicit about who did what.

Without this, errors would go unreported: further steps within the for
loop would be performed, and all source versions would be attempted. If
one is lucky, a general issue (missing backslash somewhere) could easily
be spotted as it would affect all source versions. In worse cases, a
failure somewhere in the middle could go unnoticed.

Therefore: use “set -e” locally, and print an explicit error message
when any failure happens; also break out of the loop to ensure the first
issue is fixed before considering other items.

Over-quoting leads to ENOENT at the chown stage. Possibly due to copying
and pasting from within the sudo call to outside it, keeping the
protected quotes, while the protection should have gone away.

Mainly for consistency.

It's needed to trigger the Jenkins job, and the shell session in which
it was computed will likely be busy with the IUK generation already.

It often happens that we push release process fixes to master
(e.g. that's most convenient place where one can push such fixes
during a release process). But then, if the RM follows the previous
version of this doc, and nobody merged master into the release branch
recently enough, then they'll miss these fixes. This just happened :(