generate-languages-list is not meant to be used directly
by anyone, so let's move it out of the way.
auto/build has auto/scripts/ in its $PATH.

This avoids this error during the build:

  touch: cannot touch 'config/chroot_local-includes/live/overlay': No such file or directory
  touch: cannot touch 'config/chroot_local-includes/lib/live/mount/persistence': No such file or directory
  touch: cannot touch 'config/chroot_local-includes/etc/apparmor.d/disable/usr.bin.man': No such file or directory

Filtering out such errors when looking at a build log takes cycles.

Currently translated at 17.7% (11 of 62 strings)

Translation: Tails/wiki/src/news/version_3.14.1.*.po
Translate-URL: http://translate.tails.boum.org/projects/tails/wikisrcnewsversion_3141po/pt/

Currently translated at 39.0% (16 of 41 strings)

Translation: Tails/wiki/src/news/version_3.11.*.po
Translate-URL: http://translate.tails.boum.org/projects/tails/wikisrcnewsversion_311po/it/

 - isohybrid is available in our Vagrant build VMs. The manual build
   documentation is totally outdated and broken, nobody complained about it,
   which suggests nobody tried to follow it since 1+ years.
   And anyway, if isohybrid is not installed, the build will fail loudly
   later on.

 - $LB_BINARY_IMAGES is correctly set because auto/config passes
   "--binary-images iso" to "lb config". Checking it here brings no value and
   just makes things harder for anyone who would want to add support for other
   kinds of images.

 - It's been a while since we've stopped releasing source tarballs :) One can't
   reach auto/config via "rake build" if one is not building from Git, and
   building without rake is unsupported (good luck with that).

This version requirement is satisfied by Jessie and I doubt Tails would build in
anything older.

And anyway, we now only support building in Vagrant, which guarantees us we have
a recent enough syslinux installed.

Previously we would start cloning the output later in auto/build, because we
needed to do a bunch of things first, until we could figure out what the name of
the build log file was. This is not the case anymore and we can thus generate
a more complete build log.

A future improvement would be to move this to the Rakefile or to build-tails,
but that's more involved and I'm after low-risk, easy incremental improvements
at the moment.

Our Vagrant build boxes are all Stretch nowadays.

This will help understand, while looking at a build failure log, what's an
informational message we've intentionally printed vs. what's additional info (or
noise) produced by tools we call.

This convention is used in many Debian things and in some of our
own source code already.

By default mksquashfs will use 25% of the physical memory. So when we use the
"ram" build option, build in a VM with 13GB of RAM, of which up to 12G is
supposed to be used by the build tmpfs, mksquashfs will try using 13/4 = 3.25G
of memory. And then it will get reaped by the OOM killer more or less
occasionally depending on how much space is really used in the build tmpfs and
how much memory the rest of the system is using. So let's limit the memory
used by mksquashfs to 50% of the memory we allocate to the build VM,
excluding the part of it that we expect tmpfs data to fill.

In passing, the fact mksquashfs does not get killed every time suggests that our
current BUILD_SPACE_REQUIREMENT value exceeds the real needs of a build: a value
around 10 or 11G should be enough. But that will be for another commit.

By default mksquashfs will use 25% of the physical memory. So when we use the
"ram" build option, build in a VM with 13GB of RAM, of which up to 12G is
supposed to be used by the build tmpfs, mksquashfs will try using 13/4 = 3.25G
of memory. And then it will get reaped by the OOM killer more or less
occasionally depending on how much space is really used in the build tmpfs and
how much memory the rest of the system is using. So let's limit the memory
used by mksquashfs to 50% of the memory we allocate to the build VM,
excluding the part of it that we expect tmpfs data to fill.

In passing, the fact mksquashfs does not get killed every time suggests that our
current BUILD_SPACE_REQUIREMENT value exceeds the real needs of a build: a value
around 10 or 11G should be enough. But that will be for another commit.

This should fix:

  gpg: cannot open '/dev/tty': No such device or address

Fix copied from f9605653.

This problem will start affecting any branch that uses a recent APT snapshot for
the "debian" archive in the Vagrant build VM.

Since commit:936d444b we don't need
pipefail anymore.

And since commit:aed1c5fa we run under "set -e",
so manually checking for the exit code of "lb build" is useless.

Note that I'm leaving a bunch of "|| fatal MSG" elsewhere because
they provide nicer error messages.

We still had part of the pre-existing code guarded by "if [ -e binary.iso ]" in
a "then" close, while the new code for the USB image support was added
elsewhere.

The project was renamed, what, 8 years ago?

The project was renamed, what, 8 years ago?

anonym authored Feb 20, 2016 and segfault committed Feb 27, 2018

This library contains useful stuff for our effort of converting shell
scripts into python.

Refs: #11198

The copy of the website included in the ISO image has "Posted" timestamps that
apparently match when we cloned the Git repository. This is expected since we
build the website with the rcs setting disabled. Normalizing timestamps before
building should fix this.

What's surprising though is that only a few pages seem to be affected, while
I would expect that all inlined pages without an explicit meta date should
trigger the exact same problem. But anyway, normalizing mtime should fix it
everywhere, so if it works, let's not bother investigating this further.

One potential drawback of this commit is that it may make it harder to refresh
an older, cached build of the website when we reintroduce this option in the
future:  ikiwiki will have a hard time knowing which pages it should refresh.
We'll see.

This should be a no-op change.

In most cases, $BUILD_BASENAME contains a timestamp, so when building twice in
a row from the same commit, we could not have got the same ISO anymore.

Previously, a given build from a topic branch would mix inconsistent versions
of things. Most changes done in $topic_branch..$base_branch would be taken into
account, but some would not, e.g. changes that affect:

 * everything we set up in auto/config, such as
    - copying tails-transform-mirror-url,
      gnome-shell-extension-florence-indicator
    - APT snapshots
    - debian/changelog, used by `apt-snapshots-serials prepare-build'
 * auto/build

In practice, we've been suffering from some consequences of this problem
e.g.:

 * ISO build failed on documentation branches based on master;
 * topic branches fail to build building once the APT snapshots they encode
   disappears, even though their base branch encodes newer & valid APT
   snapshots.

This commit implements a cheap and partial fix: as stated on
https://labs.riseup.net/code/issues/14459, the base branch merge still happens
too late e.g. to take into account auto/config changes done in
$topic_branch..$base_branch. Ideally we should do the base branch merge first
thing in the build process, in a manner that's isolated from other build steps,
so that *all* build code except the tiny script that performs the merge will be
in the correct state.

... via the `mergebasebranch` build option.

Will-fix: #12556

So that issues such as #12453 don't go unnoticed anymore.

It was a misunderstanding to remove it.

This is more coherent with the way auto/* and Jenkins name this
variables too.

Refs: #11972

We definitely need this enabled on Jenkins. For others, let's not
enable it by default since it has quite a large impact, and might be
surprising.

We don't need to make our SquashFS exportable over NFS.

refs: #11971