Bug 1908922

IANAL as well, but I'm not sure about the legal status of aptX HD. Blocking FE-Legal (bug182235) would be a good idea.

As for the spec file -- have you considered making commandline tools a separate package? Although the only benefit I'm aware of that multilib packages could be installed in parallel (e.g. i686 + x86_64).
Looks good otherwise.

Good idea, I'll block the legal review bug.
Aleksei, good point, I'll package the 2 binaries in a separate subpackage called "openaptx". This is according to the guidelines, too.

I separated the CLI utilities into a subpackage.

Spec URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx.spec
SRPM URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx-0.2.0-2.fc33.src.rpm

Ack on the legal review. I'll get the patent status verified and then update this bug.

> %package        utils
> Summary:        %{name} encoder and decoder utilities
> Requires:       %{name}%{?_isa} = %{version}-%{release}

This is a weird pattern. Usually the main package includes the utilities and a -libs subpackage includes the libraries. This can be observed even in the RPM package: https://src.fedoraproject.org/rpms/rpm/blob/master/f/rpm.spec

Can you please restructure this accordingly?

(In reply to Neal Gompa from comment #5)
> This is a weird pattern. Usually the main package includes the utilities and
> a -libs subpackage includes the libraries. This can be observed even in the
> RPM package: https://src.fedoraproject.org/rpms/rpm/blob/master/f/rpm.spec

Seems common for codecs and other library packages:
opus (library), opus-tools (encoder/decoder)
libavif (library), libavif-tools (encoder/decoder)
libpng, libpng-tools
libwebp, libwebp-tools
...

The main content here is a library and binaries are just an additional content that is unlikely to be installed by a regular user.

Hmm, that's true since this package is actually named by the library name. Though `-utils` is weird compared to `-tools`.

Thanks for the suggestion. Renamed from -utils to -tools.

Spec URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx.spec
SRPM URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx-0.2.0-3.fc33.src.rpm

According to wikipedia, this is the patent
https://patents.google.com/patent/EP0398973B1/en,
long expired.

But please wait for ack from Legal before building this in Fedora.

fedora-review says:
- Package does not contain duplicates in %files.
  Note: warning: File listed twice: /usr/lib64/libopenaptx.so
Please fix.

+ package name is OK
+ license is acceptable for Fedora (LGPLv2.1+)
+ license is specified correctly (LGPGv2+)
+ builds and installs OK
+ Provides/Requires/BuildRequires look OK
+ distro build flags are used
+ looks OK in general

Rpmlint
-------
Checking: libopenaptx-0.2.0-3.fc34.x86_64.rpm
          libopenaptx-devel-0.2.0-3.fc34.x86_64.rpm
          libopenaptx-tools-0.2.0-3.fc34.x86_64.rpm
          libopenaptx-debuginfo-0.2.0-3.fc34.x86_64.rpm
          libopenaptx-debugsource-0.2.0-3.fc34.x86_64.rpm
          libopenaptx-0.2.0-3.fc34.src.rpm
libopenaptx.x86_64: W: spelling-error Summary(en_US) aptX -> apt X, apt, apex
libopenaptx.x86_64: W: spelling-error %description -l en_US aptX -> apt X, apt, apex
libopenaptx.x86_64: W: spelling-error %description -l en_US ffmpeg -> MPEG
libopenaptx.x86_64: W: no-documentation
libopenaptx-devel.x86_64: W: no-documentation
libopenaptx-tools.x86_64: W: no-documentation
libopenaptx-tools.x86_64: W: no-manual-page-for-binary openaptxdec
libopenaptx-tools.x86_64: W: no-manual-page-for-binary openaptxenc
libopenaptx.src: W: spelling-error Summary(en_US) aptX -> apt X, apt, apex
libopenaptx.src: W: spelling-error %description -l en_US aptX -> apt X, apt, apex
libopenaptx.src: W: spelling-error %description -l en_US ffmpeg -> MPEG
→ False positives.

libopenaptx-devel.x86_64: E: rpath-in-buildconfig /usr/lib64/pkgconfig/libopenaptx.pc lines ['9']
Yeah, the .pc files is borked:
> prefix=/usr/lib64
> exec_prefix=${prefix}
> libdir=${exec_prefix}//usr/include
→ this evaluates to libdir=/usr/lib64//usr/include
> Libs: -Wl,-rpath=${libdir} -L${libdir} -lopenaptx
→ this sets rpath, and it shouldn't.
> Cflags: -I${includedir}
→ this gets the include path wrong ;(

I think it'd be easiest to do something like
sed -r -i 's/^Libs:.*/Libs: -lopenaptx/; /Cflags:/d' /path/to/.pc

libopenaptx-tools.x86_64: W: summary-not-capitalized C libopenaptx encoder and decoder utilities
libopenaptx-tools.x86_64: E: description-line-too-long C The libopenaptx-tools package contains openaptxenc encoder and openaptxdec decoder
→ Maybe "AptX encoding and decoding tools"

6 packages and 0 specfiles checked; 2 errors, 12 warnings.

Package is APPROVED, conditional on Legal review.
Please fix issues listed above before upload.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #9)
> Yeah, the .pc files is borked:
> > prefix=/usr/lib64
> > exec_prefix=${prefix}
> > libdir=${exec_prefix}//usr/include
> → this evaluates to libdir=/usr/lib64//usr/include
> > Libs: -Wl,-rpath=${libdir} -L${libdir} -lopenaptx
> → this sets rpath, and it shouldn't.
> > Cflags: -I${includedir}
> → this gets the include path wrong ;(
> 
> I think it'd be easiest to do something like
> sed -r -i 's/^Libs:.*/Libs: -lopenaptx/; /Cflags:/d' /path/to/.pc

`%make_install PREFIX="%{_prefix}" LIBDIR="%{_lib}"` would generate correct paths in pkgconfig file. Makefile for this project expects all *DIR variables to be relative to the PREFIX.

(In reply to Ben Cotton from comment #4)
> Ack on the legal review. I'll get the patent status verified and then update
> this bug.

Hi @Ben, any advancements on the legal review? Looks like this still is still blocking the FE-Legal ticket.

It's been forwarded to the appropriate people. We're waiting for the resolution.

(In reply to Gergely Gombos from comment #11)
> Hi @Ben, any advancements on the legal review? Looks like this still is
> still blocking the FE-Legal ticket.

Not yet. I'll flag this with Red Hat Legal again.

Because the patent status is unclear, and we don't have a comprehensive list of the all patents involved in this technology, the aptX codec cannot be included in Fedora at this time. I am closing this ticket and wish I had a better answer.

Thanks @bcotton, this will go to rpmfusion then. 
I asked in IRC and @wtaymans confirmed that Pipewire could later use dlopen for codecs, so it could find the library even if it hadn't been built together with it.

I assume the needinfo was by mistake.

At the moment, adding libopenaptx to rpmfusion doesn't look like a viable alternative, because pipewire has to be built along with libopenaptx (like it's built with libldac) to enable support.
Suggestions are welcome, though.

Would it make sense to make a pipewire-freeworld package in rpmfusion until dlopening codecs work?

FYI: libopenaptx has been forked and replaced with libfreeaptx (https://github.com/iamthehorker/libfreeaptx) due to problems with the libopenaptx author and recent weird license changes.

Is it possible to split libspa-bluez5.so from pipewire-libs and give it spa-version instead of general pipewire version? That would allow easy replacement package.

You're better off just doing pipewire-freeworld.

In pipewire git (and next release 0.3.35), the codecs are split out to separate .so files that can be safely built and shipped separately, so if someone wants to make a pipewire-codec-aptx package that contains just libspa-codec-bluez5-aptx.so they can do so now.

Thanks for the heads up! Once 0.3.35 is out, I could package aptX codec for RPM Fusion.

It seems it's been already released :)

https://gitlab.freedesktop.org/pipewire/pipewire/-/tags/0.3.35

Looks like it still needs to build with libfreeaptx.
I tried a scratch build [1] of pipewire without the -D bluez5-codec-aptx=disabled option [2]. It failed miserably, not finding the library at build time. [3]

The current Fedora PW build just doesn't find the libfreeaptx codex.

But there is SBC-XQ [4] now which is almost as good as aptX and is enabled by default.

Any help and comments are appreciated though.

[1] https://src.fedoraproject.org/rpms/pipewire/blob/rawhide/f/pipewire.spec#_292
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=75626355
[3] https://kojipkgs.fedoraproject.org//work/tasks/6355/75626355/build.log
[4] https://www.lineageos.org/engineering/Bluetooth-SBC-XQ/

From the logs it doesn't look like it installs freeaptx at all, and it's not mentioned in spec file.

SBC-XQ is not comparable to APTX-LL, one has latency < 40ms, the other is > 150ms.

So, yes, you need to package libfreeaptx also.

The RPM build environment should have libfreeaptx present. Then you can do `meson configure builddir` as usual, and after that `meson compile -C builddir spa-codec-bluez5-aptx`. This generates builddir/spa/plugins/bluez5/libspa-codec-bluez5-aptx.so, which can be just copied to the right place, and the codec RPM can contain only that file.

Something like this https://gitlab.freedesktop.org/pvir/pipewire-codec-aptx-rpm/
(not planning to maintain it though)

Thanks for the POC repo! I haven't had time to look into it during the week, but I tested, this is working well, it's enough to start packaging in RPMFusion.

For those interested, I submitted:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=6088
https://bugzilla.rpmfusion.org/show_bug.cgi?id=6089

FYI for those interested: package pipewire-codec-aptx is in RPM Fusion right now (currently in testing, then stable). Please report any bugs you find in RPM Fusion Bugzilla.