sharing panel fails to properly launch required daemons

what would be required to be changed in gnome-user-share and vino?

at the very least, patching the OnlyShowIn settings in desktop files

I guess it would be useful to summarize what changed upstream, what is g-c-c expecting and what are our current packages doing. Then we can discuss possible solutions and their impact...

seb, g-s-d added a sharing plugin in 3.10 or so, that manages the sharing daemons (gnome-user-share, vino and rygel) on a per-network basis, rather than having gnome-session launch them. Though moving to that would require new UI for u-c-c.

I'll dig a bit deeper over the next few days, and update more then.

This bug was fixed in the package gnome-user-share - 3.14.2-2ubuntu1

---------------
gnome-user-share (3.14.2-2ubuntu1) xenial; urgency=medium

  * New Upstream release (LP: #1518813)
  * Merge with Debian, Remaining changes:
    - Suggests the apache2.2-bin and libapache2-mod-dnssd binaries rather than
      depends on those, we want obex push to work out of the box but we don't
      really need webdav and the apache binaries on the default installation.
    - debian/patches:
      + 0001-revert-remove-preferences-application.patch
        0002-revert-data-get-started-by-gsd-sharing.patch
        0003-revert-webdav-fix-launching-server.patch:
         Bring back the preferences app for Unity and modify to allow g-s-d sharing
         panel to also work
      + 01_notification.patch: Display an alert box instead of a notification
        for files received.
    - debian/rules:
      + Don't change path to httpd
      + Remove apache 2.2 config
  * 04_webdav_optional.patch, 05_autostart_delay.patch: Refreshed
  * 06_nodisplay_autostart.patch,
    07_onlyshowin_unity.patch: dropped, applied in preferences patches

 -- Tim Lunn <email address hidden> Fri, 27 Nov 2015 21:05:42 +1100

Will be there an update to vino?

The update doesn't bring much out of dropping the standalone settings dialogs that are used out of GNOME, it's more likely than we backport needed commits rather than update vino

The problem with staying with a much older version is that upstream will be reluctant to fix bugs and backporting fixes will get harder when the code diverges.

right, if that's the case and updating is a better option than backporting fixes then we can revisit and do the update...

So here is a small and easy fix, no backporting but simply bypassing the enabled key check if vino runs under GNOME.

Hi Robert,
   The logic of your patch is good, however there is one more check that you missed (in a seperate file).
   Also there is a spurious quilt patch in your debdiff, can you remove that.

The attachment "vino_3.8.1-0ubuntu8.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

Ok, new debdiff. Modified the check in vino-prefs.c and removed the "spurious" quilt patch :P

New clarified debdiff:

Hi Robert,
   you broke the logic in vino-prefs if statement on your rebase. also you seem to have double bumped the version number in the changelog. Both of those were correct in the previous debdiff.

Ok, fixed these issues.

vino (3.8.1-0ubuntu8) xenial; urgency=low

  * Fixes the bug with vino not launching when starting user sharing under
    GNOME due to its reliance on "enabled" gsettings key. (LP :#1518813)

 -- Robert Hoenig <<email address hidden> (indielives010: 179) (indielives010: 179) > Sun, 10 Jan 2016 10:51:46 +0100

Bug is still open (Ubuntu Gnome 16.04). See my temp solution: #1246243 (comment #2).

I can confirm that this bug is still here in 16.04. Under the user point of view, is as screen sharing is simply not working ( regression from 14.04).

I can also confirm that this bug is still present on Ubuntu Gnome 16.04.

Let's use bug 1607663 to track the 'vino sharing panel broken in Ubuntu GNOME 16.04' issue. The fix for that is in progress.

I'm having this issue on Ubuntu Gnome 16.10.

Does anyone care about fixing these issues or is Linux seriously so full of bugs these days that everyone is twiddling thumbs while they relearn coding?

Before you respond (to the devs), prove me wrong. I used to be a Linux dev 15 years ago, and quit. PROVE ME WRONG and try, just try making something that actually works out of the box without broken features.

Bradon, there is a proposed fix for this bug. If you can verify that the fix works, it can be released for all Ubuntu 16.04 users:

https://bugs.launchpad.net/ubuntu/+source/vino/+bug/1607663

But this bug should not affect Ubuntu GNOME 16.10. Please file a new bug for that with details.