Created attachment 278195 [details] media-sound/spotify ebuild for 0.5.1.151 Hi, Using http://volatileint.blogspot.com/2011/01/native-spotify-ebuild-for-gentoo.html 's ebuild, with the suggestions from the forum's thread http://forums.gentoo.org/viewtopic-t-836310.html?sid=5fbd45737e902202b805dbc73d5a7eee, attached is an ebuild for spotify-0.5.1.151, with a use flag for pulseaudio (it works here without pulseaudio).
Created attachment 281087 [details] updated ebuild to version 0.5.2.84
i updated the ebuild previously posted to reflect the most recent version they have in their public repository. seems to work fine for me so far on ~amd64
Spotify builds fine on my system (~amd64), but I am unable to log in. I receive the error, "Use of this device is not enabled for your account" (and in the console I see "Unable to login offline: no such user"). Do I need to have some sort of premium account? I am able to log in without any problems using wine with the Windows version.
Yes, you need a paid account. Spotify's website clearly states this...
I couldn't find where it says that I cannot use it with the free account, but have confirmed that it compiles on ~amd64.
I have a premium account and got a chance to try this today. Working great (amd64), thanks for the ebuild!
Created attachment 288107 [details] spotify-0.6.1.309.ebuild New version Notes: 1) This version requires the library-only 0.9.8 slot of OpenSSL 2) The GNOME support .deb hasn't been updated - I assume the old one still works as it's still on the server, but I haven't tested it as I don't use GNOME
I think you can remove the gnome-support since Spotify states this is broken and will be removed in the future: http://getsatisfaction.com/spotify/topics/since_last_update_spotify_for_linux_crashes_after_a_few_seconds-y5e80#reply_6719913
Created attachment 289853 [details] spotify-0.6.2.291 ebuild Version bumped to 0.6.2.291, gnome support removed (deprecated by upstream)
Unfortunately both this new version and the previous one now crash for me immediately on start-up. It appears to be because Spotify itself is linked against OpenSSL 0.9.8, but Qt uses the latest version: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff3bc117c in ?? () from /usr/lib64/libcrypto.so.0.9.8 (gdb) bt #0 0x00007ffff3bc117c in ?? () from /usr/lib64/libcrypto.so.0.9.8 #1 0x00007ffff3bbd097 in X509_verify_cert () from /usr/lib64/libcrypto.so.0.9.8 ^^^^^ #2 0x00007fffe462c798 in ssl_verify_cert_chain () from /usr/lib64/libssl.so.1.0.0 ^^^^^ #3 0x00007fffe4610e63 in ssl3_get_server_certificate () from /usr/lib64/libssl.so.1.0.0 #4 0x00007fffe4612315 in ssl3_connect () from /usr/lib64/libssl.so.1.0.0 #5 0x00007ffff4a830dc in ?? () from /usr/lib64/qt4/libQtNetwork.so.4 I think the reason why it's started happening now is that it's trying to display a ToS update - just before it crashes, it displays the sort of embedded window that it pops up when this happens. Anyone know a way around this? (It might be possible to modify the local configuration to make it think the update has already been accepted, but that's obviously not really a solution....)
(And of course Bugzilla mangled the backtrace... the ^^^^^s were supposed to be highlighting the mismatched .so versions.)
Spotify lies to you. It does NOT *depend* on openssl-0.9.8 even though it *links* to these library names. It depends on openssl-1.0 though and expects "compatibility" symlinks from 0.9.8 to 1.0.0. I think that's the ugly thing they do on Debian. Attached is an ebuild that actually works on x86 and amd64.
Created attachment 293087 [details] spotify-0.6.2.291.ebuild Creates the fake symlinks for old openssl.
(In reply to comment #12) > Spotify lies to you. It does NOT *depend* on openssl-0.9.8 even though it > *links* to these library names. It depends on openssl-1.0 though and expects > "compatibility" symlinks from 0.9.8 to 1.0.0. I think that's the ugly thing > they do on Debian. Attached is an ebuild that actually works on x86 and amd64. There's no such thing as a "compatibility" symlink between two libraries that have different ABIs, and if there was it wouldn't be the Spotify ebuild's business to create them. If this works for Spotify then it's because the particular functions it uses happened not to change ABI, in which case (as I've seen suggested elsewhere) modifying the binary to specify the new SONAMEs would be better (although still hacky of course). And it certainly doesn't make sense to say that it depends on OpenSSL 1.0.0 - if it was built and linked against 0.9.8 then it works with 0.9.8, and if it happens to work with 1.0.0 as well after performing the appropriate workarounds then that's just a bonus.
I know the two openssl versions have a different ABI. That's why it crashes with 0.9.8. God knows on what kind of system that binary was linked. But if that system had symlinks from 0.9.8 pointing to 1.0, it would produce this (broken) binary, right? > modifying the binary to specify the new SONAMEs would > be better (although still hacky of course). I totally agree. But I have no idea how to do that. It's not exactly the sort thing anyone should be doing every day. I'd be glad for helpful ideas.
(In reply to comment #15) > I know the two openssl versions have a different ABI. That's why it crashes > with 0.9.8. If you mean the crash that I was seeing, I think that's because Qt's linked to OpenSSL 1.0.0, so both versions get loaded into the same process and that confuses things. I'm pretty sure it would work fine on a plain 0.9.8 system. > > modifying the binary to specify the new SONAMEs would > > be better (although still hacky of course). > > I totally agree. But I have no idea how to do that. It's not exactly the sort > thing anyone should be doing every day. I'd be glad for helpful ideas. I'd previously just edited the binary with vim (and it seems to work so far), but for doing it in the ebuild, sed appears to manage OK: sed -i -e 's/\(lib\(ssl\|crypto\).so\).0.9.8/\1.1.0.0/g' spotify I checked the OpenSSL headers for 0.9.8 and 1.0.0 for the functions that Spotify uses, and it does seem as though none of them changed signature in any significant way (other than const changes and the like). I didn't check deeply into the maze of structs that OpenSSL uses, so it's possible that if Spotify accesses any struct members directly it could cause problems, but like I said it does seem to work in practice. There is also the potential for future versions of Spotify to start using functions that have changed, so an official fix from upstream would still be preferable, but this should do for now.
(In reply to comment #16) > If you mean the crash that I was seeing, I think that's because Qt's linked to > OpenSSL 1.0.0, so both versions get loaded into the same process and that > confuses things. I'm pretty sure it would work fine on a plain 0.9.8 system. Hm, I thought as they even have different names ld would load them to a different address. I can't imagine that C library loading is that much broken :-) > sed -i -e 's/\(lib\(ssl\|crypto\).so\).0.9.8/\1.1.0.0/g' spotify Fantastic. Often the simplest solution is not the worst! Attaching a new ebuild. > none of them changed signature in any > significant way (other than const changes and the like). I didn't check deeply > into the maze of structs that OpenSSL uses, so it's possible that if Spotify > accesses any struct members directly it could cause problems Whatever the reason, it's very stable. I had no crash so far. And yes, maybe we should ask upstream for a version that explicitly uses 1.0.0.
Created attachment 293279 [details] spotify-0.6.2.291.ebuild No more symlinks, patch binary instead.
Probably spotify was built on Debian, as we see the same symtoms with openssl here: http://lists.slackbuilds.org/pipermail/slackbuilds-users/2011-November/008330.html
Created attachment 294349 [details] spotify-0.6.2.291.ebuild This ebuild also kills the openssl version information from Debian from the ELF. Requires the openssl-ver.bpatch in files.
Created attachment 294351 [details] openssl-ver.bpatch binary patch (for bspatch) that removes the openssl version info from the ELF.
If anybody is interested how the binary patch was created, here is the utility that I wrote to remove the versioning information: http://www.odi.ch/weblog/posting.php?posting=645
Created attachment 294363 [details] openssl-ver.bpatch
Created attachment 294993 [details] openssl-ver-amd64.bpatch renamed because is arch specific
Created attachment 294995 [details] openssl-ver-x86.bpatch x86 binary patch
Created attachment 294997 [details] spotify-0.6.2.291.ebuild fixed: use separate binary patch for x86
The new Ebuild downloaded both amd64 and x86 binaries for me (running ~amd64). Perhaps only one is enough? =)
Created attachment 300099 [details] spotify-0.6.6.10.ebuild Version bump
Created attachment 300125 [details] spotify-0.6.6.10.ebuild with bin patch version bump
Created attachment 300127 [details] spotify-0.6.6.10-openssl-ver-amd64.bpatch
Created attachment 300129 [details] spotify-0.6.6.10-openssl-ver-x86.bpatch
Created attachment 300131 [details] spotify-0.6.6.10-openssl-ver-amd64.bpatch
Thanks! Works perfectly. Perhaps it should depend on pulseaudio since it seems to be needed? It did not work for me without pulseaudio.
Created attachment 300509 [details] spotify-0.6.6.10.ebuild with bin patch added pulseaudio USE flag
(In reply to comment #33) > Thanks! Works perfectly. Perhaps it should depend on pulseaudio since it seems > to be needed? It did not work for me without pulseaudio. Strange, on all machines I tested, it works without pulseaudio. I've never used pulseaudio. Added it to the ebuild for your convenience the same way as in KaZeR's.
I don't think Spotify has a direct dependency towards PulseAudio either. According to their repository (http://repository.spotify.com/dists/stable/non-free/binary-amd64/): Package: spotify-client-gnome-support Priority: extra Section: gnome Installed-Size: 44 Maintainer: Spotify <libspotify@spotify.com> Architecture: all Source: spotify Version: 1:0.5.2.84.g6d797eb-1 Depends: gconf2 (>= 2.12), spotify-client-qt (= 1:0.5.2.84.g6d797eb-1) Filename: pool/non-free/s/spotify/spotify-client-gnome-support_0.5.2.84.g6d797eb-1_all.deb Size: 2402 MD5sum: 36db1cd30b76d015d5799a400cb90fef SHA1: fc2e77e1e21153a0cd554ac148c11aa5aa609ce0 SHA256: 78d6952749543199887c3f521217a4ce8e1e915e2b85fa35001fa406ef94b7ee Description: Spotify desktop gnome support Package: spotify-client-qt Priority: extra Section: sound Installed-Size: 18340 Maintainer: Spotify <libspotify@spotify.com> Architecture: amd64 Source: spotify Version: 1:0.6.6.10.gbd39032.58-1 Depends: libasound2 (>= 1.0.14), libc6 (>= 2.6), libqt4-dbus (>= 4.5.0), libqt4-webkit (>= 4.5.0), libqtcore4 (>= 4.5.0), libqtgui4 (>= 4.5.0), libstdc++6 (>= 4.0.0), libxss1 (>= 1:1.2.0), usbutils, libssl0.9.8 Recommends: libavcodec52, libavformat52 Filename: pool/non-free/s/spotify/spotify-client-qt_0.6.6.10.gbd39032.58-1_amd64.deb Size: 9448994 MD5sum: 405101c92eb0755973bd6ed4c3ebc0f4 SHA1: 711b89d85ec885f0538ae183a5fb7e875dceec6e SHA256: 8c5445bab2df988fa61e94cf7571b400d733e3526fa78826ae1e7942d96bc463 Description: Spotify desktop client And as we've discussed before, the gnome-client has been deprecated and should be removed from their release info.
Created attachment 300917 [details] spotify-0.6.6.10.ebuild with bin patch sorry, last update was the old version with the new name...
Instead of creating binary patches I'm using a similar approach to firefox-bin which is to install the spotify binary into /opt/spotify, create a wrapper script /usr/bin/spotify, and then added SEARCH_DIRS_MASK=/opt/spotify in /etc/revdep-rebuild/10spotify to avoid the false positive from revdep. This avoids having to maintain binary patches in the future. I updated the latest 0.6.6.10 spotify attached to this bug in my overlay: http://git.overlays.gentoo.org/gitweb/?p=user/jtriley.git;a=blob;f=media-sound/spotify/spotify-0.6.6.10.ebuild I replaced 'ar x', tar, etc. commands with unpack which should "do the right thing" IIRC (let me know if this isn't correct).
(In reply to comment #38) > Instead of creating binary patches I'm using a similar approach to firefox-bin > which is to install the spotify binary into /opt/spotify, create a wrapper > script /usr/bin/spotify, and then added SEARCH_DIRS_MASK=/opt/spotify in > /etc/revdep-rebuild/10spotify to avoid the false positive from revdep. This > avoids having to maintain binary patches in the future. This may or may not be viable with future versions... I tried to make an ebuild for the latest super-experimental version with apps support (https://getsatisfaction.com/spotify/topics/try_out_the_linux_apps_client_beta_preview), and while I didn't manage to get it working, one difference between it and the current version is that it links against libpng 1.2, again using symbol versioning, and this time it doesn't even start unless the symbol versions are stripped out. Of course, trying to run a binary built with 1.2 using the current 1.5 is optimistic at best, and it may well be the reason why it doesn't work at all, which could mean the only solution would be for upstream to release a version built with a newer libpng, making the symbol versioning point moot. I suppose we'll just have to see what happens....
> Of course, trying to run a binary built with 1.2 using the current 1.5 is > optimistic at best, and it may well be the reason why it doesn't work at all, > which could mean the only solution would be for upstream to release a version > built with a newer libpng, making the symbol versioning point moot. I suppose > we'll just have to see what happens.... Right, if a binary package requires a particular version then the deps for that package should require that version. Even if binary patching does work to start the app it's a major hack that's likely highly unsupported and also likely to cause the user issues during runtime which is bad. In general I think we should require the exact deps that the binary was built against and then ignore the package when running revdep-rebuild. This is what firefox-bin is doing and I think it's the right approach for most binary installs. From what I can tell the only reason the binary is being patched in the first place in these builds is to get around the revdep false positive. IMO using the SEARCH_MASK_DIRS approach is *much* cleaner/simpler for this purpose.
(In reply to comment #40) > Right, if a binary package requires a particular version then the deps for that > package should require that version. Even if binary patching does work to start > the app it's a major hack that's likely highly unsupported and also likely to > cause the user issues during runtime which is bad. The problem with that, which I already encountered with OpenSSL when I tried to install 0.9.8 for Spotify rather than hacking it to use 1.0.0, is that other libraries used by Spotify such as Qt might still require a different libpng/OpenSSL/etc version than the one Spotify's linked to. This means you get both versions loaded at the same time, and there's no guarantee that the undefined symbols in Spotify will be resolved to the same library that Spotify was originally linked against, similarly for the ones in Qt. This ends up causing segfaults when the two versions of the function aren't ABI-compatible. I think the specific situation that broke for me was that libssl.so.1.0.0 was trying to call a function in libcrypto.so.0.9.8 (or maybe the versions were the other way round) that had changed ABI. On the other hand, I /think/ that all the OpenSSL functions that the Spotify binary calls are compatible between the two OpenSSL versions, so as far as I can tell it works to force it to use OpenSSL 1.0.0. > In general I think we should require the exact deps that the binary was built > against and then ignore the package when running revdep-rebuild. This is what > firefox-bin is doing and I think it's the right approach for most binary > installs. From what I can tell the only reason the binary is being patched in > the first place in these builds is to get around the revdep false positive. IMO > using the SEARCH_MASK_DIRS approach is *much* cleaner/simpler for this purpose. The actual binary patch is just for the false-positive, but we're also using sed to change the reference to the OpenSSL libraries from the old version to the new one. It's certainly true that hacking the binary is, well, a hack, but when the "correct" alternative doesn't work there aren't many options. The only viable long-term solution would be for upstream to release a more portable build, but for people who just want to get it working, the hack seems to accomplish that, at least with the current version.
Created attachment 303565 [details] spotify-0.6.2.291.ebuild Changes: - Replaced the binary patch with the revdep-rebuild ignore file, yey! - Using unpack instead of ar/tar - Tell users to remove cache Thanks for your input!
(In reply to comment #42) > Created attachment 303565 [details] > spotify-0.6.2.291.ebuild > > Changes: > - Replaced the binary patch with the revdep-rebuild ignore file, yey! > - Using unpack instead of ar/tar > - Tell users to remove cache > > Thanks for your input! No problem :D Also should make KEYWORDS="~x86 ~amd64" since this is definitely a testing package.
Created attachment 303631 [details] [UNSTABLE] spotify-0.8.0.1031.ebuild (In reply to comment #41) > The problem with that, which I already encountered with OpenSSL when I tried > to install 0.9.8 for Spotify rather than hacking it to use 1.0.0, is that > other libraries used by Spotify such as Qt might still require a different > libpng/OpenSSL/etc version than the one Spotify's linked to. This means you > get both versions loaded at the same time, and there's no guarantee that the > undefined symbols in Spotify will be resolved to the same library that > Spotify was originally linked against, similarly for the ones in Qt. This > ends up causing segfaults when the two versions of the function aren't > ABI-compatible. It occurred to me this morning that this is exactly the sort of situation that symbol versioning ought to be able to solve in the first place. It doesn't help for OpenSSL because in Gentoo it doesn't have symbol versions at all, but libpng does, and we have a library-only slot of 1.2 precisely so that binary-only apps can use it. So I changed my ebuild attempt to use that rather than hacking it to try and use the newer library, and voila! it works fine as far as I can tell, apart from these issues (that have already been reported by several other people on other distros, so presumably upstream'll fix them in a future build): 1) It crashes if the Flash player is installed 2) Right-clicking on tracks freezes the UI after you choose an option from the menu Again, this build is even more experimental than Spotify on Linux in general, so stick with 0.6.* for now if you just want it to work, but in case anyone wants to play with it, here it is. Notable-ish ebuild differences are: a) Uses src_prepare for the SONAME hacking rather than putting it in src_unpack. A minor nit, but since the two phases exist, may as well use them b) It installs the whole /usr/share/spotify to /opt and creates a symlink, rather than just the binary. It seems silly to split the package across /opt and /usr/share, and this version includes a shared library in /usr/share/spotify which definitely doesn't belong there, so I thought I'd just move everything over c) No need for a wrapper script, just a symlink to the binary works fine d) pkg_postinst uses ewarn instead of einfo since the latter is likely to get lost in the scrollback when doing multiple updates at once (PS: the ebuild in comment 42 appears to be for an older version in the 0.6 series, not the latest?)
Created attachment 307003 [details] ebuild for the new version of spotify Hi, Here is the ebuild for the new version of spotify. I removed the phonon dependency because it's not needed with gnome (at least with my config witch use pulseaudio) and I changed the nspr version (new version is stable for x86 and amd64). Regards.
Created attachment 307005 [details] spotify-0.8.2.639.ebuild I changed the name of the attachement.
spotify-0.8.2.639.ebuild works nice and stable (x86_64). Thanks!
(In reply to comment #46) > Created attachment 307005 [details] > spotify-0.8.2.639.ebuild > > I changed the name of the attachement. I tried this, and Spotify didn't launch. It gave me the error, joonas@aluna ~ $ spotify spotify: error while loading shared libraries: libcups.so.2: cannot open shared object file: No such file or directory After emerging Cups Spotify launched and is working wonderfully now. Running stable x86 system, and I don't have a single idea why Spotify would depend on Cups, but here's what happened to me. Cheers for the wonderful ebuild by the way :).
We should really review the binary dependencies once again. I can see no reference to pulseaudio in the blob for example. However ldd shows a *really* long list of libs. Depends on both libpng-1.2 *and* -1.5 for example. And then there are libcef.so and chrome.pak which seems to be an embedded version of the Chrome web browser and itself has more deps.
Created attachment 307985 [details] spotify-0.8.2.639.ebuild (fixed deps) The ebuild has dependencies taken from ldd. Yes they are totally mad: Xau, alsa-lib and phonon all at the same time. Cups (WTF). Xdamage, Xcomposite, Xfixes, Xcursor and what not. libpng-1.2 and libpng-1.5 (sic!). I have not included mesa, as any other GL implementation should work too. Does anybody know how to require OpenGL libs generically? One more problem: portage complains on every reinstall that the symlink /usr/share/portage is in the way. How can we solve that?
Created attachment 307987 [details] spotify-0.8.2.639.ebuild (more deps)
You pointed the main source of these new dependencies. Spotify now use the embedded version of chromium (cef) in binary format. The dependency to libcups is only needed by libcef (I can't see any option to print anything in spotify) and libpng-1.2 too. Perhaps if an ebuild become available for cef, the spotify ebuild may depends on it (cef is opensource as chromium). For pulseaudio, it's an optional dependency. Spotify can use pulseaudio natively if it is available. For phonon, I made a mistake to remove it but on my system, I have x11-libs/qt-phonon installed instead of media-libs/phonon. I don't know qt but it seems there is a change in the name, media-libs/phonon ebuild stops at version 4.6.0-r1. For /usr/share/portage, I don't have this warning. Regards.
Thanks for exlanations. It would really be nice to replace the bundeled cef with a native build. But I guess that's not for the faint of heart, looking at its build system... I see that libphonon.so.4 is installed both by media-libs/phonon and x11-libs/qt-phonon [1]. So we should change this to an alternative dependency (there is no virtual for that, right?). For OpenGL we can depend on virtual/opengl. As for pulseaudio: can you point out how spotify makes use of it? I haven't found any reference to pulseaudio in spotify. [1] http://www.portagefilelist.de/site/query/file/
(In reply to comment #53) > Thanks for exlanations. It would really be nice to replace the bundeled cef > with a native build. But I guess that's not for the faint of heart, looking > at its build system... If more softwares use cef (particularly those witch are opensource !), an ebuild for cef should come soon I guess. > As for pulseaudio: can you point out how spotify makes use of it? I haven't > found any reference to pulseaudio in spotify. In the changelog, they say the pulseaudio backend has been enabled with version 0.4.8 and I reported a bug about one year ago and they solved it in version 0.5.1 (* Volume slider support when using PulseAudio.) I know spotify supports pulseaudio itself because it registers natively in pulseaudio, not through alsa:default. ldd in my config (ldd /usr/bin/spotify |grep pulse): libpulse-mainloop-glib.so.0 => /usr/lib/libpulse-mainloop-glib.so.0 (0xb1a1f000) libpulse.so.0 => /usr/lib/libpulse.so.0 (0xb19d5000) libpulsecommon-1.1.so => /usr/lib/libpulsecommon-1.1.so (0xafc31000) Regards.
(In reply to comment #50) > Created attachment 307985 [details] > spotify-0.8.2.639.ebuild (fixed deps) > > The ebuild has dependencies taken from ldd. "scanelf -n" is better for this, as ldd recursively lists all the libraries that need to be loaded, not just the ones Spotify directly links to. So if you have Qt built with an exotic option that makes it link to an obscure library, ldd would make it look like Spotify itself requires that library, even though on most people's systems it wouldn't be needed. (On the other hand, with scanelf, remember to run it on both the Spotify binary itself and libcef.so.) > One more problem: portage complains on every reinstall that the symlink > /usr/share/portage is in the way. How can we solve that? I guess you mean /usr/share/spotify - this would be because I changed it from being a directory to a symlink into /opt, as mentioned in comment 44, so upgrading from an older ebuild where it was a directory might not be so smooth. I'm not sure if there's a way for the ebuild to work around the complaint, so apologies if it's causing anyone grief. I changed this as I thought it was more consistent with how binary packages are generally handled, plus previous ebuilds had already moved the binary into /opt and it seemed silly to split it between the two locations. (In reply to comment #52) > Perhaps if an ebuild become available for cef, the spotify ebuild may > depends on it (cef is opensource as chromium). That would definitely be an improvement if it's feasible. If anyone's planning on trying this, it might be good to check that a) cef keeps ABI compatibility between releases, and b) Spotify isn't using a modified version.
Created attachment 308203 [details] spotify-0.8.2.639.ebuild (fixed deps) Rewritten deps according to scanelf, pluseaudio USE flag readded. The problem with /usr/share/spotify is only when upgrading from an earlier ebuild. Not a problem, as they have not been in the portage tree anyway.
After installing, I get the message spotify: error while loading shared libraries: libplc4.so.9: cannot open shared object file: No such file or directory data@desktop ~ $ ldd /opt/spotify/spotify | grep "not found" gives me: libplc4.so.9 => not found libnspr4.so.9 => not found Both seem to belong to dev-libs/nspr. Which version is needed here? I have 4.8.9 installed.
> Both seem to belong to dev-libs/nspr. Which version is needed here? I have > 4.8.9 installed. I will reply to myself, because my eix-information was outdated. dev-libs/nspr-4.9 should do the trick
I also had to downgrade from x11-libs/qt-webkit-4.8.1 to x11-libs/qt-webkit-4.7.4 to avoid a segfault at start.
The "spotify-0.8.2.639.ebuild (fixed deps)" works fine here, it's only missing a require >=dev-libs/nspr-4.9
Created attachment 310081 [details] spotify-0.8.2.639.ebuild require >=nspr-4.9
Created attachment 311541 [details] spotify-0.8.3.278.ebuild Bare renaming of the previous ebuild. Installed and worked clean for me.
For some reason 0.8.3.278 segfaults for me after loading lots of plugins ("bundle").
Heres a trace of it when run inside gdb, seems to be libcef/webkit. #0 0x00007ffff59f1fa6 in void std::__merge_adaptive<WebCore::CSSGradientColorStop*, long, WebCore::CSSGradientColorStop*, bool (*)(WebCore::CSSGradientColorStop const&, WebCore::CSSGradientColorStop const&)>(WebCore::CSSGradientColorStop*, WebCore::CSSGradientColorStop*, WebCore::CSSGradientColorStop*, long, long, WebCore::CSSGradientColorStop*, long, bool (*)(WebCore::CSSGradientColorStop const&, WebCore::CSSGradientColorStop const&)) () from /usr/lib64/qt4/libQtWebKit.so.4 #1 0x00007ffff0034083 in ?? () from /usr/share/spotify/libcef.so #2 0x00007ffff0034198 in ?? () from /usr/share/spotify/libcef.so #3 0x00007ffff00349ff in ?? () from /usr/share/spotify/libcef.so #4 0x00007ffff0035d42 in ?? () from /usr/share/spotify/libcef.so #5 0x00007ffff0036193 in ?? () from /usr/share/spotify/libcef.so #6 0x00007ffff0038345 in ?? () from /usr/share/spotify/libcef.so #7 0x00007ffff04d5177 in ?? () from /usr/share/spotify/libcef.so #8 0x00007ffff0420844 in ?? () from /usr/share/spotify/libcef.so #9 0x00007ffff0407e1d in ?? () from /usr/share/spotify/libcef.so #10 0x00007ffff040b43e in ?? () from /usr/share/spotify/libcef.so #11 0x00007ffff0413aa3 in ?? () from /usr/share/spotify/libcef.so #12 0x00007ffff03f0109 in ?? () from /usr/share/spotify/libcef.so #13 0x00007ffff03d2c9b in ?? () from /usr/share/spotify/libcef.so #14 0x00007ffff045f304 in ?? () from /usr/share/spotify/libcef.so #15 0x00007ffff0460246 in ?? () from /usr/share/spotify/libcef.so #16 0x00007ffff045ee4b in ?? () from /usr/share/spotify/libcef.so #17 0x00007ffff0460246 in ?? () from /usr/share/spotify/libcef.so #18 0x00007ffff045ee4b in ?? () from /usr/share/spotify/libcef.so #19 0x00007ffff0460359 in ?? () from /usr/share/spotify/libcef.so #20 0x00007ffff02bb07e in ?? () from /usr/share/spotify/libcef.so #21 0x00007fffefebb0fc in ?? () from /usr/share/spotify/libcef.so #22 0x00007fffef748ca4 in ?? () from /usr/share/spotify/libcef.so #23 0x00007fffef74a85c in ?? () from /usr/share/spotify/libcef.so #24 0x00007fffef76e946 in ?? () from /usr/share/spotify/libcef.so #25 0x00007fffef907ecd in ?? () from /usr/share/spotify/libcef.so #26 0x00007fffef908264 in ?? () from /usr/share/spotify/libcef.so #27 0x00007fffef908b27 in ?? () from /usr/share/spotify/libcef.so #28 0x00007ffff23bac18 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib64/libgtk-x11-2.0.so.0 #29 0x00007ffff2da1332 in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #30 0x00007ffff2db24eb in signal_emit_unlocked_R () from /usr/lib64/libgobject-2.0.so.0 #31 0x00007ffff2dba416 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0
Created attachment 313563 [details] spotify-0.8.3.278.ebuild (In reply to comment #63) > For some reason 0.8.3.278 segfaults for me after loading lots of plugins > ("bundle"). Heh, nice timing, I came here to post about that before I saw the bugmail from your comment.... I think this is because both Qt and Spotify's libcef.so each contain a copy of WebKit, and they both export (some of) the same symbols and end up calling across each other, but (depending on Qt version) the two versions aren't compatible. The attached ebuild creates a wrapper script that sets LD_PRELOAD to force Spotify's version to be loaded first, which /seems/ to successfully work around it (at least it doesn't crash immediately on startup anymore).
> I think this is because both Qt and Spotify's libcef.so each contain a copy > of WebKit, and they both export (some of) the same symbols and end up > calling across each other, but (depending on Qt version) the two versions > aren't compatible. The attached ebuild creates a wrapper script that sets > LD_PRELOAD to force Spotify's version to be loaded first, which /seems/ to > successfully work around it (at least it doesn't crash immediately on > startup anymore). This fixes the start-up crash for me and seems to be working fine now. Thanks!
Created attachment 317910 [details] spotify-0.8.4.103.ebuild based on https://bugs.gentoo.org/attachment.cgi?id=311541
Created attachment 318324 [details] spotify-0.8.4.103.ebuild (with libcef.so LD_PRELOAD fix) Updated 0.8.4.103 ebuild with LD_PRELOAD work around from 0.8.3.278 ebuild provided by David Leverton in Comment #65
I've packaged the GNOME integration script for Spotify (http://code.google.com/p/gnome-integration-spotify/) via the "gnome" USE flag to the spotify-0.8.4.103.ebuild (2012-07-16 attachment on this bug). Here is the overlay for anyone interested: https://github.com/mrpdaemon/gentoo-overlay
Need the license of the client for me to commit it to the tree, for now it's in my overlay (prometheanfre).
If by license you mean as in GPL/MIT/BSD, etc, this is what their own package information says: Component: non-free Origin: Spotify LTD Label: Spotify Public Repository Architecture: source Description: Spotify's repository for the desktop client and libspotify I guess "Proprietary" or "NonFree" would be a valid license?
(In reply to comment #71) I don't think so, the closest I think we could come is 'as-is' because there is no clear license defined.
(In reply to comment #72) > (In reply to comment #71) > I don't think so, the closest I think we could come is 'as-is' because there > is no clear license defined. I guess then we could create a new license called "SPOTIFY" or similar with its exact content (like "skype-4.0.0.7-copyright" or many others)
I've thought about that, but I want to get a response from them first.
http://www.spotify.com/us/legal/end-user-agreement/ 10:02 < prometheanfire > do you have a plaintext version? I can copy the text, but just thought I'd ask :D 10:02 < dan^spotify > No, and copy+pasting it into a text file isn't something we really want you to to do, since it changes from time-to-time 10:04 < prometheanfire > ok, I'll see what the proper course of action is, I think you have us accept the license on first start right? 10:04 < dan^spotify > Correct 10:04 < dan^spotify > Well, first login 10:05 < prometheanfire > just as good probably 10:05 < dan^spotify > If you've already accepted the most up-to-date license on another machine, you won't be prompted again
(In reply to comment #72) > I don't think so, the closest I think we could come is 'as-is' because there > is no clear license defined. That's exactly _not_ what "as-is" is for. "as-is" was meant for free software licenses similar to BSD-2 or MIT. See this thread in gentoo-dev from a month ago: <http://thread.gmane.org/gmane.linux.gentoo.devel/80346>
it's now in tree have fun :D
