In '/usr/share/gnome/autostart/vino-server.desktop' (or
'~/.config/autostart/vino-server.desktop', which is what I used for
the test), changing the line
AutostartCondition=GSettings org.gnome.Vino enabled
to
AutostartCondition=GNOME /desktop/gnome/remote_access/enabled
fixes this problem. I can see where this changed variously in
NEWS and ChangeLog files, and I'm sure there were good intentions
and some work involved in bringing this change out (I can see the
code git to gsm-autostart.c), but the implementation totally
fails. Don't people test the code they write anymore? A simple
bounce gdm would show that vino didn't start.
Also, from the '/docs/debugging.txt' in the source tree
we see:
Debugging Vino
==============
Because gnome-session launches vino-server based on the value of the
/desktop/gnome/remote_access/enabled key, it can be a bit of a pain to
debug Vino.
'Bit of a pain' is an understatement, even more pain ensues when what
little documentation there is about vino doesn't match the debugging
instructions.
I'm sure there were reasons to change this (there is a reference to
'bug 654901', but no URL linking the bug number to a bug database.
The administrator is left guessing (launchpad, bugzilla, gnome, Debian).
The worst part is that the remote admistrator will notice they cannot
logon but the casual user/client is not skilled enough to assist in the
debugging of the problem without considerable pain on the part of
both parties.
