Hi, in both versions 0.3.22 and 0.3.24 the package is merged without installing systemd units, even if the systemd use flag is enabled! I tryed with a custom 0.3.24 ebuild in my local overlay in which I modified the src_configure() function as in the following: src_configure() { local emesonargs=( -Dexamples=enabled # contains required pipewire-media-session -Dman=enabled -Dspa-plugins=enabled --buildtype=$(usex debug debugoptimized plain) # alsa plugin and jack emulation -Dpipewire-alsa=enabled $(meson_feature jack pipewire-jack) # spa-plugins # we install alsa support unconditionally $(meson_feature bluetooth bluez5) $(meson_feature ffmpeg) $(meson_feature jack) $(meson_feature vulkan) # libcamera is not packaged # misc $(meson_feature doc docs) $(meson_feature gstreamer) $(meson_feature gstreamer gstreamer-device-provider) $(meson_feature sdl sdl2) $(meson_feature sndfile) $(meson_feature systemd) $(meson_feature systemd systemd-system-service) $(meson_feature systemd systemd-user-service) $(meson_feature test test) $(meson_feature test tests) ) meson_src_configure } This makes emerge able to install pipewire systemd units in my system, but when I tryed to start the pipewire.service unit I got a dependecy error: >> apr 06 09:35:23 howl systemd[1]: Dependency failed for Multimedia Service. >> apr 06 09:35:23 howl systemd[1]: pipewire.service: Job pipewire.service/start failed with result 'dependency'. This error is caused by the pipewire-media-session.service unit which gives the same dependency error: >> apr 11 02:01:27 howl systemd[1]: Dependency failed for Multimedia Service Session Manager. >> apr 11 02:01:27 howl systemd[1]: pipewire-media-session.service: Job pipewire-media-session.service/start failed with result 'dependency'. Then, I tryed starting both pipewire-media-session and pipewire manually and I got the results as in the following (bot using my normal user and using the root user): > pipewire-media-session & >> [W][000002339.327946][module-rtkit.c:185 translate_error()] RTKit error: org.freedesktop.DBus.Error.AccessDenied >> [W][000002339.327997][module-rtkit.c:519 set_nice()] could not set nice-level to -11: Permission denied >> [W][000002339.340638][module-rtkit.c:185 translate_error()] RTKit error: org.freedesktop.DBus.Error.AccessDenied >> [W][000002339.340782][module-rtkit.c:506 idle_func()] could not make thread realtime: Permission denied >> [W][000002339.440887][backend-ofono.c:534 backend_ofono_register()] oFono: Registering Profile /Profile/ofono failed >> [W][000002339.441136][backend-hsphfpd.c:1235 backend_hsphfpd_register()] hsphfpd: Registering application /Profile/hsphfpd/manager failed > pipewire & >> [W][000002344.539142][module-rtkit.c:185 translate_error()] RTKit error: org.freedesktop.DBus.Error.AccessDenied >> [W][000002344.539192][module-rtkit.c:519 set_nice()] could not set nice-level to -11: Permission denied >> [E][000002344.539366][module-protocol-native.c:578 lock_socket()] server 0x55e337bf5c70: unable to lock lockfile '/run/user/1000/pipewire-0.lock': Resource temporarily unavailable (maybe another daemon is running) >> [E][000002344.539408][conf.c:309 load_module()] config 0x55e337bdb4f0: could not load mandatory module "libpipewire-module-protocol-native": Resource temporarily unavailable >> [E][000002344.539427][conf.c:383 create_object()] can't find factory spa-node-factory >> [W][000002344.549999][module-rtkit.c:185 translate_error()] RTKit error: org.freedesktop.DBus.Error.AccessDenied >> [W][000002344.550038][module-rtkit.c:506 idle_func()] could not make thread realtime: Permission denied Regards, Iade Gesso, MSc PhD
The current ebuild is correctly installing the **USER** units - please use them: systemctl --user disable pulseaudio.service pulseaudio.socket systemctl --user enable pipewire.socket pipewire-pulse.socket and, if using, v0.3.24, then also this: systemctl --user enable pipewire-media-session.service and, no, it's not a mistake, the first two are .sockets and the third one is .service that will start together with the pipewire.service, which in turn is started by the socket. In principle I am not against giving people the choice of installing a system wide daemon but: 1) Upstream disables it by default 2) I'm not aware of any documentation for why or how the system service units would be used, and therefore I do not know how to integrate it into Gentoo or test that it's working. Due to lack of documentation, I don't even know why should I care about doing any of that, since it has no known uses. 3) Apart from fast user switching (which was quite flaky when I last tested; apparently a known underdeveloped use case), the existing user units work very well. 4) Enabling installation of the system units by default will only confuse people even more, because only the user units are needed.
(In reply to Niklāvs Koļesņikovs from comment #1) > The current ebuild is correctly installing the **USER** units - please use > them: > systemctl --user disable pulseaudio.service pulseaudio.socket > systemctl --user enable pipewire.socket pipewire-pulse.socket > and, if using, v0.3.24, then also this: > systemctl --user enable pipewire-media-session.service > and, no, it's not a mistake, the first two are .sockets and the third one is > .service that will start together with the pipewire.service, which in turn > is started by the socket. > > In principle I am not against giving people the choice of installing a > system wide daemon but: > 1) Upstream disables it by default > 2) I'm not aware of any documentation for why or how the system service > units would be used, and therefore I do not know how to integrate it into > Gentoo or test that it's working. Due to lack of documentation, I don't even > know why should I care about doing any of that, since it has no known uses. > 3) Apart from fast user switching (which was quite flaky when I last tested; > apparently a known underdeveloped use case), the existing user units work > very well. > 4) Enabling installation of the system units by default will only confuse > people even more, because only the user units are needed. Yesterday night I tried downgrading from 0.3.24 (unstable) to 0.3.22 (stable), but user systemd units wasn't installed in my system... I did everything to try finding a solution before firing a bug... Iade
User units are controlled via "systemctl --user" and will not show up when using regular systemctl. Are you sure you were building media-video/pipewire with the systemd USE flag enabled, but the user units were not being installed? If so, please check for INSTALL_MASK as well as please verify that they are still not being installed - if this is repeatable, you'll likely need to manually run "ebuild </path/to/the.ebuild> configure" to examine decisions it makes when configuring the source code for compilation. If that shows nothing out of the ordinary, running the install stage will show whether the units are being installed to the image directory (not the system).
(In reply to Niklāvs Koļesņikovs from comment #3) > User units are controlled via "systemctl --user" and will not show up when > using regular systemctl. > > Are you sure you were building media-video/pipewire with the systemd USE > flag enabled, but the user units were not being installed? If so, please > check for INSTALL_MASK as well as please verify that they are still not > being installed - if this is repeatable, you'll likely need to manually run > "ebuild </path/to/the.ebuild> configure" to examine decisions it makes when > configuring the source code for compilation. If that shows nothing out of > the ordinary, running the install stage will show whether the units are > being installed to the image directory (not the system). I re-emerged the unstable 0.3.24 now and, now, user units are installed; moreover, after rebooting, it seems to run... Iade
I think this was fixed?
