|Summary:||media-video/pipewire-0.3.49-r1, media-video/wireplumber-0.4.9 stabilisation|
|Product:||Gentoo Linux||Reporter:||Andreas Sturmlechner <asturm>|
|Component:||Stabilization||Assignee:||Gentoo Linux Gnome Desktop Team <gnome>|
|Severity:||normal||CC:||89q1r14hd, asturm, marecki, qa, sam, whissi, yellowhat46|
media-video/pipewire-0.3.49-r1 arm arm64 ppc ppc64 x86 media-video/wireplumber-0.4.9 arm arm64 ppc ppc64 x86 media-libs/libfreeaptx-0.1.1-r1 arm arm64 ppc ppc64 x86
|Runtime testing required:||---|
|Bug Depends on:||813015, 814524|
Description Andreas Sturmlechner 2021-11-26 18:48:34 UTC
In preparation, not stabilising just yet.
Comment 1 Niklāvs Koļesņikovs 2021-11-26 19:17:38 UTC
As a heads up, there's a WirePlumber 0.4.5-r1 incoming. And I just became aware of currently not yet upstreamed merge request that we probably should package behind USE=experimental or similar to avoid regression in Bluetooth handling.
Comment 2 Niklāvs Koļesņikovs 2021-11-30 19:21:51 UTC
Here's the bug in question which should be carefully considered before replacing pipewire-media-session with WirePlumber for Gentoo stable: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/90 Since we haven't received any direct reports, it's perhaps not a common use case but there's bound to be people who will be affected by the regression, if it's not fixed either upstream or by Gentoo applying some kind of a fix. There is https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/200 which could be made available via, I think, +experimental IUSE but the quality and viability of the code is questionable. I also never got to testing if the MR can still be cleanly applied to WirePlumber 0.4.6.
Comment 3 Niklāvs Koļesņikovs 2021-11-30 19:23:26 UTC
I meant WirePlumber 0.4.5 of course. Sorry for posting while thinking about other things.
Comment 4 Sam James 2021-12-18 05:59:18 UTC
Remaining blocker is, AFAIK, "how do we avoid wireplumber trying to steal audio by default for users of e.g. GNOME"
Comment 5 NATTkA bot 2021-12-18 06:44:42 UTC Comment hidden (obsolete)
Sanity check failed: > media-video/pipewire-0.3.42-r1 > depend ppc64 stable profile default/linux/ppc64/17.0 (12 total) > media-libs/libfreeaptx > rdepend ppc64 stable profile default/linux/ppc64/17.0 (12 total) > media-libs/libfreeaptx
Comment 6 Sam James 2021-12-18 06:48:16 UTC
(In reply to Sam James from comment #4) > Remaining blocker is, AFAIK, "how do we avoid wireplumber trying to steal > audio by default for users of e.g. GNOME" [15:45:09] <pinkflames[m]> sam_: leio : here's another way to achieve video only pipewire: create an ebuild that installs /etc/wireplumber/main.lua.d/90-enable-all.lua [15:45:33] <pinkflames[m]> with IUSE on the ebuild that control if alsa_monitor.enable() and v4l2_monitor.enable() are being called or not [15:45:53] <pinkflames[m]> do not turn them into disable() though - just comment them out or omit them entirely (Not sure about why v42l is mentioned there.)
Comment 7 Niklāvs Koļesņikovs 2021-12-21 15:04:04 UTC
Correct, I was slightly feverish due to some winter bug or another and mistakenly also included the v4l2 line since I knew there were two things to disable. The correct instructions are as follow: create an ebuild with IUSE on it that control: 1) if /etc/wireplumber/main.lua.d/90-enable-all.lua calls alsa_monitor.enable() 2) if /etc/wireplumber/bluetooth.lua.d/90-enable-all.lua calls bluez_monitor.enable() For both files do not replace enable with disable - instead omit entirely or comment out the pertinent line with -- to avoid the enable() function from being called. And just for completeness I'll note that when such /etc/wireplumber files exist, they replace upstream version in /usr/share/wireplumber, so all of their other content must be duplicated in the /etc version or things will break. Thankfully both files only see a few commits per year, so a keen eyed maintainer can probably keep such an ebuild reasonably up to date.
Comment 8 Sam James 2022-02-08 07:48:22 UTC
I'm actually not sure if we do need to wait/make any changes now. Nobody has complained about the status quo and the stable version is getting pretty stable now. Thoughts?
Comment 9 Niklāvs Koļesņikovs 2022-02-08 08:24:20 UTC
I would at least propose to wait up to 7 more days to see if maybe 0.4.8 remains without major known issues (since it's already available in Gentoo ~testing as well as probably Arch Linux). If it does, we could stabilize that in an expedited fashion. And, if serious issues are reported, we can stabilize 0.4.7-r1 immediately. Regarding PipeWire version to stabilize, you're definitely more in touch with their state than I am, since these days I only concern myself with the git master and can't comment on how good or bad previous versions of PipeWire are.
Comment 10 Larry the Git Cow 2022-02-12 05:17:06 UTC
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5e618b3296b6dc8cd626ae8f3ce176276c48679e commit 5e618b3296b6dc8cd626ae8f3ce176276c48679e Author: Niklāvs Koļesņikovs <email@example.com> AuthorDate: 2022-02-11 19:54:31 +0000 Commit: Sam James <firstname.lastname@example.org> CommitDate: 2022-02-12 05:16:52 +0000 media-video/wireplumber: clean up versions too old for stabilization WirePlumber 0.4.5-0.4.6 are both quite old and missing features, compared to pipewire-media-session, and are therefore very unlikely to be stabilized. If you're still using one of them, please let us know what issue prevents you from using a newer version. Bug: https://bugs.gentoo.org/827546 Signed-off-by: Niklāvs Koļesņikovs <email@example.com> Signed-off-by: Sam James <firstname.lastname@example.org> media-video/wireplumber/Manifest | 3 - ...-config-add-restricted-access-permissions.patch | 36 ------- ...-alsa-handle-the-release-requested-signal.patch | 33 ------- ...tes.lua-reevaluate-current-profile-only-f.patch | 81 ---------------- ...ead-hidden-files-from-the-config-director.patch | 27 ------ ...evice-replace-the-hash-table-key-on-new-i.patch | 47 ---------- ...de-wait-for-nodes-when-we-become-unlinked.patch | 34 ------- ...-find-best-linkable-if-default-one-cannot.patch | 48 ---------- ...cy-node-fix-typo-when-finding-best-target.patch | 27 ------ ...-schedule-a-rescan-without-timeout-if-def.patch | 50 ---------- ...-different-architecture-errors-for-boolea.patch | 40 -------- .../wireplumber/wireplumber-0.4.5-r2.ebuild | 101 -------------------- .../wireplumber/wireplumber-0.4.5-r4.ebuild | 104 --------------------- .../wireplumber/wireplumber-0.4.6-r1.ebuild | 97 ------------------- 14 files changed, 728 deletions(-)
Comment 11 NATTkA bot 2022-02-12 05:20:32 UTC Comment hidden (obsolete)
Unable to check for sanity: > no match for package: media-video/wireplumber-0.4.7-r1
Comment 12 Niklāvs Koļesņikovs 2022-02-23 14:04:36 UTC
It seems that the Linux kernel USB issue has been fixed in 5.16.11, so let's wait a few days for that to be deployed and for users to verify that there's not a separate PW or WP suspend/device detection regression overshadowed by that kernel bug, and we can think about stabilizing either WirePlumber 0.4.7-2 or 0.4.8-r2 with a fitting PW version. Upstream bug for reference: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/186#note_1270712
Comment 13 NATTkA bot 2022-04-17 16:48:32 UTC Comment hidden (obsolete)
Unable to check for sanity: > no match for package: media-video/pipewire-0.3.48-r1
Comment 14 Niklāvs Koļesņikovs 2022-04-20 10:19:47 UTC
It appears that bug #839525 has done the job by stabilizing PW 0.3.49 and WP 0.4.9. Cheers.
Comment 15 Andreas Sturmlechner 2022-04-20 12:17:42 UTC
Comment 16 Sam James 2022-04-21 19:42:10 UTC
Done without authorisation and incorrectly (missing all arches but amd64) in bug 839525. Too late to revert as it'll cause substantial issues for users with Chromium, Firefox rebuilds as well as general issues w/ symbol versions when downgrading libraries. Reopening this bug to do the remaining arches, with great reluctance.
Comment 17 Larry the Git Cow 2022-04-21 22:03:52 UTC
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cf0839e62df9f24422111150f0ccb5bf82a6e7bf commit cf0839e62df9f24422111150f0ccb5bf82a6e7bf Author: Sam James <email@example.com> AuthorDate: 2022-04-21 22:03:14 +0000 Commit: Sam James <firstname.lastname@example.org> CommitDate: 2022-04-21 22:03:14 +0000 media-video/pipewire: backport x86 fix Bug: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2271 Bug: https://bugs.gentoo.org/827546 Bug: https://bugs.gentoo.org/839525 Signed-off-by: Sam James <email@example.com> .../pipewire/files/pipewire-0.3.49-x86-cast.patch | 20 ++++++++++++++++++++ ...ewire-0.3.49.ebuild => pipewire-0.3.49-r1.ebuild} | 2 ++ ...re-0.3.50-r2.ebuild => pipewire-0.3.50-r3.ebuild} | 2 ++ 3 files changed, 24 insertions(+)
Comment 18 NATTkA bot 2022-04-21 22:08:29 UTC Comment hidden (obsolete)
Unable to check for sanity: > no match for package: media-video/pipewire-0.3.49
Comment 19 Agostino Sarubbo 2022-04-24 06:35:03 UTC
Comment 20 Arthur Zamarin 2022-04-24 17:47:16 UTC
Comment 21 Arthur Zamarin 2022-04-25 19:43:17 UTC
Comment 22 Larry the Git Cow 2022-04-29 01:00:23 UTC
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d4c081daccde5db94acf5894ba2653188ad6cea0 commit d4c081daccde5db94acf5894ba2653188ad6cea0 Author: Sam James <firstname.lastname@example.org> AuthorDate: 2022-04-29 00:57:06 +0000 Commit: Sam James <email@example.com> CommitDate: 2022-04-29 00:57:06 +0000 profiles: unmask split pulseaudio packages This is a move towards making it easier for users to choose between pulseaudio and pipewire for their audio needs. We now have: - media-sound/pulseaudio (a transitory metapackage, installs no files, just enforces deps with USE flags); - media-libs/libpulse (the pulseaudio libraries, needed by clients using pulseaudio's protocol to speak to pipewire, but is not the pulseaudio daemon) - media-sound/pulseaudio-daemon (the pulseaudio daemon, to be used instead of pipewire if desired) While these are technically RC/pre-releases (and I have a strong reluctance against keywording those usually), we have a good relationship with upstream who report they've been quiet developmentwise since these tags, these versions have been tested & work well, and this will help to improve the experience for Gentoo users in choosing which audio server they want. So, all in all, a win. Bug: https://bugs.gentoo.org/536780 Bug: https://bugs.gentoo.org/744622 Bug: https://bugs.gentoo.org/827546 Bug: https://bugs.gentoo.org/841494 Signed-off-by: Sam James <firstname.lastname@example.org> profiles/package.mask | 6 ------ 1 file changed, 6 deletions(-)
Comment 23 Sam James 2022-04-29 05:36:23 UTC
Comment 24 Sam James 2022-04-29 06:02:26 UTC
ppc done all arches done