Search Criteria
Package Details: librespot-git 1:1435.e5fd7d6-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/librespot-git.git (read-only, click to copy) |
---|---|
Package Base: | librespot-git |
Description: | Open Source Spotify client library |
Upstream URL: | https://github.com/librespot-org/librespot |
Licenses: | MIT |
Conflicts: | librespot |
Provides: | librespot |
Submitter: | christoph.gysin |
Maintainer: | christoph.gysin |
Last Packager: | christoph.gysin |
Votes: | 12 |
Popularity: | 0.000271 |
First Submitted: | 2016-09-05 20:30 (UTC) |
Last Updated: | 2021-12-19 12:01 (UTC) |
Dependencies (4)
Required by (4)
- raspotify-git
- spotify-qt (requires librespot) (optional)
- spotify-qt-git (requires librespot) (optional)
- tauon-music-box (requires librespot) (optional)
Latest Comments
1 2 3 4 Next › Last »
christoph.gysin commented on 2021-12-19 12:01 (UTC)
@keithspg Apparently the target for armv6h is simply
arm-unknown-linux-gnueabihf
.keithspg commented on 2021-12-19 10:12 (UTC) (edited on 2021-12-19 11:03 (UTC) by keithspg)
I have a similar issue to @chilikk, I get this package to build under aarch64 and armv7h but not armv6h. I get this when I try it on RPi:
When I list the architectures, this is all that lists for armv6
This package last built on December 5 on armv6h and I have updated my system since then. Did rust remove this as a valid architecture? When I comment out the prepare section and remove the --frozen flag it does build but I do not know if it is a functional binary.
Update... If I revert to the commit 9bd43b4 and keep the current rust and llvm-libs, I can get it to build a binary under armv6. I do not know if it works or not, though. It seems that the extra edits since then work for armv7 and aarch64 but not armv6.
christoph.gysin commented on 2021-10-17 13:30 (UTC)
@themooleman I'm afraid I don't know and won't support raspotify. You might want to ask about your issue on https://aur.archlinux.org/packages/raspotify-git.
themooleman commented on 2021-10-17 04:39 (UTC) (edited on 2021-10-17 04:45 (UTC) by themooleman)
I use raspotify (raspotify-git) on a Raspberry Pi 4b. The most recent librespot version broke raspotify.service with journalctl logging the following error:
Rolling back to version 1357.68bec41 resolved the issue.
whynothugo commented on 2021-10-07 20:00 (UTC)
$CARCH probably doesn't match with what rust calls this platform, but I'm not sure if the right name.
chilikk commented on 2021-10-07 19:35 (UTC)
Unfortunately, the new prepare() step fails for me on Raspberry Pi 4 with the following error
Removing the
prepare()
step and the--frozen
flag resolves the problem for me - but then I don't know enough about Rust to tell if it is the right solution here.christoph.gysin commented on 2021-10-05 13:13 (UTC)
Fair enough, I've switched to using the default features. That seems to use the rodio backend (which uses alsa) and mdns.
And thanks for the tip with
paru
, I'll check it out. I have now verified that it builds withmakechrootpkg
.whynothugo commented on 2021-10-05 12:09 (UTC)
Looks like some dependency is missing now (though the previous error due to network access is gone; this failure is during build):
Hint: You can set up
paru
to build packages in a clean chroot. I've found that SUPER useful to make sure packages I maintain will also build for others.Rather than use
--all-features
, it might make sense to figure out which features people want, and enable just those. I suspect that enabling pulseaudio (which is off by default) is enough for most people.I'm using
systemd-resolved
, which ships its own mDNS implementation. It doesn't really play well to avahi since it's, well, a successor/replacement. The default librespot implementation plays fine with this, but the avahi-specific one does not."might" is a key word here IMHO. So far
--with-dns-sd
has been turned off and I don't see anyone reporting issues for this.christoph.gysin commented on 2021-10-05 09:46 (UTC)
@whynothugo Thanks, I added a
prepare()
step to fetch all dependencies. Let me know if that works for you.I'm undecided about
--all-features
. I'd prefer to be able to build a single binary that works for all. Unfortunately that does not currently seem to be possible.The only issue seems to be
--with-dns-sd
, which overrides the defaultmDNS
implementation: https://github.com/librespot-org/librespot/blob/dev/discovery/src/lib.rs#L106From the wiki: https://github.com/librespot-org/librespot/wiki/Compiling#with-dns-sd "If with-dns-sd is enabled, librespot will crash if Avahi or Bonjour is not running. On the other hand, if with-dns-sd was not enabled, librespot might interfere with Avahi, Bonjour or other librespot instances if running, or even crash on some OSs."
If we add it, we break people without avahi. If we don't we break people with avahi.
I feel like staying with
--all-features
, and suggest everyone to run avahi. Could you elaborate if that's an option for you, or why not?IMO this should be reported upstream, with a PR adding a CLI parameter to choose mDNS even if dns-sd is built in.
whynothugo commented on 2021-10-05 08:54 (UTC)
The
--frozen
flag is problematic. This flag indicates that no network access should happen so build fails:This probably worked for you since you have everything in local cache -- building on a clean chroot (or cleaning up all cache and alike) will surface the error too.
I also noticed you added
--all-features
. This flag is also problematic, since it causes librespot to crash at startup if usingsystemd-resolved
instead ofavahi
. The upstream default is safe, in that it works on any environment.I think what @leonardder intended was for this to be built with pulseaudio support (or some other specific feature maybe?), but a blanked
--all-features
just makes this unusable for some of us. Generally following upstream as close as possible is the best practice.1 2 3 4 Next › Last »