Version: (using Devel) OS: Linux Installed from: Compiled sources I'm running a kdesvn-build user based installation, esp. installing it withot root privilegs to non-system wide directories. Installing kopete fails with CMake Error at kopete/protocols/skype/skypebuttons/cmake_install.cmake:41 (FILE): file cannot create directory: /usr/lib/firefox/plugins. Maybe need administrative privileges. Call Stack (most recent call first): kopete/protocols/skype/cmake_install.cmake:74 (INCLUDE) kopete/protocols/cmake_install.cmake:42 (INCLUDE) kopete/cmake_install.cmake:39 (INCLUDE) cmake_install.cmake:39 (INCLUDE) I think this would be even a bad practice for system wide installations as /usr/lib/firefox/plugins is not neccessarily the best place to install prefox plugins. On my Gentoo system this directory does not even exist.
Hello, it install skype buttons (netscape plugin) for konqueror (and firefox too). When you running cmake you see: "Mozilla plugin install dir is /usr/lib/firefox/plugins to change use parm -DMOZPLUGIN_INSTALL_DIR=<directory>" So you can change this dir to local when you start cmake: cmake -DMOZPLUGIN_INSTALL_DIR=~/.mozilla/plugins <kopete_source_dir>
Ah ... OK, so the kdesvn-build script should have a configure option for this or guess from it's own configuration wether this is a system wide or an non-privileged user installation. As I'm not experienced with bugs.kde.org, does anyone know hot to pass this bug report to the kdesvn-build maintainer? Thanks for your quick reply!
OK, solved it by adding -DMOZPLUGIN_INSTALL_DIR=~/.mozilla/plugins to cmake-options in .kdesvn-buildrc. Thanks for your help! Closing this bug as invalid.
> So you can change this dir to local when you start cmake: > cmake -DMOZPLUGIN_INSTALL_DIR=~/.mozilla/plugins <kopete_source_dir> Well, this does not change the fact the *default* installation target does not respect the chosen installation prefix. Please change it to be at least "lib/firefox/plugins".
*** Bug 191206 has been marked as a duplicate of this bug. ***
It is wrong to force the user to use -DMOZPLUGIN_INSTALL_DIR to get a clean installation. Normally it should just suffice to set the installation PREFIX to get a clean installation. It is the users responsibility to add $PREFIX/lib/firefox/plugins to his plugin search path. In my opinion this bug is not invalid and should be reopened.
In files http://websvn.kde.org/trunk/KDE/kdebase/apps/nsplugins/plugin_paths.cpp?view=markup http://websvn.kde.org/trunk/KDE/kdebase/apps/konqueror/settings/konqhtml/pluginopts.cpp?view=markup is all default paths where nsplugins/konqueror search for new nsplugins (on startup kde). So /usr/lib/firefox/plugins is in search list, it is ok?
(In reply to comment #7) > In files > http://websvn.kde.org/trunk/KDE/kdebase/apps/nsplugins/plugin_paths.cpp?view=markup > http://websvn.kde.org/trunk/KDE/kdebase/apps/konqueror/settings/konqhtml/pluginopts.cpp?view=markup > is all default paths where nsplugins/konqueror search for new nsplugins (on > startup kde). So /usr/lib/firefox/plugins is in search list, it is ok? This not justifies the force of an out-of-prefix installation of files by default. If I request the installation to a local subdirectory of mine, _all_ of its installed software should be installed there. The only few exceptions should be modules which cannot never ever work out of the system path (eg PAM moules). But this is not the case with netscape plugins, which can work in any path they are. If you are worried about the plugin paths, then it is already user's task to adjust that, if they compile from sources (you should know what you do if you compile from sources, anyway). Also, the -DMOZPLUGIN_INSTALL_DIR is not a reason either for the bug to be INVALID: while the variable can be set by distro packagers or users who want to integrate the kopete/kde4.3 installation in a system prefix, this must not be the default. Reopening; please fix (see comment #4 as help).
I would argue that even PAM modules should not be installed out of PREFIX without an additional configuration. The k3b team recently made a similar mistake. They could be convinced by this arguments: https://bugs.kde.org/show_bug.cgi?id=191207#c2
I fixed it. Now check if you choose installation prefix in home dir or /usr or /usr/local or other. If installation prefix is in home dir plugin install dir is ~/.mozilla/plugins Default dir I change to /usr/lib/mozilla/plugins because firefox cant load it.
Pali, or another Kopete developer, could you please confirm that this issue is fixed and that the report should be closed ?
I think it is fixed. See here: http://websvn.kde.org/?view=revision&revision=968828 http://websvn.kde.org/?view=revision&revision=1033094
Ok, I close it then. Thank you.