Gentoo KDE Guide
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:
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
# emerge -av kdebase-meta:4.3 kdegames-meta:4.3
|
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
|
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
# emerge -av kdebase-meta:4.4 kdegames-meta:4.4
|
Code Listing 2.7: Installation of KDE snapshots using sets |
# emerge -av @kde-4.3
# emerge -av @kdebase-4.3 @kdegames-4.3
|
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
|
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 .
# ln -s /path/to/overlay/kde-testing/Documentation/package.keywords/kde-live.keywords .
|
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 |
# emerge -av kde-meta:4.3
# emerge -av kdebase-meta:4.3 kdegames-meta:4.3
# emerge -av kde-meta:live
# emerge -av kdebase-meta:live kdegames-meta:live
|
Code Listing 2.11: Installation of KDE live ebuilds using sets |
# emerge -av @kde-4.3
# emerge -av @kdebase-4.3 @kdegames-4.3
# emerge -av @kde-live
# emerge -av @kdebase-live @kdegames-live
|
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:
- Moving from +kdeprefix to -kdeprefix (and vice versa)
-
Downgrading KDE (eg. from snapshots/live ebuilds to the Portage version)
- Fully upgrading from KDE 3 to KDE 4 (and vice versa)
- Moving from an old overlay
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%)
|
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 |
# 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
|
The contents of this document are licensed under the Creative Commons -
Attribution / Share Alike license.
|