GitLab

Merge branch 'bugfix/17511-website-cache-vs-differing-changelog-entries' into stable (Fix-committed: #17511).

Otherwise, for example we can hit this scenario:

1. build1: during a built from the stable branch, the website is built with
   SOURCE_DATE_EPOCH derived from the last changelog entry on that
   branch (date1); the result of that build is cached.

2. build2: during another build from the devel branch, on a different
   isobuilder, the website is built with SOURCE_DATE_EPOCH derived from the
   last changelog entry on that branch (date2); the result of that build is
   cached; it differs from the version cached during build1, due to a different
   SOURCE_DATE_EPOCH, because the last changelog entry on the devel branch
   has a different date than the last changelog entry on the stable branch.

3. When Jenkins tries to reproduce build2, on the same isobuilder as build1, our
   build system reuses the website built with date1, which does not match the
   website built with date2 during build 2 ⇒ different images, reproducibility
   check fails.

So let's take into account debian/changelog as part of the input
on which we key our built website cache.

I'm not closing #17323 yet, because at this point we don't know if the missing
firmware was the only problem.

Once those files are in Debian and they get updated there, if we don't notice
this warning, we'll be shipping outdated firmware, which is not ideal.

I'm concerned that this warning will be hard to spot in the middle of
a 15k-lines build log, that has 30+ other warnings which are all
false positives.

So let's abort the build whenever we detect this situation.

Use the tails-workarounds provided firmwares until the firmware-realtek
package is updated with the patch by Sjoerd Simons (Debian#935969).

Make tails-workarounds directory available inside the chroot, so that
its content can be used by any chroot local hooks.

Chroot local includes seem to be the usual way to transfer things from
the Tails checkout to the chroot environment; explicitly cleaning up
/tmp afterwards doesn't seem to be needed.

No commit message

Currently translated at 69.2% (9 of 13 strings)

Currently translated at 100.0% (15 of 15 strings)

Currently translated at 99.5% (195 of 196 strings)

Currently translated at 100.0% (15 of 15 strings)

Currently translated at 100.0% (15 of 15 strings)

Currently translated at 80.0% (12 of 15 strings)

Currently translated at 80.0% (12 of 15 strings)

Currently translated at 80.0% (12 of 15 strings)

Currently translated at 80.0% (12 of 15 strings)

Currently translated at 73.3% (11 of 15 strings)

Currently translated at 73.3% (11 of 15 strings)

Currently translated at 66.7% (10 of 15 strings)

Probably for the first time, I don't have anything to add.