Add optional tests for Pi desktop

[Dave Jones]

All tests for the Pi desktop images are currently "mandatory"; we could do with a set of "optional" tests for functionality beyond the absolute basics. For example, remote desktop is now a default part of the desktop but (as per LP: #1970139) didn't work on the Pi at release time.

While this shouldn't be a release blocker, it would be nice to verify that such things don't break.

This bug is mostly filed to remind me to write some more tests!

[fprietog (fprietog)]

Partly adapted from LP: #1970139

I think that the meaning of "basic" feature in an OS is something that can't be stated universally because it depends of the usage done by each set of users. In my opinion remote desktop is a "basic" feature because I use the Raspberry Pi remotely, and for a Raspberry Pi that's not an unusual usage. So I think it should be mandatory tested before releasing.

You may think that it's not a "basic" feature as it can be sorted using other software, but it creates several problems:

- for the users because we need to look for and to set-up and alternative (another RDP or VNC server, SSH X-forwarding...) if it doesn't work and it costs us time. Also not all users have the knowledge to do it in an easy way.

- actually the default Ubuntu's remote desktop server, gnome-remote-desktop, is the only remote desktop that works under Wayland. If it doesn't work you need to switch to X11. It may be a problem for some users or apps that rely on Wayland.

- it gives "bad press" to the distribution when something that is managed in the main settings of the distribution just don't work.

Thanks and regards.

[Dave Jones (waveform)]

> - it gives "bad press" to the distribution when something that is
> managed in the main settings of the distribution just don't work.

I certainly agree we don't want to be putting out broken stuff on the
images. On the other hand, I have to draw the testing line somewhere
:)

By way of example, libreoffice is shipped by default in the images and
currently doesn't feature in the Pi ISO tests at all. Partially this
is because it's so huge any manual testing we do will (by definition)
be superficial, but also because it's got a decent autopkgtest suite
so if that's passing there's a good chance most of the functionality
is fine anyway.

A lot of the stuff in the ISO tests is stuff that isn't "pure
software" and can't be (trivially) tested in an automated fashion,
e.g. wifi firmware where the mere fact you can load it doesn't really
mean anything: you need to actually get it to connect to different APs
and transfer stuff over a link to have some confidence in it.

That said, gnome-remote-desktop is one of those cases where the
hardware-specific nature of screen-scraping a desktop (which almost
always involves GPU specific stuff these days) does lean towards the
"cannot be trivially tested by software" side. Further, looking at the
packaging, it doesn't have any autopkgtests defined, and the test
phase in the package build [1] is overridden with "|| true" so we
won't even notice if those fail. Hmmm...

> - for the users because we need to look for and to set-up and
> alternative (another RDP or VNC server, SSH X-forwarding...) if it
> doesn't work and it costs us time. Also not all users have the
> knowledge to do it in an easy way.
>
> - actually the default Ubuntu's remote desktop server,
> gnome-remote-desktop, is the only remote desktop that works under
> Wayland. If it doesn't work you need to switch to X11. It may be a
> problem for some users or apps that rely on Wayland.

The bit I'm really struggling to understand about the use of
gnome-remote-desktop in the jammy desktop is the idea that people are
relying on it for remote control. I know that sounds a little weird,
but here's the core of the issue for me:

gnome-remote-desktop appears (to me) to be intended for remote support
(even Gnome's remote desktop page [2] describes it as "[...] remote
assistance mode"). Crucially, it doesn't provide a means to remotely
access the desktop unless someone is already logged in, which implies
that the machine being controlled already has a keyboard and screen
attached to it.

This is in contrast to SSH which can be used to login to a system from
boot, which to my mind is a more suitable solution for "remote
control", especially any situation where the pi lacks a keyboard and
screen (robotics, servers, etc.). Admittedly, SSH isn't installed by
default on the desktop image, but it is on the server images. That
then brings in the whole issue of why on earth anyone would want the
overhead of a full desktop on their robot/server/whatever, especially
on a pi.

In other words, I guess I'm struggling to understand why anyone's
using the desktop image for the remote control case, and hence why
anyone wants gnome-remote-desktop for cases other than "remote
...

[fprietog (fprietog)]

> Crucially, it doesn't provide a means to remotely
> access the desktop unless someone is already logged in, which implies
> that the machine being controlled already has a keyboard and screen
> attached to it.
That assumption is wrong. I'm using the Raspberry Pi without a keyboard or a mouse attached to the Raspberry Pi and without manually login. Remember the autologin feature, it's even offered in the Ubuntu install process so I think it's a "basic" feature.

Anyways, even if you don't use the autologin feature you can remotely connect to the login screen (GDM greeter) and login from it remotely.

In my case the Raspberry Pi is attached to a TV and hidden behind it. Main use is as a media center and a 24h P2P sharing box. When I want to do something I just connect to it with and android tablet (RealVNC Client). Don't need a keyboard or mouse at all.