Thankfully, the solution was easier than I thought. Do all the following as root…

1. Install dpkg, the Debian package management tool:

yum install dpkg

2. Download the base package for your architecture, and the gnome support package, from here:

http://repository.spotify.com/pool/non-free/s/spotify/

3. Create a temp directory, and unpack them there (we want to check for clashes):

mkdir spotify
cd spotify
dpkg -x ../spotify-client-qt_0.4.7.132.g9df34c0-1_amd64.deb .
dpkg -x ../spotify-client-gnome-support_0.4.7.132.g9df34c0-1_all.deb .

4. This gives you a directory tree starting at /usr. You can check for clashes like this:

find -not -type d -exec ls -l /'{}' \;

… and make sure there’s no files found.

5. Then re-extract them into your root partition (hence checking for clashes first):

dpkg -x ../spotify-client-qt_0.4.7.132.g9df34c0-1_amd64.deb /
dpkg -x ../spotify-client-gnome-support_0.4.7.132.g9df34c0-1_all.deb /

6. Finally, we need to manually install qt-x11 as this dependency is needed:

yum install qt-x11

7. Then just type spotify and log in!

Seems pretty stable so far, apart from a couple of minor glitches.

EDIT: As suggested by Tyson Key in this thread, I got rid of the audio glitches by starting the PulseAudio volume control (/usr/bin/pavucontrol) before Spotify. Maybe this adds some buffering or something.

N.B. I take no responsibility if this process damages your computer, your music collection, your hearing or your sanity. Try at your own risk

Everybody (?) knows that in theory, if you have 64-bit Firefox on 64-bit Linux (x86_64), you can use nspluginwrapper to install 32-bit plugins, like the Flash Player. There’s some instructions here for example.

However, those instructions are flawed in two regards.

Firstly, Flash Player 10 doesn’t come with a .xpt file any more, but that’s not apparently a problem.

Secondly, and more mistifyingly, nspluginwrapper seems to require you to give the absolute path to the plugin’s .so file, for some reason. So if you get an error like this:

$ nspluginwrapper -v -i libflashplayer.so
*** NSPlugin Viewer  *** ERROR: libflashplayer.so: cannot open
shared object file: No such file or directory
nspluginwrapper: no appropriate viewer found for libflashplayer.so

Then try again with the full path to the plugin:

$ nspluginwrapper -v -i /home/bsm/clegg/.mozilla/plugins/libflashplayer.so
Install plugin /home/bsm/clegg/.mozilla/plugins/libflashplayer.so
  into /home/bsm/clegg/.mozilla/plugins/npwrapper.libflashplayer.so

Restart Firefox, and away you go, joy! No feeling for stability yet, but I’ll post again if there are any problems.

Incidentally, I first tried installing nspluginwrapper via yum, and got a whole bunch of unsatisfied dependencies:

Error: Package devhelp needs libgtkembedmoz.so, this is not available.
Error: Package devhelp needs libxpcom.so, this is not available.
Error: Package devhelp needs gecko-libs = 1.8.0.12, this is not available.

Then I just tried installing the RPMs from the nspluginwrapper home page (first the one marked Viewer, then the one marked Plugin) and it worked like a charm.

Hat tip to this thread on the Ubuntu Forums for finally revealing the key bit of information about absolute vs. relative paths.

UPDATE: Aaargh, sound doesn’t work. But that seems to be the fault of my ALSA drivers rather than Flash or nspluginwrapper. Apparently Flash can only use ALSA for sound, and not any of the other various Linux sound architectures, and only OSS works on this PC…

Andrew.

It goes like this, as root:

$ yum update subversion

[normal messages snipped]

Transaction Check Error:
  file /usr/share/emacs/site-lisp/psvn.el
from install of subversion-1.5.5-0.1.el5.rf
conflicts with file from package subversion-1.4.2-2.el5
  file /usr/share/man/man1/svn.1.gz
from install of subversion-1.5.5-0.1.el5.rf
conflicts with file from package subversion-1.4.2-2.el5
  file /usr/share/man/man1/svnadmin.1.gz
from install of subversion-1.5.5-0.1.el5.rf
conflicts with file from package subversion-1.4.2-2.el5
  file /usr/share/man/man1/svnlook.1.gz
from install of subversion-1.5.5-0.1.el5.rf
conflicts with file from package subversion-1.4.2-2.el5
  file /usr/share/man/man5/svnserve.conf.5.gz
from install of subversion-1.5.5-0.1.el5.rf
conflicts with file from package subversion-1.4.2-2.el5
  file /usr/share/man/man8/svnserve.8.gz
from install of subversion-1.5.5-0.1.el5.rf
conflicts with file from package subversion-1.4.2-2.el5
  file /usr/share/xemacs/site-packages/lisp/psvn.el
from install of subversion-1.5.5-0.1.el5.rf
conflicts with file from package subversion-1.4.2-2.el5

WTF? Surely doing an update is supposed to replace files from an earlier release with a later one?

The reason, as my colleague Ian discovered, is that 64-bit Centos has both 32 and 64-bit versions of Subversion, which causes it to get its knickers in a twist when doing an update. So we just did the following:

$ yum erase subversion.i386
$ yum update subversion

to remove the 32-bit version and then just update the 64-bit one. Works fine. (Touch wood…)

Probably works with Redhat Enterprise (RHEL) too and possibly other distros.

EDIT: If you only have the Centos base RPM repository, you won’t find svn 1.5.5 (or any recent versions). You need to set your system up to use RPMForge as well, as documented here. Thanks to GR in the comments for pointing this out.

Andrew.