Bug#639088: Changing 'AutostartCondition' back to depend on gconf key fixes this

[Dominique Brazziel]

    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.  



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20110823/59b18b81/attachment-0001.html>