Bug 827546 – media-video/pipewire-0.3.49-r1, media-video/wireplumber-0.4.9 stabilisation

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[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"

[addCollapseLink(5, 1, 'Toggle comment display'); 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 <[e-mail]>
AuthorDate: 2022-02-11 19:54:31 +0000
Commit:     Sam James <[e-mail]>
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 <[e-mail]>
    Signed-off-by: Sam James <[e-mail]>

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

[addCollapseLink(11, 1, 'Toggle comment display'); 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

[addCollapseLink(13, 1, 'Toggle comment display'); 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]

sigh.

[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 <[e-mail]>
AuthorDate: 2022-04-21 22:03:14 +0000
Commit:     Sam James <[e-mail]>
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 <[e-mail]>

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

[addCollapseLink(18, 1, 'Toggle comment display'); 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]

x86 stable

[Comment 20 Arthur Zamarin 2022-04-24 17:47:16 UTC]

arm done

[Comment 21 Arthur Zamarin 2022-04-25 19:43:17 UTC]

ppc64 done

[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 <[e-mail]>
AuthorDate: 2022-04-29 00:57:06 +0000
Commit:     Sam James <[e-mail]>
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 <[e-mail]>

 profiles/package.mask | 6 ------
 1 file changed, 6 deletions(-)

[Comment 23 Sam James 2022-04-29 05:36:23 UTC]

arm64 done

[Comment 24 Sam James 2022-04-29 06:02:26 UTC]

ppc done

all arches done