desktop-packages team mailing list archive

[Launchpad Bug Tracker <912186@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package gnome-settings-daemon - 3.2.2-0ubuntu7

---------------
gnome-settings-daemon (3.2.2-0ubuntu7) precise; urgency=low

  * Add 54_lazily_connect_to_screensaver.patch: Do not D-BUS activate
    gnome-screensaver right at startup, this unnecessarily slows down boot
    speed. Instead, D-BUS activate it the first time we actually need it.
    (LP: #912186)
 -- Martin Pitt <martin.pitt@xxxxxxxxxx>   Thu, 05 Jan 2012 12:42:24 +0100

** Branch linked: lp:~ubuntu-desktop/gnome-settings-daemon/ubuntu

** Changed in: gnome-settings-daemon (Ubuntu)
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-settings-daemon in Ubuntu.
https://bugs.launchpad.net/bugs/912186

Title:
  Connect to gnome-screensaver when needed instead of at startup

Status in Gnome Settings Daemon:
  New
Status in The Ubuntu Boot Speed Project:
  Fix Released
Status in “gnome-settings-daemon” package in Ubuntu:
  Fix Released

Bug description:
  In current trunk and 3.2.x, the libpower plugin connects to gnome-
  screensaver's D-BUS interface right at startup, and then saves the
  GDBusProxy.

  This causes gnome-screensaver to be dbus-activated very early during
  session startup, which unnecessarily slows down boot speed. Usually
  g-s gets started much later through an autostart .desktop file, which
  can be further delayed with e. g. X-GNOME-Autostart-Delay=20 to keep
  it out of the critical path during boot.

  Also, the proxy object will be invalid if gnome-screensaver gets
  killed or restarted in between g-s-d startup and the time when the
  power plugin actually calls it in upower_notify_sleep_cb().

  To fix both, it would be better to create the GDBusProxy object in
  upower_notify_sleep_cb() instead of gsd_power_manager_start().

  If gnome-screensaver fails to start, it will just fail as well at the
  beginning, so in both cases the screen lock will just fail on sleep.
  In the normal case, g-s is already running through the autostart
  desktop file, so there is no additional delay for entering sleep mode.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-settings-daemon/+bug/912186/+subscriptions