Alien Pastures

My thoughts on Slackware, life and everything

Tag: kde (Page 25 of 28)

kmail terminates during startup with “Failed to fetch the resource collection”

November 13, 2011 / / 11 Comments

One thing that keeps boggling people’s minds when they use KDE is Akonadi, the framework used to access PIM-like data. PIM being “Personal Information Management”. Akonadi leaves me in the dark too, sometimes!

If you want to know a bit more about how Akonadi sits at the core of your personal data management in KDE, you might want to read these articles first, one being two  years old and the other a bit more recent… http://thomasmcguire.wordpress.com/2009/10/03/akonadi-nepomuk-and-strigi-explained/ and http://vizzzion.org/blog/2010/08/demystifying-akonadi/ . This is also a nice article “Akonadi misconception #1: where is my data?“: http://blogs.kde.org/node/4503 which is definitely worth checking out.

In the meantime, there is an issue I wanted to discuss with you, considering Akonadi. When you upgrade to KDE 4.7.x coming from Slackware’s KDE 4.5.5, the upgrade process is not always smooth. The PIM suite in KDE 4.7.x is now using Akonadi as its backend, meaning your PIM data (kmail, kontact etc) are migrated over to the Akonadi storage the very first time you start your new KDE. This migration is not always proceeding perfectly.

There’s a thread on LinuxQuestions.org about kmail crashing on startup with a very specific error message “Failed to fetch the resource collection“. I provided the solution in that thread but thought it would be good to document it here in the blog as well. The bug is fairly old, it is being discussed in https://bugs.kde.org/show_bug.cgi?id=259355

What you have to do if you encounter this issue, is the following:

  1. Launch Akonadi Console (for instance by pressing “Alt-F2” to open krunner and typing “akonadiconsole”).
  2. In the “Agents” tab, select the “Local Folders” resource.
  3. Select “Configure > Configure natively…”.
  4. If an error appears indicating that “the current folder does not exist” don’t worry. Select a new directory which does not yet exist, for instance: /home/<USERNAME>/.kde/share/apps/kmail/mail/

This should fix the issue with kmail.

You can fix it the hard way, by removing all of your “.kde” directory content but that is so rude, and you lose a lot of other configurations besides your mail.

A whole section of the KDE User Base is devoted to Akonadi troubleshooting, I recommend you check that out if you run into Akonadi related issues: http://userbase.kde.org/Akonadi_4.4/Troubleshooting

Cheers, Eric

KDE updated to 4.7.3

November 2, 2011 / / 40 Comments

Another month passes, and another maintenance release of KDE.arrives, we are up to 4.7.3 now. As usual, here are my KDE 4.7.3 packages for Slackware hot on the heals of the KDE team.

For those who are trying my 4.7 packages for the first time and wonder why the hell am I offering so many packages, please read my earlier post about KDE 4.7.0 which explains more about splitting KDE for Slackware into many more (and smaller) packages.

My packages have been compiled on Slackware-current. My educated guess is that you can use them on Slackware 13.37 too (several people have reported in various places that they are running my KDE 4.7.2 on Slackware 13.37 successfully).

Still:

Read the accompanying README file for installation and upgrade instructions!

Some of the highlights of these KDE packages:

  • There are several updated dependencies compared to Slackware’s own KDE 4.5.5: PyQt, QScintilla, akonadi, attica, clucene, ebook-tools, hunspell, libdbusmenu-qt, phonon, polkit-qt-1, qt, raptor2, rascal, redland, shared-desktop-ontologies, sip, soprano, strigi, system-config-printer and virtuoso-ose.
  • In comparison with my previous KDE 4.7.2 the number of updated dependencies is a bit smaller: akonadi, grantlee, libbluedevil, libssh, phonon, shared-desktop-ontologies and upower.
  • KDE dpendencies that are not part of Slackware 13.37 at all (yet): grantlee, herqq, libatasmart, libbluedevil, libssh, phonon-gstreamer, phonon-xine, sg3_utils and udisks. Note that I added phonon-gstreamer and phonon-xine only after I had already released KDE 4.7.0 packages because people reported that they no longer had sound. These two packages solve that issue.

Not new since I added these to KDE 4.7.1 before (but if you are new to KDE 4.7 this will interest you):

  • You will find some additional useful new applications, which are not part of the KDE core set. They are new, compared to Slackware’s own version of KDE. I already added bluedevil to my 4.6.5 package-set. Bluedevil is the new KDE bluetooth stack with a nice GUI, based on the BlueZ libraries already present in Slackware. And with KDE 4.7.0, I included kplayer, a KDE front-end to MPlayer. With KDE 4.7.2, I added Quanta Plus, which disappeared from KDE4 because that migrated from Qt3 to Qt4. It is now being worked on again, but no longer as a standalone application – instead it is available as a plugin to the Kdevelop Platform. And this time, I added a native WICD applet for KDE, called “wicd-kde“. It can replace the GTK based “wicd-client” which is part of the wicd package.
  • I also added oxygen-gtk, which is not really an application, but a theme engine. It (optionally) makes GTK applications visually blend in with KDE’s own Oxygen theme. There is a README in its documentation directory which explains how to enable it.
  • And right after releasing my KDE 4.7.2 packages, I added a “test” directory. The same test directory is also present in the 4.7.3 package set. It contains Networkmanager, plus some other dependencies, that allow to create a package for “networkmanagement” which is an applet plus a kcontrol (i.e. a plugin for KDE’s systemsettings). This allows you to switch from WICD to NetworkManager as your basic network management service. The applet plus kcontrol make it dead easy to configure your network (wired, wireless, vpn, dsl and mobile broadband). No new Gnome libraries had to be added for this (NM itself plus its supporting tools have no dependency on the rest of Gnome). I have added NM installation/configuration instructions to the README.

A small aside I want to mention:

There was one bug that has been plaguing me ever since KDE 4.7.0 (and I may have had this occasionally before 4.7 but I cannot remember for certain). The bug seems to be ALSA related, but unsure is whether the fault is with ALSA or with KDE. The “kde deamon (kded4)” crashes every time when I login to KDE. Surely, it will automatically restart but it is ugly. It is still there in KDE 4.7.3 and it is described in these two bug reports:

There is a workaround though. If you disable “KMixD Mixer Service (kmixd)” from being started at logon, the crash does not occur anymore and so far I have not found any lost functionality. My laptop’s hardware volume keys still work, and the KDE mixer applet is still functional. Go to System Settings > Startup and Shutdown > Service Manager, and remove the check in the checkbox for KMix Daemon.

The KDE 4.7.3 packages for Slackware-current are available for download from my “ktown” repository and several mirrors (taper will be in sync when I post this, the other mirrors will have to catch up):

Have fun! Eric

KDE bugfixes and how to use my modular KDE.SlackBuild

October 9, 2011 / / 18 Comments

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:

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

Package updates in the past days

September 11, 2011 / / 24 Comments

I have been updating some of my Slackware packages in the past few days and at least some of them are important enough to write a bit about it.

virtuoso

Along with my packages for KDE 4.7.x I added an updated version of virtuoso “data management server” which powers a lot of the functionality in today’s KDE: However there was a regression in this version 6.1.3 which messed up the display of path names containing non-ascii (i..e Unicide) characters. See https://bugs.kde.org/show_bug.cgi?id=271664 for more details about this issue. I applied a fix to my virtuoso-ose package which solves this.

Package available here in the 4.7.1 section: http://alien.slackbook.org/ktown/ as well as all the usual mirrors.

kde-workspace

Martin Graesslin wrote an email to the KDE packagers mailing list with the plea to apply a patch to all binary packages of kde-workspace after he discovered a bug in KWin’s handling of desktop effects which apparently has been present in all versions since 4.0. The bug would cause a performance degradation which becomes worse when more windows are open on the desktop. Martin’s blog article describes how he discovered the bug during his performance analysis of KDE 4.8 code. I have applied the patch he provided in his email to my KDE 4.7.1 kde-workspace package and I will wait for a backport to KDE 4.6.x before attempting to apply the fix to the kdebase-workspace package in there.

Package available here in the 4.7.1 section: http://alien.slackbook.org/ktown/ as well as all the usual mirrors.

vlcgit

This is not a package update per sé. I have been compiling the development version of the VLC media player for a long time (I think I started re-writing the vlc.SlackBuild script for the development snapshots in January 2011). I had varying success with the package, as my build script would “break” from time to time. When someone in the #videolan IRC channel wondered if the development code would work better for high-bandwidth H.264 movies (VLC 1.1.11 drops too many frames) and a VLC developer suggested that the development code has a lot of optimizations in this regard, I decided to release a package based on my SlackBuild script. I called the package directory “vlcgit” and the build script “vlcgit.SlackBuild” but the actual package is named “vlc” so that you can easily update from 1.1.11 to this development snapshot. The vlc program will identity itself as “1.2.0-git” when it starts. I think it is worth your while to try it out because there have been lots of enhancements and additional features in the past year.

VLC 1.2.0 is expected to be released before the end of 2011.

Packages here: http://slackware.com/~alien/slackbuilds/vlcgit/ (which is a US server so these packages do not contain the mp3 and aac encoders because of patent disputes) and at http://taper.alienbase.nl/mirrors/people/alien/restricted_slackbuilds/vlcgit/ (for the version that includes mp3 and aac audio ENcoding capability). Also available on all the other mirrors of course.

flashplayer-plugin

The Adobe people are finally putting good effort into their Linux flash player plugin. One month after the “beta 2” release we now have the “release candidate 1” of the upcoming Flash Player 11. It looks like the releases for Linux and Windows platforms go hand in hand now, which is a reassuring sign that we Linux users are taken seriously.

Package available at http://slackware.com/~alien/slackbuilds/flashplayer-plugin/

calibre

The calibre download page states that you should “not use your distribution provided calibre package, as those are often buggy/outdated. Instead use the Binary install described below“. Of course you are free to follow that advice, but if you prefer to know how your packages get built, like me, you can still grab the packages that I provide. There is a new release of Calibre every friday and I have been following that release cycle for the past months, releasing updated packages the same day. I use Calibre every day and am happy with my builds.

Get the package here: http://slackware.com/~alien/slackbuilds/calibre/

sigil

If you are seriously into writing or converting e-books, then Calibre is the perfect management and conversion software for the task. But Calibre does not offer an actual epub editor. Epub is an open specification for electronic books and widely used all over the world except for the US apparently where Amazon dominates with the mobi format used for its Kindle. Both mobi and epub formats are quite similar, basically it is HTML text plus a book’s metadata, bundled together in a ZIP archive. Whether you are writing an ebook yourself, or need to clean up an ebook provided by someone else, there is one application which is best suited for this task: Sigil. Sigil is designed to edit epub format only. It contains an embedded HTML tidy which cleans up the book’s HTML code autimatically and an embedded Flightcrew, which assists you in validating your book to the EPUB specification.

The Sigil homepage offers pre-built binaries, but these are quite big. Since they have to work everywhere the binaries include a lot of libraries which we already have in Slackware. The new Sigil maintainer seems to be very responsive so I asked him if he could put up a page with distro-specific packages and add a link to my Slackware package there. He did that right away, and more distros have been added there since.

Get the package fir Sigil here: http://slackware.com/~alien/slackbuilds/sigil/ .

 

Good fun with all of this! Eric

Update Sun Sep 11 15:43:06 UTC 2011:

libbluedevil

Willy Sudiarto Raharjo pointed out that there was another package update and I failed to mention it. The 32bit package “libbluedevil” was not tagged with my “alien” tag initially, and I fixed that by renaming the affected files in the repository.

Remember why tagging your packages is useful? If you use slackpkg to keep your Slackware up to date, then you can blacklist all my packages (since I apply the “alien” tag to all my packages) so that slackpkg does not “see” them anymore. Add this single line to the file “/etc/slackpkg/blacklist“:

[0-9]+alien

🙂

KDE Software Compilation 4.6.5

July 7, 2011 / / 30 Comments

The last of the 4.6 series has arrived, and I thought it would be good to compile it for Slackware-current so that Pat Volkerding can concentrate on Slackware’s core:

Please check the official announcement of the KDE Software Compilation 4.6.5 – and then proceed to download my packages for Slackware.

I had hopes that version 4.6.5 of the KDE SC would be added to Slackware but Pat is busy, and I did not want to wait. No problem! Remember, you have to be running Slackware 13.37 (32bit or 64bit) or (preferably) slackware-current in order to use these packages. They were built on slackware-current. Note that between 13.37 and -current, there was an incompatible perl upgrade which may cause some of the KDE 4.6.5 “language bindings” to fail on Slackware 13.37 (causing for instance plasmoids to break if those were programmed in perl).

Please read the accompanying README file for installation and upgrade instructions!

This is the fifth incremental release in the 4.6 series, meaning it’s mostly bugfixes and translation enhancements.

Some of the highlights of my new set of KDE packages:

  • Packages for the stable release 4.6.1 of kdepim and kdepim-runtime are included.
  • No updated dependencies since KDE 4.6.4 if you have that installed already.
  • Updated dependencies with regard to the stable Slackware 13.37 are: PyQt, QScintilla, akonadi, attica, ebook-tools, hunspell, libdbusmenu-qt,sip, soprano, system-config-printer, virtuoso-ose.
  • Not part of Slackware 13.37 at all (yet): grantlee, libatasmart, libbluedevil, libssh, sg3_utils, udisks.
  • And bluedevil was added – not a dependency as such, but rather additional functionality for your KDE desktop. Bluedevil is the new KDE bluetooth stack, based on the BlueZ libraries already present in Slackware. I added its package to the “kde” directory. It integrates a lot better into KDE than the GTK application “blueman” which is now primarily meant to be used with the non-KDE desktop environments.

The KDE 4.6.5 packages for Slackware 13.37 & current should be available for download from my “ktown” repository by now (the Indonesian mirror may need a bit of time to sync up):

Have fun! Eric

« Older posts Newer posts »

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑