Linux Spotify client 1.x now in stable

Solved!
Reply
Highlighted
3 people liked this

Re: Linux Spotify client 1.x now in stable

Edited
Garage Band
‎2016-07-27 07:19 PM

campiador wrote:

Spotify! From June 2015 you removed the tray icon and have not yet added it back! 

The tray icon is how a lot of users prefer to control the playback, instead of switching from the current window to a giant Spotify window! 

Can you please tell me how many Linux users are you ignoring?


Out of interest: Why don't you use the MPRIS interface? The Spotify team fixed a bug and since then it's working perfectly! :D

On Gnome for example:

Bildschirmfoto von »2016-07-27 20-16-19«.png

 

Personally I think it is a good thing that the tray icon is gone, it's not the standard way of media control on the linux desktop.

 

Thank you Spotify for making such a great client for Linux, it works a lot better for me than the Android one, even on a tablet :)

Re: Linux Spotify client 1.x now in stable

Garage Band
‎2016-08-05 10:05 AM
durin wrote:

rm wrote:
Please add the "add-repository" command to the instructions in https://www.spotify.com/download/linux/. Otherwise apt-key will fail with a cumbersome error message.

sudo apt-add-repository -y "deb http://repository.spotify.com stable non-free" &&

apt-add-repository is available only on Ubuntu so that doesn't work on Debian.

 

From reading the man page for apt-add-repository my understanding is that apt-add-repository does the steps 1. and 2. from the instructions in https://www.spotify.com/download/linux/

 

The best option would be the one that Dropbox uses. It installs the key and repository in a postinst script when the downloaded .deb package is installed.

Warning: The postinst maintainerscript of the package spotify-client 
Warning: seems to use apt-key (provided by apt) without depending on gnupg or gnupg2. 
Warning: This will BREAK in the future and should be fixed by the package maintainer(s). 
Note: Check first if apt-key functionality is needed at all - it probably isn't! 
Warning: apt-key should not be used in scripts (called from postinst maintainerscript of the package spotify-client)

It looks like the repository key is now installed in the postinst script and causes these warnings in Debian

Re: Linux Spotify client 1.x now in stable

Spotify
‎2016-08-05 10:30 AM

durin wrote:
The best option would be the one that Dropbox uses. It installs the key and repository in a postinst script when the downloaded .deb package is installed.
Warning: The postinst maintainerscript of the package spotify-client 
Warning: seems to use apt-key (provided by apt) without depending on gnupg or gnupg2. 
Warning: This will BREAK in the future and should be fixed by the package maintainer(s). 
Note: Check first if apt-key functionality is needed at all - it probably isn't! 
Warning: apt-key should not be used in scripts (called from postinst maintainerscript of the package spotify-client)

It looks like the repository key is now installed in the postinst script and causes these warnings in Debian


We install apt key and repository in postinst since about a year now. The plan was to change the installation instructions to be more like for Chrome, with just a download button to the deb file, but we never did it.

 

Do you get the same warnings for Dropbox?

 

Re: Linux Spotify client 1.x now in stable

Edited
Garage Band
‎2016-08-06 11:57 AM


We install apt key and repository in postinst since about a year now. The plan was to change the installation instructions to be more like for Chrome, with just a download button to the deb file, but we never did it.

 

Do you get the same warnings for Dropbox?

 


No and not for Chrome either.

Main difference between Dropbox and Chrome vs. Spotify postinst is that Dropbox and Chrome has the key installation in a function and Spotify doesn't. But that shouldn't make a difference.

 

For Chrome the postinst script has the install_keys function but it's never called. It's called from a cron job /etc/cron.daily/google-chrome and that is called at the end of the postinst script.

On Dropbox postinst the install_key function is called but it doesn't check if the key is already in the keychain; it just adds it.

 

Other difference is that Spotify is the only one that does "apt-key list" to find out if the key is already in the keychain. Chrome does "apt-key export" on their keys to see if they are already in the keychain. I'm not sure but "apt-key list" could be the reason for the warnings.

 

And you should add postrm script to remove the key. 

Re: Linux Spotify client 1.x now in stable

Edited
Concert VIP
‎2016-08-07 12:57 AM

schuhumi wrote:

campiador wrote:

Spotify! From June 2015 you removed the tray icon and have not yet added it back! 

The tray icon is how a lot of users prefer to control the playback, instead of switching from the current window to a giant Spotify window! 

Can you please tell me how many Linux users are you ignoring?


Out of interest: Why don't you use the MPRIS interface? The Spotify team fixed a bug and since then it's working perfectly! :D

On Gnome for example:

 

Personally I think it is a good thing that the tray icon is gone, it's not the standard way of media control on the linux desktop.


https://extensions.gnome.org/extension/55/media-player-indicator/

1 person liked this

Re: Linux Spotify client 1.x now in stable

Spotify
‎2016-08-08 09:49 AM

durin wrote:


Do you get the same warnings for Dropbox?

 


No and not for Chrome either.

... 

And you should add postrm script to remove the key. 


I have to figure out how to not get warnings and fix it. Maybe adding some dependencies fixes it. Thanks for your digging.

 

I don't want to remove the key in postrm. It doesn't really hurt to leave the key and if I remove it, I have to remove the sources list row for the spotify repository, otherwise you will get even worse warnings on apt-get update. That is much harder to do without messing up. And it will be very confusing for people who for some reasons wants to reinstall and then they can't. Also, right now, there is only one package in the repository, but what if there were more than one. When should you remove the repository? When you delete one package, all packages?

 

One thing is clear. That warning is a good one. You are not really supposed to mess with apt-key on package install.

 

Re: Linux Spotify client 1.x now in stable

Garage Band
‎2016-08-13 02:25 PM
jooon wrote: 

One thing is clear. That warning is a good one. You are not really supposed to mess with apt-key on package install.

 


What if instead of calling the apt-key from the postinst script and adding the key to the /etc/apt/trusted.gpg keychain you install the key as a separate file in to /etc/apt/trusted.gpg.d/spotify.pgp

Re: Linux Spotify client 1.x now in stable

Spotify
‎2016-08-13 10:57 PM

durin wrote:
What if instead of calling the apt-key from the postinst script and adding the key to the /etc/apt/trusted.gpg keychain you install the key as a separate file in to /etc/apt/trusted.gpg.d/spotify.pgp

Sounds like a good idea. I remember I thought about doing that before, but then used apt-key directly. I don't remember however why I changed my mind.

 

Re: Linux Spotify client 1.x now in stable

Festival VIP
‎2016-08-30 05:40 PM

@jooon

Regarding packaging, have you looked at flatpak? There is already a proof of concept for setting up a repository here: https://github.com/alexlarsson/spotify-app/

 

It worked flawlessly for me on Fedora. Maybe that could at least solve some of your packaging isues since youcould then more easily target a stable set of libraries?

 

Sorry if this has been asked before, but I couldn' find a way to search this thread.

1 person liked this

Re: Linux Spotify client 1.x now in stable

Spotify
‎2016-08-30 11:27 PM

kigurai wrote:

@jooon

Regarding packaging, have you looked at flatpak? There is already a proof of concept for setting up a repository here: https://github.com/alexlarsson/spotify-app/

 

It worked flawlessly for me on Fedora. Maybe that could at least solve some of your packaging isues since youcould then more easily target a stable set of libraries?

 

Sorry if this has been asked before, but I couldn' find a way to search this thread.


I've been following flatpak itself with interest. It seems like a good option. I've only glanced at the repo above, not tried it. It will require work to integrate into our build/package pipeline and setup up a new distribution endpoint, but I definitely want to do it, when I have time.

SUGGESTED POSTS