Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › KDE 4.6 tutorial (or above) with kdesrc-build [updated for oxygen-gtk]
New Posts  All Forums:Forum Nav:

KDE 4.6 tutorial (or above) with kdesrc-build [updated for oxygen-gtk]

post #1 of 7
Thread Starter 
So I've taken what they have on their site and was able to create my own build of KDE with whatever modules/programs I want. I have figured out what was moved to git, what wasn't, and what git things may or may not work. Here is a little guide on how to get there if you want, advice welcome.

First off, you need to find a way to get kdesrc-build. They have do have a good write up on getting kdesrc-build itself:

http://techbase.kde.org/Getting_Star...l_kdesrc-build

I'm going to say skip setting up your .kdesrc-buildrc and use the one I'm going to provide as a base for the install/build process. They have currently moved to GIT for most of the packages and didn't update the .kdesrc-buildrc properly. How unfortunate.

Before you can actually compile I'd recommend getting the proper dev files. This is talked about in their tutorial. For Debian I had to dip into experimental repositories, something you should ONLY enable for the soul purpose of getting specific files (such as this). Never have them enabled for regular updating, EVER.

Dependencies:
http://techbase.kde.org/Getting_Star...r_distribution

That has a general guide to follow. Unfortunately there are some blind spots, especially when things fail and they don't tell you why. That's EXTREMELY annoying, so your on your own with that, sorry.

Now comes the fun part, the building..... build..... build.... build....

-Addition- It seems I left out the build command, it's really a trivial problem. You mainly just run ./kdesrc-build and everything builds automatically. You can use the standard --help flag and also can build independent modules, just use ther name at the end:

./kdesrc-build <module name>

That's pretty basic, hopefully you don't have trouble with that. You may want to use a couple flags, at least there were two that I used for everything. I used --refresh-build and --disable-snapshot=true, this was added every time I ran kdesrc-build. I don't think you need --disable-snapshot=true, it's only used for fixing one module (I think), but the --refresh-build is recommended every time you want to compile a module from scratch.

-Addition- I forgot about chaining the modules together in one command. This is useful if it spits out a set of modules that didn't compile, such as kdelibs, module1, module2. What happens is that the other modules depend on something like kdelibs and won't build unless it builds. So you need to find out why kdelibs doesn't build, for whatever reason (the errors can be extremely vague), and then get it to build. After that you can do the rest, and even specify the order:

./kdesrc-build <flags> module1 module2 module 3

You can do that and it will build them in order, module1, module2, and then module3. This is nice, you don't have to do one at a time or wait for the entire script to finish. There is also a command to start building from a specific module, --resume-from=<module> but I found that kind of dumb because it won't skip built modules then. Rather I would just take my list of modules and chain them all after kdesrc-build. If they didn't build then and weren't thought of as essential yet I ignored it, such as kdemultimedia, and just focused on getting the core modules to work.

If you run into problems, you might have to use some archives instead of the SVN/GIT repositories. I had a couple that wouldn't build, for whatever reason. I used two sources for the following solution. The first source is in the .kdesrc-buildrc but I'll give it to you here:
https://projects.kde.org/projects

You might have to navigate through to the proper module's GIT repository and manually download it somewhere. I'm not exactly sure why this happens but for some reason kdesrc-build doesn't properly handle all GIT repositories. This was only for a few, so it wasn't much work. I opted just to get the archive file instead of using git, but as long as you get a fully pulled repository from there it doesn't matter how. When you pull from these the files have to be moved to:

<path to>/kdesrc/<module>

That however didn't always work either, for some reason some of the GIT repositories didn't have modules that would build. For whatever reason I used a link from transhour to get archives to extract to the proper module directories. This link is here:

http://mirrors.isc.org/pub/kde/stable/4.6.0/src/

--Addition-- The kdebase package in the mirror can completely replace the original module. I've recently had to do this because kde-baseapps won't build this time around, after I moved everything to /opt/kde. I bet future releases will do the same, and you can probably manually install it into your kde directory without kdesrc-build and it will cover whatever programs depend on kde-baseapps. It also seems that you can take the konq-plugins and add it to the kdebase package in the link, compiles fine and then there is no difference between the two packages.

That covers getting everything to build properly, or at least it did over here. Now came the fun part. I was working with GDM so I'm not sure how this works with KDM. If anyone wants to let me know I'll add it, but for now it's just GDM.

If you want to read on how they say to run things you can: (sessions only, you can navigate to other options though)
http://techbase.kde.org/Getting_Star...KDE_4_sessions

I made a quick and dirty way by using this script + CLI.

Code:
#! /bin/bash
export DISPLAY=:0
<location to kde folder>/kde/bin/startkde
Make an sh script with that, make it executable, and then run it like this:

X & <script name>

That's a really dirty way to get a KDE session, I couldn't make it as a whole script or it would give me the error that my user can't run X. I don't know why as I could run X alone, outside of a script, but not in a script. However, that worked for me. I originally tried the xypher method from the link above but somehow caused it to run on top of my current DE. Of course I just killed X and then started working on getting it to run just KDE, since I then knew it at least ran. I also couldn't do it as a single command, it would give me $DISPLAY not set or something. This script worked for me, it at least got me to test the desktop. Hopefully you can use one of the options in the link to test in a nested xserver, I couldn't.

Now, you may or may not get it to work with just those examples. However, I had to edit my startkde script. I used a hack/mod of the method they used, by putting the following at the top of my startkde script in ~/kde/bin:

Code:
export KDEDIR=<location to kde folder>/kde/bin
export LD_LIBRARY_PATH=$KDEDIR/lib
export PATH=$KDEDIR/bin/:$PATH
export KDEHOME=~/.kde4
They had "KDEDIR=KDEDIR=`kde4-config --prefix'" and I couldn't get that to work, so I hard coded my location in. If you build kde in another location modifying the kdesrc-buildrc you will have to put your location in.

If all goes well you should be able to drop into shell and run this and get a fully working desktop. That's great, but what about GDM? This is where this all comes together, you use all of the previous edits (except my dirty hack script) to run GDM. You'll now need to edit a .desktop file, the locations are talked about in the link above. I said I'm going to use GDM so the files for that should be in /usr/share/xsessions. You can use an older file as an example, such as kde.desktop, or my example below:

Code:
[Desktop Entry]
Encoding=UTF-8
Type=XSession
Exec=<location to kde folder>/kde/bin/startkde
TryExec=<location to kde folder>/kde/bin/startkde
Name=KDE4
Comment=The K Desktop Environment. A powerful Open Source graphical desktop environment
X-Ubuntu-Gettext-Domain=desktop_kdebase-workspace
Name[en_US]=KDE4
You'll need to put in the proper paths, just as before, but that should get it working in GDM. I ran into a problem with my setup, I had to have the startkde scripts located in /usr/bin for some reason otherwise it wouldn't show up. To remedy this I moved the original /usr/bin/startkde to /usr/bin/startkde.bak and made copies of <path to kde dir>/kde/bin/startkde in /usr/bin and everything worked fine.

After all of this you should have an up to date KDE 4.6! The hardest part was to figure out how they had interfaced the GIT with kdesrc-build. They giave me examples to add them but never told me that the kde-git they had initially included had the modules, that I just had to add them. They also don't completely let us know if kdebase is depreciated or not, so I used the packages link from transhour to download it and add it to kdesrc/<module>. I didn't test if I actually needed to build it, I just assumed, however it all works and I'm not going to go back and re-assess that. So, if somebody builds without it I and lets us know that would be nice.

Thanks goes to transhour, without the links I'd probably never have gotten it to build as quickly.

[updates]

If you want your GTK themes to fit well with KDE Oxygen theme you will need to install the oxygen-gtk module. After you do this you can make a script file, like oxygen.rc.sh, and put this inside:

Code:
#!/bin/bash

# Make sure our customised gtkrc file is loaded.
export GTK2_RC_FILES=<path to kde dir>/kde/share/themes/oxygen-gtk/gtk-2.0/gtkrc
After you do that you can log out and back in, oxygen-gtk will now work as the default!

-Addition- Another recomendation is building kwrite, otherwise this self build of KDE won't use a default text editor. I haven't yet bothered to figure out how to edit the paths so it can see the default programs, I'll get to that later. Until then I use kwrite as the default and it works fine.

-Addition- You may or may not need a .bashrc file created. Here's what mine looks like:

Code:
## A script to setup some needed variables and functions for KDE 4 development.
## This should normally go in the ~/.bashrc file of your kde-devel user, so
## that it is executed when a session for that user is started.
##
## If you don't use a separate user, the first section with the
## environment variables should go into a separate script.
 
prepend() { [ -d "$2" ] && eval $1=\\"$2\\$\\{$1:+':'\\$$1\\}\\" && export $1 ; }
 
# Other
# you might want to set a full value for PATH rather than prepend'ing, to make
# sure the your kde3 path isn't in here.
prepend PATH /usr/local/bin
 
# Qt
# only set Qt related variables if you compiled Qt on your own
# (which is discouraged). If you use the distro provided Qt, comment
# out these four lines
export QTDIR=$HOME/qt-kde
prepend PATH $QTDIR/bin
prepend LD_LIBRARY_PATH $QTDIR/lib
prepend PKG_CONFIG_PATH $QTDIR/lib/pkgconfig
 
 
# KDE
export KDEDIR=$HOME/kde
export KDEHOME=$HOME/.kde4
export KDETMP=/tmp/kde4-$USER
mkdir -p $KDETMP
export KDEDIRS=$KDEDIR
prepend PATH $KDEDIR/bin
prepend LD_LIBRARY_PATH $KDEDIR/lib
prepend PKG_CONFIG_PATH $KDEDIR/lib/pkgconfig
prepend QT_PLUGIN_PATH $KDEDIR/lib/kde4/plugins
 
export PATH
export LD_LIBRARY_PATH
export PKG_CONFIG_PATH
export QT_PLUGIN_PATH
 
# XDG
#unset XDG_DATA_DIRS # to avoid seeing kde3 files from /usr
#unset XDG_CONFIG_DIRS
prepend XDG_DATA_DIRS $KDEDIR/share
 
# make the debug output prettier
export KDE_COLOR_DEBUG=1
export QTEST_COLORED=1
 
 
function start3app {
        mkdir -p /tmp/$USER-kde
        export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
        export LD_LIBRARY_PATH=
        export KDETMP=/tmp/$USER-kde
        export KDEVARTMP=/var/tmp/$USER-kde
        export KDEHOME=$HOME/.kde
        export KDEDIR=/usr
        export KDEDIRS=$KDEDIR
        export DISPLAY=:0
        eval "$@"
        source $HOME/.bashrc   #Reset environment variables again
}
There was a dbus section and a make section, I didn't use either. This will probably be needed for path variables (the app section most likely) but not required. Things probably won't be "found" by KDE as easily. Even with this set it still won't find the proper text programs so I can set something other than kwrite. =(

--update-- KDM is built into ~/bin/kdm if you want to start it. You could probably do a syslink to auto-start kdm replacing your old one, or make startup scripts.
Edited by mushroomboy - 2/11/11 at 11:41pm
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
post #2 of 7
+Rep. Good Guide for KDE users- I would follow this but it would just take too long to build.
    
CPUMotherboardGraphicsRAM
AMD Athlon 64 3800+ Windsor Asrock N68C-S UCC XFX 8500GT Passive Cooled 2x Hynix 512MB DDR2 533MHz 
Hard DriveOptical DriveOSMonitor
Seagate 500GB SATA LG Supermulti SATA Lightscribe Debian Sid AMD64/Windows XP x86 Dell 17" TFT 
KeyboardPowerCaseMouse
CTC Keyboard PS2 Antec Basiq 350W Casecom KB-7760 Cheesegrater Logitech Mouse PS2 
Mouse Pad
F1 Magazine 
  hide details  
Reply
    
CPUMotherboardGraphicsRAM
AMD Athlon 64 3800+ Windsor Asrock N68C-S UCC XFX 8500GT Passive Cooled 2x Hynix 512MB DDR2 533MHz 
Hard DriveOptical DriveOSMonitor
Seagate 500GB SATA LG Supermulti SATA Lightscribe Debian Sid AMD64/Windows XP x86 Dell 17" TFT 
KeyboardPowerCaseMouse
CTC Keyboard PS2 Antec Basiq 350W Casecom KB-7760 Cheesegrater Logitech Mouse PS2 
Mouse Pad
F1 Magazine 
  hide details  
Reply
post #3 of 7
Thread Starter 
The longest a module would take to build was about 10-15 minutes on my Quad, which wasn't so bad. there's only like a few that take that long, all in all it would probably take a half hour to an hour to build the whole thing. Which really isn't bad at all, given that it's the entire desktop. You can set it up to build and walk a way for an hour, go do some errands or something. It'll build what it can and then spit out the modules that don't build in order.

You can either start from scratch or build the individual modules again, or chain them specifically. I'll add that cause I just forgot. =P But if you chain them they build in the order you specify, also only building what you specify so you don't have to wait for everything else.

It's really a lot of waiting once you figure out how the kdesrc-buildrc goes for the new git and have gotten the right dependencies. The hardest part was figuring out how they moved the GIT repos and mucking through some of the documentation to figure out that it was much simpler than what they were telling me to do.

[edit] I also used the "make-options -j4" to run parallel threads, which makes things much faster.
Edited by mushroomboy - 2/9/11 at 11:40am
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
post #4 of 7
i'd imagine you'd still have to manual compile and replace the systems core components that are replaced or that have become now defunct cause of the dropping of hal.

unless other distro's have done this already, from my understanding hal has been defunct for awhile now, so they might have already made the changes for you, so all you gotta do is upgrade the kde packages, took me a bit of research but i finally figured out what was causing my problem int he slackbuilds it was me not understanding the changes from 4.5.5 to 4.6, but once i did i replaced the require dep's, and all is work fine and dandy now, even got nice little packages out of it all.

i'm not to sure about swapping out modules or packages that are built for another version of KDE. i'm sure not all packages and components to kde get updated together, the just do it so we aren't going nuts to mix match from other branches when they roll out a new one.
Bazinga Punk
(12 items)
 
ooh shiny!
(6 items)
 
 
CPUMotherboardGraphicsRAM
Intel Xeon 3440 AsRock P55 extreme Evga 8800 GT 512 MB Gskill Ripjaws 
Hard DriveCoolingOSMonitor
Western Digital Blue Antec Khuler 620 Ubuntu 11.10 Asus vw264H 
KeyboardPowerCaseMouse
GIGABYTE KM7600 CORSAIR TX 650 Cooler Master 590 GIGABYTE GM-M6800 
CPUMotherboardGraphicsRAM
Intel Core I5 6500 Gigabyte z170xp-SLI Nvidia 970gtx Corsair 16gb ddr4 2666mhz  
Hard DriveOS
250gb Samsung Evo 850 Windows 10 & Ubuntu 15.10 
  hide details  
Reply
Bazinga Punk
(12 items)
 
ooh shiny!
(6 items)
 
 
CPUMotherboardGraphicsRAM
Intel Xeon 3440 AsRock P55 extreme Evga 8800 GT 512 MB Gskill Ripjaws 
Hard DriveCoolingOSMonitor
Western Digital Blue Antec Khuler 620 Ubuntu 11.10 Asus vw264H 
KeyboardPowerCaseMouse
GIGABYTE KM7600 CORSAIR TX 650 Cooler Master 590 GIGABYTE GM-M6800 
CPUMotherboardGraphicsRAM
Intel Core I5 6500 Gigabyte z170xp-SLI Nvidia 970gtx Corsair 16gb ddr4 2666mhz  
Hard DriveOS
250gb Samsung Evo 850 Windows 10 & Ubuntu 15.10 
  hide details  
Reply
post #5 of 7
Thread Starter 
For the most part KDE doesn't depend on HAL, however Gnome does (for some applications). So I was running without HAL already, as the Gnome dependencies were the HAL libs (not HAL itself). I think the goal is to completely remove HAL, every distro should be phasing that out.

As for core components, everything is built from kdesrc-build, ALL the core modules are put into the KDE directory you choose. I have NO KDE components installed in my distro, everything is built from the KDE source directory.

I still have QT installed, however that's for other things that might depend on KDE QT libs. My main KDE desktop is using the QT I built, so I could probably remove that and build the programs from source that are currently depending on my installed QT libs. I'm not going to do that for now, maybe another day.

[edit]
http://wiki.debian.org/HALRemoval

4.6 has fully removed HAL.

[update]

Debian Testing/Unstable (the new testing, not sqeeze) runs without HAL. If you want GIMP or XFCE (not sure what else currently) than you still require HAL. If I removed XFCE and GIMP I would be on a completely HAL free system. I might do that, build XFCE/Gimp without HAL.
Edited by mushroomboy - 2/9/11 at 3:31pm
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
post #6 of 7
xfce4.8 doesn't require hal, why would gimp require hal?

i have hal disabled, not removed in slackware, but gimp works without a problem, and it wasn't one of the packages i replaced? maybe i should remove hal and see what it breaks
Bazinga Punk
(12 items)
 
ooh shiny!
(6 items)
 
 
CPUMotherboardGraphicsRAM
Intel Xeon 3440 AsRock P55 extreme Evga 8800 GT 512 MB Gskill Ripjaws 
Hard DriveCoolingOSMonitor
Western Digital Blue Antec Khuler 620 Ubuntu 11.10 Asus vw264H 
KeyboardPowerCaseMouse
GIGABYTE KM7600 CORSAIR TX 650 Cooler Master 590 GIGABYTE GM-M6800 
CPUMotherboardGraphicsRAM
Intel Core I5 6500 Gigabyte z170xp-SLI Nvidia 970gtx Corsair 16gb ddr4 2666mhz  
Hard DriveOS
250gb Samsung Evo 850 Windows 10 & Ubuntu 15.10 
  hide details  
Reply
Bazinga Punk
(12 items)
 
ooh shiny!
(6 items)
 
 
CPUMotherboardGraphicsRAM
Intel Xeon 3440 AsRock P55 extreme Evga 8800 GT 512 MB Gskill Ripjaws 
Hard DriveCoolingOSMonitor
Western Digital Blue Antec Khuler 620 Ubuntu 11.10 Asus vw264H 
KeyboardPowerCaseMouse
GIGABYTE KM7600 CORSAIR TX 650 Cooler Master 590 GIGABYTE GM-M6800 
CPUMotherboardGraphicsRAM
Intel Core I5 6500 Gigabyte z170xp-SLI Nvidia 970gtx Corsair 16gb ddr4 2666mhz  
Hard DriveOS
250gb Samsung Evo 850 Windows 10 & Ubuntu 15.10 
  hide details  
Reply
post #7 of 7
Thread Starter 
https://bugzilla.gnome.org/show_bug.cgi?id=592364

GIMP requires HAL stuff currently and the bug report has been sent. I know XFCE doesn't in the new revisions but it hasn't yet hit Debian due to the slow development process. I might build my own, it wouldn't be so bad.

[edit] It's only for input devices. Build without that support and it probably runs fine.

https://wiki.ubuntu.com/Halsectomy
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Linux, Unix
Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › KDE 4.6 tutorial (or above) with kdesrc-build [updated for oxygen-gtk]