Georg Grabler (STiAT) - blog

Life is like an endlessly recursive fractal of perverse pain and suffering.

Category Archives: KDE

1 Monitoring, 2 Amarok – JuK

I know I was hardly working on JuK lately (not at all to be true), due to other favoured projects as building a own agent based system monitoring framework. I’ve given up that task though, it’s a lot of quite complex work doing this cross-platform (all flavours of unix and windows, mainframe interfaces etc).
Also, I completely underestimated the “pro-active monitoring” suites, which is basically easy if you do it protocol based, but a lot of harder concept-wise.
Besides that it’s a lot of work, I proved my current concepts quite wrong, and have no intention to start over from the start there again.

I decided I’ll work some on JuK again. I was using Amarok lately, because all people say it “rocks”. Maybe it “rocks”, because on my desktop it does play rock (metal) music. But the application itself? I don’t know. I have not succeeded yet getting Amarok to play my playlist randomly, and repeat the playlist. I can just “sort” it randomly by clicking, what’s not too nice in my eyes, while I couldn’t find the “repeat playlist” at all, not even after spending 30 minutes looking + using google. I’m pretty disappointed about that.

So – what’s next? I’ll move on now, no, not away of KDE, but back to JuK. I’ve plans spending some time again there, and I’ll definitely start out porting the last parts of JuK to Qt4 before messing around with other stuff (playlist management in example). I’d also like to make some changes to the UI, especially the playlist / collection management, but I’m not sure how many guys would disagree with that :-).

Anyway, I decided I’ll take the task of finishing the port, to get it pushed by mpyne again, and will apply for an SVN account then. I’ll go on porting first to see if I really have enough time contributing to KDE.

KDE ~/trunk in ArchLinux

In this tutorial, I describe how to build kde trunk on ArchLinux, using several tools, and providing you with configuration. This is a tutorial for KDE developers (or those who want to become a KDE developer), not for end users.

Basic Design

I decided I want the KDE trunk to be built in it’s own “sandbox”, meaning in a completely closed environment. This is done using a chroot, with basically a 2nd ArchLinux installation on your machine.
I do this for one simple reason, it is possible that you need more recent libraries for the kde trunk, and you may not want to mess up your system with other unstable libraries. You of course could also build and install unstable libraries into your home directory, but I like a closed environment better. Also, there have been problems installing kde to a custom directory lately, due to which is part of kdebase-workspace. To avoid this troubles, and even being able to push kde to /usr, I decided for a chroot.

Also, you’re able to do this on machines where you don’t even have root access, even though, you’ll have to change a few parts on the tutorial.

All this boils down to install Arch stable for your private use on your main installation, and a Arch “sandbox” in a chroot.
First Step – chroot environment

There is a great guide how to set up a chroot in Arch in the Arch Linux wiki. It is basically described how to build a Arch32 chroot in Arch64, but with some simple modifications you can also build a Arch64 chroot in Arch64. I’ll anyway describe here how to do it, if it doesn’t work out for you, you may want to read the guide. You’ll find the link in the Ressources section of this tutorial.
First of all, you can set up your arch chroot in any directory, and it must not be /opt, as in my case. This can depend on your partition settings – how ever you like.

mkdir /opt/arch-chroot
cp /etc/pacman.conf /opt/arch-chroot
cp /etc/pacman.d/mirrorlist /opt/arch-chroot
mkdir -p /opt/arch-chroot/var/{cache/pacman/pkg,lib/pacman}
pacman --root /opt/arch-chroot \
--cachedir /opt/arch-chroot/var/cache/pacman/pkg \
--config /opt/arch32/pacman.conf -Sy
pacman --root /opt/arch-chroot \
--cachedir /opt/arch-chroot/var/cache/pacman/pkg \
--config /opt/arch32/pacman.conf \
-S base base-devel sudo ttf-bitstream-vera ttf-ms-fonts
rm /opt/arch-chroot/{mirrorlist,pacman.conf}
cd /opt/arch-chroot/etc
ln -f /etc/passwd* .
ln -f /etc/shadow* .
ln -f /etc/group* .
ln -f /etc/sudoers .
ln -f /etc/resolv.conf .
ln -f /etc/localtime .
ln -f /etc/locale.gen .
ln -f /etc/profile.d/ profile.d
cp /etc/mtab .

There is a rc-script which is used to start the Arch chroot. You can add this to your rc.conf if you like.
You can save this file to /etc/rc.d/arch-chroot

You can also download it from >here<

. /etc/rc.conf
. /etc/rc.d/functions
case $1 in
stat_busy "Starting Arch chroot"
    mount --bind /proc /opt/arch-chroot/proc
    mount --bind /proc/bus/usb /opt/arch-chroot/proc/bus/usb
    mount --bind /dev /opt/arch32/dev
    mount --bind /dev/pts /opt/arch-chroot/dev/pts
    mount --bind /dev/shm /opt/arch-chroot/dev/shm
    mount --bind /sys /opt/arch-chroot/sys
    mount --bind /tmp /opt/arch-chroot/tmp
    mount --bind /home /opt/arch-chroot/home
    add_daemon arch-chroot
    stat_busy "Stopping Arch chroot"
    umount /opt/arch-chroot/proc/bus/usb
    umount /opt/arch-chroot/dev/pts
    umount /opt/arch-chroot/dev/shm
    umount /opt/arch-chroot/dev
    umount /opt/arch-chroot/sys
    umount /opt/arch-chroot/tmp
    umount /opt/arch-chroot/home
    rm_daemon arch-chroot
    $0 stop
    sleep 1
    $0 start
    echo "usage: $0 {start|stop|restart}"
exit 0

As the next step, you must chmod the file to be executable, and you should enter your chroot.

chmod +x /etc/rc.d/arch-chroot
chroot /opt/arch-chroot

Installing the KDE build dependencies

pacman -Sy subversion git bzip2 libxslt libxml2 libjpeg \
libungif shared-mime-info mesa boost dbus \
openssl pkgconfig xine-lib clucene redland \
gpgme hal cmake qt qca libical lcms xorg-server perl-libwww\
automoc4 akonadi eigen taglib soprano strigi qimageblitz phonon \
pulseaudio xorg-server gstreamer0.10-good-plugins

Setting up your KDE Development user

This step is important. You may not want to crash your local kde user and ~/.kde4 or ~/.kde directory. Since this needs environment variables, as well as your KDE install will need them, we create a own user for this.
Make sure your user is added to all groups you need for kde development, in example if you need sound or device plugging. This example includes my current configuration.

useradd -g users -G disk,wheel,games,kvm,dbus,hal,network,video,audio,optical,floppy,storage,power,policykit -m kde-devel -s /bin/bash
passwd kde-devel

Next, you should edit your ~/.bashrc
Add the following pathes and settings. This must be local user settings, if you use ksh or another shell for your user, make sure this settings work!

export QTDIR=$HOME/qt4
export PATH=$QTDIR/bin:$PATH
export PKG_CONFIG_PATH=$QTDIR/lib/pkgconfig:$PKG_CONFIG
export KDEDIR=$HOME/kde

export PATH=$KDEDIR/bin:$PATH
export QT_PLUGIN_PATH=$KDEDIR/lib/kde4/plugins

export DISPLAY=:1


kdesvn-build is a tool to easen installing the KDE repositories, this will easen up things a lot.
kdesvn-build must be configured properly. I provide my current configuration for you to download >here<

The configuration should work out of the box, I’ll describe shortly some of the options I edited.

First of all, the qt-kde git repository is fetched by http, because kdesvn-build has problems with git urls for some unknown reasons.

Also, you currently need to build phonon first form the qt repository, and then from the kdesupport library. I don’t really know why, maybe has to do with the qmake configuration parameters available building qt with phonon. This trick comes from Thiago Macieira, some KDE users on #kde-devel in IRC told me about that it’s currently needed.

Now, you should download the latest kdesvn-build from the official kdesvn-build page, extract it, and copy the kdesvn-build file in the user directory of the kde-devel user.

After you have this, kdesvn-build directory should include kdesvn-build and .kdesvn-buildrc

Now, run kdesvn-build, and ensure that you include the option –no-snapshots the first time you run it. This has the reason that kdesvn-build prefers snapshots on the first checkout, updating just a few files later. The problem is, that the svn snapshots of kde are broken (in example taglib/admin is fetched of 3.5 branch, which is just one of a lot of problems in the -svn snapshots I stumbled over).

Also note, that kdesvn-build obviously has problems building kde to /usr and qt to a custom directory at the same time. I talked Michael Pyne (maintainer of kdesvn-build) about this, but decided I will try to fix the bug myself, due to the reason that I can reproduce the problem. The version at the time writing (1.10) is still broken.

./kdesvn-build --no-snapshots

Afterwards, your ~/ direcotry should look like this:

drwx------ 9 kde-devel users 4096 2009-12-13 19:38 .
-rw-r--r-- 1 kde-devel users 6 2009-12-13 19:38 .kdesvn-lock
-rw-r--r-- 1 kde-devel users 12419 2009-12-13 19:37 .kdesvn-buildrc
-rw-r--r-- 1 kde-devel users 2786 2009-12-13 19:37 .kdesvn-build-data
drwxr-xr-x 2 kde-devel users 4096 2009-12-13 19:27 .config
drwxr-xr-x 10 kde-devel users 4096 2009-12-13 18:59 qt4
-rw------- 1 kde-devel users 2077 2009-12-13 17:58 .bash_history
drwxr-xr-x 3 kde-devel users 4096 2009-12-13 17:33 .subversion
drwx------ 3 kde-devel users 4096 2009-12-13 17:17 .dbus
drwx------ 3 kde-devel users 4096 2009-12-13 17:14 .kde4
-rw-r--r-- 1 kde-devel users 674 2009-12-13 17:13 .bashrc
drwxr-xr-x 7 kde-devel users 4096 2009-12-13 06:22 kde
drwxr-xr-x 19 kde-devel users 4096 2009-12-13 05:23 kdesvn
-rwxr-xr-x 1 kde-devel users 208941 2009-12-09 02:39 kdesvn-build
drwxr-xr-x 6 root root 4096 2009-12-08 20:15 ..
-rwxr-xr-x 1 kde-devel users 182 2009-02-09 22:43 .xinitrc
-rwxr-xr-x 1 kde-devel users 100 2009-02-09 22:43 .xsession
-rw-r--r-- 1 kde-devel users 16 2009-01-28 20:30 .bash_profile

Running kde trunk using Xephyr

Xephyr is a tool for nested sessions which shipping with the XOrg server. In archlinux the package xorg-server includes Xephyr, which was installed in the first chapter.
Switch into your chroot, and start Xephyr:

sudo chroot /opt/arch-chroot
/etc/rc.d/dbus start
Xephyr :1 -extension GLX -screen 1024x768 &;

You could also use a script to do this for you, and put it into your PATH (/bin/sbin) in your chroot environment:

if [ ! -e /var/run/ ]; then
    /etc/rc.d/dbus start
    /etc/rc.d/dbus stop
if [ -e /var/run/ ]; then
    rm /var/run/

/etc/rc.d/dbus start

Xephyr :1 -extension GLX -screen 1024x768 &

Start your KDE session

su - kde-devel

Keyboard Layouts

If you’re using evdev, you’ll very likely experience problems with your default keyboard layout and keymappings in Xephyr, since Xephyr uses XKB.
Now, there’s a simple workaround for this, run as user (in example on your primary system with your primary user)

xmodmap -pke > ~/.xmodmap
mv .xmodmap /home/kde-devel/.xmodmap

Now autostart xmodmap when your kde4 session starts:

su - kde-devel
vi .kde4/Autostart/xmodmap
xmodmap ~/.xmodmap
chmod +x ~/kde4/Autostart/xmodmap


ArchLinux Wiki (Arch32 chroot on Arch64)
KDE Techbase (Getting Started/Build/KDE4)
KDE Techbase (Getting Started/Increased productivity in KDE4 with Scripts)
KDE Techbase (Getting Started/Build/KDE4/ArchLinux)
KDE Techbase (Getting Started/Set up KDE4 for development)

JuK – won’t continue .. for now

I won’t continue developing / porting JuK for now. The reason is quite obvious, and a very sad one. Michael has some personal difficulties, and stepped down (for now) as a Maintainer, not contributing for some time to KDE – for now. No other member of the kde-multimedia community answered my request for reviewing my patches. This most likely means, nobody is interested at all. Since I have no intentions to step in as maintainer, until Michael is back, I’ll simply wait for his return (hopefully he will be back one day).

This means, in favour of my current new playground project, I’ll drop continueing the development of JuK – at least until Michael is back.

Last but not least, Michael: Take the time you and your family need. We’re all with you with our mind, soul and heart.

For QTiNT: I didn’t get along too well. At work, I’m missing the time, due to the reason that a colleague of mine is in holidays (which causes a huge amount of workload to me *grr* – start doing things right Markus!).
I’ve been busy with getting my ubuntu 32bit kvm running for oracle-xe (couldn’t get oracle installed on arch linux, and oracle-xe which I prefer for playgrounds has no 64 bit version), and getting the server side of TiNT running on my laptop, so I can continue working at home.
I’m done so far, but it seems as if the first data import failed at some parts (views), which causes some problems which I hope to solve tomorrow, so I can work on that this weekend.
Since I don’t feel too well (I’m a bit ill), I’ll spend a lot of time at home this weekend, and should have a lot of time to get something done.

@Lore: <wave> ;-).

Amarok vs JuK – aka “wasting your time”.

Did you ever wonder “Why the heck there is JuK? Why are there guys working on it?”? I’ve been asked this question some times now when I told somebody I’m spending time on JuK. But what is the reason for this? Basically nobody bothers using JuK.

Of course, we know that there is Amarok around.  We know it has a lot of more features, and is a better MP3 Player than JuK will ever be. Maybe, Amarok will replace JuK one day in KDE, even though, I don’t know why it is not replaced already. I think the Amarok team doesn’t want to handle with the KDE release management, but have their own.

Well, I’ve my reasons to develop JuK. First of all, I use it as a MP3 player. It’s my favorite for NOT having a lot of options, it just works, and just plays music.  That’s important to me, allthough, I also have Amarok installed, using it when I can’t use JuK because I work on it at this time.

The second reason is, that JuK needs quite a lot of work. It needs to be ported to KDE4 (remove k3support, which I have pretty much now). Also it would be needed rewriting the JuK backends, the interface could need some love as well, an options dialog would be great and so on. So you see, there’s a lot of interesting stuff to do. Stuff, I’ve never done before, never bothered with, things I don’t know, new things.

Even when I’m not getting along as I’d like to (my social life is time hungry), I can learn a lot of stuff working some on JuK. Even when nobody bothers using the program, I’ve fun developing it, I like it, and I want to learn by working with people as Michael (who’s a really great guy, as the rest of the KDE community).

As you can see, mostly selfish reasons. Yea, I’m a selfish person from this point of view, because I probably could help somewhere what really matters. The thing is, it’s my free time, I can do what ever I want, and I currently like what I’m spending the little spare time I can enjoy in front of the PC on.

Not said, that I won’t move on one day. If JuK gets replaced as the “default”, I probably will be looking for something else to do, or I keep with JuK. But until then, I enjoy my free time on what I want.

And now please stop asking “why the heck are you wasting your time?”. I don’t waste it, I enjoy it, and can learn within that, and I’m learning Qt and some KDE development (and Qt is a great framework). Just because I’ve developed much more complex things in the past, doesn’t mean I enjoyed it nor it means that I always want to keep on with projects I’ve been working on for almost 7 years now. Yes, I had a lot of fun writing the firewire drivers for industrial cameras, yes I had a lot of fun in image manipulation and cascade calculation, object recognition, AI systems and so on. It was just time to move on, to do something different. I enjoyed working with you, all of you (no names). You’re a great bunch of guys, but please consider that you’re paid for that, I am not. I spend my spare time on what ever I want, and my personal interests changed.


JuK – Progress?

None! Yea, I’m a bit lazy lately. I’ve started two new things in JuK development.

First of all, I’m still on removing k3support of the playlist. This is a quite huge task, and even needs a little part of refactoring the playlist down even to the core playlist.cpp which uses klistviewitems.

Secondly, I started refactoring the backend to something more modular. The current layout not existing abstraction of the playlist from the caching backend (not providing a clean api to use) is blocker for implementing mutiple backend interfaces as a QSLITE or MySQL interface, or even other data storage caches.
Also it makes it nearly impossible to thread the playlist reading, or to make the playlist “fetchmore” compatible. The first step on this which I’ll take is to split the data backends clearly from the main playlist handling code of JuK Also, it must be considered how to handle playlists in the future. Different data backends provide different posisblities.

I hope one day, as soon as those basic things are solved, we can move on improving JuK in a visible way.