[gentoo-amd64] Re: Amarok plugin problem

[Duncan]

"Mark Haney" <mhaney@××××××××××××.org> posted
458971ED.80304@××××××××××××.org, excerpted below, on  Wed, 20 Dec 2006
12:25:01 -0500:

> I sometimes opn amarok to listen to podcasts when I get some time to.
> However, today I'm getting these errors:
>
>
> /usr/kde/3.5/lib64/kde3/libamarok_void-engine_plugin.so: cannot open
> shared object file: No such file or directory
>
> /usr/kde/3.5/lib64/kde3/libamarok_xine-engine.so: cannot open shared
> object file: No such file or directory
>
> I've run revdep-rebuild and just emerged amarok by itself and I still get
> this message.  Has anyone seen this problem before?

I've not seen the problem, but if you've remerged and still see the
problem, it's likely a problem with your config.  KDE apps normally store
their user config in ~/.kde*, I have a number of symlinks here to a
non-hidden ~/kde3.5 dir and I don't know which one is the default, but
anyway, the configs of interest will be 

~/.kde*/share/apps/amarok/ , a directory with a number of files, and
~/.kde*/share/config/amarokrc , a single config file.  With amarok closed
(make sure it's not still running in the tray), rename this dir and file
to *.bak, so amorok starts with a clean config, and see if the problem
still exists.

If the problem disappears as I suspect it will, you'll have fixed that,
but will have lost all your saved settings and scores and preferences and
all that too, since that's all in the stuff you renamed (which is why I
said rename it, not delete it).  If you wish to retain all that, shut down
amarok again and remove the new nearly default settings it probably
created, and copy back amorokrc from your *.bak copy.  Restart and see if
the problem is still gone or reappears.

If the problem has reappeared, you'll know the issue is in the amarokrc
file and can delete it again (you still have the amorokrc.bak file, which
you copied back for testing) and restore the apps/amorok dir.  If the
problem didn't reappear, you'll know it's in the apps/amorok dir and can
leave the rc file where it is and proceed by copying half the files in the
amorok dir back into place.  Testing again will determine whether it's the
half you moved in or the half you left out.

Repeating this process, you'll soon isolate the problem file.  At that
point, you can either simply do without that file, recreating all the
settings and/or info that was stored therein if desired, or do what
amounts to the same process on the file, particularly if it's a text based
config file as the rc files for instance normally are.  If the file's
divided into sections, after ensuring you have a backup copy, you can
delete some of the sections while keeping the others and test that. 
Eventually you'll narrow down the problem to a single config section and
you can begin testing the individual setting lines within that section.

When you isolate the problem to an individual line, it's easy enough to
delete that line and reconfigure whatever it controlled if necessary. 
However, often you'll not need to go to that extreme.  By the time you
isolate the file, or the config section within the file causing the
problem, it'll often be less work to simply recreate its settings from the
defaults, than it will be to isolate the problem further.

The first time you use this technique, it'll be somewhat difficult, altho
I eased that by pointing out the subdir and config file for amarok so you
don't have to isolate to them from your entire ~/ dir.  However, after
doing it a couple times, you'll find it far easier to guess where in
general the problem is, and be able to wipe out 3/4 or more of the
possibilities at several steps in the isolation process, by simply making
and testing educated guesses of where the problem is.  For instance, if
you had tried this on your own, a look at your home directory may have
allowed you to conclude that ~/.kde* was the likely place for the config,
and a look in there may have allowed you to conclude that share was the
most likely suspect, and a look in there would have likely allowed you to
conclude that something either under config or under apps was the likely
suspect, and you could look for an amorok entry under each of them to
test, thus eliminating all the REST of your home dir, and all the REST of
the kde config dir, and all the REST of the share dir, and all the REST of
the apps subdirs and all the REST of the config files, without even
testing anything yet.  Each of those eliminations saves you a step in the
test and isolate process, thereby making it that much easier.  Eventually,
you'll know about where to look in most cases before you even start, and
will often be able to guess the right file on your first test.

Of course, you can simply blow away your entire config every time
something like this comes up too, but for people like me that spend a lot
of time customizing, that quickly becomes an untenable thing to
contemplate, as a few minutes of educated guess elimination testing can
often save literally hours of recustomization.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list