I've seen a case when it covered "only" 96%. IMO that's good enough.
I suppose more stuff is happening on Bullseye which can occasionally
make the kernel reclaim that some of write cache. Or, the kernel
already started to write this data out to disk, and thus removed
it from its write cache.

On feature/bullseye, I've seen 1 case where pressing Escape in "I cannot run
a command as root with pkexec and the standard passwords" did not close
the dialog. I suspect we pressed it too quickly.

So far we were checking every time we ran check_dependencies,
which in my typical usage can be 3 times.

For the life of me I can't get this to work on Bullseye: clicking on "Wired
Connected" with Dogtail closes the System menu, instead of opening the network
interface configuration sub-menu. Same if I click with xdotool. I verified in
interactive debugging mode that the coordinates are correct and the .point
method highlight the right screen area.

While this works all fine when I take over TailsToaster with virt-viewer and
test this manually. Go figure.

@anonym noticed the same in b805f1f2, and
adjusted another scenario to cope with it. So I'm refactoring anonym's code into
a method and using it in the 2 places where we interact with the system menu in
our test suite.

Let's allow us to spot as many problems as early as possible.

4d000520 broke this because it updated the image
to something that only works for PolicyKit prompts, while nowadays we also use
this code & image for the pinentry-gnome3 prompt for tails-backup.

Drop obsolete patch

See merge request tails/tails!690

I can't find where the patched script is used and I can't figure out why the
operations it does are necessary.

With a Bullseye image, I've `rgrep --text live-medium-cache` (the name of the patched script) in:

- the mounted `filesystem.squashfs`
- the unpacked initramfs

⇒ no occurrence besides the obvious one that merely indicates the script is installed: `var/lib/dpkg/info/live-tools.list:/bin/live-medium-cache`

Same with 4.27.

So either the name of that script is generated programmatically by its caller, or it's never used.

There's no occurrence of "cache" in the versions of `live-boot`, `live-tools`, and `live-config` installed in our Bullseye images. Same in the versions installed in 4.27.

Actually, it seems the code this patch modifies has never been used since a long
time: it's been moved from `live-config` in version 4.0~a24 to `live-tools`,
then factored out in
https://salsa.debian.org/live-team/live-tools/-/commit/37dd2f4e7aa76a230b7a42ac6691327150562c07,
which moved code to a new script… without ever calling that new script.
We followed suit in ae54b624 to patch that new
script in Tails 2.0. And since more than 7 years we've kept updating our patch.

refs #18691, #6228

refs #18838

Spotted by our automated test suite.

The text actually visible on the screen is truncated.

Without this, the container fails to start with this error:

Error: OCI runtime error: container_linux.go:380: starting container process caused: process_linux.go:402: getting the final child's pid from pipe caused: EOF

This was rendered as a link:

    if <span class="createlink"><a href="/ikiwiki.cgi?do=create&amp;from=contribute%2Frelease_process&amp;page=_-z___34____36__log__34___" rel="nofollow">?</a> -z &#34;&#36;log&#34; </span>; then

Besides, "[[" is mostly useless and obsolete AFAIK.

I understand this markup came out of frustration from having to do this
by hand.

Let's use bold only for critical information that the RM must really
not miss. This is not it.

That's the same as "Check for any feedback in tails-testers@boum.org",
which is 2 lines below.

Thanks to @nodens!

Most of that is simply wrong nowadays.

That's a leftover of a long-defunct manual test suite automation project.
Right now it only creates noise during manual testing.

All tests that we can realistically automate include a link
to the corresponding issue.

Note that the upstream 91.5.0 release notes prominently say "For more on all the
new features in Thunderbird 91, see New in Thunderbird 91.0", and link to
https://support.mozilla.org/en-US/kb/new-thunderbird-91/, which seems much more
informative than
https://www.thunderbird.net/en-US/thunderbird/91.0/releasenotes/ for our
target audience.

So our users will still have a chance to get information about the 78 →
91 changes.