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

lb_chroot_resolv will "cp -a" it from the source tree, so it inherits its
ownership from the whoever cloned the Git repository. This has two problems.
First, this results in unsafe permissions on this file (e.g. a Vagrant build
results in the 'amnesia' user having write access to it). Second, building with
a different user results in a non-deterministic SquashFS.

refs: #5630

refs: #5630

This reverts commit b006d507.

In current Stretch, debootstrap fails if we use eatmydata + the operation mode
picked by live-build when caching is enabled.

This may render the SquashFS creation deterministic, but this may make
the resulting SquashFS substantially larger.

Side effect is that everyone will now merge the base branch in their
feature branch before building.

Will-fix: #11972

Don't pass -mkfs-fixed-time to mksquashfs, instead rely on having it honor $SOURCE_DATE_EPOCH (refs: #5630).

This reverts commit 0f56eea5.

refs: #11903

refs: #11903

refs: #10298

Note that we disable aufs internal debug code, since it's disabled in
Jessie's kernel, and Kconfig reads: "It will have a negative impact to
the performance".

… and drop mere echo'ing of them to the build log.

This will make it easier to debug builds: looking at a dedicated file is easier
than finding the relevant info in a huge build log.

At this point, it doesn't feel worth it to make the generated file
machine-readable, but surely we can do it if/when we need that later on.

For now, we hard-code arbitrary snapshot serial numbers in the build
configuration. They at least allow us to write and test the code that
reads them from the configuration tree.

refs: #10748