GitLab

Test suite: misc. robustness improvements

Closes #18727

See merge request !827

Without this, the "I can start the Unsafe Browser in a few supported languages"
step always fails when our test suite tries using a Portuguese locale.

I see a number of weird failures where an image is not found on the screen,
while I would expect it to be: calling opencv_match_template.py with the
same arguments our test suite does in the context of those failures
does find the image on the screen.

So I suspect something down the call chain is slower than it used to be (taking
the screenshot? OpenCV?), which could make the try_for timeout before the image
has actually appeared.

This debug logging will give us timing information that'll be useful to tell
whether this is actually the case.

In some scenarios we run:

1. "I set an administration password", which ends with validating
   the chosen password with "Return" in the Administration Password dialog.
2. "I log in to a new session", which expects the Administration
   Password dialog to have vanished already.

This is racy so step (2) often fails to find TailsGreeterLoginButton.png
on the screen. Let's ensure step (1) has finished its job before returning.

- The background of the top bar is now black, not transparent.

- When an application is started, with the added "GMT" from #6284, in 1024×768
  the Applications menu button reads "Applicati…". To be on the safe side,
  let's look for "Applicat".

Recently I've seen numerous cases where the "Create new room" dialog is
displayed pretty quickly, but it is initially empty, and only after a few
seconds the "Accept Defaults" button appears. Without this change,
when this happens we would fail because we assumed that button would
be on screen as soon as the dialog appeared.

I've seen the test suite fails to find these images on screen a few times
recently, while they seemed to be there, so perhaps they needs a refresh
(and whether it succeeds or not depends on whether we give OpenCV enough
time to find the picture with a lower sensitivity despite the differences).

We're checking the *guest*'s clock here, not the host.

Previously we would pretend the clock was expected to be set to the lower bound
of the acceptable interval, which was incorrect.

I've seen this fail:

    Given I have started Tails from DVD without network and logged in
    When I bump the hardware clock's time with "-15 days"
    And I warm reboot the computer
    And the computer reboots Tails
    Then the hardware clock is still off by "-15 days"

With that error:

    The host's hwclock should be approximately '2022-04-27 02:24:44 +0000' but is actually '2022-04-27 02:24:59 +0000'.
    <false> is not true. (Test::Unit::AssertionFailedError)
    ./features/step_definitions/time_syncing.rb:116:in `/^the hardware clock is still off by "([^"]+)"$/'
    features/time_syncing.feature:46:in `Then the hardware clock is still off by "-15 days"'

Given expected_time_lower_bound == expected - max_time_drift,
then expected_time_upper_bound == expected_time_lower_bound + max_time_drift
                               == expected,
which means we did not accept the clock to be in the future at all.

Let's accept that it can be up to 1 second in the future, which happened
in the test suite run I quoted above.

This will be useful for the next commit.

refs #18557

This reverts commit 7a1b185b.

refs #18727

Follow-up on 3832a464

Upgrade apt-cacher-ng to bullseye-backports - fixes issue #18931

Closes #18931

See merge request !825

safely get gnome_env_vars

See merge request !819

Display time in the timezone that the user has chosen in Tor Connection

Closes #6284

See merge request !751

refs #6284

Automatic time sync before connecting to Tor in automatic mode

Closes #18830 and #18717

See merge request !681

# Conflicts:
#   config/chroot_local-includes/usr/local/lib/tails-shell-library/gnome.sh

Test suite: ignore failures to destroy a stopped domain

Closes #18972

See merge request !822

Follow-up on "Audit tca-portal"

See merge request !723

intrigeri authored May 11, 2022 and boyska committed May 12, 2022

Knowing that we'll check is great, but if we don't specify what we do when the
check fails, it's not informative enough IMO.

I see that b13ff6b5 had switched to date(1), but
that was targeting Buster's Python 3.7, while we can now assume 3.9 and thus
use the zoneinfo library, so it's now just as easy to do this without
forking an external process.

refs #6284

Test suite: Make opening GNOME menus more robust

Closes #18930

See merge request !816

Use Bullseye debootstrap configuration

See merge request !817