This group was only added to comps today, so it's not in the
comps in the rawhide repo yet (will be after next compose). The
Koji repo doesn't have normal comps so it's not there either.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Try and make sure maximize actually works - wait for still screen
after hitting Done and before trying to maximize.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's a failure mode we hit quite often where, when we run
the text editor after copying the character, it pops up *behind*
the character page. So let's close the page first. When we click
the 'Copy Character' button a notification that the character was
copied is briefly displayed and if we hit esc while it's visible
we dismiss *that* not the character page, so hit esc twice to be
safe. If we miss dismissing the notification, the 'extra' press
is safe, it doesn't quit the app.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
A change to how anaconda handles NFS repos changed the log
messages we get when we use one. We may need further changes for
using NFS as a base repo when this change hits Rawhide nightly.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It looks like the desktop_notifications postinstall test on KDE
on F38 is failing currently because the notification is being
shown during the install_default_upload test that precedes it,
so KDE decides not to show it again yet. So, unset the setting
that stores the timestamp of the last time the notification was
shown. This is similar to a thing we already do for GNOME above.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is needed to force the rebase on current CoreOS (because it
has zincati registered by default). It should be harmless in all
other cases.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Reasoning:
1. pandoc is not in critpath so will not itself be tested
2. pandoc is widely used and actively maintained
3. package is noarch
4. package has minimal deps
Hopefully this will work for everything. For some reason, the
"use python3-blivet for pykickstart tests" fails mysteriously
sometimes, see e.g.
https://openqa.stg.fedoraproject.org/tests/2672282
Signed-off-by: Adam Williamson <awilliam@redhat.com>
See e.g. https://openqa.fedoraproject.org/tests/1829593
sometimes we see the app UI briefly before the access prompt
appears. Handle that case by waiting a few seconds and doing
the match again.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Somehow, the dummy package being python3-kickstart causes the
graphical update tests (only) to fail for pykickstart updates
(that's the source package of python3-kickstart). The CLI and
Cockpit update tests are fine with this and pass.
To workaround this, use python3-blivet as the dummy package for
the graphical update tests when testing an update that contains
python3-kickstart. I've updated the test repo to contain both
dummy packages.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit 2fecb70468.
Sadly, clicking on the right menu entry...doesn't work. Let's
try going back to the old way, but add an 'enter' press once
the entry we want is selected.
Move the xauth disablement and the disabling of studies into
_setup_browser, instead of repeating it in a couple of other
places (but *not* doing it in the zezere test, where we should
be doing it). Drop some explicit package installs that should
no longer be needed as Firefox and/or X.org now depend on those
things. Install the current default fonts (Noto), not the old
ones (DejaVu).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's a weird issue with the rpmostree_rebase test for this
update:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-f6afa6f9e5#comment-2919613
it doesn't reproduce locally (I can type fine after doing the
same things the test does up to the rollback) and I can't think
of any possible cause, and I don't want to hold the update up.
So we're just gonna work around it and hope this doesn't start
happening to all F38 update tests after this goes stable. If it
does, we'll have to do the workaround for all of them.
The workaround is just to rollback and reboot 'blindly', instead
of checking the rollback command works. The drawback is that if
the rollback command fails we'll wait 7.5 minutes before giving
up on it, and it'll be a bit less clear exactly what happened.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Plasma 5.27.1 is going all the way back to F36 (in
FEDORA-2023-d7dcc38129), so we'll have a welcome tour on both
desktops we actually test on, on all supported releases. So we
can just drop the desktop conditional entirely here now.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's this awkward path for the live image install tests on
updates. We run the 'are the correct versions of all the packages
installed' check on these tests to ensure the right versions
actually made it onto the live image. So we don't run
`dnf -y update` at the end of repo_setup_updates on that path,
because if we did that, even if the packages on the live image
were old, we'd update them there and hide the problem.
However, this causes a bit of an ordering issue, because in
order to set up the advisory repo, we need to install a few
packages. What if the update under test includes one of those
packages, or a dependency that wasn't already installed? In
that case, we wind up with the older stable version of the
package (because obviously we can't install the newer version
from the advisory repo *before we've set up the advisory repo*),
don't update it later, and so the 'correct version' check at
the end of the test fails. See:
https://openqa.fedoraproject.org/tests/1778707 for a case of
this happening with a python-cryptography update.
Up till now I was trying to handle this by just updating the
specific packages we install, but that doesn't account for
*dependencies* of them. I looked down the path of trying to
generate a list of all those dependencies and update all of
them but it looks a bit mad. So instead let's try this. On that
specific path, we'll generate the "all installed packages" list
*before* we run repo_setup, so it just doesn't include anything
that gets installed during repo_setup. The implementation is a
bit icky but not too horrible.
We *could* just *always* generate the all installed packages
list earlier, but then that would mean we *wouldn't* catch dep
issues in this kind of package on the other test paths, whereas
currently we do. I don't want to lose that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
5.27.1 is going to F37, and adds it. In the short term this
will waste a minute and a half and cause soft fails on all other
F37 updates until the update that adds this goes stable, but
I don't really feel like working around this, let's just live
with it till the update goes stable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
OK, neither 'input' nor 'keyboard' actually gives us the Keyboard
pane, they both give results for uninstalled apps from Software
:(. 'hotkey' (which is one of the keywords in the .desktop file)
does seem to work, for now at least, let's try that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Contacts now has two burger menus, which is awkward. We need
specific needles to identify each, we can't rely on the generic
needle any more as it won't always open the right menu. We also
need to still work with the old UI for the flatpak.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
KDE has a welcome tour now, on F38 and Rawhide at least. Let's
"handle" it with extreme prejudice...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
On GNOME 44, typing 'input' is now giving us the Software page
for PulseAudio Volume Control, for some reason. Let's try typing
'keyboard' again and hope that works again now...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Logout seems to be taking a long time in Rawhide currently. Give
it longer to run, but soft fail. I'll add a bug link once I've
investigated and filed one.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In today's F38 and Rawhide, changes to the persistent overlay
stuff result in a boot warning you have to spam through. Let's
handle this as a soft fail so we don't have floods of failed
tests till it's fixed.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Tested that this is not necessary on KDE or GNOME, and on current
KDE it actually seems to break stuff. It's better to just start
typing the password.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Typing a partial binary name no longer seems to work. Typing the
full binary name works, but differently from before; seems best
to do a partial entry name search so we launch the actual entry,
not the executable directly.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I've seen a few cases of this test failing because there was
some running operation when it tries to do `rpm-ostree install`.
I think this is GNOME Software checking for updates or something,
I've seen it on my own Silverblue install too. Let's just throw
some `rpm-ostree cancel`s at it and hope that helps.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
