From Bug 33673 comment 10, Giuseppe told: "I uploaded a newer version of wireplumber and pipewire-media-session to be bundled with this newer version, that should fix some problems with bluetooth which apparently was spotted." --- I have now tested normal operation on both on my workstation svarten, mga9-64 Plasma, using draksound to switch between pipewire with wireplumber respectively pipewire-media-session, rebooted in between. Not tested bluetooth.
This bug need description/advisory proposal, package list, srpm field filled in.
CC: (none) => ghibomgx
Source RPM: (none) => wireplumber-0.5.6-1.mga9, pipewire-media-session-0.4.2-1.1.mga9
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
Keywords: (none) => advisory
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) => andrewsfarmWhiteboard: (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.