Created attachment 452982 [details] Implementation plan - 2016-11-11 This Tracker is used to track the progress of integrating sys-auth/elogind into Gentoo. About elogind: -------------- Elogind is the systemd project's "logind", extracted out to be a stand-alone daemon. It integrates with PAM to know the set of users that are logged in to a system and whether they are logged in graphically, on the console, or remotely. Elogind exposes this information via the standard org.freedesktop.login1 D-Bus interface, as well as through the file system using systemd's standard /run/systemd layout. Elogind also provides "libelogind", which is a subset of the facilities offered by "libsystemd". There is a "libelogind.pc" pkg-config file as well. About me: --------- I am no official gentoo developer. I do proxy maintain a few packages, but that's it. This means, that the following implementation plan is just a suggestion, open for debate. About the implementation plan: ------------------------------ To be able to edit the implementation plan, I will not post it directly, but attach it as a text file. Why the fuss? ------------- While Consolekit is no longer maintained upstream, the fork ConsoleKit2 is under development. Although this works pretty well, development elsewhere goes to use logind as a session tracker. Example: To use Wayland, KWin needs to communicate with logind DBus API. If this is not provided, no native Wayland session can be started. To make this work, the logind DBus interface needs to be installed (this does neither require using systemd nor logind). Elogind does provide such an interface. This site has some more details about what logind is used for: http://blog.davidedmundson.co.uk/blog/systemd-and-plasma Any suggestions, updates, help and other feedback is highly welcome and appreciated!
If this goes in, we should also be able to support GNOME without systemd officially. So CCing us. What's the status of elogind itself? Especially in regards to tracking changes done to logind code in systemd as of late? Does it see active syncing of logind code changes done in systemd or anything of that sort? I.e, is elogind an active upstream? Latest change seems from March, but maybe that's just because there's nothing changed in systemd for logind that could use porting to elogind?
Created attachment 452994 [details] Implementation plan V2 - 2016-11-11 Added the involvement of the respective package maintainers.
(In reply to Mart Raudsepp from comment #1) > If this goes in, we should also be able to support GNOME without systemd > officially. So CCing us. The only interesting ebuild I found so far was gvfs. > What's the status of elogind itself? Especially in regards to tracking > changes done to logind code in systemd as of late? Does it see active > syncing of logind code changes done in systemd or anything of that sort? > I.e, is elogind an active upstream? Latest change seems from March, but > maybe that's just because there's nothing changed in systemd for logind that > could use porting to elogind? Actually I just got involved within elogind itself. Once I have completed opening bugs for the packages I have already updated, I plan to analyze what changes where made to systemd-logind since version 219 that might be relevant for elogind.
(In reply to Sven Eden from comment #3) > (In reply to Mart Raudsepp from comment #1) > > If this goes in, we should also be able to support GNOME without systemd > > officially. So CCing us. > > The only interesting ebuild I found so far was gvfs. Usage of logind is rather widespread in GNOME for some basic functionality like being able to suspend, etc. There are no deps in ebuilds for this, it relies on something providing the org.freedesktop.login1 DBus services. Currently we force systemd for GNOME stuff, because it's the only in-tree provider of those services. There is a project to bring back these functionalities by reverting the removal of CK support in various packages (https://forums.gentoo.org/viewtopic-t-1022050.html), but this is a community effort we can not support officially due to it being a real long-term solution, instead we want an alternative logind implementation and if that implementation is up to snuff, things should just work. Hopefully elogind is one such option for this here. All of the current GNOME team members are quite happy with systemd, so we've had no interest in devoting our own time significantly to this, but if you bring us elogind, we can revise our non-systemd blockers, stance of not supporting things without systemd and so on. Good luck in your efforts :)
(In reply to Mart Raudsepp from comment #4) > Usage of logind is rather widespread in GNOME for some basic functionality > like being able to suspend, etc. There are no deps in ebuilds for this, it > relies on something providing the org.freedesktop.login1 DBus services. > Currently we force systemd for GNOME stuff, because it's the only in-tree > provider of those services. Then it is good that elogind provides org.freedesktop.login1 DBus services. :-) Maybe it will be like with kde-plasma/powerdevil. The only change needed was to have the ebuild accept elogind as a substitution for consolekit.
Didn't realize we'd get all the tracking notifications. Removing gnome@ to not bother who isn't maybe interested quite yet, and CCing in person instead to monitor the development. Once things are further along, I'm sure re-adding us where relevant is acceptable (and if it needs action in our package, rather assign to us for these bugs once the base is in). Wrt changes, in many places there simply are no dependencies at all and nothing to change for the package itself. We just need to ensure that the user has logind services running; currently we are forced to do so by making it hard to not have systemd, documenting that systemd is needed, etc. Based on some of the bugs tracked via here, I see there are various things that would want to then link to some elogind library instead of libsystemd, but I don't think these are the main things, nor would all of them be able to be satisfied by elogind, as there are e.g journald stuff, etc; and elogind doesn't handle that stuff, nor should it.
(In reply to Mart Raudsepp from comment #6) > Wrt changes, in many places there simply are no dependencies at all and > nothing to change for the package itself. We just need to ensure that the > user has logind services running; currently we are forced to do so by making > it hard to not have systemd, documenting that systemd is needed, etc. Based > on some of the bugs tracked via here, I see there are various things that > would want to then link to some elogind library instead of libsystemd, but I > don't think these are the main things, nor would all of them be able to be > satisfied by elogind, as there are e.g journald stuff, etc; and elogind > doesn't handle that stuff, nor should it. That is exactly the catch. sys-auth/elogind provides the login1 dbus service and libelogind to link against, plus the needed headers. So the only part that can be substituted is libsystemd-login. The package then needs to include <elogind/sd-login.h> instead of <systemd/sd-login.h> and that's it. Packages that use systemd-journal or any other non-logind-part, are of no concern. I found 74 packages installed on my system with at least one systemd reference in them. Most only install service files. Some make use of systemd-journal. Only 10 make use of libsystemd-login, and I have now submitted all of them but x11-base/xorg-server. The latter has to be started with "-keeptty" to add systemd-login/elogind integration, and that argument is strictly for debugging. -------- However, I am done so far. The ebuilds posted in the blocking bugs and published via layman/seden enable the following on my systemd: 1) SDDM starts with full support for shutdown, reboot, suspend and hibernate. 2) Plasma 5 starts without ConsoleKit support. Shutdown, reboot, suspend and hibernate are provided and work. 3) Suspending my laptop and waking it up later are significantly faster than while using ConsoleKit2. What does not work: A) When I plug in an USB key, it does not get recognized. It doesn't even show up in dmesg, so I guess this has nothing to do with elogind. But at least testing whether mounting of external drives work isn't done yet. B) When issuing a shutdown or reboot command from the Plasma Menu, the system drops back to SDDM and does not continue to shutdown or reboot. So the result is the same as simply logging out. These are the main issues I'll dig into next week.
(In reply to Sven Eden from comment #7) > A) When I plug in an USB key, it does not get recognized. It doesn't even > show up in dmesg, so I guess this has nothing to do with elogind. But at > least testing whether mounting of external drives work isn't done yet. Fixed in Bug 599494 (sys-apps/dbus: Add elogind support) : Brian Evans found a typo in my patch that caused elogind to not being supported by dbus at all. Once fixed I can attach, mount, unmount and eject USB drives without any issues.
Sven, thank-you very much for working on this. This is a really big step in keeping choice alive on Gentoo.
Did anyone contact Funtoo people? If I don't misremember, they are doing efforts to maintain Gnome running on non-systemd setups... then, maybe they will be able to test the changes and, anyway, they would likely be interested in the short term
Has anyone come up with description for the elogind USE flag yet?
(In reply to Michael Palimaka (kensington) from comment #11) > Has anyone come up with description for the elogind USE flag yet? I have different via metadata.xml, but that is only because the packages make different uses. It is a bit vague. Maybe a general flag might be better, like: <flag name="elogind">Use <pkg>sys-auth/elogind</pkg> for session tracking.</flag>
Sorry for being absent so long. I have worked on getting elogind up to the systemd-226 code base, which is now complete, but still needs testing. However, I have some very serious personal problems at home, which I have to attend to, so my spare time is really sparse at the moment. I do hope to be able to catch up soon.
I've been testing your patches running sys-auth/elogind-225.9999 from your overlay. Compared to the in-tree sys-auth/elogind-219.12-r5 things that I have noticed as fixed so far include: - Opening Konsole and trying to get a root shell with "sudo -s" doesn't freeze the PC. - Hitting the reboot button from the Plasma Application Launcher actually reboots the PC instead of sending one back to sddm (Xorg) or freezing the PC (Wayland).
I've moved the regular elogind USE mask to a stable mask: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fcd988a5427b136abd031da00faff8fef4c9235f
Are we still missing a bug for elogind integration of x11-apps/xinit so it can be rolled out officially? The patched ebuild is available in Sven's overlay and I haven't noticed any problems with it over the past few months of use.
(In reply to Martijn Schmidt from comment #16) > Are we still missing a bug for elogind integration of x11-apps/xinit so it > can be rolled out officially? The patched ebuild is available in Sven's > overlay and I haven't noticed any problems with it over the past few months > of use. I never opened a bug, because I wasn't entirely sure, whether the patch is needed or not. It is, as far as I can test and see, somewhat optional. However, bug 620896 opened. Thank you very much for the reminder!
We have a wiki page now: https://wiki.gentoo.org/wiki/Elogind
By the way, from the KDE Plasma 5.11 release announcements.. "Furthermore, it is now possible to use ConsoleKit2 instead of logind for setting up the Wayland session, extending the number of supported platforms." https://www.kde.org/announcements/plasma-5.10.95.php I assume Gentoo is still moving forward with the elogind integration, since it's good to have diversity, just thought I'd put this piece of news in the comments.
(In reply to Martijn Schmidt from comment #19) > I assume Gentoo is still moving forward with the elogind integration, since > it's good to have diversity, just thought I'd put this piece of news in the > comments. Sure, we'd like to support as many options as possible. It just so happens that elogind integration seems to get the most love right now because it's well used inside Gentoo KDE team. Also, it sure doesn't hurt that it "just works" and the maintainer is a Gentooer (hi Sven)!
Please check out https://bugs.gentoo.org/662088
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bea47cee314829edbb41453d1e89fa1d1d3f9993 commit bea47cee314829edbb41453d1e89fa1d1d3f9993 Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2019-03-20 09:36:42 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2019-03-20 09:50:44 +0000 profiles/desktop/gnome: globally enable elogind, disable consolekit GNOME really desires a logind provider. Now that the core gnome desktop supports elogind, we can default enable it in GNOME profile with a clean gnome-base/gnome install path without systemd. For this we also need to disable consolekit from desktop profile (until it's still enabled there), as some packages block between USE=consolekit and USE=elogind. profiles/desktop/gnome/systemd relies on the systemd profile now use.masking USE=elogind globally (a change I made some days ago), and enabling USE=systemd in its place, so should be no regressions there. Because stable doesn't have a usable non-systemd GNOME setup anyways, desktop/gnome profile wasn't out of the box usable, thus we don't need to concern ourselves for stable users here and get the profile working for ~arch users -- before this everyone using gnome should have been using desktop/gnome/systemd instead anyway. Bug: https://bugs.gentoo.org/599470 Signed-off-by: Mart Raudsepp <leio@gentoo.org> profiles/targets/desktop/gnome/make.defaults | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Could someone be kind enough to provide an official porting guide that I could throw at upstream?
Hello, after upgrading the profile to default/linux/amd64/17.1/desktop/plasma, consolekit at_console /var/run/console stopped working because it requires a symlink from /usr/lib64/ConsoleKit/run-sessions.d/pam-foreground.ck->/usr/lib/ConsoleKit/run-session.d/pam-foreground-compat.ck... It seems ConsoleKit doesn't install correctly on the 17.1 profiles. Furthermore I already had to patch by hand dbus-1.12.12-r1 ebuild to add "--with-console-auth-dir=/var/run/console" to make it work with consolekit at_console logic, because that already has been obsoleted by default in dbus. The dependency on cgroup and inotify, timerfd, eventfd doesn't sound problematic at all... there's simply no point not to build a kernel without cgroup/inotify/timerfd/eventfd for a plasma profile. So to me it sounds like it's time to switch at least the plasma profile to default on elogind which would solve many issues at once by setting USE="-consolekit elogind" by default. Thank you.
That's what we are tracking in bug 682160 already. Please file a bug consolekit.
(In reply to Andreas Sturmlechner from comment #25) > That's what we are tracking in bug 682160 already. > > Please file a bug consolekit. I'm not sure if it's worth filing a bug for consolekit 17.1 profile that broke at_console, because stable dbus already obsoleted consolekit at_console, I was patching in back in dbus manually or I wouldn't have noticed. In my configuration I did find one regression with elogind today: the backlighthelper of plasma (X using modesetting driver so xbacklight doesn't work and the backlighthelper started by dbus is required) didn't work anymore. It turns out polkitd elogind support requires polkitd to open /proc/pid/status and I had /proc mounted with the hidepid=2,gid=proc option. After I added the polkitd user to the proc group, that regression is gone (that wasn't required when polkitd was built for consolekit). So far so good with USE="elogind -consolekit" on default/linux/amd64/17.1/desktop/plasma. I thought of reporting this here in case other runs into any issue with the backlighthelper if using the hidepid proc mount option. Thanks.
https://forums.gentoo.org/viewtopic-t-1099870.html Seems that is it not working properly...
This is a tracker bug, not individual troubleshooting.