Bug 32517 - pipewire: wireplumber not activated on installation
Summary: pipewire: wireplumber not activated on installation
Status: REOPENED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 9
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: All Packagers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-11-13 23:49 CET by Marc Krämer
Modified: 2024-11-01 15:49 CET (History)
7 users (show)

See Also:
Source RPM: wireplumber-0.4.14-1.mga9.src.rpm
CVE:
Status comment:


Attachments

Description Marc Krämer 2023-11-13 23:49:13 CET
I am trying to get bluetooth auto profile switch to work. And I found the config files in
/usr/share/pipewire/media-session.d/

But inside the file it is stated:

# Copy and edit this file in /etc/pipewire/media-session.d/
# for system-wide changes or in
# ~/.config/pipewire/media-session.d/ for local changes.

I guess these files should be located in /etc in order to modify them. This is also what, e.g. Arch states:
https://wiki.archlinux.org/title/PipeWire

Where should the modifications need to be made? Why don't we install these files in /etc?
Comment 1 Morgan Leijström 2023-11-13 23:59:33 CET
I believe Thierry is in charge here

CC: (none) => fri, thierry.vignaud

Comment 2 Barry Jackson 2023-11-14 00:17:43 CET
I think the general idea is that the file in /usr/share/pipewire/media-session.d/ is the default.

If you want to make changes you don't touch that file but copy it to /etc/.. to make system wide changes, or copy it to ~/ for changes that will only affect the one user.

The 'user' one has highest priority, the system one next and the original in media-session.d the lowest priority as fallback.

CC: (none) => zen25000

Comment 3 Morgan Leijström 2023-11-14 12:58:52 CET
Please can you add the wisdom to https://wiki.mageia.org/en/Pipewire ?
Comment 4 Marc Krämer 2023-11-14 15:11:54 CET
sure, but for now, I think it is a packaging issue in frist place.
Comment 5 Marc Krämer 2023-11-14 15:15:48 CET
That is a strange idea...
if the config in /usr/share/pipewire is updated you don't get any .rpmnew file. The result may just, to see pipewire is not working anymore, if the config in /etc don't work together with the config in /usr/share

With the config in /usr/share you have a bunch of problems:
- you must know they exist and where
- you have to copy the files to a destination and hope you set all rigths and everything correct.
- I guess you won't get any errors in case you misspelled the file or the directory.

=> is there any tool that shows you, your setting is "in effect"?

I tried to copy the file to ~/.config/pipewire/media-session.d/ and it did not work - now I will copy them to etc but still do not know, if they are read or the setting just don't work as expected.
Comment 6 Jani Välimaa 2023-11-14 17:55:11 CET
It's not strange nor used only with pipewire. /usr/share/foo (or /usr/lib/foo) is for distro wide or initial configs, /etc/foo/ for system wide configs altered by sysadmins, and ~/.config/foo for per-user configs.

Usually configs are read in order:
1. per-user
2. system-wide
3. distro-wide
Comment 7 Marc Krämer 2023-11-14 17:56:39 CET
but at least the directories exist in /etc
Comment 8 Jens Persson 2023-11-14 18:21:57 CET
Hey Marc, sure you're not using Wireplumber? But I'll make a note in the wiki page about these directories. But usually it works like Jani said.

CC: (none) => xerxes2

Comment 9 Marc Krämer 2023-11-14 19:49:02 CET
wireplumber is not installed - and to be honest, I really don't know much about that sound stuff, ans it is getting more and more complex.

I have a "simple task": I have a bt headset, which connects to the pc as "A2DP Sink". And I have to switch it back to "HSP/HFP" everytime I reconnect.

So I'm trying to set bluez5.autoswitch-profil=true - so my guess was, it switches to hsp/hfp whenever I connect to a jitsi meeting (e.g. https://sichere-videokonferenz.de). But it I just get some logs like this:

Nov 14 18:41:32 localhost pipewire-media-session[2823]: spa.bluez5.native: RFCOMM receive command but modem not available: AT+CSRSF=0,0,0,1,0,0,0
Nov 14 18:41:32 localhost pipewire-media-session[2823]: spa.bluez5: BlueZ Battery Provider is not available, won't retry to register it. Make sure you are running BlueZ 5.56+ with experimental features to use Battery Provider.
Nov 14 18:41:32 localhost pipewire-media-session[2823]: spa.bluez5: Failed to register battery provider. Error: org.freedesktop.DBus.Error.UnknownMethod
Nov 14 18:41:32 localhost pipewire-media-session[2823]: spa.bluez5.native: RFCOMM receive command but modem not available: AT+BTRH?


So my guess was/is the setting in /etc or ~/.config... is not recognized, but I don't see how to ask the value of "bluez5.autoswitch-profil" so  I know the setting really is applied...
Comment 10 Lewis Smith 2023-11-16 21:48:16 CET
Given the function of each:
 /usr/share/pipewire/media-session.d/
 /etc/pipewire/media-session.d/
 ~/.config/pipewire/media-session.d/
is clear, Marc's original point was that if we provide the /usr/share/ version, should not the package installation also create the /etc/ version?

The pkg provides only the /usr/share/ version; nothing provides the /etc/ one.

Source RPM: pipewire-media-session => pipewire-media-session-0.4.2-1.mga9.src.rpm
CC: (none) => lewyssmith

Comment 11 Jens Persson 2023-11-16 22:19:29 CET
I think it's sort of considered good practice nowadays for packages to stay out of /etc as much as possible. That way the user will continue to get updates to the default config from upstreams. Otherwise what happens in /etc is a bit of voodoo if you ask me. That is probably why Pipewire stays out of /etc by default.
Comment 12 Jani Välimaa 2023-11-18 12:14:03 CET
(In reply to Lewis Smith from comment #10)
> Given the function of each:
>  /usr/share/pipewire/media-session.d/
>  /etc/pipewire/media-session.d/
>  ~/.config/pipewire/media-session.d/
> is clear, Marc's original point was that if we provide the /usr/share/
> version, should not the package installation also create the /etc/ version?
> 
> The pkg provides only the /usr/share/ version; nothing provides the /etc/
> one.

It's up to system administrator to copy configs to /etc and alter them. We should only provide directories for system-wide configs in /etc.
Comment 13 Lewis Smith 2023-11-18 22:01:24 CET
Comments 10 & 11 say the same thing. Point taken.
Marc has a specific Bluetooth problem in comment 9. The error messages noted there look irrelevant: modem & battery?
Assuming that "bluez5.autoswitch-profil=true" is specified in ~/.config/pipewire/media-session.d/? .
I think the forum might be the best place to ask. Would any packager know?

[I have a problem in the same area with PulseAudio, whereby my headphones are not recognised as connected, and audio output defaults to [non-existent] Speakers. I have to reset it to Headphones every boot; a pain. I am not pursuing that...]
Comment 14 Marc Krämer 2023-11-19 11:40:29 CET
@all: it is ok for me...

@Lewis: that is the reason I switched to pipewire (with pulse I was not able to mute the headset, switching to pipewire gave me more bt-profiles and mute works). Still it did not automatic switch to the HSP/HFP profile.

Since I use this headset only for calls, I can hard code the profile somewhere, but it would be awesome if it just works.
Comment 15 Jens Persson 2023-11-19 22:45:07 CET
But why are you using media-session? IIRC that was basically just a prototype session manager used for developing Pipewire.
Comment 16 Guillaume Bedot 2023-11-20 02:44:02 CET
(In reply to Marc Krämer from comment #5)
> That is a strange idea...
> if the config in /usr/share/pipewire is updated you don't get any .rpmnew
> file. The result may just, to see pipewire is not working anymore, if the
> config in /etc don't work together with the config in /usr/share

I don't like it very much either. With distrib config in /etc, we had rpmnew/rpmsave file that told us something has changed. Maybe we have to update the tools ?
 
> With the config in /usr/share you have a bunch of problems:
> - you must know they exist and where

That's yhe new way, you have yo learn ?

> - you have to copy the files to a destination and hope you set all rigths
> and everything correct.

I haven't experienced issues witht hat, if packaging is correct, a simple cp should work anyway.

> - I guess you won't get any errors in case you misspelled the file or the
> directory.

So copy/paste as much as you can

> => is there any tool that shows you, your setting is "in effect"?

Sometimes there are, look at pw-config and pw-cli (doesn't look easy to use though) for instance.

CC: (none) => geex+mageia

Comment 17 Guillaume Bedot 2023-11-20 03:00:09 CET
(In reply to Marc Krämer from comment #9)
> So I'm trying to set bluez5.autoswitch-profil=true - so my guess was, it
> switches to hsp/hfp whenever I connect to a jitsi meeting (e.g.
> https://sichere-videokonferenz.de). But it I just get some logs like this:

Try profile with an e maybe ?
Comment 18 Guillaume Bedot 2023-11-20 03:20:34 CET
I'm on cauldron again nowadays, but get rid of pipewire-media-session, it should be okay to use wireplumber with mageia 9 too.

I tried your site, and it switched to HSP/HFP and back to A2DP when i played music.
Comment 19 Guillaume Bedot 2023-11-20 04:06:40 CET
> It's up to system administrator to copy configs to /etc and alter them. We
> should only provide directories for system-wide configs in /etc.

Maybe, but at least flag the config files in /usr/share with %config macro, so changes mistakenly made here are not lost
Comment 20 Guillaume Bedot 2023-11-20 04:09:35 CET
Or mark them read-only to give a hint
Comment 21 Guillaume Bedot 2023-11-20 04:44:23 CET
> Usually configs are read in order:
> 1. per-user
> 2. system-wide
> 3. distro-wide

This need to be clarified, I understood there 4 levels:

1. upstream proposed config in /usr/share
2. distrib config in /etc
3. system-wide modifications in /etc/*.d folder
4. user preferences in ~
Comment 22 Guillaume Bedot 2023-11-20 05:44:29 CET
To end my monologue, if these files in /usr/share just describe the defauts settings, maybe they belong to /usr/share/doc|%docdir|whatever
Comment 23 Marc Krämer 2023-11-20 12:29:53 CET
@Guillaume: thanks for your advice. There is a "e" at profile (copy paste error ;) )

I'll try wireplumber - just used the first thing I found about pipewire. I've got so many things to monitor, I don't know every change in sound config, settings and new daemons... It is a pity we always need to learn new complex things, I don't wanted to know.
Comment 24 Marc Krämer 2023-11-20 13:52:37 CET
@Guillaume: thanks a lot, wireplumber does the magic, as far as I can say.

At least wireplumber creates the default dirs in /etc ! But it works without more changes.

Resolution: (none) => FIXED
Status: NEW => RESOLVED

Comment 25 Marc Krämer 2023-11-21 12:13:26 CET
adding/installing wireplumber does not enable it.
Is this an error???

I had to manually execute systemd --user enable wireplumber otherwise I had no sound.
Marc Krämer 2023-11-21 12:13:41 CET

Resolution: FIXED => (none)
Status: RESOLVED => REOPENED

Comment 26 Guillaume Bedot 2023-11-21 14:00:50 CET
@Marc:

Glad to read that fixed your issue.
There were a lot changes with the introduction of pipewire/wireplumber, it does the job as well as pulseaudio as far as i can tell and adds new features, this is the way to go.

Maybe there remains packaging issues like systemd units not activated automatically, did you restart your session and have to enable it, or just start it ?
Comment 27 Guillaume Bedot 2023-11-21 14:14:49 CET
I tried urpmi pipewire-media-session and then urpmi wireplumber and indeed the service is disabled.
Comment 28 Morgan Leijström 2023-11-21 14:49:31 CET
(In reply to Guillaume Bedot from comment #27)
> I tried urpmi pipewire-media-session and then urpmi wireplumber and indeed
> the service is disabled.

Maybe we can packaging wise leave it at that in this case of manual install if we note it in the wiki page.

When using our tool draksound, does it work to make pipewire avaialble?
Comment 29 Marc Krämer 2023-11-21 16:15:59 CET
Since there will be no sound unless the service is enabled and other services are uninstalled, I suggest enabling this service by default.
It is a good starting point if it just works after install unless you do some harm with it. Even for mulituser systems it would be good if it is enabled systemwide and not on a per user basis.
Comment 30 Guillaume Bedot 2023-11-22 06:46:19 CET
Nice to see some updates to drak* tools, but needs it really to have 5 options instead if 3 ? No (alsa), pulseaudio, pipewire should suffice.
Comment 31 Jens Persson 2023-11-22 20:36:00 CET
Pulseaudio did support to run system-wide but it was never the recommended way. A quick search gives basically the same answer for Pipewire. Pipewire should work system-wide but it's not recommended.

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1610
Comment 32 Lewis Smith 2023-11-22 22:39:52 CET
 (In reply to Marc Krämer from comment #24)
> @Guillaume: thanks a lot, wireplumber does the magic, as far as I can say.
> At least wireplumber creates the default dirs in /etc ! But it works without
> more changes.
(In reply to Marc Krämer from comment #25)
> adding/installing wireplumber does not enable it.
> Is this an error???
> I had to manually execute systemd --user enable wireplumber otherwise I had
> no sound.
(In reply to Marc Krämer from comment #29)
> Since there will be no sound unless the service is enabled and other
> services are uninstalled, I suggest enabling this service by default.
> It is a good starting point if it just works after install unless you do
> some harm with it. Even for mulituser systems it would be good if it is
> enabled systemwide and not on a per user basis.
Can we be clear which package we are talking about now?
 pipewire-media-session [I think got evicted]
 wireplumber [did the trick, except not being activated]
 pipewire ?

It is common for daemon type packages to start their services on installation, so this lack might be a definite bug to push forward.
Comment 33 Marc Krämer 2023-11-24 12:26:22 CET
true. it is about wireplumber.
Marc Krämer 2023-11-24 12:26:50 CET

Summary: pipewire: wrong config directory? => pipewire: wireplumber not activated on installation

Comment 34 Lewis Smith 2023-11-24 22:32:53 CET
Thanks.
The only link I can see between pipewire & wireplumber is:
$ urpmq --requires wireplumber | grep pipe
 libpipewire-0.3.so.0()(64bit)

Assigning globally, but CC'ing ghibo who knows this area.

Source RPM: pipewire-media-session-0.4.2-1.mga9.src.rpm => wireplumber-0.4.14-1.mga9.src.rpm
CC: lewyssmith => ghibomgx
Assignee: bugsquad => pkg-bugs

Comment 35 Dave Hodgins 2023-11-24 23:58:33 CET
pulseaudio is still the default in Mageia 9. Activating both pipewire and
pulseaudio will cause sound not to work at all.

Also, wireplumber can not be used at the same time as pipewire-media-session.
https://pipewire.pages.freedesktop.org/wireplumber/running-wireplumber-daemon.html

CC: (none) => davidwhodgins

Comment 36 Giuseppe Ghibò 2023-11-25 00:04:27 CET
Reading last comments (apart latest from Dave Hodgins) I've difficult to see what the bug is exactly about...

Mageia uses pulseaudio as default system audio. In general pulseaudio can't coexist with pipewire havingb oth enabled (if you do you might get some side effect and audio not working properly).

To switch from pulseaudio to pipewire + wireplumber, or pipewire + pipewire-media-session, the simplified way is to run "draksound" from MCC and select the right combination of pulseaudio or pipewire+wireplumber or pipewire+pipewire-media-session. There is no need to play with systemctl by as draksound would already do that for you.

As for a media session, you have to choose either one from wireplumber or pipewire-media-session.
Comment 37 Jens Persson 2023-11-27 20:45:12 CET
This bug never dies, it just tranforms, sometimes even changing name. Noticed a few days ago that if you install Gnome in Cauldron it does install Pipewire by default. It installs media-session by default though and that can't be right. Default should be Wireplumber. And when you try to remove media-session you run into the "removing 997 packages" bug/feature haha.
Comment 38 Giuseppe Ghibò 2023-11-27 20:51:01 CET
(In reply to Jens Persson from comment #37)
> This bug never dies, it just tranforms, sometimes even changing name.
> Noticed a few days ago that if you install Gnome in Cauldron it does install
> Pipewire by default. It installs media-session by default though and that
> can't be right. Default should be Wireplumber. And when you try to remove
> media-session you run into the "removing 997 packages" bug/feature haha.

What happens if you use pipewire with pipewire-media-session instead of wireplumber? It doesn't work for you?
Comment 39 Jens Persson 2023-11-27 21:03:34 CET
Didn't try media-session so have no idea if it would work. Been over 5 months now since last commit to media-session.

https://gitlab.freedesktop.org/pipewire/media-session

Also it says "Example session manager for PipeWire". I stick to Wirelumber instead as it's more actively developed.
Comment 40 Guillaume Bedot 2023-11-27 21:10:04 CET
Though the bug is now about mageia 9, i think it's a safe bet to place pipewire-media-session in task-obsolete for mageia 10 already.
Comment 41 Marc Krämer 2023-11-28 00:45:54 CET
Short version: new bluetooth headset
- started with pulseaudio. Headset "works", mute button does not work, manual switching to a profile for mic+audio
- switched to pipewire+media session: mute works, still need to switch the audio profile manually
- switched to wireplumber everthing works as expected.

Except, wireplumber is not enabled by default. So every user must open a terminal and use "systemctl --user enable wireplumber" otherwise no audio is active. And I guess this is a bug.
Comment 42 Giuseppe Ghibò 2023-11-28 00:53:57 CET
(In reply to Marc Krämer from comment #41)
> Short version: new bluetooth headset
> - started with pulseaudio. Headset "works", mute button does not work,
> manual switching to a profile for mic+audio
> - switched to pipewire+media session: mute works, still need to switch the
> audio profile manually
> - switched to wireplumber everthing works as expected.
> 
> Except, wireplumber is not enabled by default. So every user must open a
> terminal and use "systemctl --user enable wireplumber" otherwise no audio is
> active. And I guess this is a bug.

Actually it's not possible to switch from one audio system to another just by batch commands simply installing and uninstalling packages (including task-pulseaudio or task-pipewire).

You can achieve the same for every user, and not just for the user who run "systemctl --user enable wireplumber", running draksound (from MCC) and choosing the corresponding audio system in a set between:

[ ] pulseaudio
[ ] pulseaudio + glitchfree
[X] pipewire with wireplumber
[ ] pipewire with pipewire-media-session

Doesn't work that in your config?
Comment 43 Jens Persson 2023-11-28 20:20:26 CET
It's not really recommended to run Pipewire system-wide except for ie in cars, airplanes, trains and such embedded use cases. In a desktop computer it's recommended to run Pipewire at user-level instead.
Comment 44 Giuseppe Ghibò 2023-11-28 20:26:04 CET
It doesn't run pipewire system-wide, but rather it's already on user-level (like pulseaudio), but for any user.
Comment 45 Marc Krämer 2023-11-28 21:43:52 CET
The request is not, to start audio upon uninstall of one audio and install of another, but after a clean reboot and a relogin into the desktop environment it should automatically setup the new audio output.

You can tell every user to just do that - but please ask yourself how you tell your parents each of them has to open a terminal and write some cryptic commands in that.

We run scripts on login of the desktop. Is it really so hard to start the sound system at that stage? As far as I can tell pulseaudio, pipewire+wireplumber, pipewire+media are mutally exclusive and can't be installed at the same time.
And I am pretty sure, pulseaudio just worked on install without user interaction.
Comment 46 Jens Persson 2023-11-30 18:10:43 CET
I don't think anyones parents will ever install Pipewire. When you install a desktop edition of Mageia it should of course be enabled by default. I can see tow options to do it. When you create a user during install it would be easy to do it. Or when your user log in for the first time. If you create a new user after install (ie with useradd) or change audio subsystem you probably know how to read a wiki page, like Marc did. Found this test that Fedora was using when they switched to Pipewire. Seems like they are running Pipewire at user-level.

https://fedoraproject.org/wiki/QA:Testcase_PipeWire_PipeWire_default
Comment 47 Marc Krämer 2023-11-30 19:51:42 CET
Ok, if you need a real world example:
login to a remote machine of your employee via ssh, install task-pipewire and wireplumber because they complain about the handling of bluetooth and sound.
Next you need to explain them they should open a terminal and type some wired commands, just because you can't do it for them...
And  all of them are at least 200km away - so it is not an option to just do it on their computer.


So, this is a real example, I am having right now. And most of them just use linux but are only using it graphically and without root rights.

If we switch to pipewire and wireplumber in future, all users hitting the update button will have a computer without sound.


If I am not mistaken, the solution should just call
systemctl --global enable wireplumber pipewire pipewire-pulse

on install of wireplumber since it is mutal exclusive to pulseaudio this should not do any harm....
Comment 48 Jens Persson 2023-11-30 20:07:35 CET
I would not run Pipewire system-wide myself so not commenting on that. But upgrades will be a problem yes. If you want to run Pipewire at user-level I can see two solutions. 1. Users will have to copy and paste commands (as Marc said). 2. Admin could make the needed links manually, even using ssh. A bit ugly yes but it should work.
Comment 49 Dave Hodgins 2023-11-30 20:39:55 CET
In Mageia 10, add a script in /etc/profile.d/ that makes the switch for each
user during the first login either after install, or after an upgrade from m9.
Comment 50 Jens Persson 2023-11-30 20:44:04 CET
Hey Marc, was a long time ago since I was using SSH but can you not just use "su"? Root can do anything right, even switch to any user.
Comment 51 Jens Persson 2023-11-30 21:13:22 CET
What Dave said could work.

if [ ! -h ~/.config/systemd/user/pipewire.service.wants/wireplumber.service ]; then
  echo "enable pipewire and wireplumber"
fi
Comment 52 Dave Hodgins 2023-11-30 21:45:34 CET
I would use two scripts. The first tests for a file (or directory)
somewhere such as under ~/.config. If it doesn't exist, it creates that
file (or directory) and runs the second script that sets
pipewire/wireplumber as enabled.

That way, it only sets it once for each user, not every time they login,
allowing them to override the settings, provided they know how to. It
would also allow them to manually run the second script to change back,
if desired.
Comment 53 Giuseppe Ghibò 2023-11-30 21:58:04 CET
(In reply to Marc Krämer from comment #47)


> So, this is a real example, I am having right now. And most of them just use
> linux but are only using it graphically and without root rights.
> 
> If we switch to pipewire and wireplumber in future, all users hitting the
> update button will have a computer without sound.
> 
> If I am not mistaken, the solution should just call
> systemctl --global enable wireplumber pipewire pipewire-pulse
> 
> on install of wireplumber since it is mutal exclusive to pulseaudio this
> should not do any harm....

Or just run log remotely ssh, become root, run draksound (OK, is an X11 application so slhow on ssh, switch to pipewire+wireplumger (it will install the required packages), logout, and your administered user would have pipewire sound.
Comment 54 Dave Hodgins 2023-11-30 22:35:43 CET
Thinking about it more, I'd extend that to make it a general package that
can set things on first login after a given package has been installed.

In /etc/profile.d, have a script, mgafirstlogin, that for every script in
/etc/mgafirstlogin, checks to see if ~/.config/mgafirstlogin/$filename
exists. If it doesn't, runs the script and creates the ~/.config file

Then packages such as wireplumber simply add a script to /etc/mgafirstlogin

The benefit of this approach over systemd user level presets, is that it
only takes effect once after the package is installed, not every time the
user logs in, allowing the user to make changes that don't get lost every
logout/in. It would automatically handle release upgrades, which can not
touch /home files, as /home may or may not be mounted during upgrade.
Comment 55 Dave Hodgins 2023-11-30 22:41:13 CET
(In reply to Giuseppe Ghibò from comment #53)
> (In reply to Marc Krämer from comment #47)
> Or just run log remotely ssh, become root, run draksound (OK, is an X11
> application so slhow on ssh, switch to pipewire+wireplumger (it will install
> the required packages), logout, and your administered user would have
> pipewire sound.

Keep in mind that root can not access /home/someuser if someuser has an
encrypted home directory that root doesn't know the passphrase for, and
someuser is not currently logged in.
Comment 56 Jens Persson 2023-11-30 22:59:24 CET
What Dave says should already exist! If not it could be called something like /etc/runonce.d that every distro could use. You could even add sha1sum check to it and run the script again if it changes. It's a badass idea.
Comment 57 Morgan Leijström 2023-11-30 23:56:09 CET
(In reply to Giuseppe Ghibò from comment #53)
> ssh, become root, run draksound (OK, is an X11
> application so slhow on ssh,

Does it not run text mode then?

i.e i can ctrl-alt-F4 to a tty, log in as root and issue draksound OK
Comment 58 Marc Krämer 2023-12-01 00:03:44 CET
@Dave: mgafirstlogin could be an option, but what is the problem on activating it globally? It is not run as root or a central service, it is just started for every user:

systemctl
--global
           When used with enable and disable, operate on the global user
           configuration directory, thus enabling or disabling a unit file
           globally for all future logins of all users.
Comment 59 Dave Hodgins 2023-12-01 00:05:21 CET
(In reply to Jens Persson from comment #56)
> What Dave says should already exist! If not it could be called something
> like /etc/runonce.d that every distro could use. You could even add sha1sum
> check to it and run the script again if it changes. It's a badass idea.

SHA-1 was deprecated in 2010, and should not be encouraged.
https://en.wikipedia.org/wiki/Secure_Hash_Algorithms

The commands to support sha1 are still provided as it may be the only check
available for older files.

If a checksum is used, it should use one of the sha3 checksums, such
as sha3-512sum.
Comment 60 Giuseppe Ghibò 2023-12-01 00:11:08 CET
(In reply to Morgan Leijström from comment #57)
> (In reply to Giuseppe Ghibò from comment #53)
> > ssh, become root, run draksound (OK, is an X11
> > application so slhow on ssh,
> 
> Does it not run text mode then?
> 
> i.e i can ctrl-alt-F4 to a tty, log in as root and issue draksound OK

Ah, yes, I forgot it should work also in TTY mode, unset DISPLAY; draksound, works  in cli too.
Comment 61 Dave Hodgins 2023-12-01 00:14:12 CET
(In reply to Marc Krämer from comment #58)
> @Dave: mgafirstlogin could be an option, but what is the problem on
> activating it globally? It is not run as root or a central service, it is
> just started for every user:
> 
> systemctl
> --global
>            When used with enable and disable, operate on the global user
>            configuration directory, thus enabling or disabling a unit file
>            globally for all future logins of all users.

That may work in this case, though it needs to be tested to ensure user
changes do not get overridden on logout/login, such as if the user wants
to disable it so they can use jackit or pulse instead of pipewire.

The problem we had before was that pipewire used a file in
/usr/lib/systemd/user-preset/, which does override user changes on
logout/in.
Comment 62 Giuseppe Ghibò 2023-12-01 00:18:27 CET
(In reply to Giuseppe Ghibò from comment #60)
> (In reply to Morgan Leijström from comment #57)
> > (In reply to Giuseppe Ghibò from comment #53)
> > > ssh, become root, run draksound (OK, is an X11
> > > application so slhow on ssh,
> > 
> > Does it not run text mode then?
> > 
> > i.e i can ctrl-alt-F4 to a tty, log in as root and issue draksound OK
> 
> Ah, yes, I forgot it should work also in TTY mode, unset DISPLAY; draksound,
> works  in cli too.

Or use xpra over ssh (which works also taking remote audio).
Comment 63 Marc Krämer 2023-12-01 00:34:27 CET
> That may work in this case, though it needs to be tested to ensure user
> changes do not get overridden on logout/login, such as if the user wants
> to disable it so they can use jackit or pulse instead of pipewire.


I see.... no, users can't disable it. If enabled globally, it is run on login. Only if the service itself checks user config files as Condtion
Comment 64 Marc Krämer 2023-12-01 00:38:08 CET
But maybe we make too many thoughty about things people might do. Is it very likely a PC is shared and differen users use different sound systems?
The most common case is one pc per user. Sometimes a few more people share it. But terminal servers are not very common today.
Comment 65 Dave Hodgins 2023-12-01 00:43:13 CET
While it's fine for a distribution to set user defaults to the most commonly
used options, it should not do so in a way that stops it from working for
less commonly used options, when it is not necessary to do so.

Take away administrator and/or user choices, and they'll look for a distribution
that doesn't do that.
Comment 66 Morgan Leijström 2023-12-01 00:51:02 CET
(In reply to Marc Krämer from comment #64)
> Is it very 
> likely a PC is shared and differen users use different sound systems?

Very unlikely.
When people share same computer it is usually so that one of them (or an "external" person) do the admin work or at least decides stuff like this (possibly after discussion)
Comment 67 Dave Hodgins 2023-12-01 01:20:57 CET
Sorry, was thinking about bug 31235 that caused problems during the iso
development.

In Mageia 10, pulseaudio should be dropped.

During upgrades from Mageia 9 to 10, will changes in /home be required?
If so, that can not be done during the upgrade itself, as /home/$USER may
not be accessible during the upgrade (encrypted or network mounted /home/$USER
directory). That should be handled in a first login after upgrade.
Comment 68 Jens Persson 2023-12-01 19:33:09 CET
I got a bit inspired with Daves idea about creating a service that runs scripts only once so I wrote a little a script that does what I think is what he suggested. Tested with both bash and dash so seems pretty safe to use. It's one solution at least.

https://gitlab.com/xerxes2/mageia/-/blob/main/script/runonce.sh
Comment 69 Jens Persson 2023-12-01 19:36:55 CET
(In reply to Marc Krämer from comment #58)
> @Dave: mgafirstlogin could be an option, but what is the problem on
> activating it globally? It is not run as root or a central service, it is
> just started for every user:
> 
> systemctl
> --global
>            When used with enable and disable, operate on the global user
>            configuration directory, thus enabling or disabling a unit file
>            globally for all future logins of all users.

Never heard of this systemctl command before but it seems like something you could also use for Pipewire yes. Does it run the service the same way as --user does? Does it pass Fedora's test?
Comment 70 Dave Hodgins 2023-12-01 22:06:15 CET
(In reply to Jens Persson from comment #68)
> I got a bit inspired with Daves idea about creating a service that runs
> scripts only once so I wrote a little a script that does what I think is
> what he suggested. Tested with both bash and dash so seems pretty safe to
> use. It's one solution at least.
> 
> https://gitlab.com/xerxes2/mageia/-/blob/main/script/runonce.sh

It should be more similar to /etc/profile, and use ". /scriptname" so that
it all runs in one bash shell, instead of starting a new shell for each
script.
Comment 71 Dave Hodgins 2023-12-02 04:51:46 CET
(In reply to Jens Persson from comment #69)
> (In reply to Marc Krämer from comment #58)
> > @Dave: mgafirstlogin could be an option, but what is the problem on
> > activating it globally? It is not run as root or a central service, it is
> > just started for every user:
> > 
> > systemctl
> > --global
> >            When used with enable and disable, operate on the global user
> >            configuration directory, thus enabling or disabling a unit file
> >            globally for all future logins of all users.
> 
> Never heard of this systemctl command before but it seems like something you
> could also use for Pipewire yes. Does it run the service the same way as
> --user does? Does it pass Fedora's test?

It's run by root. Unlike using --user, user made changes are lost on logout/in
as it takes effect every login.
Comment 72 Jens Persson 2023-12-02 23:14:28 CET
(In reply to Dave Hodgins from comment #70)
> (In reply to Jens Persson from comment #68)
> > I got a bit inspired with Daves idea about creating a service that runs
> > scripts only once so I wrote a little a script that does what I think is
> > what he suggested. Tested with both bash and dash so seems pretty safe to
> > use. It's one solution at least.
> > 
> > https://gitlab.com/xerxes2/mageia/-/blob/main/script/runonce.sh
> 
> It should be more similar to /etc/profile, and use ". /scriptname" so that
> it all runs in one bash shell, instead of starting a new shell for each
> script.

Why? Would it not be better to use a new shell as these scripts are not meant for sourcing anyway as they only run once. But it must've been over a decade or so since I last wrote a shell script. I was a bit unsure about HOME and PATH were available on login but I found out that HOME is set first and PATH is hardcoded into Bash so those two should always be available. Found shellcheck.net and improved the script a bit and added unsets at the end.

So I tested it now. I first disabled pipewire, pipewire-pulse and wireplumber and checked that audio was not working. Then I rebooted and still no audio. Then I put runonce.sh in /etc/profile.d and three scripts with one line each in /etc/runonce.d that enable the three needed audio services and rebooted. After reboot audio was working perfectly and it also passed Fedora's Pipewire test case. So Dave's idea works for enabling the services as user. It doesn't solve the problem with installing them though.
Comment 73 Giuseppe Ghibò 2023-12-11 14:20:23 CET
(In reply to Dave Hodgins from comment #67)

> Sorry, was thinking about bug 31235 that caused problems during the iso
> development.
> 
> In Mageia 10, pulseaudio should be dropped.
> 

AFAIK there is no need to drop pulseaudio as package itself. FC still has it, though not enabled. Furthermore IIRC pipewire's pulseaudio compatibility level API was at 15.x, while true pulseaudio API is at 16.1.

IMHO a good solution would be to ask upstream's pulseaudio to add a little piece of C code to definitively not start pulseaudio at any condition if exists for instance the file /etc/pulse/disabled (and if it also contains for instance disabled=true). In this way whatever config there is, pulseaudio won't be started, either from systemd or from xdg or from whatever other hidden scripts might trigger it. Under these conditions, then pipewire could be made the default, without worrying about package conflicting as well as daemon conflicting with pulseaudio, because even if it would try to start, it won't be successful.
Comment 74 Marc Krämer 2023-12-11 21:00:25 CET
(In reply to Dave Hodgins from comment #71)
> (In reply to Jens Persson from comment #69)
> > (In reply to Marc Krämer from comment #58)
> > > @Dave: mgafirstlogin could be an option, but what is the problem on
> > > activating it globally? It is not run as root or a central service, it is
> > > just started for every user:
> > > 
> > > systemctl
> > > --global
> > >            When used with enable and disable, operate on the global user
> > >            configuration directory, thus enabling or disabling a unit file
> > >            globally for all future logins of all users.
> > 
> > Never heard of this systemctl command before but it seems like something you
> > could also use for Pipewire yes. Does it run the service the same way as
> > --user does? Does it pass Fedora's test?
> 
> It's run by root. Unlike using --user, user made changes are lost on
> logout/in
> as it takes effect every login.

no. not true:
- you can use systemctl --enable --user which creates symlinks in ~/.config/systemd/user/ for the logged in user and this is executed on every login.

- --global option sets symlinks in /etc/systemd/user/ and is executed as user:

ps aux|grep wirepl
kraemer   108518  0.2  0.3 588632 29480 ?        Ssl  Dez04  22:21 /usr/bin/wireplumber
support   203518  0.0  0.3 577896 25992 ?        Ssl  15:38   0:03 /usr/bin/wireplumber

l /etc/systemd/user/pipewire.service.wants/
wireplumber.service@
Comment 75 Jens Persson 2023-12-12 00:44:00 CET
(In reply to Giuseppe Ghibò from comment #73)
> (In reply to Dave Hodgins from comment #67)
> 
> > Sorry, was thinking about bug 31235 that caused problems during the iso
> > development.
> > 
> > In Mageia 10, pulseaudio should be dropped.
> > 
> 
> AFAIK there is no need to drop pulseaudio as package itself. FC still has
> it, though not enabled. Furthermore IIRC pipewire's pulseaudio compatibility
> level API was at 15.x, while true pulseaudio API is at 16.1.
> 
> IMHO a good solution would be to ask upstream's pulseaudio to add a little
> piece of C code to definitively not start pulseaudio at any condition if
> exists for instance the file /etc/pulse/disabled (and if it also contains
> for instance disabled=true). In this way whatever config there is,
> pulseaudio won't be started, either from systemd or from xdg or from
> whatever other hidden scripts might trigger it. Under these conditions, then
> pipewire could be made the default, without worrying about package
> conflicting as well as daemon conflicting with pulseaudio, because even if
> it would try to start, it won't be successful.

I don't think that is necessary really. Is it not just to make pipewire-daemon conflicting with pulseaudio-daemon? It looks like it does already.

https://svnweb.mageia.org/packages/updates/9/pipewire/current/SPECS/pipewire.spec?view=markup&pathrev=2017179#l317
Comment 76 Jens Persson 2023-12-12 01:00:37 CET
(In reply to Jens Persson from comment #75)
> (In reply to Giuseppe Ghibò from comment #73)
> > (In reply to Dave Hodgins from comment #67)
> > 
> > > Sorry, was thinking about bug 31235 that caused problems during the iso
> > > development.
> > > 
> > > In Mageia 10, pulseaudio should be dropped.
> > > 
> > 
> > AFAIK there is no need to drop pulseaudio as package itself. FC still has
> > it, though not enabled. Furthermore IIRC pipewire's pulseaudio compatibility
> > level API was at 15.x, while true pulseaudio API is at 16.1.
> > 
> > IMHO a good solution would be to ask upstream's pulseaudio to add a little
> > piece of C code to definitively not start pulseaudio at any condition if
> > exists for instance the file /etc/pulse/disabled (and if it also contains
> > for instance disabled=true). In this way whatever config there is,
> > pulseaudio won't be started, either from systemd or from xdg or from
> > whatever other hidden scripts might trigger it. Under these conditions, then
> > pipewire could be made the default, without worrying about package
> > conflicting as well as daemon conflicting with pulseaudio, because even if
> > it would try to start, it won't be successful.
> 
> I don't think that is necessary really. Is it not just to make
> pipewire-daemon conflicting with pulseaudio-daemon? It looks like it does
> already.
> 
> https://svnweb.mageia.org/packages/updates/9/pipewire/current/SPECS/pipewire.
> spec?view=markup&pathrev=2017179#l317

Looking at this more closely it's pipewire-pulseaudio that conflicts with pulseaudio-daemon. But still there is a conflict that would stop running pulseaudio in two ways.
Comment 77 Jens Persson 2023-12-12 18:11:46 CET
(In reply to Marc Krämer from comment #74)
> (In reply to Dave Hodgins from comment #71)
> > (In reply to Jens Persson from comment #69)
> > > (In reply to Marc Krämer from comment #58)
> > > > @Dave: mgafirstlogin could be an option, but what is the problem on
> > > > activating it globally? It is not run as root or a central service, it is
> > > > just started for every user:
> > > > 
> > > > systemctl
> > > > --global
> > > >            When used with enable and disable, operate on the global user
> > > >            configuration directory, thus enabling or disabling a unit file
> > > >            globally for all future logins of all users.
> > > 
> > > Never heard of this systemctl command before but it seems like something you
> > > could also use for Pipewire yes. Does it run the service the same way as
> > > --user does? Does it pass Fedora's test?
> > 
> > It's run by root. Unlike using --user, user made changes are lost on
> > logout/in
> > as it takes effect every login.
> 
> no. not true:
> - you can use systemctl --enable --user which creates symlinks in
> ~/.config/systemd/user/ for the logged in user and this is executed on every
> login.
> 
> - --global option sets symlinks in /etc/systemd/user/ and is executed as
> user:
> 
> ps aux|grep wirepl
> kraemer   108518  0.2  0.3 588632 29480 ?        Ssl  Dez04  22:21
> /usr/bin/wireplumber
> support   203518  0.0  0.3 577896 25992 ?        Ssl  15:38   0:03
> /usr/bin/wireplumber
> 
> l /etc/systemd/user/pipewire.service.wants/
> wireplumber.service@

Right you are Krämer. Tested this now and it bloody works and it passed Fedora's test case too. That is some crazy features Systemd got haha. So the --global switch does also run services as user.
Comment 78 Jens Persson 2023-12-12 18:38:56 CET
Anyone knows how a package chooses a virtual requires?

https://svnweb.mageia.org/packages/cauldron/pipewire/current/SPECS/pipewire.spec?revision=2011517&view=markup#l112

Pipewire has a virtual requires pipewire-session-manager. This must be either set to wireplumber or just comment out. Now it seems to just install media-session every time which is really annoying.
Comment 79 Gerald Snyder 2024-10-31 08:22:15 CET Comment hidden (spam)

CC: (none) => kennethjoyce549

Dave Hodgins 2024-11-01 15:49:49 CET

CC: kennethjoyce549 => (none)


Note You need to log in before you can comment on or make changes to this bug.