Okay, title pretty much says what I've run into here. Any ideas?

http://ubuntu.pastebin.us/19290

I do not know what you're problem is, however I would recommend you "svn up" to the latest trunk. I just compiled trunk, and only PIM is broken for me. Base is fine. Looks like a typo in the CMakeLists.txt file somewhere.

bcooksley wrote:I do not know what you're problem is, however I would recommend you "svn up" to the latest trunk. I just compiled trunk, and only PIM is broken for me. Base is fine. Looks like a typo in the CMakeLists.txt file somewhere.

Decided to try that. Not having a whole lot of luck though. For me kdebase fails to build with this:

Code: Select all

[ 15%] Building CXX object runtime/nepomuk/services/strigi/CMakeFiles/nepomukstrigiservice.dir/strigiservice.o
/home/blackwaltz/linux/soft/src/kde-trunk/kdebase/runtime/nepomuk/services/strigi/strigiservice.cpp:31:38: error: strigi/indexpluginloader.h: No such file or directory
/home/blackwaltz/linux/soft/src/kde-trunk/kdebase/runtime/nepomuk/services/strigi/strigiservice.cpp: In constructor ‘Nepomuk::StrigiService::StrigiService(QObject*, const QList&)’:
/home/blackwaltz/linux/soft/src/kde-trunk/kdebase/runtime/nepomuk/services/strigi/strigiservice.cpp:61: error: ‘Strigi::IndexPluginLoader’ has not been declared
/home/blackwaltz/linux/soft/src/kde-trunk/kdebase/runtime/nepomuk/services/strigi/strigiservice.cpp: In destructor ‘virtual Nepomuk::StrigiService::~StrigiService()’:
/home/blackwaltz/linux/soft/src/kde-trunk/kdebase/runtime/nepomuk/services/strigi/strigiservice.cpp:92: error: ‘Strigi::IndexPluginLoader’ has not been declared
make[2]: *** [runtime/nepomuk/services/strigi/CMakeFiles/nepomukstrigiservice.dir/strigiservice.o] Error 1
make[1]: *** [runtime/nepomuk/services/strigi/CMakeFiles/nepomukstrigiservice.dir/all] Error 2
make: *** [all] Error 2

:'(

Have you built + installed kdesupport? That is where strigi lives, and by the looks of it it can't be found. If you have done that then try rerunning CMake to update the build system.

Yeah, after a bit of googling and a little luck I came to the same conclusion. My system-wide strigi was apparently missing that ... so I downloaded kdesupport, built, and installed it. Then I got to have the fun time of forcing it to look at that version instead of the old one when I went to build : Oh well. Things seem to be going okay now, if a bit slow. Building with make -j1 sucks. Shame my usual make -j -l 3.8 eats babies when trying to compile kdebase...[hr]
Hmm, this is a weird one:

CMake Error at workspace/plasma/scriptengines/python/cmake_install.cmake:68 (FILE):
file INSTALL cannot copy file
"/home/blackwaltz/linux/soft/src/kde-trunk/kdebase/workspace/plasma/scriptengines/python/plasmascript.py"
to "/usr/lib/python2.5/site-packages/PyKDE4/plasmascript.py".
Call Stack (most recent call first):
workspace/plasma/scriptengines/cmake_install.cmake:40 (INCLUDE)
workspace/plasma/cmake_install.cmake:43 (INCLUDE)
workspace/cmake_install.cmake:62 (INCLUDE)
cmake_install.cmake:39 (INCLUDE)


Why on earth is it trying to put a file in /usr/lib when I specified an install prefix of ~/linux/soft/kde4 ....

Because it's a Python file, and I guess it's putting it into the standard Python package directory, because that's how the Python interpreter tries to load modules (local dir, then package dirs).

Yes, I had that problem. It puzzled me until I found out that you can't set a variable to tell python where to search for python packages ( which is stupid ). Since 4.1 didn't create the files, I used root to touch them, then chowned them to my trunk user. After that I was able to use kdesvn-build without problems.

Hi everybody.

I have same error:
-- Installing: /usr/lib/python2.5/site-packages/PyKDE4/plasmascript.py
CMake Error at workspace/plasma/scriptengines/python/cmake_install.cmake:68 (FILE):
file INSTALL cannot copy file
"/home/kde-devel/kdesvn/kdebase/workspace/plasma/scriptengines/python/plasmascript.py"
to "/usr/lib/python2.5/site-packages/PyKDE4/plasmascript.py".
Call Stack (most recent call first):
workspace/plasma/scriptengines/cmake_install.cmake:40 (INCLUDE)
workspace/plasma/cmake_install.cmake:42 (INCLUDE)
workspace/cmake_install.cmake:76 (INCLUDE)
cmake_install.cmake:39 (INCLUDE)

Where is solution?
Thanx for advice.

Other than disabling Python bindings ( don't know how ) you will need to, for each /usr/lib/python2.5 file it cannot install execute these commands:

Code: Select all

sudo touch $FILE
sudo chown $(whoami) $FILE

replacing $FILE with the problematic file ( /usr/lib/python2.5/site-packages/PyKDE4/plasmascript.py in this case )

It will first create the needed file if it does not exist, then transfer the ownership to your current user, in a system ( not /home ) area, so make sure to remove them when you are remove the beta from your system ( upgrading via self compilation not included )

Thanks for your efforts, but this is a bad workaround and breaks the idea of having a system wide (stable) and user specific (testing) installation, and is IMHO almost calling for hard to track down troubles. This is a bug in the build system and should be fixed in a appropriate way.

Is there already a bug report for that issue?

This would have to be filed with the Python developers. The KDE developers have been forced to do it this way because of them.

I'm not an expert in python. But as far as I can see python *is* configurable via environment vars where to look for packages: See here for explanations of PYTHONHOME and PYTHONPATH.

In this case, you may wish to contact the KDE Developers, with this information, and ask them to correct the CMake build system.

Bug reported.

furanku wrote:Bug reported.

... and dup'ed.