Gentoo KDE Guide

Theo Chatzimichos  Author
Tomas Chvatal  Author
Jorge Manuel B. S. Vicetto  Author
Marcus D. Hanwell  Author
Tobias Heinlein  Editor
Joshua Saddler  Editor

Updated November 16, 2009

1.  KDE 3

Introduction

KDE 3 is no longer maintained by upstream, with 3.5.10 being their last release. Also, most KDE 3 applications aren't maintained any more, as they already have been or are currently being ported to KDE 4. The Gentoo KDE Team, provides both KDE 3 and KDE 4 ebuilds for the base KDE and for various applications, and supports a side by side full desktop installation of KDE 3 and 4, including misc KDE applications. Our advice is for you to install and use by default a full KDE 4 desktop, and use only the KDE 3 applications that you feel have yet to be propperly ported to KDE 4 (due to missing features, random crashes etc).

Warning: Keep in mind that since KDE 3 isn't maintained by upstream any more, it is possible and likely that bug reports concerning KDE 3 applications may not be fixed, but rather closed as WONTFIX / CANTFIX / UPSTREAM, or instead kept open for a long time until a fix (patch) is provided.

KDE 3 Removal

Currently KDE 3.5.10 is masked for all architectures, as it is being removed from Portage.

The KDE team has been cleaning up the various KDE 3 applications by removing them from the tree, as they are too old, broken and unmaintained, and by dropping arts support (with major help from Media/Video teams). When this task is finished, we are going to drop arts from base KDE 3 as well.

While using KDE 3 is not recommended due to security and bug concerns, if you must install it, you can find it in the kde-sunset overlay.

Note: This overlay is completely unsupported by Gentoo. It's not maintained by the KDE team, so do not report any issues to Gentoo developers, bugzilla, etc.

2.  KDE 4

Introduction

KDE 4 is the current KDE version supported by upstream. The current KDE 4 version available through Portage is 4.3.1 (this version is considered stable by upstream). In addition, KDE upstream provides weekly snapshots, and a live SVN tree. The Gentoo KDE team provides the snapshots, trunk and latest branch live ebuilds, through the kde-testing overlay. To enable this, the user can have multiple parallel KDE 4 installations, with the use of the kdeprefix USE flag.

Choose what KDE version is most appropriate for you:

KDE from Portage (currently 4.3.1)
KDE snapshots (currently 4.3.X)
KDE live ebuilds

The kdeprefix USE flag

Warning: The kdeprefix USE flag is currently masked. It's unsupported and shouldn't be used by users in any way. Use at your own risk. Read below for the reasons that led to the masking of the USE flag.

The kdeprefix USE flag allows users to choose between an FHS compliant install (-kdeprefix) or a slotted install in the KDE prefix (+kdeprefix).

If kdeprefix is disabled (default) KDE is installed into the FHS compliant location, i.e. /usr. That means that all of the files are put under /usr. This is the desired behaviour for most users. The drawback of the FHS compliant install is that it will not be possible to have more than one minor version of KDE side by side (previous behavior), e.g. KDE 4.3 and 4.4.

Warning: Mixing a +kdeprefix and a -kdeprefix KDE installation is not supported, nor recommended. If you really want kdeprefix in your system, you'll have to unmask it and put it globally in /etc/make.conf

If kdeprefix is enabled then KDE is installed into /usr/kde/${SLOT}, which allows you to install KDE 4.3, live etc. in /usr/kde/4.3 and /usr/kde/live for example.

Warning: If you want to move between kdeprefix and -kdeprefix (or vice-versa), it is recommended that you unmerge all KDE packages and then emerge it with the modified flag. If this is not done, KDE installations can have trouble finding certain libraries/plugins. Check Cleaning Up KDE for more details.

Recently kdeprefix got masked by default, as it caused many problems, like collisions between the same packages when having two or more KDE installations, or strange behaviour even when only one +kdeprefix KDE installation was present in the system.

Great examples of packages with such problems are pykde4 and amarok. Since the Gentoo KDE Team decided to proceed with the stabilization of KDE 4, those issues needed to be resolved first. As it was difficult to fix them, we decided to mask the use flag instead. If you really know what you are doing and you are sure that you want kdeprefix unmasked and enabled in your system, add kdeprefix globally to /etc/make.conf and unmask it by following the instructions below.

Code Listing 2.1: Unmasking the kdeprefix use flag

# mkdir -p /etc/portage/profile
# echo "-kdeprefix" >> /etc/portage/profile/use.mask

Installing KDE 4.3.1 (from Portage)

Note: In order to minimize issues it is recommended to start with a clean environment. Read more in Cleaning Up KDE section.

The installation can be done either by using the meta packages or by using sets.

Code Listing 2.2: Installation of KDE using meta packages

# emerge -av kde-meta:4.3 (contains all of KDE modules)
# emerge -av kdebase-meta:4.3 kdegames-meta:4.3 (installation of chosen modules only)

For installation using sets check the Using Sets section.

Installing KDE 4.3.X snapshots (from kde-testing overlay)

Warning: KDE snapshots are bleeding edge. Use at your own risk.

KDE upstream provides weekly snapshots taken from the SVN trunk tree. KDE now provides 4.3.X snapshot series, and after the 4.4 release they are going to start with 4.4.60. Beta and Release Candidate KDE releases are following the snapshot model below:

Snaphot version KDE Version
4.X.85 KDE 4.X Beta 1
4.X.90 KDE 4.X Beta 2
4.X.95 KDE 4.X Release Candidate

Note: In order to minimize issues it is recommended to start with a clean environment. Read more in Cleaning Up KDE section.

Note: You'll need portage-2.2_rc*, so please add ~sys-apps/portage-2.2 entry to your /etc/portage/package.unmask[/*] file.

Snapshots are only available through kde-testing overlay, so you first need to add it:

Code Listing 2.3: Installing kde-testing overlay from layman

# layman -f -a kde-testing
For more information regarding overlays, please read the Overlay Guide

If you're used to git repos, don't want to use layman and rather do all the sync work yourself, you can install the repo directly:

Code Listing 2.4: Installing kde-testing overlay directly

# mkdir /<repo-base-dir>
# cd /<repo-base-dir>
# git clone git://git.overlays.gentoo.org/proj/kde.git

Users with stable systems have to keyword the packages to proceed. We provide a package.keyword file in kde-testing overlay, which we'll have to symlink to our package.keywords directory:

Code Listing 2.5: Creating symlink of the kde-4.3.keywords file

# cd /etc/portage/package.keywords
# ln -s /path/to/overlay/kde-testing/Documentation/package.keywords/kde-4.4.keywords .

The installation can be done either by using the meta packages or by using sets.

Code Listing 2.6: Installation of KDE snapshots using meta packages

# emerge -av kde-meta:4.4 (contains all of KDE modules)
# emerge -av kdebase-meta:4.4 kdegames-meta:4.4 (installation of chosen modules only)

Code Listing 2.7: Installation of KDE snapshots using sets

# emerge -av @kde-4.3 (contains all of KDE modules)
# emerge -av @kdebase-4.3 @kdegames-4.3 (installation of chosen modules only)
See the Using Sets section for more information.

Installing KDE live ebuilds (from kde-testing overlay)

Warning: KDE live ebuilds are bleeding edge. Use at your own risk.

KDE is Open Source, with its code being available for browsing throughKDE Websvn, and for public checkout through an anonymous (anonsvn) account. Gentoo, as a source based distro, has the ability to provide live ebuilds that checkout the code either from the latest branch or from trunk. Currently, we provide 4.3.9999 ebuilds from 4.3 branch.

Ebuilds version KDE Version
4.3.9999 KDE 4.3.Branch
9999 KDE 4 Trunk (currently 4.4)

Note: In order to minimize issues it is recommended to start with a clean environment. Read more in Cleaning Up KDE section.

Note: You'll need portage-2.2_rc*, so please add ~sys-apps/portage-2.2 entry in your /etc/portage/package.unmask file.

Live ebuilds are only available through kde-testing overlay, so first thing is to install it:

Code Listing 2.8: Installing kde-testing overlay

# layman -f -a kde-testing
For more information regarding overlays, please read the Overlay Guide

Users with stable systems have to keyword the packages to proceed. We provide a package.keyword file in kde-testing overlay, which we'll have to symlink to our package.keywords directory:

Code Listing 2.9: Creating symlink of the kde-4.X.9999.keywords or kde-live file

# cd /etc/portage/package.keywords
# ln -s /path/to/overlay/kde-testing/Documentation/package.keywords/kde-4.3.9999.keywords .(for 4.3 Branch)
# ln -s /path/to/overlay/kde-testing/Documentation/package.keywords/kde-live.keywords .(for KDE 4.4 Trunk)

The installation can be done either by using the meta packages or by using sets.

Code Listing 2.10: Installation of KDE live ebuilds using meta packages

(For KDE 4.3 Branch)
# emerge -av kde-meta:4.3 (contains all of KDE modules)
# emerge -av kdebase-meta:4.3 kdegames-meta:4.3 (installation of chosen modules only)
(For KDE 4.4 Trunk)
# emerge -av kde-meta:live (contains all of KDE modules)
# emerge -av kdebase-meta:live kdegames-meta:live (installation of chosen modules only)

Code Listing 2.11: Installation of KDE live ebuilds using sets

(For KDE 4.3 Branch)
# emerge -av @kde-4.3 (contains all of KDE modules)
# emerge -av @kdebase-4.3 @kdegames-4.3 (installation of chosen modules only)
(For KDE 4.4 Trunk)
# emerge -av @kde-live (contains all of KDE modules)
# emerge -av @kdebase-live @kdegames-live (installation of chosen modules only)
See the Using Sets section for more information.

Installation of KDE 4 Applications

In kde-testing you may find live ebuilds of KDE 4 applications. These are slotted in :4, but they can not be installed in parallel with normal ones. You are free though to use live KDE 4 applications with KDE 4 from Portage, or to use Portage KDE 4 applications with your live KDE.

Note: There is also a set with live KDE 4 applications, @kde-extras-live, in kde-testing and a set with Qt live applications, @qt-extras-live, in qting-edge overlay.

3.  Additional Installation/Removal Information

Using Sets

Warning: Portage 2.2_rcX is currently masked. So if you want to use sets please unmask ~sys-apps/portage-2.2.

One of the new features provided by Portage 2.2 is sets.

Sets allow the KDE team to provide a complete replacement for the monolithic packages, with the added bonus that users may choose to remove from the default sets any packages they do not want. There is still some discussion going on before we can put sets in the Portage tree. Thus, grab the sets from the kde-testing overlay sets directory or grab them as a tar.bz2 archive and put the ones you like in /etc/portage/sets -- you can browse the list of sets provided by the KDE team in the overlay by using the first link.

Note: If you are using the kde-testing overlay you can use sets directly instead of copying them to /etc/portage/sets.

Amongst others, there are sets for each KDE tarball - @kdeaccessibility, @kdeadmin, @kdeartwork, @kdebase, @kdeedu, @kdegames, @kdegraphics, @kdemultimedia, @kdenetwork, @kdepim, @kdesdk, @kdetoys, and @kdeutils. There is also a set of sets (the equivalent to the old kde-meta package) @kde, and the same for specific versions @kde-3.5 and @kde-4x, a set for KDE deps @kdedeps, a set for optional packages @kdeoptional and a set for the split qt packages @qt-split.

One can install the complete KDE by running emerge -av @kde. The specific version equivalents are very useful to uninstall an old version, e.g. emerge -C @kde-3.5, or to reinstall all packages from a specific version, e.g. emerge -av1 @kde-4x. Advanced features, like removing any unwanted packages from a set, will be supported in a future release of Portage -- you can read more about it in Marius Mauch's (genone) blog. Part of this code has now been released in portage-2.2_rc12, so you can reinstall all installed packages of a set with emerge -av @<set>/@installed or to have a /etc/portage/sets/kdebase-unwanted set and then run emerge -av @kdebase-@kdebase-unwanted.

We strongly recommend that you install the kdebase set in order to get a full KDE 4 session. The example below would install the kdebase set and the kdegames set.

Code Listing 3.1: Installing KDE

# emerge @kdebase @kdegames

Note: If you want to check the list of sets known to Portage run the following: emerge --list-sets

Note: All >= KDE 4.1 ebuilds require sys-apps/portage-2.1.6 or greater, which has implemented everything in the new EAPI 2 specification used in these ebuilds (>=sys-apps/portage-2.2_rc12 is required to use sets).

Cleaning Up KDE

In order to minimize issues, it is best to begin with a clean environment. This is recommended for the following cases:

Two possible ways of removing old KDE installations are:

Code Listing 3.2: Unmerging commands

# emerge -C @kde-4.X @kdebase-4.X @kde-3.5(using the typical sets)
# emerge -C $(qfile -C -q -e /usr/kde/%PREFIX%) (replace %PREFIX% with your KDE version, eg. 3.5, 4)

Code Listing 3.3: Unmerging commands (only applicable if you are moving from an overlay)

# cd /path/to/overlay/
# emerge -C $(find ./ -name \*.ebuild |sed -e "s:\.ebuild$::" -e "s:./::" |awk -F'/' '{print "="$1"/"$3}')

As a final step you should remove the old overlay so that there are no conflicts with the KDE ebuilds. You should remove the old unmask and/or keyword data, too.

Note: Don't forget to run emerge --depclean in order to uninstall any dependant packages.

Rebuilding the application database

To rebuild the KDE application database run:

Code Listing 3.4: kbuildsycoca command

# kbuildsycoca4 --noincremental

Localization/Internationalization

With new KDE there is new translators effort in Localization instead of Internationalization. This cause some confusion, but don't worry; just the name has been changed.

Code Listing 3.5: Getting the translations

For KDE 4 and KOffice 2:
# emerge kde-l10n
# emerge koffice-l10n

Migrating configs from 3.5 to 4.X

KDE stores its configuration files in the ~/.kde directory by default. In the Gentoo ebuilds this has been changed in KDE 4.X to allow for better integration of KDE 3.5 and 4.X when using the same user account. If you export $KDEHOME this behaviour will be overridden. It is strongly recommended that you do not do this. $KDEHOME will make KDE 3.5 and 4.X use the same configuration directory which is usually not desired.

KDE 3.5 uses ~/.kde and the default FHS (-kdeprefix) KDE 4.X uses ~/.kde4.

Settings are not migrated by default. If you want to attempt to migrate your settings you should copy your old configuration directory to the new location before logging in. For example:

Code Listing 3.6: Copying the configuration directory

$ cp -r ~/.kde ~/.kde4

If this is successful, then your settings should all be migrated. If not, it is possible to log out and remove the new configuration directory to start with a clean configuration directory.

Important: Moving backwards in version, from 3.5 to 4.X, is not supported.

4.  Hints and Troubleshooting

Plasmoids

Plasmoids are new plasma tools which can enhance your desktop experience. Many plasmoids are available in the kde-misc/ category. If you find out that your favorite plasmoid is missing, file a bug and somebody might create it for you. If you've got to have them all, there is a set called @plasmoids which contains all plasmoids currently available.

Note: Many plasmoids are in the kde-testing overlay.

x11-themes/plasma-themes

This ebuild contains various plasma themes. The procedure for requesting additional themes is the same as that for plasmoids.

x11-themes/gtk-engines-qt

This ebuild should be used if you want your GTK applications to use a theme similar to the Qt/KDE applications. Configuration can be found in System Settings->Appearance->GTK Styles and Fonts.

x11-themes/gtk-engines-qtcurve

This is another approach to making GTK/Qt 3/Qt 4 applications looks the same. You must also install x11-themes/qtcurve-qt4 for this to work with Qt 4/KDE 4 applications.

Akonadi Complains about the MySQL Config

Start by checking the permissions in /usr/share/config and /usr/share/kde4. If they're 700, you need to update them to 755 recursively.

Code Listing 4.1: Updating /usr/share/config permissions

# chmod -R 755 /usr/share/{config,kde4}

If that doesn't solve the error, you need to open the akonadi configuration and change the default mysql config. If you don't have the tray running, start akonaditray, select "Akonadi Server Configuration", activate "Use internal MySQL server" and then press the test button. If you want to use the mysql server and not the embedded executable, you'll need to ensure that mysql is running.

KDM fails to start

Start by checking the permissions in /usr/share/config. If they're 700, you need to update them to 755. Check previous section. If that doesn't solve the error, check the following notice in the kdm ebuild:

Code Listing 4.2: kdm notice

If when you restart xdm, kdm fails to start with a message like "gentoo kdm[2116]: X
server startup timeout, terminating" in /var/log/messages, uncomment the ServerTimeout
line in "grep kdmrc /var/db/pkg/kde-base/kdm-4.3.1/CONTENTS | cut -f2 -d " ""
and be sure to increase the timeout - 60 should work

Also be sure that the following services are started:

Code Listing 4.3: checking and starting services

# /etc/init.d/dbus status
# /etc/init.d/hald status
# /etc/init.d/consolekit status

If not, enable them by replacing status with start, and use the command rc-update add dbus default for every one of them to add them to default runlevel.

Finally, KDM could fail due to errors in /etc/X11/xorg.conf. Take a look in your logs: /var/log/Xorg.0.log and /var/log/kdm.log and fix xorg.conf accordingly. For additional help you can find us in IRC (#gentoo-kde at Freenode).

The battery applet or solid notifications don't show the relevant info

So that the battery applet or other solid notifications can show the relevant info, you need dbus and hald running.

Code Listing 4.4: checking and starting dbus and hald

# /etc/init.d/dbus status
# /etc/init.d/hald status
# /etc/init.d/dbus start
# /etc/init.d/hald start