This bug need description/advisory proposal, package list, srpm field filled in.

CC: (none) => ghibomgx

Created attachment 14733 [details]
files list

files list as derived from rpmsforqa

This bug address newer wireplumber that was missed in previous pipewire update. After the previous update (pipewire-0.3.85-6) sometimes it could happen that some bluetooth audio device is not correctly connected. This version update should fix the problem monf other fixes. The pipewire-media-session, which is the other (older) companion media session manager has also been rebuilt against the latest pipewire (0.3.85-6 aka 1.0.9) and includes an upstream patch to fix potential DBusMessage memory leak.

For testing, just switch to pipewire + wireplumber or pipewire + pipewire-media-session and run audio as usual.

A way to test (if you already know you might skip this) bluetooth (there are many other ways), e.g. in plasma: just add a bluetooth audio device (e.g. a BT loudspeaker, a bt microphone or headphone, etc.) in your room and turn it on. Then start bluetooth:

systemctl start bluetooth.service

if it's not started. This would add the bluetooth icon in the plasma systray. Click on it and click on "Enable Bluetooth", to enable in plasma, then click on "+" to select a BT device to be "paired". Select the right device and wait it's paired. Once it's paired it should be listed in the bluetooth systray in the list of paired devices. Select it and click on "Connect". Once connected, clicking on the "volume" icon on systray it should be listed in the audio devices where audio output (headphones) or audio input (microphones) could be routed to. Then just play as usual.

RH x86_64

rpm -q pipewire-media-session
pipewire-media-session-0.4.2-1.1.mga9

Use draksound to switch yo pipepwire
Close session
Start Plasma X11 session
Sound Works

RH x86_64

rpm -qa|grep wireplumber
wireplumber-0.5.6-1.mga9
lib64wireplumber0-0.5.6-1.mga9

Use draksound to switch to pipewire with wireplumber
Close session
Start Plasma X11 session
Sound Works

I can't test the bluetooth part

mga9, x64

Have never used pipewire and was unsure of the requirements but found pipewire-media-session-0.4.2-1.mga9 installed.  Installed wireplumber and used draksound to switch then rebooted to Mate.  Sound working on wired connection.  Pulled the wire and connected portable audio speaker to bluetooth.  Sound working OK.

draksound to switch back to pipewire-media-session and rebooted.
Updated the packages listed via qarepo and drakrpm-update and all was confusion which suggested that wireplumber and pipewire-media-session were incompatible.  And to add insult to injury draksound now crashes at launch.  Beyond my ken for sure.  Giving up on this.  I may have to do a reinstall of the whole system.

CC: (none) => tarazed25

(In reply to Len Lawrence from comment #7)
> mga9, x64
> 
> Have never used pipewire and was unsure of the requirements but found
> pipewire-media-session-0.4.2-1.mga9 installed.  Installed wireplumber and
> used draksound to switch then rebooted to Mate.  Sound working on wired
> connection.  Pulled the wire and connected portable audio speaker to
> bluetooth.  Sound working OK.
> 
> draksound to switch back to pipewire-media-session and rebooted.
> Updated the packages listed via qarepo and drakrpm-update and all was
> confusion which suggested that wireplumber and pipewire-media-session were
> incompatible.  And to add insult to injury draksound now crashes at launch. 
> Beyond my ken for sure.  Giving up on this.  I may have to do a reinstall of
> the whole system.

Try just uninstall wireplumber

Also you can try this script https://bugs.mageia.org/attachment.cgi?id=13717

(In reply to katnatek from comment #8)

Thanks.  Had installed that on another machine but not this one.
The bigger problem is draksound.  Hopefully, running the utility will mend it.
Later.

Just a few note. draksound shouldn't be doing anything special different than the script.

pipewire-media-session and wireplumber are mutually exclusive each other in their respective chains of dependency, with pipewire-media-session choosed as default in meta-task. pipewire-session-manager is the common dependency of both.

If you provide an isolated environment of urpmi media sources to exclude meta-task it might generate unpredictable results.

Switched back to pulseaudio using pa-switcher.
$ rpm -qa | grep pipewire
lib64kpipewire5-5.27.10-1.mga9
lib64kpipewiredmabuf5-5.27.10-1.mga9
lib64kpipewirerecord5-5.27.10-1.mga9
kpipewire-5.27.10-1.mga9
pipewire-0.3.85-6.mga9
lib64pipewire0.3_0-0.3.85-6.mga9
pipewire-module-x11-0.3.85-6.mga9
gstreamer1.0-pipewire-0.3.85-6.mga9
pipewire-utils-0.3.85-6.mga9
lib64pipewire-devel-0.3.85-6.mga9

draksound runs OK.
Chose pipewire media-session.  task-pipewire and pipewire-media-session needed to be installed.  Reboot.

The most important here is that the installer and the GUI method, that users use, works.

draksound is now the recommended method
https://ml.mageia.org/l/arc/qa-discuss/2024-10/msg00065.html

mga9, x64, Mate

Sound working over bluetooth in pipewire media-session.

Installed the updates.
After reboot sound with bluetooth was working.
Used draksound to switch to a wireplumber session.

$ rpm -qa | grep wireplumber
lib64wireplumber0-0.5.6-1.mga9
lib64wireplumber-gir0.5-0.5.6-1.mga9
wireplumber-0.5.6-1.mga9

After reboot bluetooth sound was still working.

(In reply to Giuseppe Ghibò from comment #10)
> Just a few note. draksound shouldn't be doing anything special different
> than the script.
> 
> pipewire-media-session and wireplumber are mutually exclusive each other in
> their respective chains of dependency, with pipewire-media-session choosed
> as default in meta-task. pipewire-session-manager is the common dependency
> of both.
> 
> If you provide an isolated environment of urpmi media sources to exclude
> meta-task it might generate unpredictable results.

I not understand how the mess that Len report could be possible

urpmq --conflicts wireplumber
wireplumber: pipewire-session-manager

I just can think is an unexpected side effect of install packages by hand and not use draksound

BTW Give OK now that Len fix his issue and report about bluetooth

CC: (none) => andrewsfarm
Whiteboard: (none) => MGA9-64-OK

(In reply to katnatek from comment #14)

> I not understand how the mess that Len report could be possible

Nor do I, but it happens.
One thing I do manually is install any missing release packages before the update and try and test them but I sometimes forget that (age = 85) or miss some.  If any are missed then it is not a clean update and manual intervention is required.  Perhaps it is time to retire.

(In reply to Len Lawrence from comment #15)

> [...]
> update and try and test them but I sometimes forget that (age = 85) or miss
> some.  If any are missed then it is not a clean update and manual
> intervention is required.  Perhaps it is time to retire.

Please don't, you have 40 years ahead of us of computer science experience, if not more, that we don't. And also these things keep the mind in exercise.

With aging, maybe apart the frequency earing cutoff (btw, are matching something those earing test about age/frequency on YT?), probably changes just the timing of getting more focused within a certain part of the day, e.g. getting more focused at some time (morning?) and less focused in other (e.g. at night, or might be the opposite), but the faculties shouldn't change that much.

In this case I think I understand what happened. This is a bad beast package, basically because, unless you had already installed wireplumber, the installation of wireplumber is better to let handled from draksound.

What I think it happened is this. You had probably a default installation where sound was (as default) set to pulseaudio (and with pipewire-media-session installed somewhere). Then you installed, as usually do for any other package, just all the packages in the list above, maybe forcing or using --auto. But the list above already includes two packages conflicting each other (wireplumber and pipewire-media-session), plus since wireplumber|pipewire-media-session brings the dependency of pipewire as whole, then pipewire triggered the uninstallation of pulseaudio (because they are mutually-exclusive), which triggered uninstallation of other stuff and so on, but not the corresponding installation of the alternative packages (and also because was made outside task-pipewire). And then might explain the package hell you see in some way.

Beyond this, I was thinking to some environment which might be useful for testing delicate things or stuff like this, but to quickly restore the system to the previous working state in case of fault, without having to reinstall the whole system. In a VM one might just do a snapshot (e.g. in Virtualbox), or backup the filedisks (e.g. in qemu), but in a native system? Without having to waste with things like btrfs snapshots, etc., what of 'easy' that comes to mind it's something similar to the live system with the persistent partition.

In the live system we have the base system preinstalled, then with the persistent partition, we overlap it to the working filesystem (and everything installed later), using the overlayfs. To restore the live state we have just to discard the content (it's just a dir) of the persistent partition. If we would try a simple mechanism like this, by some script, to boot a current installed system, and then append as working overlayfs some dir in / and /home, then we could just discard the dir later. E.g. I boot with appending to the boot cmdline something like:

test_sysdir=sdb1:mysysdir_test_wireplumber_20241104 test_homedir=sdb1:myhomedir_test_wireplumber_20241104

then the dir mysysdir_test_wireplumber_20241104 in the partition /dev/sdb1, will be appended to the / as overlayfs, and the dir myhomedir_test_wireplumber_20241104 will be appended to the /home as overlayfs. In this case every new package installed in / or modification in $HOME, will be made in the overlayfs dirs, and you can restore the working system within seconds, by just discarding the content of the dirs '{mysysdir_test_wireplumber_20241104,myhomedir_test_wireplumber_20241104}', or alternatively by not providing any test_{sysdir,homedir}= boot cmdline argument. IMHO shouldn't be too difficult to implement some extra scripts for doing this.

Also, beyond this, if we wan't a system really robust for the alternative sound system we should operate at program level, i.e. patch the binaries of all the daemons (pipewire, pulseaudio, wireplumber, pipwire-media-session), and if a certain file or env var exists somewhere the daemon is not started at all, it just exits in even trying to start. In this case we wouldn't have to care about package conflicts, overlapping, whatever, and we could keep all the packages installed together without any worrying of conflicts, because only one will run.

Thanks for the response Giuseppe.  We are certainly a bit OT for this update.  It looks like this might be a good point to shift to mageia-discuss.  Your thinking reminds us of discussions in the distant past when containers were suggested as a possible way to test updates safely.

You probably overrate my skills but I take the point that Mageia needs to hang on to its active members, and we all appreciate how you have stepped up to nurse the kernels in addition to all your other work.

My preferred operating procedure is to ensure that release packages are already installed before tackling updates and then to use qarepo and drakrpm-update to start the tests.  This time I did not follow the plan closely enough.

So Len, do you agree with the OK? I don't want to dismiss any concerns you might still have.

Yes, it looks OK.

I will try 32 bit on my T43 in a few hours.

mga9-32 OK

Was using pipewire with wireplumber OK
testing medias are enabled, incl as update media
led drakrpm update
Rebooted, still OK
used draksoud to switch to pipewire with pipewire-media-session
Rebooted, still OK

In both cases I also tried after suspend and hibernation.
Desktop is LXDE, and from launch menu root there I can launch "Volume control for Pulseaudio" (yes it say so) and it works.


[ettan@localhost ~]$ inxi -SMA
System:
  Host: localhost Kernel: 6.6.58-desktop-2.mga9 arch: i686 bits: 32
    Desktop: LXDE v: 0.10.2.r1 Distro: Mageia 9
Machine:
  Type: Laptop System: IBM product: 2668R1G v: ThinkPad T43
    serial: <superuser required>
  Mobo: IBM model: 2668R1G serial: <superuser required> BIOS: IBM
    v: 1YET62WW (1.27 ) date: 05/18/2006
Audio:
  Device-1: Intel 82801FB/FBM/FR/FW/FRW AC97 Audio driver: snd_intel8x0
  API: ALSA v: k6.6.58-desktop-2.mga9 status: kernel-api
  Server-1: PipeWire v: 0.3.85 status: active

Keywords: (none) => validated_update
Whiteboard: MGA9-64-OK => MGA9-64-OK, MGA9-32-OK
CC: (none) => sysadmin-bugs

OK on three more 64 bit Plasma systems, 
Normal sound, not tested bluetooth.

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2024-0225.html

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