© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
> - 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-
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-
> 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-
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-
(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/
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-
assistance" (which is also the crux of why I lean away from an
assessment of "basic functionality")?
That said, the lack of tests in it does convince me (for all the wrong
reasons :) that it should definitely be in an "optional" test list.
[1]: https:/
[2]: https:/