On Fri, 2015-11-20 at 15:38 +0100, Andrew Shadura wrote: > Enable the user-sessions support with a PACKAGECONFIG flag.
I've tried this out in combination with the D-Bus 1.10 update patches. It's perhaps worth pointing out that user sessions only work in combination with pam. I also found that one minor fix was needed in meta/recipes-core/dbus/dbus_1.10.2.bb. Andrew, Ross, feel free to just squash that into the pending patch. But overall it looked good, so I'd love to have this in OE-core. https://github.com/pohly/poky/commit/5b32e63f9e37492cef8de7aabfae562ab072b510 commit 5b32e63f9e37492cef8de7aabfae562ab072b510 Author: Patrick Ohly <[email protected]> Date: Fri Jan 8 15:34:50 2016 +0100 dbus_1.10.2.bb: fix path to systemctl When compiling with systemd, pam and user sessions, the resulting /usr/lib/systemd/user/dbus.socket ensures that the right DBUS_SESSION_BUS_ADDRESS gets put into the environment when logging into the system. The default configure behavior is to look in the PATH, which picks up the tool from the host sysroot. We need to override that so that the final location on the target is used instead. This is only relevant at the moment when enabling user sessions, but it makes sense to fix the value in all cases. Signed-off-by: Patrick Ohly <[email protected]> diff --git a/meta/recipes-core/dbus/dbus_1.10.2.bb b/meta/recipes-core/dbus/dbus_1.10.2.bb index ffb428b..a6cb649 100644 --- a/meta/recipes-core/dbus/dbus_1.10.2.bb +++ b/meta/recipes-core/dbus/dbus_1.10.2.bb @@ -96,6 +96,10 @@ EXTRA_OECONF = "--disable-tests \ EXTRA_OECONF_append_class-native = " --disable-selinux" +# Automatic detection in the configure script picks up the path to +# the native tool, therefore we must override the automatism. +EXTRA_OECONF_append_class-target = " SYSTEMCTL=${base_bindir}/systemctl" + PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} \ ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}" PACKAGECONFIG_class-native = "" -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
