GitLab

Documentation: take into account that Tails Installer will soon refuse installing Tails to devices smaller than 8 GiB (refs: #12706).

It'll still allow *upgrading* such sticks though, but I'm told that our
documented manual upgrade process goes through a full install anyway
so let's just write "8 GB" everywhere.

Test suite: take into account that Tails Installer will soon refuse installing Tails to devices smaller than 8 GiB (refs: #12707).

It'll still allow *upgrading* such sticks though.

commit b5ad7f96 reverted it to a regular file
by mistake, and our review'n'merge process missed that bug.

Fix-committed: #14602

Refresh torbrowser-AppArmor-profile.patch to apply cleanly on top of torbrowser-launcher 0.2.8-1 (refs: #14602).

Merge remote-tracking branch 'origin/bugfix/13623-reproducible-etc-hostname-permissions' into devel (Fix-committed: #13623).

So /[D|d]/ will match "|" which wasn't the intention. Presumably the
intention was /(D|d)/, but a plain /[Dd]/ is cleaner.

Refs: #10494

Fix-committed: #11840

Fix-committed: #13513

Fix-committed: #12686

Fix-committed: #12685

Fix-committed: #12684

Fix-committed: #12733

A user reported all executable bits of /etc/hostname being set when
trying to reproduce Tails 3.1.

Will-fix: #13623

It seems that some servers (sometimes) do not send their headers with
first letter uppercased, hence a lot of failures to find the date in it.

As discussed in more details on https://bugs.debian.org/869416, there's a bug
somewhere in the Seahorse → gnupg-agent → pinentry-gtk2 communication, that
leads to pinentry-gtk2 being invoked with the $DISPLAY environment variable
being unset. Strangely, this does not happen for gpg → gnupg-agent →
pinentry-gtk2. Now that upstream is aware of the problem, let's apply
a temporary workaround to Tails until the root cause is fixed.

 Conflicts:
	debian/changelog

This reverts commit 6230a463.

This reverts commit 9f635930.