I believe Thierry is in charge here

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

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

Please can you add the wisdom to https://wiki.mageia.org/en/Pipewire ?

sure, but for now, I think it is a packaging issue in frist place.

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.

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

but at least the directories exist in /etc

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

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...

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

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.

(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.

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...]

@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.

But why are you using media-session? IIRC that was basically just a prototype session manager used for developing Pipewire.

(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

(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 ?

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.

> 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

Or mark them read-only to give a hint

> 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 ~

To end my monologue, if these files in /usr/share just describe the defauts settings, maybe they belong to /usr/share/doc|%docdir|whatever

@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.

@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

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:

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 ?

I tried urpmi pipewire-media-session and then urpmi wireplumber and indeed the service is disabled.

(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?

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.

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.

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

 (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.

true. it is about wireplumber.

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.

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

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

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.

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.

(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?

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.

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.

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.

(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?

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.

It doesn't run pipewire system-wide, but rather it's already on user-level (like pulseaudio), but for any user.

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.

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

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....

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.

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.

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.

What Dave said could work.

if [ ! -h ~/.config/systemd/user/pipewire.service.wants/wireplumber.service ]; then
  echo "enable pipewire and wireplumber"
fi

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.

(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.

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.

(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.

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.

(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

@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.

(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.

(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.

(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.

(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).

> 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

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.

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.

(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)

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.

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

(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?

(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.

(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.

(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.

(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.

(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@

(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

(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.

(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.

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.