New package: shairport-sync-classic-4.3.2
Implementation of an Airplay 1 audio receiver. Homepage.
Note: the source can be built into either an Airplay 1 or Airplay 2 receiver. The Airplay 2 version is packaged as another package shairport-sync-airplay2. Both packages provide the alternative shairport-sync:/usr/bin/shairport-sync.
The application supports virtually all audio systems, and it builds with support for ALSA, Pulse, JACK, and PipeWire by default (audio systems available in the Void repos). It does not build with Unix pipe output support -- (imo) use cases for this should be handled by the user's audio system instead.
I've been using this package for ~a year on Pulse and PipeWire now without issue.
Needs alac to build.
Testing the changes
- I tested the changes in this PR: YES
New package
- This new package conforms to the package requirements: YES
Local build testing
- I built this PR locally for my native architecture,
x86_64-glibc - I built this PR locally for these architectures:
- aarch64-musl
- aarch64
- armv7l-musl
- armv7l
- armv6l-musl
- armv6l
Don't add all these build options; this isn't Gentoo. Just configure it the way that makes sense for you and, if somebody later decides adding or removing features makes sense, that person can propose individual options.
Also, there's no value building with mbedtls. OpenSSL is part of the base system, so just build with that.
I see, thanks for the tips.
Since the same codebase builds for an Airplay 2 version (which I've packaged separately), and that version has its own dependency that needs to be packaged, should I bundle them all into this one PR?
Ideally, you would have one template that builds the same source twice (once for each AirPlay version) and splits the resulting products between the main package and a subpackage.
Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.