Spec URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx.spec SRPM URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx-0.2.0-1.fc33.src.rpm Description: This is Open Source implementation of Audio Processing Technology codec (aptX) derived from ffmpeg 4.0 project and licensed under LGPLv2.1+. This codec is mainly used in Bluetooth A2DP profile. Fedora Account System Username: gombosg Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=57676629 --- This is going to be very useful for pipewire, along with libldac. Upstream implementation is going on in here: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/227 Then, pipewire can be built with this in Fedora: https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/meson.build#L31-32 Note that aptX was patent protected, but (IANAL) it has expired. The library README says "derived from ffmpeg 4.0 project". But this only contains aptX related code and doesn't depend on ffmpeg. Maybe it will need legal review?
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.