| 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> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 89q1r14hd, asturm, marecki, qa, sam, whissi, yellowhat46 |
| Priority: | Normal | Keywords: | CC-ARCHES, PullRequest |
| Version: | unspecified | Flags: | nattka:
sanity-check+
|
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://github.com/gentoo/gentoo/pull/24163 https://bugs.gentoo.org/show_bug.cgi?id=744622 https://bugs.gentoo.org/show_bug.cgi?id=839525 https://bugs.gentoo.org/show_bug.cgi?id=840278 |
||
| Whiteboard: | |||
| Package list: |
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 | ||
| Bug Blocks: | |||
|
Description
Andreas Sturmlechner
2021-11-26 18:48:34 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. 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. I meant WirePlumber 0.4.5 of course. Sorry for posting while thinking about other things. Remaining blocker is, AFAIK, "how do we avoid wireplumber trying to steal audio by default for users of e.g. GNOME" 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
(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.) 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. 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? 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. 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 <89q1r14hd@relay.firefox.com> AuthorDate: 2022-02-11 19:54:31 +0000 Commit: Sam James <sam@gentoo.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 <89q1r14hd@relay.firefox.com> Signed-off-by: Sam James <sam@gentoo.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(-) Unable to check for sanity:
> no match for package: media-video/wireplumber-0.4.7-r1
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 Unable to check for sanity:
> no match for package: media-video/pipewire-0.3.48-r1
It appears that bug #839525 has done the job by stabilizing PW 0.3.49 and WP 0.4.9. Cheers. sigh. 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. 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 <sam@gentoo.org> AuthorDate: 2022-04-21 22:03:14 +0000 Commit: Sam James <sam@gentoo.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 <sam@gentoo.org> .../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(+) Unable to check for sanity:
> no match for package: media-video/pipewire-0.3.49
x86 stable arm done ppc64 done 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 <sam@gentoo.org> AuthorDate: 2022-04-29 00:57:06 +0000 Commit: Sam James <sam@gentoo.org> 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 <sam@gentoo.org> profiles/package.mask | 6 ------ 1 file changed, 6 deletions(-) arm64 done ppc done all arches done |
