Archive for the ‘KDE’ Category

A new home for KDESvn

A few days ago, the KDESvn repository was converted from Subversion to Git.

But that’s not all…

It’s now hosted on !

A new product was created on, Krazy report is available, translations were moved to the KDE infrastructure and the release tarballs will be moved to soon

Welcome home, KDESvn.


Written by krop

8 July 2013 at 11:15

Posted in KDE

Things you should double check twice (or more) before releasing your software

When you start packaging more and more things for your distribution, you realize how things would be easier if upstream was slighly more concerned about how distributions work. Here are a couple examples of things you shall double check before releasing your work.

1/ Don’t install headers with your runtime stuff.

This sounds obvious, right ? Runtime applications should not be used as a build dependency for anything or it’s no longer a runtime thing.

A bad example: kde-runtime
A good example: nepomuk-core

# ls /kde/inst/kde-runtime/include

knotifyconfig.h knotify_export.h knotifyplugin.h

Now, sit and think: How can you use these headers ?
Simple answer, you can’t because they’re installed by a runtime module, which means:

– There’s no CMake config files installed,
– There’s consequently no way to know these headers locations nor how to link to knotify, anyway.

A solution? Don’t installs headers in a runtime-only module or move your code elsewhere.

That’s the reason why a nepomuk-core module was created before the KDE 4.9 release. We then could get rid of all the nepomuk-dms copies in different KDE projects.

2/ Applications icons *MUST* be installed in the hicolor namespace

Bad examples: lots of KDE applications.
A (very) good example: Okular

Because KDE apps are great, they should also look great in non-KDE environments.

Again, let’s sit and think:

myApp.desktop has an Icon=myIcon line and myIcon.png is only installed in the Oxygen namespace.
Now, what happens if a Gnome, XFCE or $whatever_DE_using_a_different_icon_theme user installs myApp?

Simple, the application icon won’t be visible. Despite what was discussed here, the Oxygen icons set shouldn’t be a must-have to use KDE applications.

Quoting the Icon theme spec:

« So, you’re an application author, and want to install application icons so that they work in the KDE and Gnome menus. Minimally you should install a 48×48 icon in the hicolor theme. This means installing a PNG file in $prefix/share/icons/hicolor/48×48/apps. Optionally you can install icons in different sizes. For example, installing a svg icon in $prefix/share/icons/hicolor/scalable/apps means most desktops will have one icon that works for all sizes. You might even want to install icons with a look that matches other well known themes so your application will fit in with some specific desktop environment.

It is recommended that the icons installed in the hicolor theme look neutral, since it is a fallback theme that will be used in combination with some very different looking themes. But if you don’t have any neutral icon, please install whatever icon you have in the hicolor theme so that all applications get at least some icon in all themes.»


After reading this, you should also have realized something: Icons/pixmaps used in your applications that do not exist in the hicolor theme should be installed by your application (duplication is not an issue since these icons won’t be installed in the icons theme directory).

Additional note on this: in openSUSE, rpmlint now throws an error if the application icon is defined in a desktop file but is not installed.

3/ Don’t include half the world in your tarball.

While this may be convenient for your build system, this is a maintainance nightmare for packagers and takes hours to rebuild everything when we have to change even a tiny line.

(very) Bad example: Digikam

Let’s examine the Digikam 2.9.0 tarball: its size is ~55 Mb. Once uncompressed, 29% of the data come from the “core” subdir and 25% come from the “extra” one.

Now, let’s see what in this extra dir:

/tmp/digikam-2.9.0 # ls extra
CMakeLists.txt kipi-plugins libkdcraw libkexiv2 libkface libkgeomap libkipi libksane libkvkontakte libmediawiki

Why is that so bad ?

– kipi-plugins can be used at runtime by Gwenview but didn’t get a proper release since ages (it’s nowhere on and the last release on sourceforge is more than one year old),
– libkvkontakte is a build requirement for the akonadi-vkontakte resource, but was never released),
– libksane is already shipped with kdegraphics,

From a packager point of view, this raises several issues:
– We have to split the packages in sub-packages that can clash when they’re also shipped with KDE,
– We usually don’t want to use embedded 3rd party libraries and prefer some proper releases.
– And more important, a couple libraries that are used to develop other applications don’t have a release cycle.

4/ Embedded 3rd party stuff should not be mandatory

Bad example: qt-creator.

Instead of requiring Botan at build time, qt-creator ships a copy. It could be easily patched out before the 2.6 pre-releases in order to use the distribution Botan. With qt-creator 2.6, it suddenly required more work:

– Commit fcc9ba4 not only updated the botan version, it also merged everything in an ugly blob.

While packaging qt-creator 2.6 beta, some includes had to be added in several places to build with the system botan instead of this blob.

You may think it can’t be worse for packagers? I’m sorry to disappoint you…

– Commit 6f7ce3f4 added a Qt specific patch to the 3rd party embedded Botan. So, now, we not only have to patch qt-creator in order to use the distro Botan, we also have to revert a commit in order to make qt-creator build.

Really, if you can’t resist the temptation to add 3rd party applications in your tarballs, at least:

– make sure to add an option to disable it,

– don’t alter the 3rd party code… and even in this case…

5/ Make sure your application still builds if embedded 3rd party libraries can be disabled

Bad example: Qt5

Qt5 provides a configure option to use the system pcre library. Nothing really new, Qt4 also has the -system-pcre option.

However, for some unknown reason, the system pcre wasn’t found. Using the -v option gives some clues:

PCRE auto-detection… ()
g++ -c -pipe -O2 -Wall -W -fPIE -I/usr/include -I../../../mkspecs/linux-g++ -I. -I/usr/include -I/usr/include/pgsql -I/usr/include/pgsql/server -I/usr/include/mysql -o pcre.o pcre.cpp
g++ -Wl,-O1 -o pcre pcre.o -L/usr/lib64 -lpcre16
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lpcre16
collect2: error: ld returned 1 exit status
gmake: *** [pcre] Error 1
PCRE disabled.

You may wonder where this -lpcre16 comes from and you will likely not find a reason. It’s just hardcoded in qtbase/config.tests/unix/pcre/
It doesn’t matter whether the libpcre pkgconfig file mentions Libs: -L${libdir} -lpcre, this file is just ignored.

*EDIT 2012-11-07* This issue comes from a lack of documentation when using  ./configure –help.  -system-pcre means… “Check whether pcre was built with –enable-pcre16”.
The 7th point could be: “Packagers are not seers, don’t forget docs or build howtos.”

6/ Make sure your application runs if installed in a custom prefix (iow: don’t assume everyone has the same setup as you)
Bad example: plasma (more precisely, libplasma, so this also breaks kactivities)

A couple months ago, Jenkins appeared in the KDE infrastructure. It’s quite nice to detect missing dependencies and includes here and there.

The secret: Jenkins installs everything in a different prefix, updates its environment variables and tries the next target. But what would happen if you try to run KDE with such a setup ?

I can answer: almost all works fine. All… but Plasma. This is kinda problematic since it became unavoidable to run KDE.

What happens in such cases:

– Activities don’t work (the bar is empty),
– You can’t add widgets (same behavior),

I suppose installing kde-workspace in a different prefix than kdelibs is enough to reproduce this issue.

There are probably lots of other minor or real issues that make packagers cry every night, add them in the comments, maybe I’ll write a part#2 🙂

Written by krop

6 November 2012 at 23:22

Posted in KDE

BKO: How to look for duplicate bugs (without wasting too much time)

One of the best Bugzilla feature is its search interface. You can look for almost anything, a comment, an author, a modification date, a bug flag and so on…

Those who sometimes make some noise and suggest to throw away and replace it with <insert a random tracker name> are usually not the ones who triage bugs.

The downside: Bugzilla advanced search interface is quite complex…

So, what about saving some time ?


Using and abusing bookmarks and shortcuts to find duplicate bugs

Let’s try with Konqueror…

  • Open the Web Shortcuts kcm Settings > Configure Konqueror > Web Shortcuts

  • Let’s create a new shortcut

Shortcuts: Choose something you won’t forget easily 😉

Shortcut URL:\{@}&longdesc_type=allwordssubstr&bug_severity=crash

To search in more than a product, add several product parameters, eg: product=kmail&product=kontact

The longdesc will be replaced by our search string.

Note: on older Bugzilla versions, this parameter is called long_desc. so, use longdesc or long_desc but don’t mix them

bug_severity=crash : We’ll only look for crashes


Our shortcut is ready, what about testing now ?

Let’s try with a recurrent crash from 2009: enter  kmailc:KIO::Slave::Deref in Konqueror


and the result:


Using another browser ? No problemo !

  • Opera

Open Tools > Preferences > Search and press Add


  • Firefox

Open Bookmarks > Show All Bookmarks > Select (or create) a new folder > Organize > New Bookmark


etc…  Note that %s is used in these browsers.

To reduce the amount of result, you can also look for several lines of the backtrace: eg  kmailc KIO::Slave::deref KIO::Slave::gotInput



Look for normal bugs or wish reports ? / List the critical bugs ?

the bug_severity parameter accepts the following values: critical, grave, major, crash, normal, minor, wishlist

eg: &bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=normal&bug_severity=minor will look for all but crash and wishlist reports.

Look only for bugs marked as FIXED ?

Add  &bug_status=FIXED to the search URL

the bug_status parameter accepts the following values: UNCONFIRMED, NEW, ASSIGNED, REOPENED, RESOLVED, NEEDSINFO, VERIFIED, CLOSED

Find normal duplicate bugs ?

This is a bit harder, look for words, synonyms…

eg: kmailw toolbar returns here




Written by krop

18 May 2012 at 12:00

Posted in Bugzilla, KDE

Is Kmail still being developed?

This question was posted on the KDE forum a few days ago and deserves an answer.

Yes, KMail is maintained, It even has a new maintainer since a few months. Laurent Montel now takes care of KMail2 and already made an awesome work.

So, what’s the state of KMail in KDE 4.7 ?

Since the 4.7.0 tag, 556 commits were made in kdepim/kmail.
But KMail is no longer a monolithic block, so let’s add:

  • 207 commits in kdepim/mailcommon,
  • 51 commits in kdepim/mailfilteragent.
  • 98 commits in kdepim/messagecomposer,
  • 43 commits in kdepim/messagecore,
  • 54 commits in kdepim/messagelist,
  • 153 commits in kdepim/messageviewer,

Still not convinced ? Let’s head to the KDE Bugs Tracker

Since the creation of the KMail2 product, 690 bugs were marked as RESOLVED.

Amongst those:

  • 11 bugs were marked as UPSTREAM (bug in one of the KDEPIM/KDE dependencies)
  • 4 bugs were marked as DOWNSTREAM (distribution/packaging bug)
  • 6 bugs were marked as WONTFIX
  • 67 bugs were marked as INVALID
  • 77 bugs were marked as WORKSFORME (the reporter cannot reproduce the issue)
  • 178 bugs were marked as DUPLICATE (!!)
  • 324 bugs were marked as FIXED

Still according to our bugs tracker,

  • 14 bugs were explicitly marked as fixed in 4.7.2
  • 24 bugs were explicitly marked as fixed in 4.7.3
  • 24 bugs were explicitly marked as fixed in 4.7.4
  • 15 bugs were explicitly marked as fixed in 4.8

KMail bugs closed since KDE 4.7.3 (only the reports explicitly marked as fixed-in 4.7.4 are listed):

  • 143059 printing of mails ignores if part of the mail is blinded out
  • 258117 Cannot create Mailing List filter via context menu
  • 259422 Kmail ignores trash folder setting. It moves deleted emails to the local trash folder.
  • 263587 BCC addresses shows bcc’s to “To:” recipient
  • 278060 Mailing list detection does not work
  • 280649 Kontact crash when closing
  • 282652 Setting up filters for Distribution lists does not work
  • 284789 Does not remember mail transport
  • 285134 Closing the drop action popup by clicking somewhere else will execute a “move” operation instead of “cancel”
  • 285508 subject line is always spell checked with default dictionary
  • 285623 emails are not sent until restart of mail dispatcher agent
  • 285653 Thousands of errors “Select Failed, server replied A000… NO Mailbox …
  • 285814 Shortcut for moving mail to folder does not move to folder highlighted in dialog
  • 285878 search mail – unusable sort by date
  • 286505 kmail no more send mails
  • 286615 Encrypted email not decrypted in-time for printing
  • 286663 Kontact crashed when canceling creation of sieve script
  • 286827 Unable to reply to an encapsulated message
  • 286875 Redirected email is stored in wrong sent-folder
  • 286889 Move Thread to Trash Context Menu
  • 286922 edited mail from outbox deleted after closing
  • 287367 Kmail is truncating recipients in “reply to all”
  • 287696 redirected mail isn’t marked as redirected (or forwarded)
  • 287779 Copy Email then Paste As Attachment does not work as expected

Written by krop

7 December 2011 at 22:30

Posted in Bugzilla, KDE, kdepim

Time to close some KMail bugs…

With kdepim and kdepim-runtime 4.6 release getting close, I think it’s finally time to squash the KMail 1 bug reports.

What will happen ?

In a couple of hours, I’ll close the KMail product, which means reporting new bugs will not be possible anymore. The bugs audit will then begin.

Several phases are planned :

  • Revisit the KMail crash reports and close the ones that are no longer reproducible with KMail2
  • If a given crash is reproducible, open a new KMail2 report with a fresh and useful backtrace and a link to the old report.
  • Test the ‘Normal’ bugs, close the ones that cannot be reproduced, reassign the reproducible ones to the proper product (kmail2, kdepim, kdepimlibs…)

What to do with the wish reports has yet to be defined. I think evaluating the ones which received the most votes and discard the others is probably the best choice.

How can YOU help ?

You have KDEPIM 4.6 beta 5 installed ?  What about starting with triaging your own bugs ?

Once logged on, click on “My bugs” voilà, you’re ready to triage.

Want more ? visit, pick a category and check whether you’re able to reproduce the original report. Drop a comment to the report if you cannot close it.

Written by krop

22 April 2011 at 14:54

Posted in Bugzilla, KDE, kdepim