GNOME Bugzilla – Bug 772863
g-s-d doesn't support plugins anymore
Last modified: 2017-01-09 18:38:25 UTC
gnome-settings-daemon 3.23.2 uses separate daemons for each one of what used to be plugins. The current g-s-d plugin should be a stand-alone daemon, with a .desktop file in the xdg autostart folder. I'll provide patches when I've handled more urgent problems.
Created attachment 338824 [details] [review] notify: Port g-s-d plugin to new architecture gnome-settings-daemon 3.23.2 uses separate daemons for each one of what used to be plugins. The current g-s-d plugin should be a stand-alone daemon, with a .desktop file in the xdg autostart folder.
Created attachment 338825 [details] [review] data: Fix schema generation for strict checks org.gnome.Disks.gschema.xml:7:31 Error on line 7 char 31: Only one <summary> element allowed inside <key>. --strict was specified; exiting. org.gnome.settings-daemon.plugins.gdu-sd.gschema.xml:7:31 Error on line 7 char 31: Only one <summary> element allowed inside <key>. --strict was specified; exiting.
Review of attachment 338824 [details] [review]: I'm a bit surprised the test program functions as a gsd plugin with no changes, but it looks believable. Thanks!
Review of attachment 338825 [details] [review]: I think we need to look closer at this. The gschemas are not generated at all, so intltool shouldn't be touching them. And isn't the merge rule required for appdata translation?
Attachment 338824 [details] pushed as 403e6e7 - notify: Port g-s-d plugin to new architecture Attachment 338825 [details] pushed as 23b4892 - data: Fix schema generation for strict checks
(In reply to Michael Catanzaro from comment #4) > Review of attachment 338825 [details] [review] [review]: > > I think we need to look closer at this. The gschemas are not generated at > all, so intltool shouldn't be touching them. And isn't the merge rule > required for appdata translation? Answer is yes, it did indeed break the appdata file. I'm going to revert this. I have no clue how you are getting that error message; the gschema file is not generated so something is going very wrong if somehow you are getting translations merged into it. I'd be interested to see a full build log!
I got rid of intltool, that should fix the build error you were seeing. (Still not sure how it was happening....)
(In reply to Michael Catanzaro from comment #7) > I got rid of intltool, that should fix the build error you were seeing. > (Still not sure how it was happening....) Great, thanks
Not sure if this should be opened as new bug... "notify: Port g-s-d plugin to new architecture" commit adds desktop file with Autostart-Phase set to Initialization. Applications started in this phase are required to register with session manager. See: https://wiki.gnome.org/Projects/SessionManagement/NewGnomeSession gnome-session will wait until all applications registers before it will start next phase. gnome session prints this warning: WARNING: Application 'org.gnome.SettingsDaemon.DiskUtilityNotify.desktop' failed to register before timeout
Probably best to reuse this bug. Bastien, do you have time to fix it...?
Minimal patch would be: diff --git a/src/notify/org.gnome.SettingsDaemon.DiskUtilityNotify.desktop.in b/src/notify/org.gnome.SettingsDaemon.DiskUtilityNotify.desktop.in index 1121c5e..8e2a561 100644 --- a/src/notify/org.gnome.SettingsDaemon.DiskUtilityNotify.desktop.in +++ b/src/notify/org.gnome.SettingsDaemon.DiskUtilityNotify.desktop.in @@ -4,6 +4,4 @@ Name=gnome-disk-utility notification plugin for GNOME Settings Daemon Exec=@libexecdir@/gsd-disk-utility-notify OnlyShowIn=GNOME; NoDisplay=true -X-GNOME-Autostart-Phase=Initialization -X-GNOME-Autostart-Notify=true X-GNOME-AutoRestart=true Alberts, can you test that? Might also be an idea to move this into g-s-d proper.
I already did that as workaround. :) And probably that is right fix, at least I don't see any reason why it should be started in initialization phase.
Created attachment 343172 [details] [review] notify: Avoid failure on startup With the new g-s-d architecture, we needed to start the helper as soon as possible, but starting it as part of the initialisation of the session meant that we would have needed to register with the session. We don't need to start this early, and it's easier to start in the background as an app, and not register. https://bugzilla.gnome.org/show_bug.cgi?id=772863#c9
(In reply to Bastien Nocera from comment #11) > Might also be an idea to move this into g-s-d proper. If it only depends on udisks/storaged and not gnome-disks itself, then sure. But you surely don't want gnome-settings-daemon to depend on gnome-disks, right?
(In reply to Michael Catanzaro from comment #14) > (In reply to Bastien Nocera from comment #11) > > Might also be an idea to move this into g-s-d proper. > > If it only depends on udisks/storaged and not gnome-disks itself, then sure. Looks like it depends on udisks only. > But you surely don't want gnome-settings-daemon to depend on gnome-disks, > right? As long as the dep is optional, why not. It's just another tiny daemon.
Attachment 343172 [details] pushed as 78034ca - notify: Avoid failure on startup