Debian 9, higher versions dependencies

[xanvader]

Sorry for my English…

Debian 9 Stretch now has higher dependencies than Spotify needs. Version libssl1.0.2 is installed, Spotify wants version libssl1.0.0. Libavcodec57 is installed, but libavcodec54 is still required. Additional dependencies were not displayed when the installation was attempted.

Is it possible to expect an early remedy?

[andr3wyong]

ALAC playback and sync to portable devices is broken for me (too) on Debian 9 because of the incompatible (newer) libavcodec57.

[xanvader]

Does one answer here? I pay for my product (Spotify) and no one logs in or provides a newer version? Performance = consideration

[jooon]

I sometimes answer in these forums. That's about it. The regular customer service will not and does not know the answer to most of the linux questions, because linux desktop client is not a supported client.

libssl1.0.0 is the supported package in Ubuntu 16.04 LTS which is the current target desktop environment, not Debian 9, but they are very similar, except for this package. Ubuntu 16.04 LTS is the target, mostly because there is so little development time spent on the linux client.

There are a few different options available, but very little progress is spent on them.

The simple open source solution would be to have one binary per distribution, linking to that distribution's version of the package. That won't happen.

Another solution would be to start using libssl1.0.2 and stop using libssl1.0.0. A transition like that has happened before (between libssl0.9.8 and libssl1.0.0). That was also painful. It would mean to drop support for 16.04LTS. That probably won't happen.

A not so simple solution would be to dynamically open libssl1.0.2 or libssl1.0.0 depending on what is available. This could happen.

Another solution would be to use a container technology like snap/flatpak where a security supported version of a libssl version is included. That would mean people would have to stop using the debian package and start using that release instead. This could also happen.

Another solution would be to drop the feature that libssl is used for (communicating with embedded playbuttons on the web) and then stop depending on the library. Will probably also not happen.

[andr3wyong]

LibSSL is relatively easy to work around (it’s just a package that generally works in newer Debian versions).

It’s libav that is really difficult to get all dependencies for since it consists of a large number of other packages that have to be present for Spotify to function fully.

[jooon]

Yes. libav* libraries are in a similar situation.

There is code in the client to dynamically load the latest version of libavcodec and libavformat that is installed on the system. However, there was a problem in that loading code which made the client misbehave or crash when loading anything newer than libavcodec54, so newer versions were disabled until we would have time to fix it.

[user-removed]

Here is a quick guide for those looking for a solution on Debian 9.

https://wiki.debian.org/spotify

[Abyssos113]

This Work for me

https://www.comoinstalarlinux.com/instalar-spotify-debian-9-stretch/

[venomvjhvbhjbhb]

This one worked for me too! Thank you so much! 🙂

[Diegote]

Hi, I have a problem when I try to update,

#apt update
Ign:1 http://dl.google.com/linux/chrome/deb stable InRelease
Obj:2 http://dl.google.com/linux/chrome/deb stable Release 
Obj:4 http://security.debian.org/debian-security stretch/updates InRelease 
Ign:5 http://cdn-fastly.deb.debian.org/debian stretch InRelease 
Obj:6 http://cdn-fastly.deb.debian.org/debian stretch-updates InRelease
Obj:7 http://cdn-fastly.deb.debian.org/debian stretch Release 
Des:9 http://repository.spotify.com stable InRelease [1.155 B]
Err:9 http://repository.spotify.com stable InRelease
 El fichero firmado en claro no es válido, «NOSPLIT» obtenido (¿la red requiere autenticación?)

Does anyone know what this error is about? 

Thanks!

[somnophobe]

@Diegote - google translate gives me this: `The signed file in clear is not valid, "NOSPLIT" obtained (does the network require authentication?)`

which tells me you probably need to update the keys you have from spotify, because what you have isn't what they're signing with.  Try just re-running the first command from the linux installation notes

also please start a new thread for a new issue, instead of adding on to an existing one next time.

[kakarotoreis]

# Debian Stretch Spotify
1. Instale os pacotes libssl1.0.0 e dirmngr:
$ wget http://ftp.br.debian.org/debian/pool/main/o/openssl/libssl1.0.0_1.0.1t-1+deb8u6_amd64.deb
$ sudo apt install gdebi dirmngr
$ sudo gdebi libssl1.0.0_1.0.1t-1+deb8u6_amd64.deb
2. Instale a chave de autenticação:
$ sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys BBEBDCB318AD50EC6865090613B00F1FD2C19886 0DF731E45CE24F27EEEB1450EFDC8610341D9410
3. Adicione o repositório do Spotify:
$ echo deb http://repository.spotify.com stable non-free | sudo tee /etc/apt/sources.list.d/spotify.list
4. Instale o Spotify:
$ sudo apt update && sudo apt install spotify-client

[jooon]

---

@jooon wrote:

A not so simple solution would be to dynamically open libssl1.0.2 or libssl1.0.0 depending on what is available. This could happen.

Another solution would be to drop the feature that libssl is used for (communicating with embedded playbuttons on the web) and then stop depending on the library. Will probably also not happen. 

---

Both of these happened, sort of. We stopped using the TLS parts of libssl.so for communicating with the embedded playbuttons on the web a few versions ago. However, we were still using libcrypto.so from the same debian package from other things. However, suddenly dynamically open different version of the library became a simple solution which was implemented.

Spotify 1.0.69 in the testing repository now (soon stable) can dynamically load different version of libcrypto.so (from the libssl* packages).