So, there was a talk about 1.0.77 version bump earlier, but it was deemed as 'unstable testing version'. However today spotify dropped the 1.0.72 build for amd64, leaving only that 1.0.77 available. For x86, the old 1.0.72 is still present. https://bugs.gentoo.org/651984 http://repository-origin.spotify.com/pool/non-free/s/spotify-client/
guess this means I need to tell them, again, that their solution is not cross platform.
OK, I built curl with both gnutls and openssl support and tested again, same fails as before though. I made a thread on their forums, hopefully someone responds. For completeness, this was the old (not used) because it never failed to coredump. https://github.com/gentoo/gentoo/pull/7710
I've also uploaded an strace here https://dev.gentoo.org/~prometheanfire/fails/spotify-1.0.77-fail.strace.xz
I tried updating to 1.0.77 today. I didnt do anything else with the ebuild except change the build, and remove x86. After installation I did manually patchelf, as you suggested in spotify thread: patchelf --replace-needed libcurl-gnutls.so.4 libcurl.so.4 /opt/spotify/spotify-client/spotify Ive been using spotify-1.0.77 now for 2 hours and it hasnt crashed once. I cant really say the differences with our systems, or whats causing it. I do get these errors when starting spotify, /opt/spotify/spotify-client/spotify: /usr/lib64/libcurl.so.4: no version information available (required by /opt/spotify/spotify-client/spotify) /opt/spotify/spotify-client/spotify: /usr/lib64/libcurl.so.4: no version information available (required by /opt/spotify/spotify-client/spotify) /proc/self/exe: /usr/lib64/libcurl.so.4: no version information available (required by /proc/self/exe) but nothing after, and Spotify works like it should. Im gonna try and run spotify for longer period of time after work today. Here's my curl, it looks the same as yours but I have 'threads' USE flag enabled. Cant believe thats the reason to your crashes, since the other guy in the previous bug also didnt have 'threads' enabled. [ebuild R ] net-misc/curl-7.59.0::gentoo USE="ssl threads -adns -brotli -http2 -idn -ipv6 -kerberos -ldap -metalink -rtmp -samba -ssh -static-libs -test" ABI_X86="32 (64) (-x32)" CURL_SSL="openssl -axtls -gnutls -libressl -mbedtls -nss (-winssl)" [ebuild R ] dev-libs/openssl-1.0.2o::gentoo USE="asm sslv3 tls-heartbeat zlib -bindist -gmp -kerberos -rfc3779 -sctp -sslv2 -static-libs -test -vanilla" ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="(sse2)" [ebuild R ] dev-util/patchelf-0.9_p20180129::gentoo Here are some QA notices when emerging spotify-1.0.77 without significant changes to ebuild: * QA Notice: Pre-stripped files found: * /opt/spotify/spotify-client/swiftshader/libEGL.so * /opt/spotify/spotify-client/swiftshader/libGLESv2.so * /opt/spotify/spotify-client/libwidevinecdmadapter.so * /opt/spotify/spotify-client/libcef.so * /opt/spotify/spotify-client/libGLESv2.so * /opt/spotify/spotify-client/libEGL.so Hope this helps in some way!
ok, maybe it's something else then Installed versions: 7.59.0^t{xpak:4}(06:53:56 PM 04/12/2018)(brotli http2 ipv6 rtmp ssl -adns -idn -kerberos -ldap -metalink -samba -ssh -static-libs -test -threads ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="32 64 -x32" CURL_SSL="gnutls openssl -axtls -libressl -mbedtls -nss -winssl" ELIBC="-Winnt")
actually, how do you run it at all? do you have net-libs/libcurl-debian installed?
oh, patchelf, I forgot, guess it's time for bed
could you show me what version of boost you have installed (with use flags)?
threads seems to help
or not...
Hey, I do not have net-libs/libcurl-debian installed. Here's my boost: [ebuild R ] dev-libs/boost-1.65.0:0/1.65.0::gentoo USE="nls threads -context -debug -doc -icu -mpi -python -static-libs -tools" ABI_X86="32 (64) (-x32)" PYTHON_TARGETS="python2_7 python3_5 -python3_4 -python3_6" Spotify has been running absolutely fine for hours now.
ok, can you give the output of lddtree then (upload/attach)?
Sure, ------------------- spotify => /opt/spotify/spotify-client/spotify (interpreter => /lib64/ld-linux-x86-64.so.2) libasound.so.2 => /usr/lib64/libasound.so.2 ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 libresolv.so.2 => /lib64/libresolv.so.2 libcurl.so.4 => /usr/lib64/libcurl.so.4 libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 libdl.so.2 => /lib64/libdl.so.2 libcef.so => /opt/spotify/spotify-client/libcef.so libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 libpcre.so.1 => /lib64/libpcre.so.1 libnss3.so => /usr/lib64/libnss3.so libplc4.so => /usr/lib64/libplc4.so libplds4.so => /usr/lib64/libplds4.so libnssutil3.so => /usr/lib64/libnssutil3.so libsmime3.so => /usr/lib64/libsmime3.so libnspr4.so => /usr/lib64/libnspr4.so libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 libxcb.so.1 => /usr/lib64/libxcb.so.1 libXau.so.6 => /usr/lib64/libXau.so.6 libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 libbsd.so.0 => /usr/lib64/libbsd.so.0 libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 libXcursor.so.1 => /usr/lib64/libXcursor.so.1 libXdamage.so.1 => /usr/lib64/libXdamage.so.1 libXext.so.6 => /usr/lib64/libXext.so.6 libXfixes.so.3 => /usr/lib64/libXfixes.so.3 libXi.so.6 => /usr/lib64/libXi.so.6 libXrender.so.1 => /usr/lib64/libXrender.so.1 libXtst.so.6 => /usr/lib64/libXtst.so.6 libexpat.so.1 => /usr/lib64/libexpat.so.1 libXrandr.so.2 => /usr/lib64/libXrandr.so.2 libXss.so.1 => /usr/lib64/libXss.so.1 libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 libelogind.so.0 => /lib64/libelogind.so.0 libatomic.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libatomic.so.1 libm.so.6 => /lib64/libm.so.6 libX11.so.6 => /usr/lib64/libX11.so.6 libpthread.so.0 => /lib64/libpthread.so.0 librt.so.1 => /lib64/librt.so.1 libz.so.1 => /lib64/libz.so.1 libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 libXinerama.so.1 => /usr/lib64/libXinerama.so.1 libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 libffi.so.6 => /usr/lib64/libffi.so.6 libmount.so.1 => /lib64/libmount.so.1 libblkid.so.1 => /lib64/libblkid.so.1 libuuid.so.1 => /lib64/libuuid.so.1 libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 libfribidi.so.0 => /usr/lib64/libfribidi.so.0 libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0 libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3 libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 libpng16.so.16 => /usr/lib64/libpng16.so.16 libcairo.so.2 => /usr/lib64/libcairo.so.2 libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 libEGL.so.1 => /usr/lib64/opengl/nvidia/lib/libEGL.so.1 libGLdispatch.so.0 => /usr/lib64/opengl/nvidia/lib/libGLdispatch.so.0 libxcb-shm.so.0 => /usr/lib64/libxcb-shm.so.0 libxcb-render.so.0 => /usr/lib64/libxcb-render.so.0 libGL.so.1 => /usr/lib64/opengl/nvidia/lib/libGL.so.1 libGLX.so.0 => /usr/lib64/opengl/nvidia/lib/libGLX.so.0 libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 libfreetype.so.6 => /usr/lib64/libfreetype.so.6 libbz2.so.1 => /lib64/libbz2.so.1 libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libstdc++.so.6 libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgcc_s.so.1 libc.so.6 => /lib64/libc.so.6 --------------------
OK, more info [pid 31184] 10:32:52.539388 <... getsockname resumed> {sa_family=AF_INET6, sin6_port=htons(52407), inet_pton(AF_INET6, "V6_ADDR_REDACTED", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0 [pid 31176] 10:32:52.539401 <... futex resumed> ) = 1 [pid 31229] 10:32:52.539410 gettid( <unfinished ...> [pid 31184] 10:32:52.539419 close(128 <unfinished ...> [pid 31229] 10:32:52.539428 <... gettid resumed> ) = 31229 [pid 31184] 10:32:52.539436 <... close resumed> ) = 0 [pid 31176] 10:32:52.539444 epoll_wait(31, <unfinished ...> [pid 31229] 10:32:52.539463 gettid( <unfinished ...> [pid 31187] 10:32:52.539472 mprotect(0x7faf7c596000, 4096, PROT_READ|PROT_WRITE <unfinished ...> [pid 31229] 10:32:52.539481 <... gettid resumed> ) = 31229 [pid 31187] 10:32:52.539489 <... mprotect resumed> ) = 0 [pid 31229] 10:32:52.539496 gettid( <unfinished ...> [pid 31184] 10:32:52.539505 setsockopt(130, SOL_IP, IP_MULTICAST_IF, [315642584], 4 <unfinished ...> [pid 31229] 10:32:52.539516 <... gettid resumed> ) = 31229 [pid 31187] 10:32:52.539525 mprotect(0x7faf7c597000, 4096, PROT_READ|PROT_WRITE <unfinished ...> [pid 31184] 10:32:52.539534 <... setsockopt resumed> ) = -1 EADDRNOTAVAIL (Cannot assign requested address) I *THINK* this means that spotify is trying to set up a multicast option on that interface. That interface is a VPN interface and it's not able to do so, so it bails with the boost error. If I stop OpenVPN, start spotify, then start OpenVPN it works again. So that's a workaround, but it looks like it's still broken. I'm going to go ahead and package 1.0.77 since it's the only one available, but at least there's a workaround...
I hate to tell this to you, but Im using openvpn as well and its currently on. Spotify works :) [ebuild R ] net-vpn/openvpn-2.4.5::gentoo USE="examples lzo pam plugins ssl -down-root -inotify -iproute2 -libressl -lz4 -mbedtls -pkcs11 (-selinux) -static (-systemd) -test" Oh, but one thing that comes to my mind is that Ive globally disabled ipv6 even from the kernel. I dont really understand your strace, but I see inet6 and sin6_addr that reminded me of ipv6. Using ipv6 with openvpn, I think you need to have following enabled in your kernel: CONFIG_IPV6 CONFIG_IPV6_ROUTER_PREF CONFIG_IPV6_ROUTE_INFO CONFIG_IPV6_OPTIMISTIC_DAD CONFIG_IPV6_MULTIPLE_TABLES CONFIG_IPV6_MROUTE CONFIG_IPV6_MROUTE_MULTIPLE_TABLES CONFIG_IPV6_PIMSM_V2 ^ taken from a kernel config with working ipv6-openvpn connection.
(In reply to Matthew Thode ( prometheanfire ) from comment #10) > or not... So can you remove the dep on threads again? :P
removed the tun dep Do you run openvpn with a tap or a tun device? A tap device will allow setting a multcast address on it (it's a L2 device). A tun device will not (it's a L3 device). IPV6 works fine with openvpn for me (I use it for that purpose as one of the primary reasons I use it). All those options are enabled though.
s/tun/threads
Im running tun. Seems like spotify wont work under _very_ special circumstances ;)
I wonder if the same bug exists in Windows. If someone can install OpenVPN under Windows, if the bug exists there too, then there's a higher chance that they'll fix it.
I just hit the same issue. I'm not running OpenVPN, but I do have IPv6 enabled.
Does this return anything? ls /sys/class/net/*/tun_flags
$ ls /sys/class/net/*/tun_flags ls: cannot access '/sys/class/net/*/tun_flags': No such file or directory $ spotify /opt/spotify/spotify-client/spotify: /usr/lib64/libcurl.so.4: no version information available (required by /opt/spotify/spotify-client/spotify) /opt/spotify/spotify-client/spotify: /usr/lib64/libcurl.so.4: no version information available (required by /opt/spotify/spotify-client/spotify) /proc/self/exe: /usr/lib64/libcurl.so.4: no version information available (required by /proc/self/exe) [0418/174928.631993:ERROR:nss_util.cc(724)] After loading Root Certs, loaded==false: NSS error code: -8018 terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >' what(): set_option: Cannot assign requested address Aborted (core dumped)
Strangely, Spotify started working for me today, with no change in the Spotify installation itself, just after a @world update. And it work with and without an active tun device, so at least for me, no relation with tunneling.
@prometheanfire As this bug was about version bump, I think we can close this as resolved? Then continue talk in a new bug if the tunneling issue happens again? :) I'll close in ~48h if no reply.
ya, I think we can close this
