I should be setting up fglrx first, but I failed to back up my my custom Xorg configuration I spent a year perfecting. So this tired Phanes is putting stuff he can’t live without on first and bringing the rest on as fast as can be done properly in a controlled manner, because I’m not going through that again later.

So first I need RPMFusion as not only do some of the dependencies for Spotify reside in that repository, many of the other needs for other installs will as well.

[highlighter line=0]
Add the RPMFusion Repos:

su -c 'dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm'

Add teh negativo17.org repositories as they have taken the ubuntu binary package and rebuilt it to be compatible with DNF:

dnf config-manager --add-repo=https://negativo17.org/repos/fedora-spotify.repo

If you’re using etckeeper…

If you followed my etckeeper guide you’ll see that this failed:

[root@localhost ~]# dnf install spotify-client
RPM Fusion for Fedora 23 - Nonfree                   758 kB/s | 218 kB     00:00    
RPM Fusion for Fedora 23 - Free - Test Updates       1.1 MB/s | 319 kB     00:00    
RPM Fusion for Fedora 23 - Nonfree - Test Updates    147 kB/s |  76 kB     00:00    
RPM Fusion for Fedora 23 - Free                      697 kB/s | 738 kB     00:01    
negativo17 - Spotify                                 9.5 kB/s | 3.7 kB     00:00    
Last metadata expiration check performed 0:00:00 ago on Sun Feb 14 22:12:45 2016.
Dependencies resolved.

** etckeeper detected uncommitted changes in /etc prior to dnf run
** Aborting dnf run. Manually commit and restart.

Error: etckeeper returned 1
[root@localhost ~]# 

Nothing to worry about, you put etckeeper there to make sure etc was being watched, right? Observe:

[root@localhost ~]# etckeeper vcs status -s
?? yum.repos.d/fedora-spotify.repo
[root@localhost ~]# 

See? Just commit. This is a great feature of DNF as it will not let you install packages without committing your etc working set to version control.

[root@localhost ~]# etckeeper commit "Added fedora-spotify repo to DNF"
[master 335a6b5] Added fedora-spotify repo to DNF
 Author: phanes <phanes@localhost>
 2 files changed, 16 insertions(+)
 create mode 100644 yum.repos.d/fedora-spotify.repo
[root@localhost ~]# etckeeper vcs status
On branch master
nothing to commit, working directory clean
[root@localhost ~]# 

With Etckeeper committed, Resume Installation…

Rerun the install command.  With all the dependencies included it will install 11 total packages:

From the fedora-spotify Repo:

• compat-libgcrypt
• spotify-client

From the rpmfusion-free-updates-testing repo:

• ffmpeg-libs
• lame-libs
• x264-libs
• x265-libs
• xvidcore

And finally, from the fedora base and updates repositories:

• fribidi
• schroedinger
• libass
• libva

Took more time to write it down than it did to install it.  I followed this guide for cues:

Spotify client

(Ok, not really.  His repo is really slow and should be cloned in case it doesn’t stick around longer than the next release)

Items of Concern regarding etckeeper:

I did notice that the first command that was run to get the rpmfusion repositories did not trigger etckeeper.  I should come back to this and look more closely at why when I’m done flying through changes.  I suspect that this is caused by hooks in DNF to work with etckeeper that it may be advanced enough to automatically commit if the change is made by the specified primary package manager yet there is no commit in the revision history.  If that is the case I should consider disabling that feature.