[bug#54379] gnu: linux: update PipeWire & WirePlumber

* gnu/packages/linux.scm (pipewire-0.3): Update to 0.3.48.
Also add a few more inputs to PipeWire to enable a few options:
 - libfdk to support the AAC Bluetooth codec
 - libsndfile to build pw-cat
* gnu/packages/linux.scm (wireplumber): Update to 0.4.8.

---

PipeWire also supports the aptX Bluetooth codec but the situation
appears to be very muddy: some distributions like Debian, Gentoo or
Arch package libfreeaptx (a fork of libopenaptx to work around licensing
issues) but other like Fedora or OpenSUSE refuse to do it.
---
 gnu/packages/linux.scm | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)
  

On Fri, 1 Apr 2022 at 21:34, Maxime Devos <maximedevos@telenet.be> wrote:
> What's the impact on the output closure size?

I assume you mean ./pre-inst-env guix size pipewire?
store item                                                       total    self
/gnu/store/vbcfrng1aadxa79g7f8mlgm7wp9dzqwf-mesa-21.3.2            411.5   169.5  21.2%
/gnu/store/fvfymzksvj8k6pc54gmhx2lnvkxysfd8-llvm-11.0.0            221.5   149.5  18.7%
/gnu/store/b6j1qw1a5rkbfvcy7lc9fm95abbzpa4x-python-3.9.9           155.3    63.7   8.0%
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7            129.1    52.0   6.5%
/gnu/store/hzic3ddl5yvnyw7gm4a0qc5icgqy2442-icu4c-69.1             110.7    38.0   4.7%
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33              38.3    36.6   4.6%
/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib          71.7    33.4   4.2%
/gnu/store/6qlv57cr2xz37sarbwiv6ksqabf589p6-iso-codes-4.5.0         18.5    18.5   2.3%
/gnu/store/78b0194wv2d5vrqr408x2m2ndfy11j7j-eudev-3.2.11           102.2    17.7   2.2%
/gnu/store/84bvs9y0arsimxd2ay26a57xkqw7nsqm-glib-2.70.2             98.1    15.3   1.9%
/gnu/store/rvirnmnxxm2ymqgcxcnj3dxvnrnqlk0l-fftwf-3.3.8             85.9    13.2   1.6%
/gnu/store/614385afpnp5kcnixhrz5mz3fnbgyqkf-gst-plugins-base-1.18.5   656.1    12.8   1.6%
/gnu/store/df3ghmicrls14q2zcaj86217dicgnzs7-gstreamer-1.18.5       196.6    10.5   1.3%
/gnu/store/ln5dqqs2wkhhaqrpib5xqga0m1wpj028-pipewire-0.3.49        799.5    10.2   1.3%
/gnu/store/gkjna040y14xvk4y5mcccvjkkmdcvmnv-font-dejavu-2.37         9.8     9.8   1.2%
/gnu/store/5583c2za2jsn9g6az79rnksgvigwnsk7-util-linux-2.37.2-lib    80.7     9.0   1.1%
/gnu/store/84v5kpb4wcag0q173rq1jc9ajc953455-pulseaudio-15.0        304.1     8.9   1.1%
/gnu/store/3dy6pwfayfwdmf9y3rm4yaryzxkbdqv7-libical-3.0.10         149.6     7.5   0.9%
/gnu/store/9rrnm5hdjw7cy96a2a9rfgh6y08wsbmf-ncurses-6.2.20210619    77.6     5.9   0.7%
/gnu/store/zkl2vfmlifcyxphidx5nbv177qs9ziaz-harfbuzz-2.8.2         147.3     5.5   0.7%
/gnu/store/plr00nij45964cyy7sfcg5rcsi8hks0h-openssl-1.1.1l          77.2     5.5   0.7%
[...]
total: 799.5 MiB

Do you need the full output (where should I paste it)?
WirePumber doesn't add much:
[...]
/gnu/store/x4aak1x0l6wvb229zdqh3lh94bf2kl0j-wireplumber-0.4.9      802.3     1.5   0.2%
/gnu/store/wa7cjcx12pgx2zpk2psmlpxkmkqn79ri-lua-5.3.5               80.3     1.3   0.2%
[...]
total: 802.3 MiB

> For future reference, I would put this information in comments in the
> package definition. That seems much more convenient to me than having
> to dig through the git history.

I wasn't too sure if that's common style, but I also prefer commenting the
dependencies when they aren't obvious. Done.

On Fri, 1 Apr 2022 at 21:41, Maxime Devos <maximedevos@telenet.be> wrote:
> Looks like some of these are only used for some plugins.

Yeah, most of them.

> Can plugins be built separately? If they are built separately (and
> hence, the 'main' pipewire package does not have these extra packages),
> then updating, say, lilv, would cause less rebuilds.

I've no idea how that works on Guix, I assume it's not as simple as with other
distributions where all libraries/plugins can be found in a single place (/lib).
Do you have an example? I agree it would be nicer and I'm happy to split the
package (talking about plugins, do you happen to have some pointers for
https://issues.guix.gnu.org/54379#5?).

On Fri, 1 Apr 2022 at 21:42, Maxime Devos <maximedevos@telenet.be> wrote:
> Can this be updated in a separate patch or are pipewire and wireplumber
> too intertwined?

It builds and plays sound. I've split the commit.

Kevin Boulain (3):
  gnu: linux: update PipeWire
  gnu: linux: update WirePlumber
  gnu: rename pipewire to pipewire-0.2 and pipewire-0.3 to pipewire

 gnu/packages/chromium.scm        |  2 +-
 gnu/packages/freedesktop.scm     |  6 ++--
 gnu/packages/gnome.scm           |  4 +--
 gnu/packages/kde-systemtools.scm |  2 +-
 gnu/packages/linux.scm           | 49 ++++++++++++++++++++------------
 gnu/packages/telegram.scm        |  2 +-
 gnu/packages/video.scm           |  2 +-
 7 files changed, 40 insertions(+), 27 deletions(-)
  

Kevin Boulain schreef op vr 01-04-2022 om 22:44 [+0200]:
> I assume you mean ./pre-inst-env guix size pipewire?
> store item                                                       total    self
> [...]
> Do you need the full output (where should I paste it)?

More concretely, I'm wondering what the impact is of the new inputs:

 +                       libfdk
 +                       libsndfile
 +                       libusb
 +                       lilv
 +                       openssl
 +                       readline
 +                       webrtc-audio-processing

What are their 'total self percentage' values?

Greetings,
Maxime.
  

Kevin Boulain schreef op vr 01-04-2022 om 22:44 [+0200]:
> I've no idea how that works on Guix, I assume it's not as simple as with other
> distributions where all libraries/plugins can be found in a single place (/lib).
> Do you have an example?

Maybe have a look at how audacity searches AUDACITY_MODULE_PATH and
'dlopen's things?  Or BASH_LOADABLES_PATH.

Greetings,
Maxime.
  

On Sat, 2 Apr 2022 at 18:19, Maxime Devos <maximedevos@telenet.be> wrote:
> More concretely, I'm wondering what the impact is of the new inputs:
> [...]
> What are their 'total self percentage' values?

Right, so just to make sure we're on the same page:
 - guix size pipewire before this patch:
https://paste.debian.net/hidden/57a05080/
 - guix size pipewire after this patch:
https://paste.debian.net/hidden/cbb93545/
 - diff: https://paste.debian.net/hidden/3cb51fbd/

Surprisingly there isn't that much of an increase (~5MiB). That's
because most of the new dependencies were already pulled in by
existing dependencies.
For example, PulseAudio was pulling libsndfile &
webrtc-audio-processing. Bluez was pulling readline. I traced one
OpenSSL use back to a ffmpeg plugin dependency (rav1e's rust-cargo-c,
it's also used by other things but the Graphviz graph is too big to
generate a visualization).

This leaves us with only these new dependencies (see diff):
libfdk-2.0.1            75.2     3.5   0.4%
libusb-1.0.24           72.1     0.4   0.0%
lilv-0.24.12            74.0     0.3   0.0%
serd-0.30.8             71.9     0.2   0.0%
sord-0.16.8             73.7     0.1   0.0%
sratom-0.6.6            73.7     0.1   0.0%
  

Kevin Boulain schreef op za 02-04-2022 om 20:33 [+0200]:
> Surprisingly there isn't that much of an increase (~5MiB). That's
> because most of the new dependencies were already pulled in by
> existing dependencies.

Ok, that doesn't seem too bad.

Greetings,
Maxime.
  

Friendly ping: what's the status of these patches? Are we waiting to see 
if the extra functionaly can be provided as separate plug-in packages so 
they won't clutter up the dependency graph?

Thanks,
Jack
  

On 18-08-2022 22:46, Jack Hill wrote:

> Friendly ping: what's the status of these patches? Are we waiting to 
> see if the extra functionaly can be provided as separate plug-in 
> packages so they won't clutter up the dependency graph?

AFAIK, no, it would be useful but AFAIK not a blocker.

AFAIK the only thing we are waiting for is for someone to commit the 
patches.

Though as a reminder, I only looked at the patches, I didn't check the 
source diff for various forms of 'badness'.

Greetings,
Maxime.
  

Now that weston has been update to 10, it appears there isn't anything else in
Guix that requires pipewire 0.2. I notice in your last patchset Kevin, you set
Telegram to use pipewire 0.2, but I'm not aware of any reason that in needs it?
Was that intentional?

Apologies in advance for 1) highjacking your submission with my own patchset,
and 2) Messing up commit messages and other basic things I always forget.
  

Same as v3 but uses PREFIX instead of DESTDIR for libfreeaptx.
  

On Sun, 9 Oct 2022 at 06:02, 'Brendan Tildesley <mail@brendan.scot> wrote:
> Now that weston has been update to 10, it appears there isn't anything else in
> Guix that requires pipewire 0.2. I notice in your last patchset Kevin, you set
> Telegram to use pipewire 0.2, but I'm not aware of any reason that in needs it?

Most of the packages depended on PipeWire 0.3 but a few still depended
on PipeWire 0.2. Because I couldn't test all of them, I went for a
minimal change and kept the same PipeWire version as previously
declared in the dependencies (but renamed 'pipewire' to 'pipewire-0.2'
and 'pipewire-0.3' to 'pipewire' to make updates easier).
So no reason in particular besides that I didn't test if Telegram was
still working with a newer version.
  

Hi Brendan and Kevin,

'Brendan Tildesley <mail@brendan.scot> writes:
> Same as v3 but uses PREFIX instead of DESTDIR for libfreeaptx.

This patch totally flew under my radar before, but now that I wanted to
add aptX support I finally found it (after writing the libfreeaptx
definition myself first :p).

Looks good overall, I'm using it without any issues, but I have a couple
of very small nitpicks:

* First of all, patch 1 doesn't cleanly apply on master anymore (which
  is normal). To make it easier for maintainers to merge your patches,
  you should specify base-commit in your patches using the --base
  option, so that they know what patch this was supposed to cleanly
  apply on;

* in patch 5, you apparently left an entry in the commit message about
  the `/etc` change, even though you separated it into its own commit;

* while we're at it, there's a small typo in patch 1's commit message,
  `theinput` -> `the input`;

* if you're inheriting patches from someone else, you should consider
  either leaving them as the primary author if you're keeping their
  changes as-is, or putting them in the commit message as
  Co-authored-by:.  It's not really an issue here I think, but something
  to remember.

Best,
  

Hi again both of you,

To avoid letting this patch rot in the MLs for too long, I can pick it
up, rebase it and fix up the commit messages, unless you plan to work
further on it.  I can also update the programs to latest while I'm at
it.

Unless there are objections, I'll try doing that in the upcoming
week(s).

Best,
  

Hi,

Josselin Poiret <dev@jpoiret.xyz> writes:

> To avoid letting this patch rot in the MLs for too long, I can pick it
> up, rebase it and fix up the commit messages, unless you plan to work
> further on it.  I can also update the programs to latest while I'm at
> it.

I've done the above, here's an updated and cleaned patchset.

Best,
  

Hello,

> I've done the above, here's an updated and cleaned patchset.

I just pushed the latest patchset.

Thanks everyone,

Mathieu