Commit Graph

6 Commits

Author SHA1 Message Date
Adam Williamson 8b997279a4 vnc: give a dnf install command a bit longer to run
These can take a while if repos haven't been refreshed lately.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-06-19 12:42:03 +02:00
Adam Williamson 1a65993d36 Add a perltidy check and apply it to the entire codebase
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-28 14:38:38 -07:00
Adam Williamson b24802d4e0 Update a FIXME note in VNC client test
Connections is now default, we just have to update the test to
use it.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-05-16 16:33:40 -07:00
Adam Williamson 35660bb4ed Use Vinagre instead of Boxes as VNC client, prepare Connections
Boxes dropped VNC functionality. It's supposed to be replaced by
Connections, but we can't use that until it has fullscreen:
https://gitlab.gnome.org/GNOME/connections/-/issues/5
so use Vinagre for now. We do also prepare some needles for
Connections in anticipation of being able to use it later (since
I already did the work and don't want to waste it...)

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-05-06 16:28:49 -07:00
Adam Williamson 940848b628 Use 'test.openqa.fedoraproject.org' not 'domain.local'
Using .local is apparently Bad Form because it's reserved for
mDNS. However there doesn't appear to be any particularly Good
Form for what to call a test domain you never want to exist
outside of a closed system, apparently. Sigh. Let's try this.
Includes a bump to disk_ks version because the kickstarts on
that image also need to have this change applied.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 14:40:30 -08:00
Adam Williamson 92d52c6ac6 Split VNC client steps in two for aarch64 timing issue
So, there's a problem with how we figure out the NetworkManager
connection to use in setup_tap_static: it expects the first
connection in the list to be the right one, but this is only
actually true so long as it's *active*. When we're in the tap
case, it's usually not going to actually *work* out of the box
on boot (or else we wouldn't need setup_tap_static at all...),
so some time after boot, NetworkManager gives up on it and marks
it as inactive. And after that, setup_tap_static won't work any
more.

I never noticed this as a problem before because usually we do
setup_tap_static before that point. But it seems in the vnc
client tests, on aarch64, desktop boot and login is slow enough
that by the time we switch to a VT and try to setup the network,
we're very close to that cutoff, and sometimes miss it.

This, I hope, avoids the problem by doing the network setup in
that test before we deal with the desktop login, then doing the
desktop login, then doing the actual VNC bits.

The alternative here would be to figure out a better way to do
setup_tap_static, but I can't.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 12:39:52 -07:00