Arch Linux User Repository

Please make sure to import the correct GPG key first:

$ curl -sS https://download.spotify.com/debian/pubkey_6224F9941A8AA6D1.gpg  | gpg --import -

And always build in a clean chroot. It is as easy as:

pacman -S devtools
git clone https://aur.archlinux.org/spotify.git
cd spotify
pkgctl build
pacman -U <path-to-spotify-package>

It is expected that the package will break now and then, as spotify continuously changes download binaries, gpg keys etc (which is not appropriate, but we cannot change this). Please be patient if an update does not occur the next day, you can still use an existing spotify install or update the version yourself.

@lightofpast Just pushed v1:1.2.20.1210-2 that now allows you to set custom launch flags in a spotify-flags.conf file under $XDG_CONFIG_HOME or ~/.config :)

Guys you must start Wm using dbus-run-session <wmname>

Got same issues as @crispy-caesus (spotify window opens but it's blank gray) for several months now :(. Arch wiki suggestion to delete ~/.cache/spotify did nothing. I'm on hyprland wayland, haven't tested on xorg.

I had issues when authenticating and almost ran out of ideas. One of my last attempts was using another browser. I set the default browser app back to Firefox, instead of Brave, and it worked! In case anyone else has problems authenticating, this might be a solution.

Getting the same error as @rearwindowtaxidr. Restarting and cleaning files won't fix it.

@rearwindowtaxidr yeah, maybe just try again, that's not a problem with the package atleast.

Depending on your setup you might need to clean up the (partially) downloaded files, idk if the server supports byte ranges.

When downloading deb from repository.spotify.com, cURL outputs an error and stops. curl: (18) transfer closed with 71965275 bytes remaining to read Is this because Spotify's servers are poor?

@gromit, I've restarted yes, I've had this problem for 2 days now (I've installed it from flatpak but I'd prefer AUR if possible)

I tried deleting the cache now, though nothing changed.

I run Wayland usually, though it doesn't work either when I try it on Xorg

Where would I ask in the forums exactly, sorry I'm new to this

@crispy-caesus, did you restart in the meantime?

Also the output you mentioned is talked about here: https://wiki.archlinux.org/title/Spotify#/usr/lib/libcurl-gnutls.so.4_error

Although in my experience this should not be a hard error 🤔

Do you run under X or Wayland? Maybe others can help you in the forums or on IRC :)

On spotify 1:1.2.31.1205-2 I can't seem to start the app, this also applies to the spotify-launcher

[crispy@bob ~]$ spotify /opt/spotify/spotify: /usr/lib/libcurl-gnutls.so.4: no version information available (required by /opt/spotify/spotify) /opt/spotify/spotify: /usr/lib/libcurl-gnutls.so.4: no version information available (required by /opt/spotify/spotify) /opt/spotify/spotify: /usr/lib/libcurl-gnutls.so.4: no version information available (required by /opt/spotify/spotify) [crispy@bob ~]$

is what I keep getting, also upon reinstalling and a few other things like emptying my config

@agowa Thanks for your detailed input on the matter.
Your proposal is interesting but I'm not convinced it's the way to go though (as you kinda said yourself).

While the information you gave may be valuable security wise I don't think such workflow would be expected:

First of all, while it may not be convenient in Spotify's specific case (since they tend to change the signing GPG key often, even between two releases), I don't think having a "self-updating" PKGBUILD on that front would be expected. I assume such a change should be acknowledged, verified and edited properly by the package maintainers themself, as it's supposed to be for pkgver or checksums changes for instance (with the exception of -git packages by their nature, obviously). Additionally, having it automatically importing the key in user's local keyring would be even less expected ('# Maybe even:' part in your proposal). For what it's worth, such mechanism has been implemented in this package once but was quickly reverted due to it being objectively wrong.

Moreover, I think it's important to keep the PKGBUILD as clear and as intelligible as possible, not only for its maintenance but also for trust reasons. In my opinion, it is more trustworthy to have the PKGBUILD clearly stating what key it is expecting (whether it is correct/up-to-date or not) than having to actually launch a build against the said PKGBUILD to get the information (since with such an auto-updating mechanism, you cannot guarantee that the key noted in the validpgpkeys array is indeed the one returned by the validpgpkeys=() function, until you actually run it yourself). It may be convenient but it just makes getting the actual information harder in my opinion.

Lastly, I think it is to important to remind that AUR packages are not officially supported (as community maintained packages). This is to say that implementing such mechanism that "we'd never do under normal circumstances" is probably not expected at the package level for the above reasons; but such useful information as the ones you provided should, in my opinion, be directed to users instead so they get more input to verify the trustworthiness of the package before building/installing it on their system (as everyone is expected to do when it comes to the AUR).

Once again, this is just my opinion. Don't hesitate to challenge me :)