Created attachment 403958 [details] first spotify-beta ebuild submission Spotify has released a beta version of their linux client (currently at version 1.0.1.1062) Users have a .deb file or the packed source archive to choose from, however the .deb file is more up to date (1.0.1.1062 vs 1.0.0.1146) but it doesn't contain an icons folder, while the source archive does. Links: http://download.spotify.com/beta/spotify-client_1.0.1.1062_amd64.deb http://download.spotify.com/beta/spotify-app-1.0.0.1146.gf9b5fe37.tar.bz2 To avoid having to download the program twice just for the icons, I figured it might be better to simply extract them and put them in the /files directory. Hopefully there's no size issue. I attached the ebuild in this initial post and will attach the icons archive in the following one. I suggest the name spotify-beta as it shouldn't be a replacement for spotify.
Created attachment 403960 [details] archive of the files directory (extra icons)
I would rather not package beta ebuilds. If I did want to package it, I'd do it under the normal spotify ebuild as well. Thanks for this though. It could probably go into something like the sunrise overlay.
Created attachment 409504 [details] spotify-1.0.11.131.ebuild For what it's worth, here's an ebuild for the newest beta. Based on the in-tree ebuild.
This needs to be tested on hardened profile I think. I don't seem to be able to use paxctlt on the binary. Will test and report back.
paxmark uses paxctl-ng instead of paxctl and it does work. I had to replace the dosym ${SPOTIFY_HOME}/spotify /usr/bin/spotify line with dodir /usr/bin cat <<-EOF >"${D}"/usr/bin/spotify #! /bin/sh exec ${SPOTIFY_HOME}/spotify "\$@" EOF or fperms fails when testing with ebuild install. I believe SpotifyHelper isn't bundled with this version, so you don't need any of the pax-mark directives for SpotifyHelper. Strangely enough, pax-mark doesn't complain about non-existing files. Is there a reason to move spotify out of /opt and into /usr/share? Why not keep compatibility with the previous versions of spotify on Gentoo. Also, why not request a version bump for media-sound/spotify instead of introducing a new ebuild? I am not sure what is considered beta but none of the spotify builds are *officially* supported AFAIK. I would think that this version qualifies for a straight version bump.
Created attachment 410870 [details] spotify-1.0.13.111.ebuild
Just an update for the latest beta version with some remarks of Gokturk (fperms fix + pax-mark lines removed).
Created attachment 411358 [details] spotify-1.0.13.112.ebuild
I'm attaching a new ebuild for 1.0.13.112: * This is a rewrite of the app, so the list of dependencies changed substantially. You can check them in the debian control file or in Arch: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=spotify-beta * The ebuild can be further simplified: no need for revdep-rebuild, QA_PREBUILT is shorter, etc. * For KDE users it's recommended to remove the icon cache. The old ebuild also does a sed substitution to fix the .desktop file, but today I pushed a commit to master that fixes the desktop file upstream. It should be included in 1.0.15 in a couple of weeks.
@prometheanfire While this is a beta, the 1.0 client is the default for Windows and Mac users, and has been the default for a couple of months. It's beta for Linux mostly because we haven't yet implemented some important parts in Linux, like menu or tray icon. Apart from that, the client is very stable and I've been using it for a couple of months. Besides, it's much less memory-hungry than 0.9, so for some users it's a must. I'd personally include it in Gentoo. It's masked as ~amd64 afterall.
Created attachment 412174 [details] 1.0.14 is out
1.0.14 is in tree now
I am curious if I'm gonna get bug reports stating it needs to be re-paxmarked though. If it's still based off of chrome it probably will.
(In reply to Matthew Thode ( prometheanfire ) from comment #13) > I am curious if I'm gonna get bug reports stating it needs to be > re-paxmarked though. If it's still based off of chrome it probably will. It needs to be pax-marked or it segfaults :)
