I didn't notice this problem as I am running 0.4.5_p20120320-r2. I have consolekit and systemd at the same time (as openSuSE and Fedora are doing) and have no problem. Also both USE flags enabled system wide. I have checked: http://cgit.freedesktop.org/ConsoleKit/log/ And I can't see why the blocker was added, could you clarify this? Thanks
because you should use USE="-consolekit systemd" and systemd-logind (pam_systemd.so) you don't need both of them installed at the same time, which is exactly what the blocker is trying to tell you the change happened now, and not earlier because logind support were still missing from so many places one session tracker is enough
But there are packages that RDEPEND on consolekit unconditionally that won't be able to be installed if systemd is present, right? For example lxdm, that looks to need consolekit (and is currently being supplied in Fedora even with systemd unit files because they let consolekit be installed with systemd)
http://fedoraproject.org/wiki/Features/ckremoval http://fedoraproject.org/wiki/Talk:Features/ckremoval points to them being parallel installable
Will drop the blocker in a week as I still don't see any reason for not letting consolekit and systemd coexist (as other distributions are doing and I am just running now)
(In reply to Pacho Ramos from comment #4) > Will drop the blocker in a week as I still don't see any reason for not > letting consolekit and systemd coexist (as other distributions are doing and > I am just running now) + 07 Aug 2013; Samuli Suominen <ssuominen@gentoo.org> consolekit-0.4.6.ebuild: + Stop blocking sys-apps/systemd (to let users switch between OpenRC and + ConsoleKit vs. systemd and systemd-logind without uninstalling one or the + another) wrt #478258 by Pacho Ramos However the sys-auth/consolekit doesn't install any systemd files and that will stay. Only allowing parallel installation for easy switching between OpenRC and systemd.
That looks fine to me, thanks a lot
But, I see this change: + rm -rf "${ED}"/usr/lib/systemd # avoid collision with systemd-logind I am running 0.4.5_p20120320-r2 without problems, needed services are started on demand under systemd and everything looks to work, what has changed in 0.4.6? (causing that collisions) (I am accessing internet using my smartphone and, then, I cannot download new tarball to review its NEWS file :( )
Per bug 481016 we currently have regressions due dropping consolekit unit files. The problem is that it's not clear to me what to do: - What other distros are doing is to simply install upstream unit files to let consolekit run with systemd too - Samuli suggests (and that sounds also better to me if it works... I cannot test it now :( ) to disable consolekit USE flag for pambase -> for this one we need to: 1. Either make sys-apps/systemd block sys-auth/pambase[consolekit] 2. Modify pambase ebuild to disable consolekit support when both (systemd and consolekit USE flags) are enabled as both collide => I would prefer this last option What do you think?
(In reply to Pacho Ramos from comment #8) [...] > 2. Modify pambase ebuild to disable consolekit support when both (systemd > and consolekit USE flags) are enabled as both collide => I would prefer this > last option > > What do you think? Other options could be: - Make pambase use REQUIRED_USE to force only one (consolekit and systemd) to be enabled at the same time. - Is there anyway to skip a pam file when another one is present? In that case, the idea would be to load systemd module and only rely on consolekit one when that one is not available
(In reply to Pacho Ramos from comment #8) > Per bug 481016 we currently have regressions due dropping consolekit unit > files. The problem is that it's not clear to me what to do: > - What other distros are doing is to simply install upstream unit files to > let consolekit run with systemd too > - Samuli suggests (and that sounds also better to me if it works... I cannot > test it now :( ) to disable consolekit USE flag for pambase -> for this one > we need to: > 1. Either make sys-apps/systemd block sys-auth/pambase[consolekit] > 2. Modify pambase ebuild to disable consolekit support when both (systemd > and consolekit USE flags) are enabled as both collide => I would prefer this > last option > > What do you think? I didn't suggest blocking sys-auth/pambase[consolekit] since that would be futile... that's only used by the pam_systemd.so module, not used by eg. GDM when logging in with internal logind support, not used by anything with internal logind support As in, pambase is only small part of the issue and blocking just that won't do much good except for text logins and display managers like slim without logind support. There are multiple ways to invoke ConsoleKit, by PAM module, by dbus call or by manual console-kit-daemon / ck-launch-session -like commands. If you want to block, block them all or nothing. The solution is the blocker that you had me remove earlier in this bug... another possible solution is the removal of this line from the .service file in addition to removing the files already: /usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service:SystemdService=console-kit-daemon.service The purpose is to *prevent* anything from system using systemd calling CK since the status of it is gone so far, and logind is mostly supported where required, we can rely in pam_systemd.so module to take care of the rest (like x11-misc/slim) By letting them be installed like this side-by-side has the purpose of allowing people to switch between openrc+consolekit vs. systemd+logind just by changing init= Otherwise I have no idea why you keep wanting CK so much on GNOME 3.8+ system with systemd, that doesn't compute to me :P
(In reply to Samuli Suominen from comment #10) [...] > I didn't suggest blocking sys-auth/pambase[consolekit] since that would be > futile... that's only used by the pam_systemd.so module, not used by eg. GDM > when logging in with internal logind support, not used by anything with > internal logind support Then, pambase[consolekit] and pambase[systemd] should be exclusive or, otherwise, pambase[systemd] should disable consolekit as it takes care of it and prevents consolekit for being invoked. > As in, pambase is only small part of the issue and blocking just that won't > do much good except for text logins and display managers like slim without > logind support. > There are multiple ways to invoke ConsoleKit, by PAM module, by dbus call or > by manual console-kit-daemon / ck-launch-session -like commands. If you want > to block, block them all or nothing. > > The solution is the blocker that you had me remove earlier in this bug... > another possible solution is the removal of this line from the .service file > in addition to removing the files already: > /usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service: > SystemdService=console-kit-daemon.service > > The purpose is to *prevent* anything from system using systemd calling CK > since the status of it is gone so far, and logind is mostly supported where > required, we can rely in pam_systemd.so module to take care of the rest > (like x11-misc/slim) > By letting them be installed like this side-by-side has the purpose of > allowing people to switch between openrc+consolekit vs. systemd+logind just > by changing init= > Otherwise I have no idea why you keep wanting CK so much on GNOME 3.8+ > system with systemd, that doesn't compute to me :P I want to keep it for now because, clearly, tree is not ready to drop consolekit completely at this stage, even "consolekit" is not used always only for consolekit support currently. But you are forcing this incompatibility that is not present on any other distribution. The only distribution cleaning completely consolekit is Mageia, but they have all their packages ported to use logind. That is not the case in Gentoo and won't be the case in the near future. The pambase blockers would allow both positions to live: - You would still get consolekit not started on systemd systems - Things like slim wouldn't break
(In reply to Samuli Suominen from comment #10) [...] > Otherwise I have no idea why you keep wanting CK so much on GNOME 3.8+ > system with systemd, that doesn't compute to me :P Regarding this: my intention is to not cause breakage on stuff outside GNOME 3.8
I am also unsure about what will occur with some packages like the following if we keep dropping the units for starting consolekit when needed on systemd: - app-emulation/spice-vdagent -> Looks to be consolekit only (I don't see any systemd support), then, I am unsure about how will it work on systemd when disabling consolekit completely - kde-base/kdm -> The same case, what will occur if that "consolekit" support is disabled since doesn't look to have alternative logind support? (or is it builtin?) - net-wireless/bluez -> this could be solved for now creating plugdev group unconditionally I think - sys-auth/ykpers - x11-apps/xdm - x11-misc/cdm - x11-misc/slim -> bug 481016 - xfce-base/xfce4-session -> it's using "consolekit" USE flag also for systemd
Also: - app-admin/packagekit-base -> requires consolekit unconditionally in RDEPEND - gnome-extra/gnome-packagekit -> the same - lxde-base/lxdm -> the same Also sys-auth/polkit -> maybe some other "consolekit" USE flags in other packages (like slim) should be replaced by a "pam" one pulling proper pam module depending on systemd USE flag :/
(In reply to Pacho Ramos from comment #13) > - kde-base/kdm -> The same case, what will occur if that "consolekit" > support is disabled since doesn't look to have alternative logind support? > (or is it builtin?) I think KDM should work fine without consolekit with systemd, see bug #451954.
(In reply to Michael Palimaka (kensington) from comment #15) > (In reply to Pacho Ramos from comment #13) > > - kde-base/kdm -> The same case, what will occur if that "consolekit" > > support is disabled since doesn't look to have alternative logind support? > > (or is it builtin?) > > I think KDM should work fine without consolekit with systemd, see bug > #451954. But, it's for 4.11, what about 4.10? For it I see: - "+consolekit" set - $(cmake-utils_use_with consolekit CkConnector) - elog message explaining consolekit needs to be running How does it behave on systemd? (I don't have KDE :S) How does it behave depending on consolekit support being enabled/disabled even having pam configured to use pam_systemd as fallback?
(In reply to Pacho Ramos from comment #16) > (In reply to Michael Palimaka (kensington) from comment #15) > > (In reply to Pacho Ramos from comment #13) > > > - kde-base/kdm -> The same case, what will occur if that "consolekit" > > > support is disabled since doesn't look to have alternative logind support? > > > (or is it builtin?) > > > > I think KDM should work fine without consolekit with systemd, see bug > > #451954. > > But, it's for 4.11, what about 4.10? For it I see: > - "+consolekit" set > - $(cmake-utils_use_with consolekit CkConnector) > - elog message explaining consolekit needs to be running 4.10 has limited if any useful support for systemd. We anticipate continuing to force consolekit for 4.10 > > How does it behave on systemd? (I don't have KDE :S) How does it behave > depending on consolekit support being enabled/disabled even having pam > configured to use pam_systemd as fallback? I don't use systemd so I can't test, sorry. It looked like floppym had success with using pam_systemd.
(In reply to Michael Palimaka (kensington) from comment #17) [...] > > > > How does it behave on systemd? (I don't have KDE :S) How does it behave > > depending on consolekit support being enabled/disabled even having pam > > configured to use pam_systemd as fallback? > I don't use systemd so I can't test, sorry. It looked like floppym had > success with using pam_systemd. Will wait then for him, hopefully he will be able to know what combination gives better results until native systemd is supported in 4.11 :/
OK, bluez case should be solved. Will CC the other maintainers: @maintainer, I would like to know what regressions could appear when disabling "consolekit" support for your packages while running systemd. In some cases (like slim), looks like having pambase[-consolekit,systemd] is enough. Thanks! (In reply to Pacho Ramos from comment #13) > I am also unsure about what will occur with some packages like the following > if we keep dropping the units for starting consolekit when needed on systemd: > - app-emulation/spice-vdagent -> Looks to be consolekit only (I don't see > any systemd support), then, I am unsure about how will it work on systemd > when disabling consolekit completely > - kde-base/kdm -> The same case, what will occur if that "consolekit" > support is disabled since doesn't look to have alternative logind support? > (or is it builtin?) > - net-wireless/bluez -> this could be solved for now creating plugdev group > unconditionally I think > - sys-auth/ykpers > - x11-apps/xdm > - x11-misc/cdm > - x11-misc/slim -> bug 481016 > - xfce-base/xfce4-session -> it's using "consolekit" USE flag also for > systemd (In reply to Pacho Ramos from comment #14) > Also: > - app-admin/packagekit-base -> requires consolekit unconditionally in RDEPEND > - gnome-extra/gnome-packagekit -> the same > - lxde-base/lxdm -> the same > > Also > > sys-auth/polkit -> maybe some other "consolekit" USE flags in other packages > (like slim) should be replaced by a "pam" one pulling proper pam module > depending on systemd USE flag :/
(In reply to Pacho Ramos from comment #19) > In summary, we would highly appreciate if you could tell us what was the > best configutation for old stable kdm in the tree when running systemd. > Should consolekit for it be enabled/running or is some fallback > mechanism (usually from pam config) working? I was running kdm with systemd for a long time. In the end, I had USE="-consolekit systemd" enabled in /etc/portage/make.conf and -consolekit in /etc/portage/use.force. This worked well - I experienced no actual problems. The only minor problem I noticed was that the shutdown took well over a minute - apparently systemd was waiting for something. In bug #391339 we figured out that this is probably ssh-agent, which cannot be killed due to some KDE bug that makes it start with masked signals. I was able to workaround this using the following change to the kdm systemd unit file: [Service] TimeoutStopSec=10 The last versions I used were kde-base/kdm-4.10.5-r1 and sys-apps/systemd-206, where the mentioned workaround was no longer needed. At that point, everything was running smoothly without any customisation. sys-auth/consolekit was no longer installed at that time. Generally, KDE 4.10 (dunno about 4.11) did not support systemd directly, so it worked with just PAM. The default PAM config should suffice - we fixed that quite a while ago already. I remember having consolekit and systemd installed in parallel in the beginning, and I even think there were no major issues, but I would not bet my head on it. iirc, I just set USE="-consolekit", because I had been told that consolekit is outdated and unmaintained and I wanted to test a pure systemd system. I hope this contains all the information you need. If there is anything else I can do, please do not hesitate to ask.
Thanks a lot Dennis :)
for Xfce it was there as purely runtime dependency, I've removed it from there now
(In reply to Pacho Ramos from comment #11) > (In reply to Samuli Suominen from comment #10) > [...] > > I didn't suggest blocking sys-auth/pambase[consolekit] since that would be > > futile... that's only used by the pam_systemd.so module, not used by eg. GDM > > when logging in with internal logind support, not used by anything with > > internal logind support > > Then, pambase[consolekit] and pambase[systemd] should be exclusive or, > otherwise, pambase[systemd] should disable consolekit as it takes care of it > and prevents consolekit for being invoked. Why? If sys-auth/consolekit still blocked sys-apps/systemd like it did earlier in this bug, then the "-" beginning in the pam file line for pam_systemd.so would recognize the module isn't there and allow it to be skipped without errors. > > As in, pambase is only small part of the issue and blocking just that won't > > do much good except for text logins and display managers like slim without > > logind support. > > There are multiple ways to invoke ConsoleKit, by PAM module, by dbus call or > > by manual console-kit-daemon / ck-launch-session -like commands. If you want > > to block, block them all or nothing. > > > > The solution is the blocker that you had me remove earlier in this bug... > > another possible solution is the removal of this line from the .service file > > in addition to removing the files already: > > /usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service: > > SystemdService=console-kit-daemon.service > > > > The purpose is to *prevent* anything from system using systemd calling CK > > since the status of it is gone so far, and logind is mostly supported where > > required, we can rely in pam_systemd.so module to take care of the rest > > (like x11-misc/slim) > > By letting them be installed like this side-by-side has the purpose of > > allowing people to switch between openrc+consolekit vs. systemd+logind just > > by changing init= > > Otherwise I have no idea why you keep wanting CK so much on GNOME 3.8+ > > system with systemd, that doesn't compute to me :P > > I want to keep it for now because, clearly, tree is not ready to drop > consolekit completely at this stage, even "consolekit" is not used always > only for consolekit support currently. But you are forcing this > incompatibility that is not present on any other distribution. The only > distribution cleaning completely consolekit is Mageia, but they have all > their packages ported to use logind. That is not the case in Gentoo and > won't be the case in the near future. The tree is ready enough for it. My systemd arm box is doing just fine with no CK installed, and in fact having CK installed results in the issues people have raised. You haven't provided a single case where having CK on Gentoo with systemd would be useful. > The pambase blockers would allow both positions to live: > - You would still get consolekit not started on systemd systems Not true, it would get invoked by programs doing runtime checks if ConsoleKit can be called by dbus, or by execution of one of it's helpers (like, ck-launch-session). Back to the proper blocker we had in place earlier. > - Things like slim wouldn't break It's not broken, but works just fine with plain pam_systemd.so when ConsoleKit isn't messing things up. Back to the blocker which was correctly in place before. :-)
(In reply to Pacho Ramos from comment #13) > I am also unsure about what will occur with some packages like the following > if we keep dropping the units for starting consolekit when needed on systemd: > - app-emulation/spice-vdagent -> Looks to be consolekit only (I don't see > any systemd support), then, I am unsure about how will it work on systemd > when disabling consolekit completely Looks like optional CK support, like in sys-auth/ykpers, nothing to worry about > - kde-base/kdm -> The same case, what will occur if that "consolekit" > support is disabled since doesn't look to have alternative logind support? > (or is it builtin?) Same as for other DMs, if the internal logind support isn't available, the fallback, pam_systemd.so is being used > - net-wireless/bluez -> this could be solved for now creating plugdev group > unconditionally I think OK > - sys-auth/ykpers I don't see any problems w/ ykpers ebuild > - x11-apps/xdm > - x11-misc/cdm > - x11-misc/slim -> bug 481016 All the DMs, including slim, can use pam_systemd.so when the internal logind support is missing, and there is no need to have CK installed, in fact, it will propably mess things up As in, I still fail to see any issues... except issues raised when people are doing stupid things like installing CK on systemd based system, exposing the system to races with old programs.
I don't think we can do better without systemd specific profiles in order to keep them parallel installable: 21 Aug 2013; Samuli Suominen <ssuominen@gentoo.org> consolekit-0.4.6.ebuild, metadata.xml: Rename USE="systemd" by USE="systemd-units" to avoid conflict with systemd vs. -systemd, package.use.mask and profiles. 21 Aug 2013; Samuli Suominen <ssuominen@gentoo.org> consolekit-0.4.6.ebuild, metadata.xml: Introduce USE="systemd" to force installation of systemd unit files despite of systemd-logind making it more or less obsolete (and remove SystemdService= line from the .service file when required) wrt #478258 21 Aug 2013; Samuli Suominen <ssuominen@gentoo.org> pambase-20120417-r2.ebuild: Warn people from enabling weird setup with USE="consolekit systemd" and having 2 session trackers running at the same time wrt #478258 Some end applications might still use DBUS to run it, or in worst case some display managers (or end applications) will still call the binaries This could be done better if we had systemd specific profiles
(In reply to Samuli Suominen from comment #23) [...] > Why? If sys-auth/consolekit still blocked sys-apps/systemd like it did > earlier in this bug, then the "-" beginning in the pam file line for > pam_systemd.so would recognize the module isn't there and allow it to be > skipped without errors. > Probably both can be used: the main point is that when both pam modules are present, systemd should take precedence on a system *running* systemd (and, then, likely having systemd enabled systemd wide), what will occur for people having systemd ebuild as udev provider? [...] > > I want to keep it for now because, clearly, tree is not ready to drop > > consolekit completely at this stage, even "consolekit" is not used always > > only for consolekit support currently. But you are forcing this > > incompatibility that is not present on any other distribution. The only > > distribution cleaning completely consolekit is Mageia, but they have all > > their packages ported to use logind. That is not the case in Gentoo and > > won't be the case in the near future. > > The tree is ready enough for it. My systemd arm box is doing just fine with > no CK installed, and in fact having CK installed results in the issues > people have raised. > You haven't provided a single case where having CK on Gentoo with systemd > would be useful. > Well, for example bluez wasn't working as expected as its "consolekit" USE flag wasn't only controlling consolekit support (but also logind), the same for xfce-base/xfce4-session > > The pambase blockers would allow both positions to live: > > - You would still get consolekit not started on systemd systems > > Not true, it would get invoked by programs doing runtime checks if > ConsoleKit can be called by dbus, or by execution of one of it's helpers > (like, ck-launch-session). Back to the proper blocker we had in place > earlier. > The problem of adding the blocker at sys-apps/systemd level is that it prevents people from using udev from it Regarding sys-auth/ykpers -> do you know what consolekit USE flag is doing to it? I was asking the maintainer to know how will it behave when that support being disabled (even having logind and pam_systemd around) (In reply to Samuli Suominen from comment #25) > I don't think we can do better without systemd specific profiles in order to > keep them parallel installable: I agree, my final intention would be to mask that USE flag --> I reported bug 481920 yesterday but was waiting for this one to know if we should mask consolekit USE globally or for some set of packages. Looks like globally (apart of the ykpers case that I don't know about :S) Will add a note to the bug for remembering. Thanks for your contribution :)
(In reply to Pacho Ramos from comment #26) > Well, for example bluez wasn't working as expected as its "consolekit" USE > flag wasn't only controlling consolekit support (but also logind), the same > for xfce-base/xfce4-session xfce4-session was always false-positive in your check, the version in ~arch had it's own USE="systemd" and the one in stable only had sys-apps/systemd in || ( ) runtime-only depend and was thus 100% harmless As in, it was only bluez > Regarding sys-auth/ykpers -> do you know what consolekit USE flag is doing > to it? I was asking the maintainer to know how will it behave when that > support being disabled (even having logind and pam_systemd around) No, I'm not sure what it does but it looks optional and the software otherwise very HW -specific (Yubico's YubiKey?!) Hardly qualifies as anykind of blocker, imho > (In reply to Samuli Suominen from comment #25) > > I don't think we can do better without systemd specific profiles in order to > > keep them parallel installable: > > I agree, my final intention would be to mask that USE flag --> I reported > bug 481920 yesterday but was waiting for this one to know if we should mask > consolekit USE globally or for some set of packages. Looks like globally > (apart of the ykpers case that I don't know about :S) If and when systemd specific profiles come up, just go with global mask, there are numerous logind patches floating out there. Those we have missed can be fixed retroactively. And yeah, dunno about ykpers, but I'm still not worried ;)
*** Bug 482242 has been marked as a duplicate of this bug. ***
