Main menu:

Sponsoring

Please consider a small donation:

 

 

Or you can donate bitcoin:

 

Thanks to TekLinks in Birmingham, AL, for providing colocation and bandwidth.

Page Rank

Fame

FOSS Force Best Blog--2013 Award

Recent posts

Recent comments

About this blog

I am Eric Hameleers, and this is where I think out loud.
More about me.

Search

My Favourites

Slackware

Calendar

December 2014
M T W T F S S
« Nov    
1234567
891011121314
15161718192021
22232425262728
293031  

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages

Meta

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 283467Kmail 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:

The 64bit packages:

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

Comments

Comment from escaflown
Posted: October 11, 2011 at 04:37

Thanks for the tutorial Eric. You mentioned in Linuxquestion the availability of NM in you KDE builds without relying on any gnome package. Is it activated in your current kde builds?

Comment from escaflown
Posted: October 11, 2011 at 04:58

My bad. I just noticed the change in the rss feed :)

Comment from dr_alex
Posted: October 11, 2011 at 06:40

Hi, Eric! Thanks for howto but i have a question. Is it possible to build ark or kmix as standalone packages?

Comment from alienbob
Posted: October 11, 2011 at 08:24

Hi dr_alex

It will be possible to build ark and kmix as individual sub-packages once the kdeutils and kdemultimedia sources have been split into smaller tarballs (modularized) by the KDE release team. For the moment that is not yet possible.
However have anticipated on the split-up of kdeutils, and my KDE.SlackBuild is ready for that, it just needs the removal of a few “#” comments.

Eric

Comment from toudi
Posted: October 11, 2011 at 14:24

cool,
you said something about using firefox 7 over a week ago any idea why the package still cannot be found anywhere? ;-(

Comment from alienbob
Posted: October 11, 2011 at 15:49

Yeah, I hope the updates will be pushed out soon. There are several fixes for CVE entries contained in those updates.

Eric

Comment from Drew
Posted: October 13, 2011 at 02:10

Eric,

I’m playing with your KDE 4.7.2 packages on Slackware64 -current in a QEM-KVM machine. So far, so good. I have a quick question though: where is Koffice? Is it still being developed? Thanks.

-Drew

Comment from alienbob
Posted: October 13, 2011 at 08:05

@ Drew

Koffice is part of Slackware itself, you can use the official packages. I would only consider including a newer version of it when it gets released in stable form under the new name “calligra”.

Eric

Comment from suozbek
Posted: October 22, 2011 at 13:50

hi alienbob,

i installed kde 4.7.2 on slackware current 32bit and i think this runs smoother (so far) than slack 13.37 with kde. thanks for the packages and tutorial. i want to ask one question, though. i’m using a wired connection (dhcpcd is still running, obviously) but i cant see anything on network manager. is this something i need to fix or it is normal (as dhcp is taking care of it)?

thanks again
-suozbek

Comment from Wild Wizard
Posted: November 15, 2011 at 08:54

Eric I’ve been fiddling around with your script to port it back to X and noticed that you have a small but rather nasty error.

On line 198 you have “return” this should be “continue”

I found the problem when a blacklisted package is hit while building a whole meta package that the whole function exited instead of staying in the loop and trying the next package

Comment from alienbob
Posted: November 15, 2011 at 15:37

Wild Wizard,

You are absolutely right. I have updated the KDE.SlackBuild in the 4.7.3 directory and re-uploaded it.

Thanks, Eric

Comment from Kristian
Posted: December 27, 2011 at 12:22

Hi Eric,

Thank you for explaining this; I have been meaning to compile 4.7 on my 13.37 install for some time, so will have a go now. I do have one question. I’d like to add the -j3 option to make when building to make use of all of the cores on my cpu. What is the best way to address this within the scripts?

Kind regards,

Kristian

Comment from alienbob
Posted: December 29, 2011 at 14:05

Hi Kristian

In the file “KDE.options” you will find these lines:

# Use this to set the number of parallel make jobs:
if [ -z “$NUMJOBS” ]; then
export NUMJOBS=”-j7″
fi

So, by default the compilation will build with “-j7″ unless you specify something else by defining the NUMJOBS variable in your environment.

Eric

Comment from Kristian
Posted: January 9, 2012 at 13:00

Hi Eric,

I’m pleased to report that KDE 4.7 is now running problem free on my 13.37 install-many thanks again.

Kristian

Pingback from How do you rebuild a single package in KDE 4.7.4
Posted: January 20, 2012 at 12:24

[…] that as a line in the KDEMODS variable or mention it explicitly on the commandline. Please read http://alien.slackbook.org/blog/kde-…de-slackbuild/ for more background info. […]

Pingback from Unable to compile jovie using my.slackbuild from Eric’s kde4.8
Posted: March 17, 2012 at 18:10

[…] you try to run? The output you posted looks like you didn't use the correct syntax. Did you check http://alien.slackbook.org/blog/kde-…de-slackbuild/ ? Also, I left out the jovie package for a reason: it needs a speech subsystem like speechd and […]

Pingback from Alien Pastures » KDE 4.8.1 – the best DE you can get
Posted: June 16, 2012 at 14:28

[…] Please note that my own KDE packages have been compiled on Slackware-current. There has been an incompatible update to slackware-current recently (the glibc package) which will cause run-time errors if you attempt to start these KDE programs in Slackware 13.37. If you consider using KDE 4.8.1 on one of Slackware’s earlier (stable) releases, then you have no other option than to compile packages yourself. I have written down the guidelines in another blog post.. […]

Pingback from Compiling KDE4 KAlarm Without Akonadi
Posted: March 30, 2013 at 12:16

[…] can find the KDE.SLakBuild framework documented here if you want to know how to change stuff: http://alien.slackbook.org/blog/kde-…de-slackbuild/ […]

Write a comment