KDE bugfixes and how to use my modular KDE.SlackBuild

KDE 4.7.2 fixes

In the past week, fixes have been posted to the KDE packagers mailing list, asking us to apply those to our packages. Both fixes are important enough that I updated my kdelibs and kdepim-runtime packages.

There is a fix for kdelibs of which Sebastian Trueg states “Hi packagers, sadly I introduced a serious issue into kdelibs 4.7.2 which was intended to be a fix. This bug prevents any query which does NOT use wide unicode characters to fail. The attached patch provides a workaround for this issue and will make all queries work“. Another patch is for the kdepim-runtime package. It fixes bug 283467 “Kmail has duplicated folders after migration from previous version”

Both updated packages are now available in the KDE 4.7.2 section of my “ktown” repository.

The 32bit packages:

• http://alien.slackbook.org/ktown/4.7.2/x86/kde/kdelibs-4.7.2-i486-2alien.txz (gpg signature)
• http://alien.slackbook.org/ktown/4.7.2/x86/kde/kdepim-runtime-4.7.2-i486-2alien.txz (gpg signature)

The 64bit packages:

• http://alien.slackbook.org/ktown/4.7.2/x86_64/kde/kdelibs-4.7.2-x86_64-2alien.txz (gpg signature)
• http://alien.slackbook.org/ktown/4.7.2/x86_64/kde/kdepim-runtime-4.7.2-x86_64-2alien.txz (gpg signature)

KDE.SlackBuild HOWTO

Some people have asked how to work with the modularized KDE.SlackBuild script. It is not immediately clear to everybody for instance how to apply patches, or how to rebuild individual packages. I will use this  opportunity to explain a bit about the innards of the new framework.

The KDE.SlackBuild concept is loosely based on Patrick’s modular X.Org build. For a user of the script, there are not really that many differences compared to building X.Org. Let me tell you more:

The directory structure

• KDE.SlackBuild :this is the script which you run to build the complete KDE Software Compilation, or any number of its individual packages.
• KDE.options : this file contains common options for all packages. For instance, it contains the version of KDE we are compiling, and the overall build number (usually all the packages will get a build number “1”)
• build/ : If a package needs another build number than defined in KDE.options, you should create a new file in the “build” directory that must carry the name of this package. Iinside the file you write the desired build number.
• cmake/ : This directory contains the actual compilation script, called “cmake”.. The cmake program is used to configure the source code for Qt/KDE based applications (make will be called afterwards to compile the configured soiurces). If an application needs a non-standard set of cmake/make parameters or commands, you must create a new file in this directory, carrying the name of the application, and inside you add the custom compilation commands. Use the default “cmake” script as your starting point. The KDE.SlackBuild script will then use this custom file instead of the default “cmake” file.
• docs/ : The KDE.SlackBuild script will add a couple of common documentation files from the source tarball into the resulting package’s “/usr/doc” diretory. Think of files like “AUTHORS* CONTRIBUTING* COPYING* HACKING* INSTALL* MAINTAINERS README* NEWS* TODO*“. If an application’s source tarball contains other documentation files that you want to have added instead, then you should create a new file in the “docs/” directory, containing the application’s name and inside you add the files that the KDE.SlackBuild should add to the package’s “/usr/doc” directory.
• doinst.sh/ : To every package a generic “doinst.sh” script will be added. This is the script which is run by “installpkg” and “upgradepkg” after installing the package (for instance to refresh the KDE menu or to register new MIME types). If an application needs its own “doinst.sh” script “doinst.sh” then you add it to the “doinst.sh” directory, the file should carry the name of the application (I am repeating myself a lot but that’s because the concept is identical for all these subdirectories)
• makepkg/ : Creating the actual package after its compilation has been completed is accomplished by calling the “makepkg” command. If you have a package that needs a custom makepkg commandline you can add that here.
• modularize : KDE Software Collection is built out of modules (think of modules like “kdelibs”, “kdenetwork”, etc…). These modules used to be distributed as big “monolithic” source tarballs in the past, and we would create one Slackware package for every module. This has changed since KDE 4.7.0 where the sources of these modules were split off into a lot of separate tarballs. The KDE.SlackBuild still builds one package per module if you do not tell it to do otherwise. If you need/want to split up a module into sub-packages, then you edit section in the “modularize” file which applies to this module. Every name you add to the “modularize” file (which must correspond to a source tarball of the same name) will be built as a separate package. for instance, the “kdebase” section contains the following lines, which means that compiling the “kdebase” module will result in the additional packages: konsole, kate, kde-wallpapers, kde-workspace, kde-runtime: These separate programs used to be included in the kdebase package itself previously:

# kdebase:
konsole
kate
kde-wallpapers
kde-workspace
kde-runtime

• modules/ : This directory contains the KDE modules, one file per module. Inside each file you will find the basenames of the individual source tarballs which make up this module. If a source tarball is listed inside one of these files but is not listed in the “modularize” file (see the previous bullet) then the binaries resulting from compiling this source will be included into the main module package and not be split off into its own separate package.
• noarch : Most of the KDE packages will be built for a specific machine architecture (i486 or x86_4 for instance). If a package does not contain machine-dependant code then its architecture type should be “noarch“. In that case you should add the name of the package to the “noarch” file.
• package-blacklist :  The collection of source tarballs is bigger than what we support on the Slackware Linux platform (some of the sources apply to other distros only or to MS Windows, such as the “csharp” tarball for instance). The “package-blacklist” file is where you enter the names of source tarballs to skip compiling  Just the application’s basename – no version.number is needed.
• patch/ : This directory contains patch scripts for applications (see further down for more detail).
• post-install/ : A few packages need additional work after the “cmake && make && make install” sequence. If you need that, you can add a file with the name of the application inside the “post-install” directory containing those commands.
• pre-install/ : A few packages need additional preparation before the “cmake && make && make install” sequence. If you need that, you can add a file with the name of the application inside the “pre-install” directory containing those commands.
• slack-desc/ : Every package that is going to be created needs a descriptive file (the package’s slack-desc file). They go into the “slack-desc” directory, each carrying the name of their application.
• src/ : All the KDE sources go in here. It does not matter if you put some of the sources into their own subdirectory, the KDE.SlackBuild script will figure out where they are. For instance, I moved the “extragear” sources (these are the applications which do not belong to the core of KDE SC) into a subdirectory “extragear” but in fact the name can be arbirtrarily chosen.

Compiling one or more single packages

By default, the compilation script “KDE.SlackBuild” will compile all the packages for the KDE Software Compilation. If you want to build only one module, or only a few of a module’s sub-packages, then you have to call the script with the appropriate parameters. If you want to build a sub-package you have to specify to which module it belongs. A module and a sub-package are separated by a colon (:). Multiple sub-packages are separated by a comma (,).

The generic method is:

# ./KDE.SlackBuild [ module[:subpackage1,subpackage2,…] [ module[:subpackage1,subpackage2,…] …] ]

For instance:

• To compile only the “kdelibs” module, you run:

# ./KDE.SlackBuild kdelibs

• To compile the “kdelibs” module as well as the kdepim-runtime package which is a component of the “kdepim” module:

# ./KDE.SlackBuild kdelibs kdepim:kdepim-runtime

• To compile packages for kalgebra, kstars and marble which are all components of the “kdeedu” module, you run:

# ./KDE.SlackBuild kdeedu:kalgebra,kstars,marble

You see that it is actually quite simple, although a bit different from the old method (until KDE 4.6) of building individual packages.

Applying a patch to a KDE package

If you need to patch a package in the KDE Software Compilation, then you must first create a subfolder in the “patch” directory with the name of the package. Then add the patch file into that subdirectory. Finally create a file <packagename>.patch (or edit the file if it already exists) in the “patch” directory, The file “<packagename>.patch” must perform the actual patching, and the patch command must be appended with the following series of commands in order for KDE.SlackBuild to determine if the patch failed or not:

 || { touch ${SLACK_KDE_BUILD_DIR}/${PKGNAME}.failed ; continue ; }

And to make the new package name differ from the old version, you have to update its BUILD number. Edit (or create) a file in the “build” directory for the package and write the new BUILD number in that file. Usually the new BUILD number is one higher than the previous if that was an integer value.

Checking if your sources match the build files

Suppose you are not certain if the source tarballs you added to the “src/” directory match the available slack-desc files and module files, you can run the build script with an additional environment variable. If you run the following command, the KDE.SlackBuild script will compare the content of the “src” directory with the content of the “slack-desc” directory and the content of the “modules” directory and will complain if it finds anything amiss (and abort the script):

# PRECHECK=yes ./KDE.SlackBuild

I hope this clears up things a bit for you!

Cheers, Eric