The primary download website is download.replicant.us and it is hosted
on the Replicant VM at the FSF. It's also a good idea to keep
https://ftp2.osuosl.org/pub/replicant/ so we need to keep releasing
there as well.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

In the Replicant 6.0 0004 transition release, we have the following
patches on top of the vendor/replicant master branch:
    53ab2743 Release Replicant 6.0 0004 transition release
    6c2772be Re-run the key migration at each boot
this is because for transition releases, we need two apply two patches
instead of one in vendor/replicant in the builder source code.

The goal of the transition releases is to enable users running images
signed with older keys to migrate to new images that are signed with
newly generated keys (which are stored in vendor/replicant-security),
without having to erase all their data.

This requires an extra patch to enable the service that runs the key
migration script at each boot.

After booting a transition release, users are expected to install a
regular release like the Replicant 6.0 0004 in order not to have the
key migration run at each boot (if the power runs out precisely
when the migration script runs, users could loose all their data).

The second patch is similar to what we have in all other releases: it
just sets the release versions and potentially adds release notes to
the changelog.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

Without that fix, when releasing the metadata, the release.sh script
blocks with a pager with the following content:
    Saved manifest to [...]/metadata/manifest.xml
If the user press 'q', the pager exit and the release proceed.

This removes this pager and makes the release proceed without human
intervention anymore.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

Without that fix, we end up with no zip files in the release, so we
can't install Replicant.

This was broken by commit 10c741bd9ff53e86e6a5035f09af159f7116b6c8
(releasevars.sh: generate RELEASE_IMAGES from RELEASE_DEVICES).

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

The releases are now built from a source tarball that is then
officially released and signed as part of the release process.

So having to force push to correct mistakes during a release is still
possible until that tarball is signed and officially released.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

The square brackets ([]) are most of the time used for optional
arguments, but here the REPLICANT_DIR argument is mandatory, so we use
the Less-than and more-than signs (<>) instead as they are typically
used for mandatory arguments.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

Without that fix, if the output directory is not the current directory
(. or ./), making the tarball fails:
    $ ./make_source_tarball.sh replicant-6.0-0004 releases
    Fetching projects: 100% (502/502), done.
    Checking out projects: 100% (502/502), done.
    repo sync has finished successfully.
    tar: releases/replicant-6.0-0004: Cannot stat: No such file or directory
    tar: Exiting with failure status due to previous errors
    lzip: replicant-6.0-0004.tar: Can't open input file: No such file or directory

This is because the path that referred to the Replicant source
directory was relative to the directory that the user was in when
launching make_source_tarball.sh, instead of being relative to the
current directory, in the script, when running the tar command.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

This script makes a patch out of the latest commit from the following
repositories:
- ../vendor_replicant-release-scripts
- ../vendor_replicant
- ../manifest
it then apply them inside the respective directories inside the
replicant directory on another machine, with SSH and Rsync.

When doing a release we typically need to change the Replicant
version, and so that requires to add 1 patch to each of the
repositories mentioned above.

However in some cases, the Replicant directory is on another
computer. This is for instance the case for people working on their
laptop and building Replicant on another machine.

The release process already takes care of that situation but it
required to manually apply patches on the remote builder before
tagging the source code.

And the Replicant 6.0 0004 RC6 release failed because some patches
were missing in the released (and signed) source code. So it's better
to automate things to avoid forgetting patches for the next releases.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

The xz format is not well adapted for long term archiving[1]
as the format has a lot of room for incompatible
implementations. In addition, the format is very fragile
which makes it harder to implement robust and easy to use
recovery tools.

In contrast the lzip format is designed to make it easy to
recover data from corrupted archives and a tool
(lziprecover[2]) already exists for that.

There are also several downsides of using lzip over other
compression formats (like xz, gzip or bzip2):
- The lzip package usually needs to be installed, and there
  is no 'unlzip' command (users are expected to use
  'lzip -d' instead), and for progression you need two -v
  instead of one but at least once lzip is installed,
  tar commands work out of the box[3].
- There is no option to use more than one thread in the most
  popular lzip implementation (GNU lzip).

In addition, for the previous Replicant 6.0 source releases
tarball, xz -9e compresses more than lzip -9.

Here the size in bytes (retrieved with du -b <path>) of the
replicant-6.0-0001.tar source release:
13415884800     replicant-6.0-0001.tar
5732651960	replicant-6.0-0001.tar.xz
5927113267	replicant-6.0-0001.tar.lz

And for replicant-6.0-0004-rc5:
15629813760	replicant-6.0-0004-rc5.tar
6662406932	replicant-6.0-0004-rc5.tar.xz
6969502733	replicant-6.0-0004-rc5.tar.lz

[1]https://www.nongnu.org/lzip/xz_inadequate.html
[2]https://www.nongnu.org/lzip/lziprecover.html
[3]For instance 'tar xf replicant-6.0-0004-rc5.tar.lz' or
   'tar tf replicant-6.0-0004-rc5.tar.lz' work out of the
   box.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

Without that fix, running releasetag.sh in the replicant root
directory fails:
    $ ../releasetag.sh ./
    ../releasetag.sh: line 26: releasevars.sh: No such file or directory

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>