Today I finally succeeded to build KDE trunk (development version of KDE SC) after previously struggling with some Phonon-related problems. I decided to start from scratch, and while the overall process was quite smooth, I managed to hit some bumps along the way. Below I’ve shared my experience.
First I want to remind you that this isn’t a comprehensive guide to build KDE SC from SVN – you can find those on Techbase. I followed much of the Getting Started/Build/KDE4 guide to get started.
Introduction
I’ve found it easiest to build KDE trunk using a tool called kdesvn-build. From its Techbase page:
kdesvn-build is a tool to allow users and developers to easily download and build the latest versions of the KDE Software Compilation (KDE SC) from the KDE source code repositories. It automates the following tasks and more:
- Performing the initial checkout.
- Handling updates for modules that are already checked out.
- Setting up the build system for the module.
- Performing the build and install.
- Specifying your CMake options or configure flags (so you don’t have to remember them every time).
It’s basically a script that does the hard work for you. And it’s pretty, too.
Since I want to keep my stable KDE SC version, I have a special user called kde-devel
to run trunk. Everything will be install in this user’s home directory – no root access is needed, and if something breaks, the risk is minimal that it’ll affect my whole system.
You can do the same with your usual user and some scripts, see Increased Productivity in KDE4 with Scripts for more information.
1. Create and setup user
First this kde-devel
user has to be created:
useradd -m -G [groups] -s /bin/bash kde-devel
[groups]
depends on how much rights you want to give this user, for example the right to access sound or use sudo
. For my kde-devel
I used
useradd -m -G users,audio,optical,storage,video -s /bin/bash kde-devel
Now, add a password:
passwd kde-devel
To use applications from trunk instead of the stable version installed, you have to set the correct environmental variables. I added the code from this example .bashrc to /home/kde-devel/.bashrc
and changed the line
export QTDIR=$HOME/qt-kde
to
export QTDIR=$HOME/qt4
since that’s where qt-copy will be installed.
2. Install required packages
I’m an Arch Linux user and used the command here to install the required packages. You can find similar information for your distribution on this page.
Regarding Qt, .kdesvn-buildrc
(more about this configuration file later) states:
# KDE /trunk requires a very recent Qt so qt-copy is the best route if you're
# building /trunk. If you are building an older branch you may use your
# system installed Qt by setting qtdir to point to it (what qmake -v
# reports with the /lib removed).
So, I chose to let kdesvn-build compile qt-copy as well.
3. Get and setup kdesvn-build
At the time of writing, the latest version of kdesvn-build is 1.11. If you want to use the commands below, substitute <version>
with your version number, e.g. 1.11
.
I downloaded kdesvn-build as kde-devel
and extracted the tar to ~/kdesvn/kdesvn-build
(you may choose a different location if you want):
su - kde-devel
<write password for kde-devel>
mkdir -p ~/kdesvn/kdesvn-build
wget http://kdesvn-build.kde.org/releases/kdesvn-build-<version>.tar.bz2
tar xjvf kdesvn-build-<version>.tar.bz2 -C ~/kdesvn/kdesvn-build/
Before using kdesvn-build it needs to be configured. There’s a sample configuration file in the extracted directory – all we have to do is to copy it to ~/.kdesvn-buildrc
and edit it to fit our needs.
cp ~/kdesvn/kdesvn-build/kdesvn-build-<version>/kdesvn-buildrc-sample ~/.kdesvn-buildrc
<your favorite editor> ~/.kdesvn-buildrc
The file is quite long, but don’t worry, most of the text consists of comments. I found the default configuration to be good for my purposes, the only thing I did was to comment out some modules that I didn’t want, for example
#module kdetoys
#end module
By default KDE trunk and Qt will be installed at ~/kde
and ~/qt4
, respectively.
4. Build
When everything has been set up we can let kdesvn-build perform its magic. As kde-devel
:
~/kdesvn/kdesvn-build/kdesvn-build-<version>/kdesvn-build
Be patient, this will take a while. I encountered some problems during the build – see the next section for solutions. Remember that you can cancel the build with Ctrl-C
.
kdesvn-build also offers some useful options, use --help
to list them all.
~/kdesvn/kdesvn-build/kdesvn-build-<version>/kdesvn-build --help
5. Troubleshooting
As said, the process wasn’t flawless for me – actually, I ran into a problem very early. If you use the same version of kdesvn-build, it’s likely you’ll encounter this as well.
Can’t checkout qt-copy
Error updating qt-copy, removing from list of packages to build.
> Can't checkout qt-copy: No such file or directory at /home/kde-devel/.bin/kdesvn-build line 1981.
The problem is known, but I’m not sure if I can say the same about the cause. If you look in the logs you’ll see
less ~/kdesvn/log/latest/qt-copy/error.log
# kdesvn-build running: 'git' 'clone' '--' 'git://gitorious.org/+kde-developers/qt/kde-qt.git' '/home/kde-devel/kdesvn/qt-copy'
Initialized empty Git repository in /home/kde-devel/kdesvn/qt-copy/.git/
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
To solve it I cloned the git repository manually by copy-pasting the command from the log:
'git' 'clone' '--' 'git://gitorious.org/+kde-developers/qt/kde-qt.git' '/home/kde-devel/kdesvn/qt-copy'
Here kdesvn-build has no problem to update and build qt-copy after this fix.
Phonon-related problems
Apparently kdebase needs Phonon from kdesupport now, which also is the default option in the new kdesvn-buildrc-sample
file. My problems with Phonon vanished after upgrading to kdesvn-build 1.11 and making a new .kdesvn-buildrc
based on the new sample file.
file INSTALL cannot copy file
CMake Error at workspace/plasma/generic/scriptengines/python/cmake_install.cmake:76 (FILE):
file INSTALL cannot copy file
"/home/kde-devel/kdesvn/kdebase/workspace/plasma/generic/scriptengines/python/plasmascript.py"
to "/usr/lib/python2.6/site-packages/PyKDE4/plasmascript.py".
Call Stack (most recent call first):
workspace/plasma/generic/scriptengines/cmake_install.cmake:39 (INCLUDE)
workspace/plasma/generic/cmake_install.cmake:42 (INCLUDE)
workspace/plasma/cmake_install.cmake:38 (INCLUDE)
workspace/cmake_install.cmake:90 (INCLUDE)
cmake_install.cmake:39 (INCLUDE)
The first time I ran kdesvn-build, kdebase failed to compile due to this error. A quick search pointed me to this Techbase page, which says
try to set: -DPYTHON_SITE_PACKAGES_DIR=~/.local/lib/python2.6/site-packages (check that this path corresponds to something in your system, you might have a different version of python) as a parameter for cmake (or cmakekde)
I had no idea how to do that, so I asked on IRC and was suggested to run cmake . -DPYTHON_SITE_PACKAGES_DIR=[...]
in the kdebase build directory:
cd ~/kdesvn/build/kdebase
cmake . -DPYTHON_SITE_PACKAGES_DIR=~/.local/lib/python2.6/site-packages
make
make install
Other problems
I didn’t run into any other problems, but if you do, I recommend that you check out Troubleshooting on Techbase and see if you find a solution. Sometimes some modules simply won’t compile, with a higher risk on Mondays. Visit Dashboard to see the build status.
6. Run
Now finally for the fun part – trying out new features in trunk. You can find more information about this topic on this page.
Launch applications
Sometimes I want to launch the trunk version of individual applications from my stable KDE SC session, for example if I want to see if I can reproduce a bug. To handle things like the DISPLAY
variable I use sux, which is available in many distribution repositories. (If you’re an Arch user like me, you can get it from AUR).
For example, to run Dolphin:
sux - kde-devel
<write kde-devel password>
dolphin
As simple as that. The -
after sux
is very important – it ensures that the environmental variables we set in /home/kde-devel/.bashrc
are used.
Start a new session
You can also start a full KDE trunk session, but first you need to tell your login manager how to start it. For KDM this is done by adding a desktop file to `kde4-config --prefix`/share/apps/kdm/sessions/
.
We want to add it to our stable version of KDM, so make sure to use another user than kde-devel
for the following commands (you’ll need root privileges):
cd `kde4-config --prefix`/share/apps/kdm/sessions/ # use kde-config if you're on KDE SC 3.x
cp kde.desktop kdetrunk.desktop
<your favorite editor> kdetrunk.desktop
Change the lines (yours might differ slightly)
Exec=/usr/bin/startkde
TryExec=/usr/bin/startkde
to where you’ve installed trunk, in my case
Exec=/home/kde-devel/kde/bin/startkde
TryExec=/home/kde-devel/kde/bin/startkde
and Name=KDE
to something else, for example Name=KDE trunk
.
That’s it. Now you can start a new session (Leave -> Switch User from the default application launcher), choose “KDE trunk” and login with your kde-devel
user. To switch between sessions, you can use Ctrl-Alt-Fx
, usually Ctrl-Alt-F7
and Ctrl-Alt-F8
.
It’s also possible to run a nested session, see Techbase for more information.
Tips
I hope this has helped some to build KDE SC from SVN, and I look forward to hearing your feedback. Before I go back and play around in trunk, I’ll share some tips with you.
Make it easier to run kdesvn-build
By adding kdesvn-build to your PATH
, you can run the script by simply typing kdesvn-build
. I do this by making a symlink in ~/.bin
and adding that directory to PATH
:
su - kde-devel
mkdir -p .bin
ln -s kdesvn/kdesvn-build/kdesvn-build-<version>/kdesvn-build .bin/
and add the line
PATH=$PATH:$HOME/.bin
to ~/.bash_profile
. Next time you login you can simply use the command kdesvn-build
.
Make it even easier to run kdesvn-build
If you like to update often, you can add kdesvn-build to your regular user’s application launcher.
- Run
kmenuedit
- Navigate to where you want to put kdesvn-build
- Click on New Item in the toolbar and name it kdesvn-build
- Click on the icon to choose a nice icon for the menu item
- Enter
<path to kdesvn-build>
in Command, for example/home/kde-devel/kdesvn/kdesvn-build/kdesvn-build-<version>/kdesvn-build
- Click on Advanced and check Run in terminal and Run as different user
- Write
kde-devel
as username and click on Save in the toolbar
If you use Konsole as your terminal you can add --noclose
in Terminal options to make it stay open after the build is finished.
Check logs for errors
If a module failed to build, it’s often a good idea to check the logs to see what went wrong. By default kdesvn-build stores them at ~/kdesvn/log
. I’ve found it useful to make a symlink to the latest logs in the home direcory of kde-devel
:
ln -s ~/kdesvn/log/latest/ ~/log
Pause kdesvn-build
So kdesvn-build is halfway through compiling kdebase when you realize you want to watch a HD movie – what to do? No worries, you can easily pause the script (this won’t work if you use the tip from “Make it even easier to run kdesvn-build”).
To pause the script, press Ctrl-Z
. You’ll see something like
[1]+ Stopped kdesvn-build
The number within the brackets is the job number, in this example 1
. To resume it, run
fg 1
where fg
stands for foreground and 1
is the job number.
January 21, 2010 at 0:13
Hey Hans,
I’m in a hurry so I didn’t read your whole post (will tomorrow am) but I was wondering one thing – is the KDE from SVN installed locally, i.e, only for, in your case, the kde-devel user? Or is it system wide?
I’m interested in trying to compile KDE from Trunk but I wouldn’t want to break my current KDE 4.4RC1 install. I’d normally use VBox but it doesn’t support KWin compositing so it’s a little dry.
Thanks!
January 21, 2010 at 0:20
@zak89:
It’s installed locally for one user (kde-devel). The same applies to qt-copy, by the way. You can also use your usual user and switch environments with scripts, but I like to have a separate user to run trunk for simplicity.
January 21, 2010 at 0:32
You should think about using a chroot environment for developing and testing. This way you keep your system clean and working and don’t have to deal with prefixes, special users and linking against wrong versions etc..
January 21, 2010 at 0:47
Basically this is what I do too, create a new account, log on to new account, create a bash script that places the kde/qt dirs (/opt/) in the path first. download kdesvn-build extract it, compile/install the dependencies. Then I copy the compiled dirs kde and qt4 to /opt. copy the bash script I created with paths setup as another file to the regular user.
Login as regular user into failsafeX session, delete existing .kde/.qt dirs (hopefully no important data there). source bash_script then ./startkde &
then testing 🙂 and bug reports
January 21, 2010 at 8:12
What terminal and font for the terminal are you using? They look good. 🙂
January 21, 2010 at 10:54
Great one, thanks for sharing especially the “sux” command, which I didn’t know (arch has it in unsupported, so no packages).
May I adopt my “guide” how to build KDE ~/trunk in Arch Linux with the experience you share here?
http://forum.kde.org/viewtopic.php?f=14&t=84678
Regrads,
Georg
January 21, 2010 at 11:47
@Pierre:
Thanks for the suggestion. For now I’m quite happy with this separate user approach, but I might try chroot in the future.
(I was going to link to a tutorial in the KDE forums, but STiAT already posted the link above. :D).
@slashdevdsp:
You shouldn’t have to delete .kde/.qt if that’s what your regular user uses. For example, you can set
when you use trunk.
By the way, why don’t you set the install path to /opt in ~/.kdesvn-buildrc instead of manually copying?
@Wei:
The terminal in the screenshot is Konsole with Terminus.
@STiAT:
Of course! Thanks for sharing your guide as well, it’ll be useful if I decide to try the chroot approach.
January 21, 2010 at 15:07
I think it is unnessary to create this kde-devel user:
Just run setup .kdesvn-buildrc with sensible defaults and then run it to first get all packges –no-build option
Next run the git clone and DPYTHON_SITE_PACKAGES_DIR as stated above. Wait for the build to complete.
Assuming you have installed QT to ~/kde4git/qt4git and KDE to ~/kde4git create a .bashrc file with
export QTDIR=/psfhome/karthik/kde4git/qt4git
PATH=”$QTDIR/bin:$PATH”
export KDEDIR=$HOME/kde4git
export KDEDIRS=$HOME/kde4git
export KDEHOME=$HOME/.kde4git
export PKG_CONFIG_PATH=”$QTDIR/lib/pkgconfig”
PATH=”$KDEDIR/bin:$PATH”
export LD_LIBRARY_PATH=”$KDEDIR/lib:${LD_LIBRARY_PATH}:/usr/lib/kde4:/lib:/usr/lib:/usr/local/lib”
export QT_PLUGIN_PATH=$KDEDIR/lib/kde4/plugins
If you have kubuntu then create a ~/.xsession with (use absolute path here)
exec /home/karthik/kde4git/bin/startkde
Then logout. select in KDM “session – Default”. Your setting regarding the new KDE-SC are stored in ~/.kde4git so your original settings are unmodified ! you can revert back to the stable kdesc whenever you require by logging in as “Session – KDE”
January 21, 2010 at 17:19
thank you very much for this post. I was thinking about build ing kde from svn from a long time, but i’m very lazy and always thought it would be too troublesome… then i read your post and it seemed so simple, i gave it a try and i did it at the first shot!
thank you again 🙂
January 21, 2010 at 19:03
@Karthik:
Yes you can use your regular user, and I also mentioned it briefly in the text. However, since I’m quite new to this (in fact I learned a lot by writing this blog post), it feels more “clean” and safe to use a separate user for trunk.
It’s nice that you write your method. There’s one thing I wonder, however – if I want to use my stable KDE SC version, won’t my environmental variables be messed up if I use that .bashrc? Or do you switch .bashrc before logging in?
Wouldn’t it be better to put that stuff in a separate file and source it when needed?
@Ex:
That’s great to hear 😀 the kind of response I hoped to see when writing this. Thanks for taking the time to post a comment, it makes me motivated to continue to write posts such as this one.
January 22, 2010 at 1:25
the reason I manually copy over to /opt is because if something breaks in the default builddir (say for example kdelibs failed) but all others compiled, I would be using stale kdelibs from previous version along with newer versions of others in trunk.
January 22, 2010 at 11:32
@Hans
>>It’s nice that you write your method. There’s one thing I >>wonder, however – if I want to use my stable KDE SC >>version, won’t my environmental variables be messed up
It will be messed up.
>>if I use that .bashrc? Or do you switch .bashrc before >>logging in?
In my office we have LDAP accounts so I have in my .bashrc the following:
“if hostname=”myhostname” then “/kdesvn/path/enviroment” otherwise use the default “distro KDE”
>>Wouldn’t it be better to put that stuff in a separate file >>and source it when needed?
From my experience in the last 5 years if SVN compiles correctly then KDE _just works_ I do not go back to the “distro installed” kde
January 23, 2010 at 16:38
Thanks or the clarification slashdevdsp and Karthik.
@slashdevdsp:
kdesvn-build has a
--no-install
switch, but I guess manually copying works as well. =)January 23, 2010 at 17:58
hi,
the trunk kde can be installed system wide and no special user for building is required – it you don’t worry to do it as root. i installed a week ago:
1) download the script and install it in /root/kdesvn
2) copy the example rc file in to /root/.kdesvn-buildrc
3) edit the kdesvn-buildrc and change the install locations for qt and kde:
kdedir /opt/kde4
and
qtdir /opt/qt4
in the ‘global’ section.
4) compile and install using the kdesvn-build script
once the kde sc is compiled and installed (i had to try several times unless i had all the necessary libs and devel packages instaled), create a script containing:
#!/bin/bash
export PATH=/opt/kde4/bin:$PATH
export KDEHOME=~/.kde4svn
export KDEDIR=/opt/kde4
exec /opt/kde4/bin/startkde
and place it somewhere in the $PATH – of course with the ‘x’ permissions. then you can add the script to your kdm and enjoy the brave new kde! because the KDEDIR is set in the launcher script, the trunk kde will use it’s own place to store configuration and data, so it will not break your existing kde installation. i am able to switch between the trunk kde and the kde 4.3.4 (installed under /usr). the kde 4.3 apps are working under the trunk kde just fine.
ps: i used this scenarion under mandriva 2010.0
January 25, 2010 at 19:46
Thanks for the tip sine.nomine. I probably wouldn’t run the script as root, but rather do something like slashdevdsp (see comments above).
There are some benefits to install it as user instead of root, see e.g. http://techbase.kde.org/Getting_Started/Increased_Productivity_in_KDE4_with_Scripts#Why_install_as_user_and_not_as_root.3F
But well, some might like to have trunk installed system-wide, so why not. 🙂