If USE="systemd" is not set, the current ebuild forcefully disables support for libsystemd-login. The ebuild should be updated to accept USE="elogind", which then patches in support for libelogind as a substitution for libsystemd-login.
Created attachment 453028 [details] udisks-2.1.7-r3.ebuild Updated ebuild that accepts USE="elogind" and patches in support for libelogind as a substitution for libsystemd-login. Patch follows.
Created attachment 453030 [details, diff] Patch to enable elogind support The patch does the following: a) Add checking for libelogind to configure.ac b) Add LIBELOGIND_CFLAGS and _LIBS to src/Makefile.am c) Add an include <elogind/sd-login.h> to src/udisksdaemonutil.c, used when libelogind is found and libsystemd-login not present.
Created attachment 454326 [details] udisks-2.1.7-r4.ebuild Apply xdg environment fix from official udisks-2.1.7-r1 ebuild
Created attachment 454650 [details] udisks-2.1.8-r1.ebuild : Version bump with elogind support Just a version bump to the new version. I'll keep the old one in my overlay, as it is based upon the stable udisks-2.1.7
Hi Sven, The udisks-2.1.8-r1.ebuild pulled in through the seden overlay fails during the configure phase for me, I believe the important piece of text here is as follows: configure: WARNING: unrecognized options: --disable-debug At the end of the configure phase it crashes out with: ./configure: line 12290: syntax error near unexpected token `maximum' ./configure: line 12290: `GNOME_COMPILE_WARNINGS(maximum)' I will attach the (broken) build.log and config.log in the bugtracker momentarily. After comparing the ebuild in your overlay with the one in Gentoo's main tree, I noticed that the one in the main tree does not inherit "autotools". After removing the autotools inherit statement from the ebuild and running a manifest, I was able to successfully compile udisks-2.1.8-r1.ebuild with the elogind patches enabled.
Created attachment 461542 [details] udisks-2.1.8-r1.ebuild faulty build.log with inherit autotools
Created attachment 461544 [details] udisks-2.1.8-r1.ebuild faulty config.log with inherit autotools
Created attachment 471958 [details] sys-fs/udisks-2.6.4-r1 : Version bump with elogind support Here is the adapted new udisks versions ebuild with elogind support. The old patch does not work, so I'll upload the new one next. Currently I can not upload to my overlay until next week, though.
Created attachment 471960 [details, diff] Enable elogind support in udisks-2.6.* This is the mentioned patch.
Just forgot! udeved has created https://github.com/storaged-project/udisks/pull/257 to bring direct elogind support to udisks.
Created attachment 473864 [details, diff] sys-fs/udisks-2.6.5 : Add elogind USE flag (In reply to Sven Eden from comment #10) > Just forgot! > > udeved has created https://github.com/storaged-project/udisks/pull/257 to > bring direct elogind support to udisks. And accepted! *yay* https://github.com/storaged-project/udisks/commit/884b630 udisks-2.6.5 already supports elogind upstream. However, I have seen that while the ebuild has a systemd USE flag, pulling in systemd as a dependency, an elogind USE flag is missing. Please see the attached patch. Once that is added, this bug can be closed.
Your ebuild does not set any build flag; is that correct?
(In reply to Andreas Sturmlechner from comment #12) > Your ebuild does not set any build flag; is that correct? Yes. The udisks build system automatically supports elogind if it is found. The USE flag sets the dependency only. Although, at the point where udisks is merged, there *should* be something having pulled in elogind already, I think it is good to have the dependency set in the ebuild. I do not like implicit dependencies. ;-)
In that case your diff is fine of course, with two minor ammendments: - REQUIRED_USE="?? ( elogind systemd )" # a shorter equivalent - elogind? ( >=sys-auth/elogind-219 ) # no need to add version, no earlier in tree
Created attachment 474508 [details, diff] reviewed patch to add elogind dependency according to USE Flags So this is ok? Thank you very much for the hint about the ?? operator. It's very handy!
Thanks for your work, pushed in git commit 3ef78c1dc3bf8b75864388044a5bf233ff6088f0 ;)