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.000000
First Submitted: 2016-09-05 20:30 (UTC)
Last Updated: 2021-12-19 12:01 (UTC)

Required by (6)

Sources (1)

Latest Comments

1 2 3 4 Next › Last »

christoph.gysin commented on 2024-09-15 13:57 (UTC) (edited on 2024-09-15 15:14 (UTC) by christoph.gysin)

@acidicX This is a -git package, please file a bug upstream or use librespot instead.

Upstream issue: https://github.com/librespot-org/librespot/issues/1336

acidicX commented on 2024-09-10 18:26 (UTC)

@christoph.gysin the package won't build anymore:

error: the lock file /home/.../librespot-git/src/librespot/Cargo.lock needs to be updated but --locked was passed to prevent this
If you want to try to generate the lock file without accessing the network, remove the --locked flag and use --offline instead.

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.

1 2 3 4 Next › Last »