'emerge -v --update --newuse --deep --with-bdeps=y --backtrack=30 --keep-going @world' fails with: root@impala:/etc/systemd/system(69)# emerge -v --update --newuse --deep --with-bdeps=y --backtrack=30 --keep-going @world ... [ebuild R ] sys-apps/dbus-1.10.24::gentoo USE="X doc systemd user-session* -debug -elogind (-selinux) -static-libs {-test}" ABI_X86="32 (64) (-x32)" 0 KiB ... [ebuild U ] kde-apps/kdenetwork-meta-17.08.2:5::gentoo [17.08.1:5::gentoo] USE="nls ppp qt4" 0 KiB Total: 129 packages (114 upgrades, 1 downgrade, 12 new, 1 in new slot, 1 reinstall), Size of downloads: 267,930 KiB Conflict: 1 block !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: sys-apps/dbus:0 (sys-apps/dbus-1.10.24:0/0::gentoo, ebuild scheduled for merge) pulled in by sys-apps/dbus[user-session] required by (kde-plasma/plasma-workspace-5.11.0:5/5::gentoo, ebuild scheduled for merge) ^^^^^^^^^^^^ (sys-apps/dbus-1.10.24:0/0::gentoo, installed) pulled in by >=sys-apps/dbus-1.6:0/0=[-user-session] required by (net-wireless/bluez-5.47-r1:0/3::gentoo, installed) ^^^^^^^^^^^^^ >=sys-apps/dbus-1.6:=[user-session=] required by (net-wireless/bluez-5.47-r1:0/3::gentoo, installed) ^^^^^^^^^^^^^
I think you'll need to build bluez with USE="user-session" too.
Same problem for me. As suggested by Michael Palimaka, build bluez with USE="user-session" worked. Maybe should be enabled by default, for bluez, since is required also by plasma-workspace. Thanks
Are you both using this profile? default/linux/amd64/13.0/desktop/plasma/systemd
Yes I am.
I think there's already plenty of bugs against portage to improve conflict resolution and output in cases like this, let's turn this into a bug to improve the plasma/systemd profile. Since plasma-workspace[systemd] depends on dbus[user-session], and bluez depends on dbus[user-session=], let's enable these flags by default in the profile.
+1
(In reply to Michael Palimaka (kensington) from comment #3) > Are you both using this profile? > default/linux/amd64/13.0/desktop/plasma/systemd I am using at impala default/linux/amd64/13.0: Available profile symlink targets: [1] default/linux/amd64/13.0 * [2] default/linux/amd64/13.0/selinux ...
(In reply to Juergen Rose from comment #7) > (In reply to Michael Palimaka (kensington) from comment #3) > > Are you both using this profile? > > default/linux/amd64/13.0/desktop/plasma/systemd > > I am using at impala default/linux/amd64/13.0: > > Available profile symlink targets: > [1] default/linux/amd64/13.0 * > [2] default/linux/amd64/13.0/selinux > ... +1 too.
Well, if you are not using the Plasma profile you are a bit more on your own with those use flags...
Based on the current profile inheritance structure, I think we have two options: 1. See if systemd team wants to enable this USE flag in the base systemd target 2. Create our own systemd target and add an extra layer of inheritance to each of the desktop/plasma/systemd profiles
Enabling this USE flag for the systemd profile sounds good to me. Any objections from the GNOME team?
I would not like to see user-session enabled globally due to bug https://bugs.gentoo.org/577416 It is still unsolved because upstream "solved" it relying on making systemd to kill services at exit... but as it broke other things, we are not enabling that by default. Then, running a computer with multiple users login in and out can become a mess of processes left running forever (and causing in some cases issues when, for example, one tries to login in again and an old instance is running too)
Ah, I see that finally gnome upstream decided to treat it as a problem instead of refusing to do anything on their side: https://bugzilla.gnome.org/show_bug.cgi?id=764029 But it seems we will need to wait for Gnome 3.26 to get it solved
Same problem for me. Wouldn't be nice to enable the fix for KDE/systemd profiles? This can be a temporary fix until Gnome fix the issue. I'm on profile `default/linux/amd64/17.0/desktop/plasma/systemd (stable)`, and I have no package from Gnome.
FTR, for systemd user-session to work, you have to disable consolekit support in pambase. Haven't investigated why but this was the reason why I would not get systemd --user working after turning USE=user-session on.
(In reply to Giorgio Premi from comment #14) > Same problem for me. > > Wouldn't be nice to enable the fix for KDE/systemd profiles? This can be a > temporary fix until Gnome fix the issue. > > I'm on profile `default/linux/amd64/17.0/desktop/plasma/systemd (stable)`, > and I have no package from Gnome. No problem to do this, just someone needs to fine the time to write a patch (I believe due to the current profile structure, a separate plasma/systemd target will need to be added to the inheritance of each of the profiles.
This was fixed for plasma/systemd profile in commit e971d9d838345833f8ed6c06147835c34e48ecbf thanks to grknight. @gnome, as soon as enabling user-session globally for systemd profile is fine please feel free to clean up profiles again.
