Postings by Alexander Neundorf

How to commit to kruler ?


it seems to me that kruler is basically unmaintained, e.g. the patch for bug
<a href="" title=""></a> hasn't been applied since April
So, I'd like to fix that now.
How is the procedure for kruler ?
Do I need to post this to Phabricator for review first ? (I don't expect
anybody to review it, looking at the activity in the bug report)
Or can I simply commit/push ?


Less time for KDE... :-)


for very happy personal reasons (since Tuesday, named David :-) ) I'll have
significantly less time for KDE in the future.
Still I'll stick around and try my best.


P.S. no, it is not because of dfaure ;-)

Somebody interested in porting mingw manifest support into cmake ?


in kdelibs in the frameworks branch, we are trying to get rid of KDE-specific
extensions, both for Qt and for cmake.
This means also no longer kde4_add_executable(), but plain cmake
add_executable() instead.

This means we loose the manifest support for mingw under Windows we currently

To keep manifest support for mingw, somebody needs to port that to cmake.
The cmake developers signalles support for that idea, but we (i.e.

Fwd: [CMake] CMake 2.8.11-rc1 ready for testing


the first RC for CMake 2.8.11 has been released.
Please give it good testing, it contains lots of changes in the core.


kdelibs frameworks buildsystem under Windows


we are doing quite some rework of the build system in the frameworks branch of

Short version: please try to build one of the tier1/ libraries, e.g.

What is the git workflow for kdelibs ?


I have worked since last year basically only in the kdelibs frameworks

So, what is the git workflow for KDE 4.x kdelibs ?
I looked around on, also here
<a href="" title=""></a> , but couldn't find
(This one <a href="" title=""></a> still only has a "SVN Commit
Policy" link, and AFAIK this
<a href="" title=""></a> is not being used).

So, should I simply pull and push to master, and somebody else will merge into
the 4.10 branch ?


CMake 2.8.8 will be required for kdelibs 4.10 starting October 30th


in kdelibs we require since more than 2 years cmake .2.6.4, since then many
improvements and fixes have gone into cmake, and we cannot make use of them.

These are e.g.

Requiring cmake 2.8.9 for kdelibs 4.10 ?


since May 2010 kdelibs requires CMake 2.6.4 for building.

This version is quite old in the meantime, and we are missing on new CMake
features and also run into problems with some cmake modules where we have an
own copy, which is not forward compatible to the new versions coming with

So, I'd like to raise the required minimum version of CMake for kdelibs 4.10
to 2.8.9 (released beginning of August).

I know this will cause some effort, because I guess only few distributions
already come with CMake 2.8.9, but doing this once again after 2 1/2 years
seems acceptable for me.


Running tests faster..


just a quick hint, maybe you don't know this yet:

You can run tests using "make test".
This will run test by test after each other.
Internally this simply calls ctest.

If you call ctest manually, you can use extra command line options, and, it
supports -jN, as make does.

So, if you have 4 cores, run
ctest -j4
to have it execute 4 tests in parallel and save time this way.

Happy testing :-)

TechBase git policies, infrastructure documentation, please


I wanted to look how our current branching, committing etc.

Drop Win CE support in KDE frameworks branch ?


we have support for Windows CE in kdelibs.
At least on the buildsystem side, this looks more like a hack.

Do we want to keep this for KDE frameworks ?

I'm for removing it. WinCE is IMO just too different for us to support it.

Basically that's also what Till said in his talk at the Desktop Summit "Limits
of portability" or something like this.


From kdelibs4 to KDE frameworks... how to make KDE more cross platform...


KDE is based on Qt, and Qt is very cross platform.
While there are Windows and also OSX builds of KDE4, they are not really
I mean, it's not like everybody is running amarok today under Windows, or
kate, or kdevelop, or digikam, kmail, etc.
Some applications decided to go Qt-only for their Windows versions, e.g.

At FOSDEM I talked with Pau, and he said one thing that scares Windows users
are (beside the huge downloads tdue to the many dependencies) that running a
KDE application needs several helper processes running:
2. kdeinit
3. klauncher
4. kded

FindOpenSSL.cmake - ours vs. the cmake one


I'm still in the process of merging our stuff, e.g. Find-modules from kdelibs,
into cmake.
Now, attached are the current FindOpenSSL.cmake from CMake and the one from
Especially under Windows they do quite different things.

Can somebody else please have a look at the two files and let me know whether
anything from our version has to be merged into the one from cmake or whether
the one from CMake is good enough as it is ?


Summary from Buildsystem BoF at Desktop Summit


last week at Desktop Summit we had a KDE buildsystem BoF, where we discussed
the state of our buildsystem with regard to Qt5 and the KDE frameworks
modularization efforts.
The nice thing is it seems there is a small community building up around this
topic :-)

Attendees were: Marco Martin, Marcus Hanwell, Heinz Wiesinger (Slackware),
David Faure, Sebastian Kuegler, Stephen Kelly, Guillaume (yoms), Sune Vuorela,
John Layt, Volker Krause, Tobias Koenig, Alex Neundorf, Dirk Mueller, Emanuele
Taponi and Raphael Cubo da Kosta.

The following topics were discussed, details see below
1) Up

buildsystem BoF at Desktop Summit


I registered a KDE buildsystem BoF for the Desktop Summit:
<a href=";_BoFs/2011/KDE_Buildsystem_BoF" title=";_BoFs/2011/KDE_Buildsystem_BoF">;_BoFs/2011/KDE_Buildsystem_BoF</a>

Topics will be what is mentioned there, mostly the issues discussed at the
Platform 11 sprint in Randa:
<a href="" title=""></a>
<a href="" title=""></a>
<a href="" title=""></a>

But currently the BoF is scheduled for Wednesday 16:00.
I'll be leaving Wednesday 17:00, so I think having the buildsystem BoF just
directly before I leave doesn't make a lot of

X11 expert help needed


I'm currently comparing our FindX11.cmake with the one in current cmake.
Our copy is in kdelibs/cmake/modules/, CMake's is in its Module/ directory.

There are some things our version checks for, which the one from cmake
doesn't, and vice versa.
Also, we append more of the libs to the X11_LIBRARIES variable.

Is this good ?
Should the stuff we do just be merged into the cmake version ?
Can somebody who knows more about X11 please have a look at these two files,
one in kdelibs, the other one in cmake 2.8.5 or git HEAD ?
<a href=";a=summary" title=";a=summary">;a=summary</a>

Helping hands are ver

RFC: replacing MacroLogFeature.cmake with FeatureSummary.cmake


in KDE we have the file MacroLogFeature.cmake which we use to print a summary
of found/missing packages at the end of a cmake run.
I added similar functionality later on in 2007 to cmake in the form of
<a href="" title=""></a>

Among others due to source compatibility requirements we are still using
MacroLogFeature.cmake in KDE, but I'd like to get rid of this and instead use
FeatureSummary.cmake from the not yet existing cmake 2.8.6, which means we
have some time to improve it so it does what we need.
The plan is

Enabling the wiki on ?


I'm not sure which mailing list is appropriate for this, so I try here. is Redmine, and Redmine has a wiki.
AFAIK the wiki is currently disabled on (or can I enable it
on a per-project basis and I just didn't find it ?).

Can we enable the wiki please ?
I created the "SuperBuild" project there after the Platform sprint, and having
the wiki right there would IMO be a perfect place to put documentation etc.
I wouldn't have to go to yet another wiki, or set up a whole website, etc.

So, what's the state with the wiki on ?


svn -> git transition status ?


what's the current status with our svn to git transition ?
There are still several modules in svn (kdeaccessibility, kdeadmin,
kdeartwork, kdebindings, kdegames, kdegraphics, kdemultimedia, kdenetwork,
kdesdk, kdetoys, kdeutils, kdewebdev).

Is it planned to move them also to git ?
Is somebody working on this ?

git and commitfilter ?


is commitfilter (<a href="" title=""></a>) actually working with git ?
Just today I figured that there is such silence wrt. to commit emails for
kdelibs/cmake/modules/ because probably commitfilter is not working with
git ?

Is there an equivalent for it ?
Or should I do the filtering on my side in the email client ?
Or does it work and there is really nothing being committed ?