[Linux] Fedora RPM package for F17-F19

[leamas]

Current method to install the spotify rpm is based on the rpmfusion lpf-spotify-client package. Basically, this automates the process of downloading, building and installing a spotity rpm based on the official Debian packages.

EDIT: Bug reported (page 19), temporary work-around published.

EDIT: New solution based on the rpmfusion lpf-spotify-client package. Old  method deprecated but still available.

EDIT: updated for new upstream release: 0.9.4.183.g644e24e.428-2

EDIT: Solution updated for 0.9.1.55.

EDIT: Downgrading procedure to 0.8.4 published

EDIT: Update header to include F19

EDIT: Solution updated for 0.9.0.133

EDIT: updating link

EDIT: new solution for 0.8.8 published.

[leamas]

Oops... I appreciate that you want to be helpful, but according to this thread we (you or I) cannot redistribute the RPM:s - that's why I posted instructions instead of submitting them to rpmfusion (if you read the complete thread you will find the rpmfusion review request).

For the sake of the relations with Spotify I kindly ask you to withdraw these links until the license conditions are clarified to allow re-distribution.

[patchon]

Ah, yes maybe I was a bit quick. 

It's a shame though, and I really hope that this gets sorted out soon.

Some people are not that comfortable with the terminal, even less so with building rpms. 

Anyway, rpms removed and updated blogpost about it.

[ivnmad]

I presume this should be reported somewhere else, but I don't know if it is a general problem or a problem with my installation on my specific platform (Fedora 18).. After using 0.8.8 for a few weeks, I've noticed the following problems:

- error when booting system (not always) and error when closing the application;

- small gaps between mixed songs, even if "gapless playback" is selected in the preferences;

- application crashes when trying to drag and drop an album or song into a playlist.

Apart from that, the application is usable.

I had none of the above problems when using 0.8.4.

I'll try to reinstall 0.8.4 and see what happens.

Fedora 18 x86_64

[leamas]

FIrst of all: thanks for reporting!

I have also an error (segmentation fault, SIGSEGV) when closing spotify. I doesn't seem to affect the app, and I frankly doubt if other users have cared to report. But it's certainly a problem.

If there is a boot error we need more info to sort out the failing component. What fails, when and how?

The small gaps between songs... I suggest that you report that as a new topic or in the general 0.8.8 announcement thread. Until someone on another platform says it isn't problem there I guess this isn't Fedora-specific(?)

The DnD bug has been acknowledged by parbo, in the 0.8.8 announcement IIRC.

God, I hate there isn't a descent bugtracker. A discussion board is good, but it's not a tracker. We repeat ourselves, don't find the bugs, all is a mess (not blaming you, for sure 🙂 )  And no bug is ever closed.

EDIT: Add a  "thanks"

[ivnmad]

OK, played it with a bit (uninstalled, canceled profile, reinstalled, etc.)..

All good apart from the 2 known problems ((segmentation fault, SIGSEGV when closing spotify. + DnD)..

I should have done that first, before posting..

Anyway, thank you.. and you are right: a bugtraker would be a good thing..

[smuskiew]

Hello,

First off, thanks for making the RPM spec available!  I was previously running 0.8.4 on Fedora 17 successfully.

Last week I decided to upgrade to Fedora 18 and after that realized I need to update my spotify client as 0.8.4 no longer worked.

Followed your steps for building 0.8.8 and everything went fine, RPM built and installed successfully.

However when I go to run it, now I'm getting a "Failed loading skin" dialog, along with the following on the console:

17:36:12.952 I [breakpad.cpp:106 ] Registered Breakpad for product: spotify

17:36:12.954 I [translate.cpp:133 ] Reloading language file
17:36:12.954 E [resource_loader.cpp:226 ] Loading of skin file(msgid.pob) failed
17:36:12.955 E [translate.cpp:110 ] Spotify resources and binary are out-of-sync. This should never happen.
17:36:12.955 I [breakpad.cpp:259 ] Searching for crashdumps: /home/steve/.cache/spotify/*.dmp

17:36:12.986 E [resource_loader.cpp:226 ] Loading of skin file(skin.xml) failed

Since I had run the older Spotify, I thought it might be my config/cache files so I removed $HOME/.config/spotify and $HOME/.cache/spotify.  Still no joy (same error).

I've done multiple Google searches and although there are some hits on the "Failed loading skin", they all appear to be related to the Windows or Mac clients.

Also looks like in the 0.8.4 to 0.8.8 there has been a change in how things are packaged so the skin.xml file is no longer separately provided in the install (part of the resources.zip file now?)

Anyone have any ideas as to what might be causing the error?  I'm pulling my hair out on this one...

thanks!

steve

[leamas]

As you have noted, it's not that F18 is broken per se. It's something special with your system...

I notice this line:

17:36:12.955 E [translate.cpp:110 ] Spotify resources and binary are out-of-sync. This should never happen

Never seen that one... Is it that you failed to remove the old package, now having a mix of new + old? Any difference if you nuke all spotify dirs on your machine and then  reinstalls?

[smuskiew]

It's possible given that I didn't remove the spotify 0.8.4 package before I upgraded Fedora.

Here's what I just tried:

Removed spotify-client 0.8.8 RPM.  Checked to be sure that /usr/lib64/spotify-client and /usr/share/spotify-client directories were gone (they were).  Checked that the old /usr/share/spotify directory from the 0.8.4 client was also gone (it was).

Wiped $HOME/.cache/spotify and $HOME/.config/spotify again.

Reinstalled the spotify-client 0.8.8 RPM and retried.  Still the same problem.

I also did some poking around in the gconf editor just in case it was possibly some kind of GNOME-related setting.  I couldn't find any keys or values with "spotify" in them.

If I have a chance later I will probably try creating a new UNIX user account and testing on that, maybe it's some other obscure setting somewhere in my $HOME account.

Thanks for the advice!

[smuskiew]

OK so I tried creating a new user on my Fedora 18 box and running spotify there and got the exact same error.

So it sounds like it's something related to having done an upgrade from F17 to F18 and/or from spotify 0.8.4 to 0.8.8.

I did try running an "strace /usr/lib64/spotify-client/spotify" and did see something odd.   Right before the error, it looks like it's trying to read resources.zip, but the path to the spotify client directory has "K\240" in the path name.  See the bold line below from the strace output:

clone(child_stack=0x7fd8fa1b7cb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGH
AND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEA
RTID, parent_tidptr=0x7fd8fa1b89d0, tls=0x7fd8fa1b8700, child_tidptr=0x7fd8fa1b8
9d0) = 26137
open("/home/steve/.config/spotify/prefs", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/home/steve/.config/spotify/settings", O_RDONLY) = -1 ENOENT (No such file
or directory)
readlink("/proc/self/exe", "/usr/lib64/spotify-client/spotif"..., 4095) = 33
access("/usr/lib64/spotify-client/spotifyK\240/Data/resources.zip", F_OK) = -1 ENOENT (No such file or directory)
gettimeofday({1359549198, 902229}, NULL) = 0
write(2, "12:33:18.902 I [translate.cpp:13"..., 7412:33:18.902 I [translate.cpp:133 ] Reloading language file
) = 74
readlink("/proc/self/exe", "/usr/lib64/spotify-client/spotif"..., 4095) = 33
open("/usr/lib64/spotify-client/msgid.pob", O_RDONLY) = -1 ENOENT (No such file or directory)

gettimeofday({1359549198, 902916}, NULL) = 0
write(2, "12:33:18.902 E [resource_loader."..., 8912:33:18.902 E [resource_loader.cpp:226 ] Loading of skin file(msgid.pob) failed
) = 89
gettimeofday({1359549198, 903167}, NULL) = 0
write(2, "12:33:18.903 E [translate.cpp:11"..., 12212:33:18.903 E [translate.cpp:110 ] Spotify resources and binary are out-of-sync. This should never happen.
) = 122
gettimeofday({1359549198, 903424}, NULL) = 0
write(2, "12:33:18.903 I [breakpad.cpp:259"..., 11012:33:18.903 I [breakpad.cpp:259 ] Searching for crashdumps: /home/steve/.cache/spotify/*.dmp

) = 110
openat(AT_FDCWD, "/home/steve/.cache/spotify", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 17
getdents(17, /* 3 entries */, 32768) = 80

getdents(17, /* 0 entries */, 32768) = 0
madvise(0x33f0000, 212992, MADV_DONTNEED) = 0
close(17) = 0
clock_gettime(CLOCK_MONOTONIC, {158960, 655045320}) = 0
sendmsg(14, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\30\0\0\0\3\0\0\0\200\0\0\0\
1\1o\0\25\0\0\0/org/fre"..., 144}, {"\16\0\0\0com.spotify.qt\0\0\4\0\0\0", 24}],
msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 168
clock_gettime(CLOCK_MONOTONIC, {158960, 655351772}) = 0
poll([{fd=14, events=POLLIN}], 1, 25000) = 1 ([{fd=14, revents=POLLIN}])
recvmsg(14, {msg_name(0)=NULL, msg_iov(1)=[{"l\4\1\1\23\0\0\0\5\0\0\0\215\0\0\0\
1\1o\0\25\0\0\0/org/fre"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXE
C}, MSG_CMSG_CLOEXEC) = 263
recvmsg(14, 0x7fff2fd1e4d0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily
unavailable)
mkdir("/home", 0755) = -1 EEXIST (File exists)
mkdir("/home/steve", 0755) = -1 EEXIST (File exists)
mkdir("/home/steve/.cache", 0755) = -1 EEXIST (File exists)
mkdir("/home/steve/.cache/spotify", 0755) = -1 EEXIST (File exists)
mkdir("/home/steve/.cache/spotify/Storage", 0755) = -1 EEXIST (File exists)
open("/home/steve/.cache/spotify/Storage/index.dat", O_RDWR|O_CREAT, 0664) = 17
fcntl(17, F_SETFD, FD_CLOEXEC) = 0

read(17, "\21o4\324\246\3205\213<\367i\242Y\251\353\313\\\367o\327\222\275i\301\1\3040:1cfS"..., 512) = 512
statfs("/home/steve/.cache/spotify/Storage/", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=5160607, f_bfree=4775669, f_bavail=4513525, f_files=1310720, f_ffree=1299784, f_fsid={-262966150, -1025249807}, f_namelen=255, f_frsize=4096}) = 0
stat("/home/steve/.cache/spotify/Storage/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
write(16, "\0", 1) = 1
clock_gettime(CLOCK_MONOTONIC, {158960, 658113463}) = 0
open("/home/steve/.config/spotify/watchdog.bnk", O_RDONLY) = -1 ENOENT (No such file or directory)
clock_gettime(CLOCK_MONOTONIC, {158960, 658435837}) = 0
clock_gettime(CLOCK_MONOTONIC, {158960, 658528024}) = 0
access("/home/steve/.config/spotify/running", F_OK) = 0
open("/home/steve/.config/spotify/running", O_WRONLY|O_CREAT|O_TRUNC, 0664) = 18
fcntl(18, F_SETFD, FD_CLOEXEC) = 0
close(18) = 0
brk(0) = 0x3424000
brk(0) = 0x3424000
brk(0x3524000) = 0x3524000

madvise(0x3421000, 1060864, MADV_DONTNEED) = 0
--- SIGPROF {si_signo=SIGPROF, si_code=SI_KERNEL} ---
readlink("/proc/self/exe", "/usr/lib64/spotify-client/spotif"..., 4095) = 33
open("/usr/lib64/spotify-client/skin.xml", O_RDONLY) = -1 ENOENT (No such file or directory)
gettimeofday({1359549198, 912322}, NULL) = 0
write(2, "12:33:18.912 E [resource_loader."..., 8812:33:18.912 E [resource_loader.cpp:226 ] Loading of skin file(skin.xml) failed
) = 88
write(4, "\1\0\0\0\0\0\0\0", 😎 = 8

Sorta looks like it fails to read the resources.zip (because of the weird/wrong path) and then tries to fall back on reading the skin.xml file (which of course isn't there)?

I'm stumped as to why it uses /usr/lib64/spotify-client/spotifyK\240/Data/resources.zip when it looks like every other line of the strace output where it accesses the spotify install directory is using the correct path (/usr/lib64/spotify-client)

If anyone has any suggestions of what I could try next, please let me know.  Thanks!

[smuskiew]

Update, just tried your spotify installer from https://github.com/leamas/spotify-make and it's running great.

So it's definitely something bizarre with the RPM packaging and/or Fedora upgrade.  If there's anything helpful I can do to try to debug further let me know, otherwise I'll just stick with the separate installer for now!

[leamas]

When you used the installer, did you use the "user install" option? I guess you did. In this case, your system-wide directories are somehow broken, whereas you personal directories used by "user install" should be OK.

I still think you have parts of the old installation left which are affecting the new; the error message is pretty clear.  But it's hard to tell what it is. If you ever get access to another Fedora box I'm certain that you will have the same experience as the other 8 or so success stories on F18 in this thread.  But that's not much of a help, I know.

One thing you could do is to run (in the installer dir)

# rm -rf  /usr/share/spotify-client  /usr/lib64/spotify-client /usr/share/spotify /usr/lib64/spotify 
$ ./configure --prefix=/usr --libdir=/usr/lib64
# make install
# make register
$ /usr/bin/spotify

 This is basiclally the same thing as the rpm does, but with a little more control. After that, you should have a fresh installation in /usr/share/spotify-client and /usr/lib64/spotify-client and it should work. It will not affect the personal installation you did earlier.

Look carefully for error messages when running ./configure!

Have you installed any symlinks in /usr/lib64 when using the previous rpm? if so, remove them!

[smuskiew]

Yes, I originally did a user install.

To test out, I just did as you suggested and used the installer with prefix=/usr and libdir=/usr/lib64.  That also gives the same "out-of-sync" error as the RPM install was giving. 

But then if I run the install to /usr/local (./configure with no options), then Spotify works fine!

Something about /usr and/or /usr/lib64 that is not making it happy but I'm stumped as to what it could be!

It's really bizarre, I have checked /usr/lib64 and /usr/share for spotify "remnants" and found nothing.  All the symlinks that I had created to make 0.8.4 work have been removed (and I did run "ldconfig" to refresh the cache afterward).  There is nothing with "spotify" in the name when I do a "find" on the /usr directory.

[leamas]

Bizarre is the word. But the basic conclusion seems to be that this not about what's  installed, but where.

A hint might be that the new version has a $ORIGIN rpath. It means that it loads it's libraries from the same directory as the binary is in (falling back to ld.so's other paths if not found there). So, when installing in /usr/local/ it will prefer the libs in /usr/local/lib/spotify-client to the libs in /usr/lib64. Same is true for a personal install.

If this is the problem, it should be visible in the ldd output from the different cases. But that requires some serious grepping, I guess. But this seems like a hard problem...

[user-removed]

I'm not wanting to be an ass or anything, but I could not care less about any licensing at this point. As someone that does not want to have to build an RPM themselves, i'd rather it already be done and working so I don't screw something up. I don't think anyone really cares at all. I'm paying 10 bucks a month for this, so it's not like I'm stealing work.

[leamas]

As for the licensing issues, these are basically between you and Spotify. They are capable of explaning their position on this, as done in several threads recently (look in the sticky threads on top of  this page.)

That said, I don't think you should have any worries about rolling your own RPM using these instructions. In this 6-page thread noone have so far reported any problems building the RPMs. On the other hand, if you download RPM:s from some  place out there there is always a risk that someone uses these RPM:s to install trojans or worse. Remember, when installing RPM:s you are acting as root, without safety nets.

Actually, the only safe way is the user-mode install described in this thread. Using that, everything is installed and run by a regular user without using root permissions at all. As long as you trust Spotify not to deliver trojans (I certainly do that) you are also safe when building your own RPM:s as described here.

-alec

[LowBrassRage]

Hey!

First of all, great guide. Built the RPM with no problem. Installed it with no issue, but spotify won't run without root. I used chown to change the /etc/share/spotify-client so that my regular user is the owner, but no dice. Here is what is output when I run Spotify without root: 

Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
ICE default IO error handler doing an exit(), pid = 23288, errno = 0

Any idea how to make it so I can launch it from a regular user?

Edit: I also tried the scripts you so thoughtfully provided on github, but I had the same problem. Still need root permissions to run. 

[leamas · Accepted solution]

Simply speaking I haven't the faintest idea of what you are hitting... Some basic questions:

• What are you running on (F17, F18..., i386/x86_64)?
• Can you run other players such as rhythmbox and vlc?
• Is your user member of the 'audio' group?

EDIT: Also, after running as root you might run into problems with the ~/.cache/spotify and ~/.config/spotify directories. Remove them (as root) before running as regular user.

[LowBrassRage]

Oops. I suppose I should have added more info at the beginning, huh?

• Anywho, I am running F18 x86_64. 
• Yes, I can run other players. Rhythmbox and vlc. 
•  Audio group?

D'oh. That was it. I added my user to the audio group, restarted, and everything is running brilliantly! Thank you very much! 

Interesting note: The application shows up as "My Spotify", so I can't tell how much of this is thanks to the script on your Github and how much is due to the RPM that I built.

[leamas]

"My Spotify" is what the  github script installed. The Rpm should show up as Spotify, but there might be a bug (feature?) which makes the github installation "mask" the rpm one. Anyway, if you run 'my-spotify' on the command line it will invoke the "github" version whereas 'spotify" will run the RPM one.

That it works is fine. It would be even better to know what's working :). I suggest that you uninstall the github version and reinstall the rpm, just to get a defined state. The mechanics:

$ cd ~/.local/share/spotify-client
$ make uninstall
# yum reinstall ~/rpmbuild/RPMS/x86_64/spotify-client*

 Having a clean rpm installation like this wil make upgrades much easier

Hm... it might make sense to check this audio group membership in the launcher on Fedora... might fix that.

EDIT: ~/local -> ~/.local,  ~/.rpmbuild -> ~/rpmbuild  😉

[leamas]

Just trying to tag this thread as a LInux one. Seems to require a new reply (?)