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