This is a major problem as upstream has dropped support for power/session tracking for non-systemd setups :S, have looked to Debian and OpenBSD but they are for now "happy" with losing power support :(
This are the patches that would need reversion, but, due other changes, they need to be modified:
*** Bug 464984 has been marked as a duplicate of this bug. ***
I mailed debian gnome maintainers to know about his plans on this, also, maybe when Ubuntu starts working on 3.8 this will be handled in some way :|
Debian people told me they will rely on logind as they say it can be used even running a different init system (!?), but I tried to merge our systemd package and I started to get some blocks (udev the most important), could systemd people clarify if we really can rely on logind even not booting using systemd?
(In reply to comment #3)
> Debian people told me they will rely on logind as they say it can be used
> even running a different init system (!?), but I tried to merge our systemd
> package and I started to get some blocks (udev the most important), could
> systemd people clarify if we really can rely on logind even not booting
> using systemd?
Yep. OpenRC boots fine for me, we're installing udev in a manner compatible with OpenRC and split /usr.
Would it be possible to integrate the suspend code into app-admin/openrc-settingsd? If I understand it correctly, openrc-settingsd would then sort of tell dbus that it can receive and handle suspend request and all applications that communicate over dbus would know, that there is supend functionality and they can use it (thus making gnome 3.8 power management work again).
I don't know much about it, tetromino will probably know how feasible is to add that support. Probably would be better (or, at least, easier) to rely on logind (since it looks to be able to work booting with openrc)
Some info from ubuntu:
Can I install systemd and use the functionality of logind without actually using systemd as init?
(In reply to comment #8)
> Can I install systemd and use the functionality of logind without actually
> using systemd as init?
Honestly, I have no idea. I've heard Samuli's working on integrating logind into udev's ebuild, but dunno how that goes and if he checked if the daemon runs at all.
You can generally try launching it, updating pam.d and seeing what happens :). But you'd generally need to set USE=systemd then since otherwise many apps won't use it.
Will CC Samuli to try to know more about that efforts to have working logind on non-systemd setups
I have matured some experience with logind and consolekit support in gnome and fdo packages. The best future proof solution is to switch to logind, from consolekit, or we'll end up writing patches for many pkgs as soon as upstreams drop consolekit support. I think that we could fork logind off the systemd ebuild into a separate pkg and then phase out consolekit in favour of it.
All the packages that support consolekit now work with logind without problems, some are able to detect consolekit/logind at runtime, others don't (and I have patches for them: polkit, networkmanager in the systemd-love overlay) and do it at build time (and we can just force logind through ./configure flags).
A good amount of ebuilds featuring IUSE=systemd are actually only needing logind (aka libsystemd-login).
logind is just a consolekit replacement. It is included in systemd but can work without it. As far as I've seen, Ubuntu is doing/did this.
All this sucks, but consolekit is also no longer maintained.
(In reply to comment #11)
> upstreams drop consolekit support. I think that we could fork logind off the
> systemd ebuild into a separate pkg and then phase out consolekit in favour
> of it.
USE="logind" to sys-fs/udev is/was the plan. Some initial ebuild patcehs are at bug 461940, but at the time I've stumbled upon some blockers which are now solved, will try to get it in asap :-/
> All the packages that support consolekit now work with logind without
Xfce doesn't have anykind of systemd support yet.
And ConsoleKit support is not going to be dropped because Xfce supports other platforms like BSDs.
> All this sucks, but consolekit is also no longer maintained.
It's just mature and works well, thus has no urgent need for any changes. Last time it needed larger changes was when udev dropped udev-acl and we migrated it over to ConsoleKit git with the Debian maintainer. I'd expect same to happen if something else comes up.
I tried to make logind working with openrc (using systemd as device manager).
The good thing is that the init script works.
The bad thing is that's not enough. We need to start a "fake" version of org.freedesktop.systemd1 as Ubuntu does . This way gdm won't fallback to consolekit and will use logind instead.
Unfortunately, systemd-shim is segfaulting here (just try to start it as root). It looks like it needs a lot of patchwork.
Now, at this time, people wanting GNOME 3.8 need a fully working systemd environment :(
Ok, it looks like that gdm-3.6 (the one I tried, actually) is still using sd_booted() instead of looking for /run/systemd/seats.
And IIRC this has been fixed in gdm-3.8.
I am double checking both and will report here soon.
I've got logind running on openrc with GNOME 3.6 (still emerging and fixing my other GNOME 3.8 virtual machine).
Basically we need:
- a working logind init script for udev || systemd https://github.com/Sabayon/systemd-love/blob/master/sys-apps/systemd/files/logind.init.d
+*gnome-settings-daemon-3.8.3-r1 (14 Jul 2013)
+ 14 Jul 2013; Pacho Ramos <firstname.lastname@example.org>
+ +gnome-settings-daemon-3.8.3-r1.ebuild, -gnome-settings-daemon-3.8.2.ebuild:
+ Apply patches from gnome-3.8 branch, systemd needed for power and session
+ management, bug #464944
*** Bug 480270 has been marked as a duplicate of this bug. ***