We never hit this path without a system menu button any more,
due to changes in KDE over time. It hasn't been hit for two years.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Now both GNOME and KDE do offline updates on all supported
releases, we never see an 'update done' screen any more. This
branch is left over from when the KDE offline update branch was
still conditional on release number.
If we ever implement this test on a desktop that doesn't do
offline updates, we can put this back easily enough.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's no need to do all this 'check whether it's selected and
click it if not' stuff (for three different mount points). Just
always click it. If it's already selected, clicking it again
doesn't hurt (one of these stanzas even clicks it *even if it's
selected*!)
If we need to cover both cases, we just need two needles with
the same tag, we don't need separate code paths. In each case,
though, we actually haven't matched one of the needles for ages
(the most recent was part_boot_selected, but now we're using
GPT by default, we won't hit that any more as it'll be the BIOS
boot partition that's selected by default), so delete the needles
we aren't matching any more. If we *do* hit any case where we
need to handle the 'other' state, we can just add the alternative
needle with the same tag.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This has not been hit for a year (on stg; three years on prod).
I *think* it would only be hit if we ran the test on an Everything
image, but as the test is now specifically associated with the
Server install DVD, that doesn't seem likely to happen.
If we somehow *do* hit ext4 pre-selected again, this can still
be handled simply by adding an alternate
anaconda_blivet_part_fs_ext4 needle which matches on ext4 already
being selected; that avoids the need to keep an alternate code
path around.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This branch is very fragile, because the test won't fail if we
miss the match on the security needle. So in practice, we are
never going to notice when the needle goes stale, and we'll just
wind up never triggering this branch and always going down the
other path. That's the current situation: the security_install
needle last matched more than a year ago at least. Let's just
admit the truth here and drop the branch entirely.
Also update the cockpit_updates_restart_ignore needle. This is
in a similar case - we don't really notice when it goes stale,
as the test completes, it just takes a bit longer - but since
this one is quite easy to find, let's just update it instead of
dropping it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This was resolved upstream and we're no longer hitting this bug
in tests on F38, Rawhide or even F37 respins, so we should no
longer need this workaround.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It looks like neither of these has been a problem for some time.
The notification needle has not matched for a year. The akonadi
needle doesn't exist any more - it was cleaned up in the 2021
needle cleanup, meaning it hadn't matched for weeks in 2021. I
checked the last several months of KDE app start/stop tests and
don't see any case where there was a stray notification that we
missed. So I think we can just ditch this whole mechanism for
now; if we have problems with these notifications again in future
we can put it back.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The last one of these was deleted during the last needle cleanup,
but we do actually still occasionally hit the dialog, e.g. in
https://openqa.fedoraproject.org/tests/1837435/modules/kontakt/steps/3
so let's add an updated version of the needle.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I think the shade of grey on the background changed. We'll
probably need more needle updates for the compose tests (the
desktop_login test and different languages), but this covers the
update tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In today's Rawhide, for some reason, after we delete the first
file, the second file we want to delete is highlighted.
Previously the other file in the directory was highlighted. No
biggie, just handle both cases.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's a difference in the Info page and we get every font
twice on Silverblue because they're present in two locations.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This actually hasn't matched for years, we've been falling back
to ctrl-t the entire time. Happened to notice it today while
debugging https://bugzilla.redhat.com/show_bug.cgi?id=2184549
Signed-off-by: Adam Williamson <awilliam@redhat.com>
These variants only show up when a security update is in play,
so not very often; this happened today, so now we get to update
them for current KDE.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The font rendering on this URL bar seems to be slightly unstable
for some reason. We got a 95% match on this needle in
https://openqa.fedoraproject.org/tests/1846906#step/about/10
so let's just bump the level down a bit.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
