Package Details: librespot-git 1:1435.e5fd7d6-1

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)

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:

==> Starting prepare()...
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names --target armv6h-unknown-linux-gnu --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg` (exit status: 1)
  --- stderr
  error: Error loading target specification: Could not find specification for target "armv6h-unknown-linux-gnu". Run `rustc --print target-list` for a list of built-in targets

==> ERROR: A failure occurred in prepare().
    Aborting...

When I list the architectures, this is all that lists for armv6

armv6-unknown-freebsd
armv6-unknown-netbsd-eabihf
armv6k-nintendo-3ds

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:

raspotify.service: Main process exited, code=exited, status=101/n/a

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

==> Starting prepare()...
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names --target armv7h-unknown-linux-gnu --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg` (exit status: 1)
  --- stderr
  error: Error loading target specification: Could not find specification for target "armv7h-unknown-linux-gnu". Run `rustc --print target-list` for a list of built-in targets

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 with makechrootpkg.

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):

error: failed to run custom build command for `portaudio-sys v0.1.1`

Caused by:
  process didn't exit successfully: `/build/librespot-git/src/librespot/target/release/build/portaudio-sys-33780b1c305f126b/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=PORTAUDIO_2.0_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PORTAUDIO_2.0_STATIC
  cargo:rerun-if-env-changed=PORTAUDIO_2.0_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at '`"pkg-config" "--libs" "--cflags" "portaudio-2.0"` did not exit successfully: exit status: 1
  --- stderr
  Package portaudio-2.0 was not found in the pkg-config search path.
  Perhaps you should add the directory containing `portaudio-2.0.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'portaudio-2.0', required by 'virtual:world', not found
  ', /build/.cargo/registry/src/github.com-1ecc6299db9ec823/portaudio-sys-0.1.1/build.rs:8:19
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed
==> ERROR: A failure occurred in 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.

librespot might interfere with Avahi, Bonjour or other librespot instances if running, or even crash on some OSs."

"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 default mDNS implementation: https://github.com/librespot-org/librespot/blob/dev/discovery/src/lib.rs#L106

From 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:

==> Starting build()...
error: failed to get `base64` as a dependency of package `librespot v0.2.0 (/build/librespot-git/src/librespot)`

Caused by:
  attempting to make an HTTP request, but --frozen was specified
==> ERROR: A failure occurred in build().

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 using systemd-resolved instead of avahi. 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 »