A push request will follow soon, applying a patch available here: https://github.com/the-cavalry/light-locker/pull/117/files
Plus: reconsider IUSE=+consolekit It clashes with the planned switch of desktop profiles to +elogind. This package apparently does not need any of session managers enabled to run - or otherwise it was missing a REQUIRED_USE so far - so it should be fine without a default; desktop profiles at this time are setting +consolekit globally anyway, except if otherwise defined by systemd subprofile.
(In reply to Andreas Sturmlechner from comment #1) > This > package apparently does not need any of session managers enabled to run - or > otherwise it was missing a REQUIRED_USE so far This assertion is partially false. In fact that’s why I spotted the issue : if your session is handled with elogind and light-locker does not has elogind support, you will be able to lock the session, but you will never be able to re-enter the session again and will be stuck with a black screen after unlocking. And as soon as xorg is compiled with elogind support, the xfce session uses elogind automatically, so you must have light-locker support set accordingly. Same for systemd I assume (but I cannot check since I remain an openrc user). I will fix all the comments on the pull request as soon I can (probably not until tomorrow), regarding default USE flags, required USE, dependency mess and EAPI bump. But if someone else want to take over before that, you are welcome. Initially I just wanted to add elogind support by porting a PR that is available upstream ;)
(In reply to Guillaume Castagnino from comment #2) > (In reply to Andreas Sturmlechner from comment #1) > > This > > package apparently does not need any of session managers enabled to run - or > > otherwise it was missing a REQUIRED_USE so far > This assertion is partially false. In fact that’s why I spotted the issue : > if your session is handled with elogind and light-locker does not has > elogind support, you will be able to lock the session, but you will never be > able to re-enter the session again and will be stuck with a black screen > after unlocking. That misses the point I made. Does light-locker work without any session management? If so, a default session manager is not necessary. If not, the ebuilds have been wrong so far. Does a revdep of light-locker require light-locker built with a certain session-manager? Fine, that's not for light-locker to solve, but for the revdep to set the correct use deps on light-locker.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c355d1d34e9c90ebdfb422fedde2f9f1aee1b1d6 commit c355d1d34e9c90ebdfb422fedde2f9f1aee1b1d6 Author: Guillaume Castagnino <casta@xwing.info> AuthorDate: 2019-03-22 14:03:36 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-03-30 09:58:21 +0000 x11-misc/light-locker: add elogind support This patch comes from the pull request https://github.com/the-cavalry/light-locker/pull/117/files and add elogind support. Without this patch, if xorg is compiled with elogind support, the session cannot be restored after locking the screen and result in a black screen. Closes: https://bugs.gentoo.org/681300 Signed-off-by: Guillaume Castagnino <casta@xwing.info> Package-Manager: Portage-2.3.62, Repoman-2.3.12 Closes: https://github.com/gentoo/gentoo/pull/11460 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> .../files/light-locker-1.8.0-elogind.patch | 257 +++++++++++++++++++++ x11-misc/light-locker/light-locker-1.8.0-r1.ebuild | 74 ++++++ 2 files changed, 331 insertions(+)
