This is the automation of the optional testcase https://fedoraproject.org/wiki/QA:Testcase_i18n_default_fonts.
The test implementation runs the same commands as the mentioned test
case and checks the expected output. It is designed to run in the scope
of postinstall tests when the language is set to "japanese".
I'd prefer not to do this, but I don't see a better way to deal
with the stupid 'welcome' screens. I'm not maintaining needles
to click them away forever.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Firefox 97 is now stable on all releases, so we can forget about
handling browser_download_save and just assume download will
happen automatically.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Up to F33 we could check that an error message was shown when we
tried to log in with the wrong password on GNOME, but since F34
it's transient and disappears too quick to reliably catch, so
we don't check it any more. Now F33 is EOL, drop the conditional.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The g-i-s new user mode was removed in F34, so we don't need to
do this any more (as the now-removed comment said).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Before F34 we had to launch the update tool from the systray.
This isn't the case any more, so we can throw all this code and
these needles away.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We seem to be solidly back to always getting a permanent update
notification in current F36/Rawhide, so we don't need this more
complex path any more. We also don't need these needles any more,
they haven't matched for months.
Logging of additional repo setup changed recently in F37, we
need to handle the new message format here.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2 seconds isn't enough to be sure it opened, which is causing
some weird failures in KDE Rawhide update tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
aarch64 tests are failing here because anaconda's still thinking
about the delete confirmation, it seems.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When testing Rawhide updates we set VERSION to the Rawhide
release number, not "Rawhide". This post-upgrade version check
needs adjusting to handle that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Seeing a failure quite often lately where when we try and hit
ctrl-p to print, we just type a p. There's no wait between
maximizing and trying to print, and only a short wait on
launch, so let's try being a bit more defensive there.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This can actually take a bit of time, it seems, especially with
debug kernels. Let's give it a minute.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Lately anaconda can take up to 10 seconds to exit the root pw
spoke, which can defeat the subsequent `wait_still_screen` that's
meant to wait out the 'slide-in-from-the-top' animation of the
hub. So let's assert the hub after we click Done, then the still
screen wait will only happen *once the hub is visible* and should
really do its job.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
OK, this is annoying. GNOME Software intentionally does *not*
clear the 'download' or 'reboot and update' button when you hit
the refresh button, it just leaves them sitting there while the
refresh happens. So let's specifically require the 'refreshing'
text to appear and go away before we try and click on download
or apply.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Agh, GNOME's UI is *not* helpful here at all. The Apply button
remains visible for a long time after you hit Refresh.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is yet another twiddle to that same damn bit where we try
to apply updates. This more or less reverts the last tweak to
it, where we skipped hitting 'refresh' if 'download' or 'apply'
are already visible. The trouble with that is that the app may
have already found and prepared updates before we got our
"prepared" python3-kickstart update in place - so the update
operation might work perfectly, but not update the package we
expect it to update, and the test may fail.
This time, let's try *always* refreshing, then wait a bit after
hitting the refresh button before we start looking for apply
or download to try and avoid the 'race' we were trying to solve
with the last tweak (where we hit refresh then immediately try
to hit a download or apply button which vanishes before we can
hit it). I think this should be safe as both KDE and GNOME
should always show a refresh button now (this wasn't the case
before, I think, F34).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's a bug in the Save As... dialog on the flatpak version
of evince currently where the existing filename is not pre-
selected, so when the test types 'alternative', it gets
prepended to the existing filename instead of overwriting it,
and we wind up with alternativeevince.pdf, not alternative.pdf.
Let's treat this as a soft failure rather than a hard failure.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
On upgraded systems, gedit might still be present; remove it so
we don't launch it by accident and try to test it instead.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Firefox 97+ don't ask you what to do with downloads any more,
they just...download them. For now we'll handle both workflows,
once 97+ is stable everywhere we can drop handling the old one.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
At the end of _podman_client we create a mutex that we want the
server to pick up. If we exit too soon, the mutex goes away and
the server test fails. 5 seconds turns out to be not enough of a
wait because, although the server retries the lock call every
5 seconds, it can hit `api_call_2 failed` and wait 10 seconds
before retrying. Let's wait 30 seconds just to be safe.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Otherwise, if there's an update to fXX-backgrounds pending, we'll
get it on reboot in the middle of the test, and the real
backgrounds will comes back and replace our black fake ones and
break the test.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Silverblue still has an old version of g-t-e where this theming
stuff worked differently, so put that stuff back for Silverblue
but keep the new stuff for RPMs.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
So just type 'text-editor'. If you have both gedit and gte
installed this will find both, but that should never be the case
so it should be OK.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
To get to the keyboard/input method settings and add an input
method when doing a Japanese install test, we type 'keyboard',
but in current GNOME 42.beta that doesn't find the right pane.
Typing 'input' does work, though, so let's use that instead.
Also the GDM login needle needed updating.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The backend is now cryfs in F36/Rawhide. I don't think we need
to be policing which backend Vault decides to use, so let's just
accept either.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The 'software' test module in GNOME apps_startstop does a subset
of what the desktop_update_graphical test does already, but
using its own needles. Let's just have it use the same needles.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We can't use the default similarity_level for wait_still_screen
when there's a flashing cursor - flashing cursor will always
cause the similarity level to be too low and the wait will just
time out at 30 seconds. Cut it to 42.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This was originally a test of nm-connection-editor. However,
at some point that app stopped shipping a .desktop file by
default (it's in a subpackage that is not included in a default
KDE install) and the needle got updated to match on what the
same string now launched, which is a random part of the KDE
system settings. But there's no real sense in this - we don't
test launching every other pane of the system settings app from
the launcher, so it doesn't make sense to just test one random
one like this. Let's just throw the test out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We have three different needles which all match on a stock KDE
"cancel" button. Let's just have one. Also, update it for latest
Rawhide/F36 KDE.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
script_output has no arg to make it type slowly, and I'm seeing
that the test often fails trying to do full-speed script_output
at a desktop terminal. Let's do this part from a VT.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The help test had its own needle for the user creation link,
but we already have an existing one. We should probably re-
arrange all the needles that are in 'install_process' now the
root and user creation spokes are moved to the main hub, but
that's a big change so I'll do it separately. This just removes
the duplicate needle and tweaks some match names.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When the printing_builtin test ran on an F35 respin compose it
failed; it turns out the target filename was different for the
built-in print-to-PDF on GNOME on F35. So let's just always
use the 'ls' output to find the file, but pick the directory
to check based on whether we're using cups or not.
Also rename the needles to have unique names, and add one for
F35 GNOME.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The PR introduces an improved logic to the desktop_printing.pm
that allows to use the USE_CUPS variable in templates to trigger
the installation of cups-pdf prior to the actual test.
The cups-pdf is then used as an alternative PDF printer
instead the built-in Save As PDF method.
It was removed from the default install:
https://pagure.io/fedora-comps/c/5371509
in favor of a new screenshot mechanism that's built in to GNOME
Shell.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit 182bfdaa55. The
problem was not in the test code here, it's just that the tests
were run with RAWREL set to 36 when it should be 37; this is
because fedfind's data source hadn't been updated for 36 branch
when the tests ran. It's tricky to time this exactly right -
ideally we'd probably update fedfind's data source one second
before the first Branched compose completes, but of course that's
difficult in practice.
