Re: Review Request 128002: address alignment issue with the OS X native "macintosh" style

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128002/#review95755
---


Ship it!




Also the navigator got fixed by you after all. Thanks, René!

- Marko Käning


On May 24, 2016, 2:50 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128002/
> ---
> 
> (Updated May 24, 2016, 2:50 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> This patch addresses a misalignment issue in KUrlNavigator when using the 
> native "macintosh" widget style on OS X.
> 
> Cf. https://bugs.kde.org/show_bug.cgi?id=296845
> 
> 
> Diffs
> -
> 
>   src/filewidgets/kurlnavigatorbuttonbase.cpp 8b06bfa 
> 
> Diff: https://git.reviewboard.kde.org/r/128002/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9 with frameworks 5.20.0 (sic), Qt 5.6.0 using my MacPorts build.
> 
> The additional attribute doesn't have any effects for me with other styles, 
> but this still has to be verified on other platforms.
> 
> 
> File Attachments
> 
> 
> The widget concerned in Kate's interface, showing the result with and without 
> the patch. It is clear which is which.
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/24/ca3c7872-68ee-4ed6-b1f4-4d0b05111be1__Screen_Shot_2016-05-24_at_14.37.43.png
> other widgets remain to be done
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/24/71b20243-8dda-4f22-89e1-21559b767fd5__Screen_Shot_2016-05-24_at_14.38.30.png
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128005: fix alignment issue with the OS X native "macintosh" style

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128005/#review95754
---


Ship it!




Hi René,

nice to see that you finally found a solution for this old problem!

Congrats,
Marko

- Marko Käning


On May 24, 2016, 6:39 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128005/
> ---
> 
> (Updated May 24, 2016, 6:39 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Christoph 
> Feck.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> ---
> 
> This patch fixes the size & alignment issue discussed in 
> https://bugs.kde.org/show_bug.cgi?id=296810
> 
> 
> Diffs
> -
> 
>   src/kmultitabbar.cpp f7739fa 
> 
> Diff: https://git.reviewboard.kde.org/r/128005/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with KF5 5.20.0, Qt 5.6.0 and Kate 16.4.01 . No adverse 
> effects when used with other themes on this platform.
> 
> 
> File Attachments
> 
> 
> Kate5 running with the native "macintosh" qpa & theme, showing correct 
> alignment.
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/24/fe90cba8-f6de-4e5c-8732-4cbebf4abe8b__Screen_Shot_2016-05-24_at_18.38.16.png
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

[Marko Käning]

Hi René,

On 22 Oct 2015, at 19:24 , René J.V. Bertin  wrote:
> Not exactly, no. The patch was rejected in the presented form, but we were 
> invited to file a bug report (I think it's 
> https://bugreports.qt.io/browse/QTBUG-44473). Here we (me, IIRC) managed to 
> make the case for special needs by MacPorts and family.
> My understanding is that the door is still open for a QSP patch that does not 
> alter the default QSP behaviour, which is exactly what my patch does (i.e. it 
> requires activation).

ok, you're right.


>> Could it be, that we have to introduce a QSP patch in MacPorts’ qt5-mac to 
>> revert back to the Linuxy way of XDG paths?
> 
> Have you forgotten I'm working on that, and that I actually created a qt5-kde 
> port so that (y)our KF5 ports could depend on a port with the required 
> patch(es) and install layout?

How could I forget that? ;-) I was merely trying to trigger the discussion!


Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

[Marko Käning]

Thanks René and Jeremy,

On 22 Oct 2015, at 22:43 , Jeremy Whiting  wrote:

> ...It sounds like a good solution for embedding a copy of Qt next
> to each application for windows use (and maybe for osx use too if
> resources don't make it completely unneccessary), but not for the
> macports shared Qt case.

for clarifying this.

Greets,
Marko


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

[Marko Käning]

Hi Ralf,

On 22 Oct 2015, at 08:35 , Ralf Habacker  wrote:
> umbrello for example depends on about 50 other libraries and packages
> https://build.opensuse.org/project/show/home:rhabacker:branches:windows:mingw:win32:KF511.
> Not patching Qt requires to repack every single package :-(, by either
> hacking the cmake build system to use different install locations or to
> reorder the installed files after cmake installing.
> 
> Having Qt support for "standard linux path layout" for example by
> extending qt.conf to support QStandardPath (qt.conf is already required
> for KDE on Windows) shortcuts this repackaging need completely.


have you followed the discussion with Qt's developers regarding the QSP patch 
[1]?
If not, I advise you to do a little reading there!
Qt won’t ever support such an approach, i.e. one would have to patch it, if KDE 
itself doesn’t
come with its own provisions for this...

If every single KDE application wants to be self-contained - to be more easily 
distributable -
then that’s fine, especially for bigger apps like KMail, DigiKam, Marble, 
KDEnlive… This would
perhaps even make a distribution via the App Store possible. ;-)


However, if one wants to avoid all the duplication of libs to be shipped, then 
one better uses
a package management system like MacPorts, Homebrew, Fink on OSX and who knows 
what on Windows.


This however will require extra efforts for those systems, if KDE doesn’t 
somehow envisions such
distribution mechanisms for non-Linux distros.

Wondering where things are heading to now...


I think it’s great, that this thread(s) started a discussion about this 
pressing topic.

:-)


Could it be, that we have to introduce a QSP patch in MacPorts’ qt5-mac to 
revert back to the
Linuxy way of XDG paths?

Greets,
Marko





[1] https://codereview.qt-project.org/#/c/103277/

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Version numbering at download location

[Marko Käning]

Hi David,

On 10 Oct 2015, at 15:37 , David Faure  wrote:
> OK, so we're not talking about the organization of the FTP directories, but 
> about HTML pages.
> That's quite different (a single HTML page could point to multiple FTP 
> directories, for instance).

yep.


> Does https://www.kde.org/info/kde-frameworks-5.15.0.php work for this?
> Well, the above has all you need for z==0.

Looks good for z=0…


> For z > 0, I previously sometimes made a separate page, but that's not 
> automated and I'm lazy
> so I actually forgot for kservice 5.14.z.
> Might be simpler for me to just add entries into that table above, and then 
> it would work better
> for you, right?

I think it’s indeed simpler to just append a section to above page which lists 
all incoming patch
releases for the respective x.y version.

This way MacPorts’ livecheck could easily find out whether there is a new 
patch-version z present.

The creation of the patch-release section could surely be automated by a script 
which would have
to be executed on every patch release.

Thanks,
Marko

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Version numbering at download location

[Marko Käning]

On 05 Oct 2015, at 10:08 , David Faure <fa...@kde.org> wrote:

> On Monday 05 October 2015 09:34:04 Marko Käning wrote:
>> The issue is that the version regexp match should preferably
>> happen on a single web page. With this setup the full version numbers are 
>> spread over two dir
>> levels… :-(
> 
> I'm not sure I understand which web page this is about.
> I can do things differently for hotfix releases on www.kde.org, but maybe 
> this isn't what you meant?

In MacPorts the version check is usually done by downloading the web-page where 
the corresponding source
code archives can be grabbed from. This is usually a simple web-page created by 
source-forge, github,
bitbucket or the like…

Such a HTML page would contain all valid version numbers (together with other 
infos) of a given code-archive.
The regexp to be defined now grabs the version numbers in the desired format, 
i.e. x.y.z and thus allows
to cross-check all numbers found against the one currently in use be the 
installed version of the corresponding
software.

Yet, KF5’s approach means that you have at first a page where you get a choice 
between x.y’s and then at the
following page - a lever lower - you only start to see x.y.z refinements...

Does KDE perhaps have another overview web-page where for every code-archive 
distributed all currently available
versions are listed?! That would come very handy for me now!
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Building KF in version 5.14 on OSX fails for framework kdesignerplugin

[Marko Käning]

Hi David,

now that I learnt, that we can have bug-fix releases in already released KF5 
versions,
I’d suggest a 5.14.1 for the kdesignerplugin, which contains Kurt’s fix:

On 18 Sep 2015, at 20:42 , Marko Käning <mk-li...@mailbox.org> wrote:

> Dear Kurt,
> 
> On 16 Sep 2015, at 15:20 , Kurt Hindenburg <kurt.hindenb...@gmail.com> wrote:
>> Git commit 6cbf534c3cd2c5bdda819e092c9778c27e814161 by Kurt Hindenburg.
> 
> thanks for your commit!
> 
> Looking forward to release 5.15 then, David.
> :)

That would finally allow me to test the 5.14 on a MacPorts-based OSX VM.

What do you think about that?

Greets,
Marko

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Building KF in version 5.14 on OSX fails for framework kdesignerplugin

[Marko Käning]

Well, I know, I could simply make my Portfile use a patch file…

On 05 Oct 2015, at 21:18 , Marko Käning <mk-li...@mailbox.org> wrote:
> I’d suggest a 5.14.1 for the kdesignerplugin, which contains Kurt’s fix:

… or simply wait a a tiny bit longer…

Perhaps that’s less hassle then you trying to do create a another tiny release 
step
for this framework given that you’ll come up within the next few days with new 
version
5.15.0 anyways!

:)
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Version numbering at download location

[Marko Käning]

Hi David,

On 05 Oct 2015, at 09:27 , David Faure  wrote:
> Yes, this fix allows to have hotfix releases of single frameworks. Look at
> KService 5.14.1, 5.14.2 and 5.14.3.
> They are in the 5.14 subdir, where they belong.

ok, I wasn’t aware of that.


> x.y.z where z is > 0 is *always* about single framework hotfixes, never about 
> all frameworks,
> hence the new subdir numbering scheme.

Understood.


> I'm sure you can remove "everything after the last dot" in your regexp, 
> otherwise I can
> help with that :-)

The regexp isn’t the point! ;-) The issue is that the version regexp match 
should preferably
happen on a single web page. With this setup the full version numbers are 
spread over two dir
levels… :-(

Need to check whether this can be achieved anyway within MacPorts Portfile 
syntax by some Tcl
magic.

Thanks for the pointer!

Greets,
Marko

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Version numbering at download location

[Marko Käning]

Hi David,

I was surprised to find that up to version 5.3.0 you were still using the 
trailing zero
for the folder name below

http://download.kde.org/stable/frameworks/

but from 5.4 on you started to omit it. The archives in those folders but still 
have
that trailing zero...

Does this mean that there will never be a x.y.z folder ever again on that page, 
or is
that only temporally so?

I am thinking about formulating the right regex for the version livecheck for 
MacPorts’
kf5-* ports, which is why I am asking.

To be honest, I’d prefer, if you could revert back to x.y.z, as this simplifies 
the
setup of the version livecheck tremendously!

Greets,
Marko

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Building KF in version 5.14 on OSX fails for framework kdesignerplugin

[Marko Käning]

Dear Kurt,

On 16 Sep 2015, at 15:20 , Kurt Hindenburg  wrote:
> Git commit 6cbf534c3cd2c5bdda819e092c9778c27e814161 by Kurt Hindenburg.

thanks for your commit!

Looking forward to release 5.15 then, David.
:)

Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Building KF in version 5.14 on OSX fails for framework kdesignerplugin

[Marko Käning]

Hi kdesignerplugin devs,

On 14 Sep 2015, at 15:00 , Kurt Hindenburg  wrote:
> 
> It appears the  QT_VERSION check in d53ec9b97d7b353ea4cce54d5ecae3c93b933ddd 
> is not enough when using Qt 5.4.x

anyone out there who can fix kdesignerplugin regarding this version check so 
that the next KF5 release is build-able again on Qt 5.4.x?

Greets,
Marko


P.S.: Thanks, Kurt, for investigating this! :)
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Building KF in version 5.14 on OSX fails for framework kdesignerplugin

[Marko Käning]

Hi devs,

the other day I had built version 5.13 successfully on a OSX/MacPorts-based VM.
And so I wanted to try the same with the newest 5.14 just now, but failed! :(

Any idea why those three interfaces are undefined?

Greets,
Marko



---

:info:build [ 85%] Generating qrc_testplugin.cpp
:info:build cd 
/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build/autotests
 && /opt/local/libexec/qt5-mac/bin/rcc -name testplugin -o 
/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build/autotests/qrc_testplugin.cpp
 
/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/kdesignerplugin-5.14.0/autotests/testplugin.qrc
:info:build 
/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build/src/kdewebkitwidgets.cpp:22:
 Error: Undefined interface
:info:build [ 85%] Generating testpluginwidgets.cpp
:info:build cd 
/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build/autotests
 && ../src/kgendesignerplugin -o 
/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build/autotests/testpluginwidgets.cpp
 
/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/kdesignerplugin-5.14.0/autotests/testplugin.widgets
:info:build make[2]: *** [src/kdewebkitwidgets.moc] Error 1
:info:build make[2]: Leaving directory 
`/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build'
:info:build make[1]: *** [src/CMakeFiles/kdewebkitwidgets.dir/all] Error 2
:info:build make[1]: *** Waiting for unfinished jobs
:info:build 
/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build/autotests/minimalwidgets.cpp:23:
 Error: Undefined interface
:info:build make[2]: *** [autotests/minimalwidgets.moc] Error 1
:info:build make[2]: Leaving directory 
`/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build'
:info:build make[1]: *** [autotests/CMakeFiles/minimalplugin.dir/all] Error 2
:info:build [ 86%] Generating testpluginwidgets.moc
:info:build cd 
/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build/autotests
 && /opt/local/libexec/qt5-mac/bin/moc 
@/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build/autotests/testpluginwidgets.moc_parameters_debug
:info:build 
/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build/autotests/testpluginwidgets.cpp:25:
 Error: Undefined interface
:info:build make[2]: *** [autotests/testpluginwidgets.moc] Error 1
:info:build make[2]: Leaving directory 
`/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build'
:info:build make[1]: *** [autotests/CMakeFiles/testplugin.dir/all] Error 2
:info:build 
/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build/src/kdewidgets.cpp:69:
 Error: Undefined interface
:info:build make[2]: *** [src/kdewidgets.moc] Error 1
:info:build make[2]: Leaving directory 
`/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build'
:info:build make[1]: *** [src/CMakeFiles/kf5widgets.dir/all] Error 2
:info:build make[1]: Leaving directory 
`/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory 
`/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build'
:info:build Command failed:  cd 
"/opt/local/var/macports/build/_Users_marko_WC_GIT_macports-kde_dports_kde_kf5-kdesignerplugin/kf5-kdesignerplugin/work/build"
 && /usr/bin/make -j5 -w all VERBOSE=ON
:info:build Exit code: 2
:error:build org.macports.build for port kf5-kdesignerplugin returned: command 
execution failed
:debug:build Error code: CHILDSTATUS 4898 2

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 123075: do not require X11 on Mac OS X

[Marko Käning]

 On March 20, 2015, 8:07 a.m., Martin Gräßlin wrote:
  as in other similar requests: -2 from my side
 
 Martin Gräßlin wrote:
 To extend: I think the way is wrong. If it now builds on MacOS the 
 required is wrong. It should be an optional find_package properly ifdefed.
 
 Christoph Cullmann wrote:
 Actually, you don't want that it is optional as you really don't want 
 that it ever is found on MacOS. If you install an XQuartz for legacy apps, it 
 will be found, and you will have a completly mess as result ;=)
 
 Martin Gräßlin wrote:
 Christoph, that argument is wrong. The same would be the case with 
 Windows and any other platform which optionally offers X11 (this includes 
 Linux!). CMake can handle the situation quite well to disable an unwanted 
 build dependency. If a user installs XLib headers (which is not the same as 
 just installing XQuartz) we should expect the user to disable the cmake build 
 option.
 
 Christoph Cullmann wrote:
 That means that nobody will get a senseful build on Mac, if he doesn't 
 disable that optional dependency. Thats the opposite of a normal optional 
 dependency, that leads to missing features if not found but not complete mess 
 if found.
 I tried to compile frameworks stuff on Mac, and IMHO, really, that makes 
 it close to unusable, that you need to tweak each cmake call just to have 
 something usable, if you have too much stuff installed. I never had to do 
 that on Linux/Other Unices.
 
 Martin Gräßlin wrote:
  That means that nobody will get a senseful build on Mac
 
 What since when is XLib as a build dependency available by default on OS 
 X?
 
 Christoph Cullmann wrote:
 Actually, if you work with Frameworks there, you will install something 
 over MacPorts or Homebrew, and yes, you will have XQuartz installed, to run 
 some legacy apps and there is really no user understandable way to install 
 XQuartz without its devel headers, the .dmg will just install everything, I 
 was suprised myself that I have X devel headers just by installing an 
 X-Server. My first workaround was just to deinstall XQuartz, later I started 
 to tweak CMake options or do exactly the same fixes as above. And yes, I 
 think, per default, without any magic options, frameworks should just build 
 to a usable state. And I see 0 reason to ever have even an optional with 
 x11 build of an frameworks application. But I might be wrong. Therefore I 
 don't vote here or say ship it, just wanted to state my concerns ;=)
 
 Martin Gräßlin wrote:
 my concern is that we make our CMakeLists.txt way more complex (it's not 
 the only framework which recently saw such a proposed change) and work around 
 broken systems in our CMakeLists. That's something I do not want to see - if 
 the downstream packaging sucks, it needs to be fixed there. We would tell the 
 same to every Linux distribution.
 
 I do not want to see such OS specific changes go in as X11 is not OS 
 specific - all operating systems we support in KDE can provide X11 and on all 
 OS there are alternative windowing systems. What I don't want to see is 
 something like:
 if (NOT APPLE AND NOT WINDOWS AND NOT LINUX_ANDROID AND NOT 
 LINUX_UBUNTU_PHONE AND NOT LINUX_SAILFISH AND NOT LINUX_WEBOS AND NOT ...
 
 if we start with one platform, where do we end? Is adding the check for 
 Apple OK and Windows not?
 
 Christoph Cullmann wrote:
 We could wrap the X11 search in a own module that will not do anything on 
 Apple, to avoid the if stuff.
 On the other side, even with the if, it still avoids that we have some 
 combinations feasible in the frameworks, that we need will not test anyway, 
 e.g. apple + X11.
 That avoids complexity, too. Actually I would be OK do have the same for 
 WIN, too, yeah, still better than a code path that you can configure in, that 
 actually will not work.
 
 Martin Gräßlin wrote:
 I'm not worried about the code paths - everything X11 specific should be 
 runtime wrapped anyway in a if (QX11Info::isPlatformX11()). If not: that 
 needs fixing.

What's the status of this one?


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123075/#review9
---


On March 19, 2015, 11:59 p.m., Harald Fernengel wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123075/
 ---
 
 (Updated March 19, 2015, 11:59 p.m.)
 
 
 Review request for KDE Frameworks and Michael Palimaka.
 
 
 Repository: kdesu
 
 
 Description
 ---
 
 do not require X11 on Mac OS X
 
 
 Diffs
 -
 
   CMakeLists.txt 9623483d6f11f9cdb7d7dc19decfd7cf5e86d079 
 
 Diff: https://git.reviewboard.kde.org/r/123075/diff/
 
 
 Testing
 ---
 

Re: Review Request 123692: autotests: Use QTEST_GUILESS_MAIN

[Marko Käning]

 On June 13, 2015, 10:26 a.m., Heiko Becker wrote:
  Ping?

Hi Heiko, I've added this to our KDE's Phabricator task 
[T398](https://phabricator.kde.org/T398). ATM I can't test on my own OSX/CI 
system, as that is in limbo since we changed to Scarlett's new KDE/CI system. 
But I'll come back to this RR, once I had a chance to check it independently on 
OSX.


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123692/#review81439
---


On May 8, 2015, 9:15 p.m., Heiko Becker wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123692/
 ---
 
 (Updated May 8, 2015, 9:15 p.m.)
 
 
 Review request for KDE Frameworks and Jeremy Whiting.
 
 
 Repository: knewstuff
 
 
 Description
 ---
 
 The tests still work fine with it, allowing them to run without a
 display server.
 
 
 Diffs
 -
 
   autotests/knewstuffauthortest.cpp 5ca7c4903e90a5b8bf377c3c12d5bbe7c0623002 
   autotests/knewstuffentrytest.cpp 7862ebbbf7c6a913cb4d6d0b70b2edf151ec6327 
 
 Diff: https://git.reviewboard.kde.org/r/123692/diff/
 
 
 Testing
 ---
 
 Built and ran the tests successfully.
 
 
 Thanks,
 
 Heiko Becker
 


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: A CI dashboard with multiple versions of Qt5 on Linux

[Marko Käning]

Hi Jan,

On 12 Jun 2015, at 01:17 , Jan Kundrát j...@kde.org wrote:
 http://ci-logs.kde.flaska.net/matrix.html

that looks really neat, indeed!
:-D

Congratulations,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: missing dep on OSX CI?

[Marko Käning]

Hi David,

On 06 Jun 2015, at 10:37 , David Faure fa...@kde.org wrote:

 KActivities fails with the error below. Is boost::optional installed?
 
 04:17:31 
 /Users/jenkins/builds/kactivities/kf5-qt5/src/utils/continue_with.h:14:10: 
 fatal error: 'boost/optional.hpp' file not found
 04:17:31 #include boost/optional.hpp

yes, it is installed, but below /opt/local!

I’ve added you to https://phabricator.kde.org/T353

Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: CI for kf5-qt5 is not green anymore

[Marko Käning]

Hi Scarlett,

I’ve logged onto my VM as user jenkins, i.e. a GUI session is now available.
So you could run a test-build for a project which failed before on you.

Let me know how it goes.

Greets,
Marko


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 123595: Fix KUser test for Mac.

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123595/#review79919
---


Looks like the test is still failing: 

https://build.kde.org/job/kcoreaddons%20master%20kf5-qt5/24/PLATFORM=OSX,compiler=clang/testReport/(root)/TestSuite/kusertest/

Anything I could do?

- Marko Käning


On May 2, 2015, 8:45 p.m., David Faure wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123595/
 ---
 
 (Updated May 2, 2015, 8:45 p.m.)
 
 
 Review request for KDE Frameworks and Marko Käning.
 
 
 Repository: kcoreaddons
 
 
 Description
 ---
 
 According to CI [1], an invalid user belongs to nogroup on Mac.
 Not sure if this is true on all OSX installations though?
 
 https://build.kde.org/view/Frameworks%20kf5-qt5/job/kcoreaddons%20master%20kf5-qt5/PLATFORM=OSX,compiler=clang/19/testReport/%28root%29/TestSuite/kusertest/
 
 
 Diffs
 -
 
   autotests/kusertest.cpp d17a2d3e97d5056524281eb18766377e48a0da35 
 
 Diff: https://git.reviewboard.kde.org/r/123595/diff/
 
 
 Testing
 ---
 
 Still passes on Linux; should fix the CI for mac, AFAICS.
 
 
 Thanks,
 
 David Faure
 


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: stable-KF5-QT5 QT version...

[Marko Käning]

Hi Scarlett,

On 18 Apr 2015, at 17:17 , Scarlett Clark sgcl...@kubuntu.org wrote:

 15:09:51   with requested version 5.4.0”.

this is not a matter of whether apps use stable-kf5-qt5 or kf5-qt5 branch
groups, it is just about the notion devs have about requirements to be
expected for stable-kf5-qt5. And this is clearly not the CI team’s job to
get this fixed. ;)

Many believe that 5.3.2 isn’t being developed for anymore and thus simply
assume 5.4.0 to be the minimum requirement, also on stable-kf5-qt5!

This is - of course - not in line with out CI system(s) and has popped up
a couple of times on K-F-D in the last half year...


So, I guess, we all need to come to a decision about what stable-kf5-qt5
actually means for all of KDE!

Greets,
Marko


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kdepimlibs fails to build on branch master

[Marko Käning]

Hi Daniel,

On 12 Apr 2015, at 09:50 , Daniel Vrátil dvra...@kde.org wrote:
 it's referring to a file in kdepim-runtime.git/resources (where Knut 
 originally was before it was moved to kdepimlibs auto tests).

I see.


 I don't understand Mac much, but is the file actually needed for the Knut 
 resource?

Well, the build fails because of it, thus it’s needed for that at least. :)
Whether it is still really required I have no clue.

 
 It's installed, but it's only used for unit tests.

Yep, and those shall be run.


 If it is still needed, we can just copy the file from kdepim-runtime.git
 to the knut folder in kdepimlibs and adapt the CMakeLists.txt.

Go for it, please! :-)

Thanks,
Marko


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

New KDE/CI: qca fails to build on branch qt5 for branch group kf5-qt5 on platform OSX

[Marko Käning]

https://build-sandbox.kde.org/job/qca%20qt5%20kf5-qt5/PLATFORM=OSX,compiler=clang/7/console
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kdepimlibs fails to build on branch master

[Marko Käning]

Here is now the detailed information available from the new CI system:


https://build-sandbox.kde.org/job/kdepimlibs%20master%20kf5-qt5/9/PLATFORM=OSX,compiler=clang/console

Smells like a real Qt bug, indeed.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 120649: Encode the URIs which end up in DTD files

[Marko Käning]

 On Oct. 24, 2014, 12:05 a.m., Marko Käning wrote:
  I will have to test this in a specially configured OSX/CI VM. Will report 
  back on it.

Herewith I can report, that on Scarlett's new CI system we were able to verify 
that the file 
```/opt/kde/install/darwin/mavericks/clang/kf5-qt5/frameworks/kdelibs4support/inst/Library/Application\
 Support/kf5/kdoctools/customization/dtd/kdex.dtd``` correctly contained the 
escaped space in ```Application Support```!


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120649/#review69058
---


On Feb. 28, 2015, 11:05 p.m., Luigi Toscano wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120649/
 ---
 
 (Updated Feb. 28, 2015, 11:05 p.m.)
 
 
 Review request for Build System, KDE Software on Mac OS X, KDE Frameworks, 
 and kdewin.
 
 
 Repository: kdelibs4support
 
 
 Description
 ---
 
 The URI need to be encoded, because some valid characters for
 filenames are not valid according RFC 2396.
 Easy way to trigger the issue: when the path contains spaces,
 as it happens on MacOSX builds.
 
 The function is duplicated from the matching functions in kdoctools
 because:
 - this module will go away in the not far future;
 - the function is not generic enough to be used outside (yet)
 
 See also https://git.reviewboard.kde.org/r/120648/ for the twin review on 
 kdoctools.
 
 
 Diffs
 -
 
   cmake/uriencode.cmake PRE-CREATION 
   src/CMakeLists.txt 4a1d80d 
 
 Diff: https://git.reviewboard.kde.org/r/120649/diff/
 
 
 Testing
 ---
 
 It compiles, but I can't properly test Mac and Windows scenarios
 
 
 Thanks,
 
 Luigi Toscano
 


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: kdepimlibs fails to build on branch master

[Marko Käning]

Hi folks,

after a long time I am finally able to build kmime [1] and thus also kimap and 
kmbox needed for kdepimlibs!
:-D

Now I can tackle kdepimlibs again, but the build fails because of a missing 
template file:
---
-- Configuring done
CMake Error: Target akonadi_knut_resource Info.plist template 
/Users/marko/WC/KDECI-builds/kf5-qt5/kdepimlibs/akonadi/autotests/testresource/../Info.plist.template
 could not be found.
---

Any idea where it has gone, if it ever existed??

Greets,
Marko




[1] https://git.reviewboard.kde.org/r/123334/
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 120648: Encode the URIs which end up in DTD files

[Marko Käning]

 On April 3, 2015, 5:58 p.m., Andrius da Costa Ribas wrote:
  cmake/uriencode.cmake, line 15
  https://git.reviewboard.kde.org/r/120648/diff/2/?file=320784#file320784line15
 
  I've tried changing this to:
  
  execute_process(COMMAND perl -MURI::Escape -e print 
  uri_escape_utf8(\${escaped_uri}\, \^A-Za-z0-9\\-\\._~\\/:\);
  (...)
  
  it works here, but I'm not sure if it'd be the proper fix.
 
 Patrick von Reth wrote:
 ah that whas the error, thanks I finally can compile kdoctools (atleast 
 locally ) again

Has this already been committed, or should this RR still considered to be 
re-opened?


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120648/#review78445
---


On Feb. 28, 2015, 11:02 p.m., Luigi Toscano wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120648/
 ---
 
 (Updated Feb. 28, 2015, 11:02 p.m.)
 
 
 Review request for Build System, KDE Software on Mac OS X, KDE Frameworks, 
 and kdewin.
 
 
 Repository: kdoctools
 
 
 Description
 ---
 
 The URI need to be encoded, because some valid characters for
 filenames are not valid according RFC 2396.
 Easy way to trigger the issue: when the path contains spaces,
 as it happens on MacOSX builds.
 
 See also https://git.reviewboard.kde.org/r/120649/ for the twin review on 
 kdelibs4support.
 
 
 Diffs
 -
 
   cmake/uriencode.cmake PRE-CREATION 
   src/CMakeLists.txt 341ecf4 
 
 Diff: https://git.reviewboard.kde.org/r/120648/diff/
 
 
 Testing
 ---
 
 It compiles, but I can't properly test Mac and Windows scenarios
 
 
 Thanks,
 
 Luigi Toscano
 


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 120648: Encode the URIs which end up in DTD files

[Marko Käning]

 On April 3, 2015, 5:58 p.m., Andrius da Costa Ribas wrote:
  cmake/uriencode.cmake, line 15
  https://git.reviewboard.kde.org/r/120648/diff/2/?file=320784#file320784line15
 
  I've tried changing this to:
  
  execute_process(COMMAND perl -MURI::Escape -e print 
  uri_escape_utf8(\${escaped_uri}\, \^A-Za-z0-9\\-\\._~\\/:\);
  (...)
  
  it works here, but I'm not sure if it'd be the proper fix.
 
 Patrick von Reth wrote:
 ah that whas the error, thanks I finally can compile kdoctools (atleast 
 locally ) again
 
 Marko Käning wrote:
 Has this already been committed, or should this RR still considered to be 
 re-opened?
 
 Luigi Toscano wrote:
 No reopen, it was submitted. No, it was not committed, I'd like to 
 understand the implication of the patch.

Thanks for clarifying.

BTW, thanks to Scarlett's progress on the new CI system it looks like we might 
soon be able to check whether this works also reliably on OSX when installing 
the files in space-containing paths.


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120648/#review78445
---


On Feb. 28, 2015, 11:02 p.m., Luigi Toscano wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120648/
 ---
 
 (Updated Feb. 28, 2015, 11:02 p.m.)
 
 
 Review request for Build System, KDE Software on Mac OS X, KDE Frameworks, 
 and kdewin.
 
 
 Repository: kdoctools
 
 
 Description
 ---
 
 The URI need to be encoded, because some valid characters for
 filenames are not valid according RFC 2396.
 Easy way to trigger the issue: when the path contains spaces,
 as it happens on MacOSX builds.
 
 See also https://git.reviewboard.kde.org/r/120649/ for the twin review on 
 kdelibs4support.
 
 
 Diffs
 -
 
   cmake/uriencode.cmake PRE-CREATION 
   src/CMakeLists.txt 341ecf4 
 
 Diff: https://git.reviewboard.kde.org/r/120648/diff/
 
 
 Testing
 ---
 
 It compiles, but I can't properly test Mac and Windows scenarios
 
 
 Thanks,
 
 Luigi Toscano
 


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: qca fails to build on branch qt5 for branch groups (stable-)kf5-qt5

[Marko Käning]

On 11 Apr 2015, at 01:22 , Marko Käning mk-li...@email.de wrote:

 I see tons of deprecation warnings for QCA as well as a real error:
 
 ---
 
 /Users/marko/WC/KDECI-builds/stable-kf5-qt5/qca/plugins/qca-ossl/qca-ossl.cpp:5719:13:
  warning: 'SSL_get_error' is deprecated: first deprecated in OS X 10.7 
 [-Wdeprecated-declarations]
int x = SSL_get_error(ssl, ret);
^
 /usr/include/openssl/ssl.h:1506:5: note: 'SSL_get_error' has been explicitly 
 marked deprecated here
 int SSL_get_error(const SSL *s,int ret_code) 
 DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;
^
 /Users/marko/WC/KDECI-builds/stable-kf5-qt5/qca/plugins/qca-ossl/qca-ossl.cpp:5808:33:
  error: use of undeclared identifier 'SSL_SESSION_get_compress_id'
sessInfo.isCompressed = (0 != 
 SSL_SESSION_get_compress_id(ssl-session));
  ^
 —

It indeed fails for kf5-qt5 as well.


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: qca fails to build on branch qt5 for branch group stable-kf5-qt5

[Marko Käning]

I see tons of deprecation warnings for QCA as well as a real error:

---

/Users/marko/WC/KDECI-builds/stable-kf5-qt5/qca/plugins/qca-ossl/qca-ossl.cpp:5719:13:
 warning: 'SSL_get_error' is deprecated: first deprecated in OS X 10.7 
[-Wdeprecated-declarations]
int x = SSL_get_error(ssl, ret);
^
/usr/include/openssl/ssl.h:1506:5: note: 'SSL_get_error' has been explicitly 
marked deprecated here
int SSL_get_error(const SSL *s,int ret_code) 
DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;
^
/Users/marko/WC/KDECI-builds/stable-kf5-qt5/qca/plugins/qca-ossl/qca-ossl.cpp:5808:33:
 error: use of undeclared identifier 'SSL_SESSION_get_compress_id'
sessInfo.isCompressed = (0 != 
SSL_SESSION_get_compress_id(ssl-session));
  ^
---



qca.log.gz
Description: GNU Zip compressed data
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KDE/CI for KF5

[Marko Käning]

Hi Ben,

On 08 Mar 2015, at 04:05 , Ben Cooksley bcooks...@kde.org wrote:
 Not entirely. What we probably need is a better way for developers to
 communicate to people on the porting status.

yes, I guess so.


 The best way to do this would probably be through the build metadata -
 if the branch has been set then we can probably assume developers
 think it is ready.

Existence of the branch alone isn’t enough, as Christoph and I noticed.


 Anything being released needs to have CI really. If the tarballs end
 up on download.kde.org, it should be Green on CI first.

OK, everything with a tarball on download.kde.org? Well, I will integrate
such a check in my CI scripts.


 That is quite a bit of effort for little return.

You can say that again.


 Out of interest, what was the primary blocker to getting things to
 build? 140 seems quite high as a number….

Yes, that’s a lot, more general failures are due to

 - porting to KF5 not yet done
 - missing Qt stuff (e.g. Qt5GStreamer, Qt5WebEngine, AccountsQt5, SignOnQt5)
 - QCA2 (even a problem on Linux)


and OSX-specific:

 - some dependency on X11
 - issues with the correct location of libs installed through MacPorts
 - missing dependencies on MacPorts
 - Apple’s clang not supported 
 - linking issues

I have left a few comments in my tier 5 list of projects [1] and more
outdated on [2].


 Anything in Extragear, Frameworks or kde/* should be covered by CI
 really. If it can't build, we need to fix that.

OK. Everything IS a lot, too much in fact, so we need to focus! This must
be helped by the project developers themselves. I think every project
should cross-check against Christoph’s site [3] and verify the fairly
detailed - automagically determined - porting status information.

What about introducing a status change notification feature for [3]?
That way the CI team could get informed once a project newly arrives or
somehow updates (by e.g. removing kdelibs4support) on KF5? I think this
would be a real help for a more effective KDE/CI.

Greets,
Marko





[1] 
http://quickgit.kde.org/?p=clones%2Fwebsites%2Fbuild-kde-org%2Fkaning%2Fmp-osx-ci.gita=blobh=d582668b5ddf434948b39257bf4db673b9f69addhb=daa9eafdc6186a5a60cc46ac3dd9e23e5f76611df=tier5.fw

[2] 
https://trac.macports.org/wiki/KDEProblems/KDEMacPortsCI/Status/ProjectsBeyondKF5

[3] http://developer.kde.org/~cfeck/portingstatus.html

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KDE Frameworks 5.8

[Marko Käning]

On 07 Mar 2015, at 19:32 , šumski hrvoje.sen...@gmail.com wrote:
 A few things regarding kpeople:
 It requires Qt 5.3, rest of KF5 5.2;

There are quite a few frameworks which require 5.4 even!


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KDE/CI for KF5 WAS OSX/CI: libkcddb and ark fail to build for KF5

[Marko Käning]

Hi Jeremy AND folks,

On 07 Mar 2015, at 02:14 , Jeremy Whiting jpwhit...@kde.org wrote:
 I appreciate the efforts you are making :)


Thanks. :)

Just wondering whether I am wasting my time because of my “perfectionism here 
on OSX/CI.
E.g. libkcddb I perhaps shouldn’t have touched at all for now, as it hasn’t 
been committed to
since last autumn… Well, for ark it’s different - of course!

But still, e.g. on my dependencies-RR [1] I have been working for 2 weeks now 
and while doing
so I more and more began to wonder whether it makes sense for all the new 
projects I am trying
to get into CI...

I have the feeling that my work (inspired by Christoph Feck’s post on KDE-DEVEL 
[2] and his
porting status page [3]) runs a little too uncoordinated - which gives me only 
extra head aches,
since I have to iterate through all these projects _manually_ while knowing far 
too little of their
real status and objectives. This lead to the result that I 

- could effectively only add about _30_ new projects

- which means that there are now about 200 projects successfully built 
on OSX/CI [4],

- while having had to go through *170* potential projects from [3] step 
by step.

For all of these I needed to figure out how to build them on OSX/CI and how to 
fix their
dependency metadata. 140 projects are thus disabled on OSX/CI for now. I doubt 
that this can
be considered a very efficient workflow! ;-)

I think we need to have another CI IRC meeting sometime soon, where we could 
discuss -
besides the change to the new KDE/CI system - also which projects are actually 
worth
considering (not only on OSX but) on Linux/CI in general!

What do you think?

Greets,
Marko



[1] https://git.reviewboard.kde.org/r/122672/
[2] http://lists.kde.org/?l=kde-develm=142434697530863w=2
[3] http://developer.kde.org/~cfeck/portingstatus.html
[4] https://trac.macports.org/wiki/KDEProblems/KDEMacPortsCI/Status
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KPeople part of KDE Frameworks

[Marko Käning]

Dear Michael,

On 04 Mar 2015, at 02:00 , Michael Pyne mp...@kde.org wrote:
 There's a reason I'd mentioned kdesrc-build's current behavior in my reply to 
 that RR. :)

yep, I figured that.

And thus I decided to come back to this issue - targeting a wider audience. :)


 I personally would retain empty entries.

OK, I see, it makes sense to revert all these removals then, just to make sure
that the current state of kdesrc-build behaves as it was supposed to do with
these explicit defines…


 But that would be a significant behavior change, especially for lesser-used 
 modules (e.g. in playground/) that don't necessarily receive CI coverage, but 
 which users and developers may still want to build via kdesrc-build.

Yes, I see that point. I guess the majority of projects currently does NOT have
CI… So, imposing the CI’s way of dealing with dependencies would add a lot of
extra work on all devs…


 I think the real solution (so that we don't need empty branch-group hacks) 
 would come from finally implementing the proposal Ben and I had made back in 
 August 2014 (currently just an email thread in kde-frameworks-devel 
 https://mail.kde.org/pipermail/kde-frameworks-devel/2014-August/018391.html).

Yes, I remember your post from last August, but unfortunately there was no
(visual) feedback on the list, nor is there any feedback here on K-F-D up to
now - which is no good news, I suppose.


 I ran out of time to do effectively any development for some months after 
 that, so as far as I know there's been no progress. But that's the direction 
 we *intend* to head... now would be a good time if you want to review the 
 proposal to see if it would help or hurt your efforts.

Right, I do believe it is time to come up with a decision in this respect!
In the light of Ben’s and Scarlett’s work on the new (multi-platform) KDE/CI
system it would be good to also tackle dependency definitions for kdesrc-build.
Scarlett has already acted in this regard, so it would be good if we could
make that more consistent for kdesrc-build as well.


Yet, I am afraid the subject of this thread isn’t attracting too many readers.
Probably you should simply repost your proposal from last August and ask for
any active discussion. I believe CI is a critical component for KDE’s further
development and thus shouldn’t be treated with too much neglect. ;-)

Greets,
Marko

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KPeople part of KDE Frameworks

[Marko Käning]

Hi Michael,

On 03 Mar 2015, at 03:30 , Michael Pyne mp...@kde.org wrote:

 On Mon, March 2, 2015 20:15:20 Marko Käning wrote:
 So, having those ktp-* entries in dependency-data-stable-kf5-qt5 shouldn’t
 do any harm.
 
   But I don’t know how kdesrc-build will handle this, though...
 
 For missing entries kdesrc-build will infer master as the git branch to 
 use. 
 It would be very confusing for a user to ask to build a module and still have 
 kdesrc-build ignore it because it doesn't have an entry in kde-build-metadata.
 
 With that said, kdesrc-build *will* ignore modules that have a defined branch 
 of  (i.e. empty) in logical-module-structure, so if a module simply should 
 not be built for a given branch-group my recommendation would be to define 
 the 
 branch-group after all but set it to an empty value. E.g.
 
kde/kdenetwork/ktp*: {
stable-qt4: kde-telepathy-0.9,
latest-qt4: kde-telepathy-0.9,
kf5-qt5: master,
stable-kf5-qt5: 
},
 
 I believe that Scarlett's new CI supports this as well, and the current 
 Jenkins CI also supports this.

Scarlett’s CI also supports to treat *undefined* entries as _set to empty_,
just like my OSX/CI does.

   So, in the light of your remarks the question is, whether all the
   removed empty definitions in my RR [1] should actually be left the
   way they are!?!?

Greets,
Marko


[1] https://git.reviewboard.kde.org/r/122672/
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KPeople part of KDE Frameworks

[Marko Käning]

Hi,

I think CI still needs something like this:
---
$ git diff
diff --git a/dependency-data-kf5-qt5 b/dependency-data-kf5-qt5
index 3731ec6..6005971 100644
--- a/dependency-data-kf5-qt5
+++ b/dependency-data-kf5-qt5
@@ -241,6 +241,11 @@ frameworks/plasma-framework: frameworks/kwindowsystem
 frameworks/plasma-framework: frameworks/kxmlgui
 frameworks/plasma-framework: frameworks/ktexteditor
 frameworks/kxmlrpcclient: frameworks/kio
+frameworks/kpeople: frameworks/kcoreaddons
+frameworks/kpeople: frameworks/kwidgetsaddons
+frameworks/kpeople: frameworks/kservice
+frameworks/kpeople: frameworks/ki18n
+frameworks/kpeople: frameworks/kitemviews
 
 # Frameworks, tier4
 frameworks/frameworkintegration: frameworks/ki18n
@@ -1056,12 +1061,5 @@ kde/kdegames/palapeli: kde/kdegames/libkdegames
 kde/kdegames/picmi: kde/kdegames/libkdegames
 extragear/games/knights: kde/kdegames/libkdegames
 
-# Playground Libs
-playground/network/kpeople: frameworks/kcoreaddons
-playground/network/kpeople: frameworks/kwidgetsaddons
-playground/network/kpeople: frameworks/kservice
-playground/network/kpeople: frameworks/ki18n
-playground/network/kpeople: frameworks/kitemviews
-
 # A standalone application, no need to install KF5
 extragear/pim/trojita: -frameworks/kf5umbrella
diff --git a/dependency-data-stable-kf5-qt5 b/dependency-data-stable-kf5-qt5
index 912255e..d5ed49b 100644
--- a/dependency-data-stable-kf5-qt5
+++ b/dependency-data-stable-kf5-qt5
@@ -236,6 +236,11 @@ frameworks/plasma-framework: frameworks/kwidgetsaddons
 frameworks/plasma-framework: frameworks/kwindowsystem
 frameworks/plasma-framework: frameworks/kxmlgui
 frameworks/plasma-framework: frameworks/ktexteditor
+frameworks/kpeople: frameworks/kcoreaddons
+frameworks/kpeople: frameworks/kwidgetsaddons
+frameworks/kpeople: frameworks/kservice
+frameworks/kpeople: frameworks/ki18n
+frameworks/kpeople: frameworks/kitemviews
 
 # Frameworks, tier4
 frameworks/frameworkintegration: frameworks/ki18n
---

Greets,
Marko___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KPeople part of KDE Frameworks

[Marko Käning]

Hi,

On 02 Mar 2015, at 19:14 , Luigi Toscano luigi.tosc...@tiscali.it wrote:
 This should really be solved somehow in a more clear way, if I'm not 
 misunderstanding all the process: there is no stable version of ktp right now 
 for kf5.

yes, I guess so.

If there is no stable version for it, it shouldn’t appear in this file!

Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KPeople part of KDE Frameworks

[Marko Käning]

We need to remember that the stable-kf5-qt5 branch group needs to be kept in 
sync
whenever updating kf5-qt5… I committed the still missing info for it in [1].

Greets,
Marko



[1] 
http://commits.kde.org/kde-build-metadata/1aa3609df9b3b513c4fd555d38cb3d047f4e3c03
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KPeople part of KDE Frameworks

[Marko Käning]

Well, Luigi, this is what the logical deps say:
---
extragear/network/telepathy/*: {
stable-qt4: kde-telepathy-0.9,
latest-qt4: kde-telepathy-0.9
},
kde/kdenetwork/ktp*: {
stable-qt4: kde-telepathy-0.9,
latest-qt4: kde-telepathy-0.9,
kf5-qt5: master
},
---
which means that kde-telepathy-0.9” is set as the latest stable for Qt4 only.

As the port group “stable-kf5-qt5” isn’t set to a value, it is not considered in
OSX/CI and Scarlett’s new version of Linux/CI.

So, having those ktp-* entries in dependency-data-stable-kf5-qt5 shouldn’t do
any harm.

   But I don’t know how kdesrc-build will handle this, though...

Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: purpose fails to build on branch master

[Marko Käning]

Hi Aleix,

after adding a few dependencies:
---
$ git diff
diff --git a/dependency-data-kf5-qt5 b/dependency-data-kf5-qt5
index 7cf844f..2a303d4 100644
--- a/dependency-data-kf5-qt5
+++ b/dependency-data-kf5-qt5
@@ -1002,6 +1002,12 @@ playground/base/kio-mtp: frameworks/ki18n
 playground/base/kio-mtp: frameworks/solid
 playground/base/kio-mtp: frameworks/kio
 
+# Playground Libs
+playground/libs/purpose: frameworks/kcoreaddons
+playground/libs/purpose: frameworks/kconfig
+playground/libs/purpose: frameworks/ki18n
+playground/libs/purpose: frameworks/kdeclarative
+
 # KAccounts
 kdereview/kaccounts-integration: frameworks/kcmutils
 kdereview/kaccounts-integration: frameworks/kio
diff --git a/logical-module-structure b/logical-module-structure
index c7f929e..284c54a 100644
--- a/logical-module-structure
+++ b/logical-module-structure
@@ -738,6 +738,9 @@
 playground/libs/kpackage : {
 kf5-qt5: master
 },
+playground/libs/purpose : {
+kf5-qt5: master
+},
 playground/base/qtcurve : {
 latest-qt4: master,
 kf5-qt5: “master”
---
I was able to start building purpose on OSX/CI...


...but then it failed later on:
---
/Users/marko/WC/KDECI-builds/kf5-qt5/purpose/src/plugins/ktp-sendfile/ktpsendfileplugin.cpp:65:28:
 error: no matching constructor for initialization of 'const QJsonObject '
Q_EMIT output( {{ QStringLiteral(url), {} }});
   ^~~
/Users/marko/WC/KDECI-builds/kf5-qt5/purpose/src/plugins/dummy/dummyplugin.cpp:48:13:
 error: no matching function for call to 'singleShot'
QTimer::singleShot(100, this, [this](){ setPercent(10); });
^~
---

Please find the whole build log attached.

Greets,
Marko


P.S.: I was trying to build kamoso. Stop me, please, if this still doesn’t make 
sense (on OSX)!!!



purpose.log.gz
Description: GNU Zip compressed data
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 121390: make Qt5 theme build on Linux again

[Marko Käning]

 engine present 
 doesn't mean that indidual KDE applications or plugins can no longer decide 
 to support only a subset to be set at build time. *)
 
 No issue either with Unix but not OS X - that's what I came up with for 
 lack of something better. Turns out Yichao has his own alternative to 
 HAVE_X11, I'll see if I can make do with that.
 
 *) or else I'll start making a ruckus to have kwin and more Plasma 
 goodies on OS X!! ;)
 
 Martin Gräßlin wrote:
 Yes, it's not about compile time checks, it's about introducing runtime 
 checks as Thomas and I wrote ;-)
 
 René J.V. Bertin wrote:
 Actually, Thomas wrote The compile time checks have no implication on 
 the runtime. Surely a typo, but those can have devastating consequences 
 around code ;)
 
 René J.V. Bertin wrote:
 (published too fast again)
 
 Actually, that blog post of yours also starts out by talking exclusively 
 about compile-time checks for about 2/3 of its length. It's only after the 
 screenshot that it becomes clear you actually use the compile-time check to 
 include a runtime-check or not. A casual reader might be tempted to stop 
 reading early, thinking he got the message ...
 
 And I can't stop thinking something that has been stamped into me: ifs 
 are expensive. Guess that shows my age ...
 
 Thomas Lübking wrote:
 That's not a typo. Meaning distorting partial quote.
 I wrote:
 The compile time checks have no implication on the runtime 
 *environment*.
 
 Ifs are expensive might be stamped into your mind and/or true, but 
 they're completely inavoidable in this context.
 
 Just that X11 was available at runtime does NOT (no more w/ Qt5) mean 
 that it's available at runtime.
 = Keep the branching out of hot loops (as always) ;-)
 
 René J.V. Bertin wrote:
 yes, I know I didn't copy the last word of your statement. That doesn't 
 change the fact that your 2nd word was *compile* instead of *run*, in a 
 context where you (at least) seemed to be saying that I apparently claimed 
 that those (= compile time) checks had an impact on runtime performance.
 
 Anyway, yes, I understood perfectly well that X11 might not be available 
 at runtime while it was when compiling, and that an application trying to do 
 X11 calls will exit with an error when trying to connect to an inexisting X11 
 server. (Or crash if X11 was actually uninstalled ... but it would take other 
 runtime checks to protect against that, and frankly that'd just be crazy.)
 
  Ifs are expensive might be stamped into your mind and/or true, but 
 they're completely inavoidable in this context.
 
 Not true, see my remarks about using function pointers above. Not that 
 that would be particularly clever and less expensive when X11 is the only 
 platform that provides a certain functionality ... :)
 (I do seem to recall that using function pointers instead of normal 
 functions was hardly more expensive on x86)
 
 Yichao Yu wrote:
 Sorry somehow my filter missed this review request and I've just seen it 
 today...
 
 To answer Martin's concern, I totally agree and it's in my mind the first 
 time I added X11 support back to the Qt5 version. The X11 related stuff in 
 `libqtcurve-utils` have also always had that check. All X11 related functions 
 are guarded by both a compile time check (e.g. if libxcb/X11 is not found or 
 somehow the user simply don't want to link to them...) and a runtime check 
 (i.e. the X11 related functions are no-ops if X11 is not initialized first at 
 runtime).
 
 Now (AFAIK) the compile failure on OSX seems to be related to some 
 sturture name conflict (or whatever it is that causes a forward declaration 
 of `Display` not working...). The real issue is already addressed in another 
 review request and it is not necessary to disable calls to X11 related 
 functions (which might be no-ops) on OSX anymore.
 
 In any case, the issue related to this request should already be resolved 
 now and the status is also monitored on build.kde.org (and AFAIK both Qt4 and 
 Qt5 versions build successfully now). I think this review request can be 
 discarded.
 
 Marko Käning wrote:
 Just for the record, QtCurve currently fails to build on OSX/CI:
 
 
 /Users/marko/WC/KDECI-builds/kf5-qt5/qtcurve/qt5/config/qtcurveconfig.cpp:1085:
  Warning: Macro argument mismatch.
 In file included from 
 /Users/marko/WC/KDECI-builds/kf5-qt5/qtcurve/lib/utils/dirs.cpp:22:
 /Users/marko/WC/KDECI-builds/kf5-qt5/qtcurve/lib/utils/dirs.h:68:1: 
 error: implicit instantiation of undefined template 
 'std::__1::basic_stringchar, std::__1::char_traitschar, std::__1::
 allocatorchar '
 getConfFile(const std::string file)
 ^
 
 Shall I send the full build log of this failure to you via PM?

For completeness: I haven't THIS RR applied to my OSX/CI system as of now. 
SHOULD I, perhaps???


- Marko

Re: Review Request 121390: make Qt5 theme build on Linux again

[Marko Käning]

 On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote:
  this is wrong - please have a look at various frameworks on how to do it 
  properly. In the end it should be:
  #if HAVE_X11
  // x11 specific stuff
  #endif
  
  obviously it also needs a runtime check:
  if (QX11Info::isPlatformX11())
  
  as we no longer should assume that X11 is the only platform on Unix(non 
  OSX).
 
 René J.V. Bertin wrote:
 I found a reference to HAVE_X11 online, but that token is not defined. 
 Note also that the Qt5 theme is supposed to build without KF5 too, for pure 
 Qt5 applications, so this kind of token should rather be provided by the Qt 
 cmake files rather than KDE's.
 
 I'll leave the runtime checks to the QtCurve devs, as they obviously 
 should be made in lots of locations and it's their call. I myself don't see 
 the point in doing a runtime check whether a platform is X11, though. It's 
 known at build time if a platform is X11. Doing a runtime check before each 
 theming action if `Q11Info::isX11Active()` (or some such call) seems to be an 
 expensive concession to a rather improbable set-up. If distros really decide 
 to give the user a choice between X11 and Wayland at login ... let them 
 figure out how to streamline that first, and then add runtime checks for the 
 active graphics backend where really needed...
 (In fact, I myself would avoid anything tied to the display layer as much 
 as possible; the fact I had to go back in a few months after the previous 
 porting effort goes to show how easy it is to break builds on other platforms 
 with that kind of functionality - as if my own error wasn't enough already.)
 
 Martin Gräßlin wrote:
 HAVE_X11 is neither defined by Qt5 nor by KF5. It needs to be set 
 manually depending on whether the source is built with or without X11 support.
 
 Concerning the runtime check:
 kwrite -platform wayland
 
 and your app is going to crash like hell if there is no runtime checks.
 
 René J.V. Bertin wrote:
 ``` neon5-exec /opt/project-neon5/bin/kwrite -platform wayland
 This application failed to start because it could not find or load the Qt 
 platform plugin wayland.
 
 Available platform plugins are: linuxfb, minimal, offscreen, xcb.
 
 Reinstalling the application may fix this problem.
 Abort (core dumped)
 ```
 
 Right, so with runtime checks it doesn't crash, it just self-destructs. 
 Very useful difference :)
 Of course an application will crash if it tries to use an unavailable 
 displaying method, or if the linker tries to load shared libraries that 
 aren't present. In fact, with X11 it might actually exit nicely with a 
 message about a display rather than crash.
 
 This just underlines my point: the only use for runtime checks in this 
 context if is the same binaries are supposed to work with multiple displaying 
 backends (or platform plugins). Whether QtCurve ought to support that is a 
 call for its developers to make, like I said above. The only way to do that 
 properly without (too much) overhead is to do the check at initialisation 
 time rather than preceding each backend-specific call, i.e. use 
 functionpointers or some OO/C++ alternative. I don't know how preferable 
 Wayland is to X11; without that I see only an interest for people working on 
 Wayland development under X11 for this kind of runtime switch support.
 To put this into context: I've often thought how it'd be nice if Qt-mac 
 would be able to use X11, but I've always dismissed the possibility that that 
 might be a runtime switch, exactly because it would introduce too much 
 overhead and/or complexity for a feature that'd be used only rarely.
 
 Thomas Lübking wrote:
  Right, so with runtime checks it doesn't crash, it just self-destructs. 
 
 You're missing the point entirely. The compile time checks have no 
 implication on the runtime environment.
 Of course you cannot use the wayland platform plugin if it's not 
 available, but you *can* compile Qt/KDE w/ X11 and wayland present - but 
 making X11 calls when running on the wayland PP will crash the application - 
 thus you must check whether you're operating on X11/xdg at runtime.
 
 Also testing for UNIX but not OSX to make X11 calls is plain wrong. 
 Could be framebuffer console or wayland and no X11 installed at all.
 
 Martin Gräßlin wrote:
 for more information please see my blog post: 
 http://blog.martin-graesslin.com/blog/2014/02/running-frameworks-powered-applications-on-wayland/
 
 Btw. the QtWayland PPA will be available starting with Qt 5.4 - a version 
 I'm already using.
 
 René J.V. Bertin wrote:
 @Thomas: we're not talking about compile time checks. Those evidently 
 don't have any implication on the runtime environment (if done correctly :)).
 I guess my point is simply that the fact that you can (= it's possible 
 to) compile Qt/KDE with every conceivable display/rendering 

Re: Review Request 121390: make Qt5 theme build on Linux again

[Marko Käning]

 engine present 
 doesn't mean that indidual KDE applications or plugins can no longer decide 
 to support only a subset to be set at build time. *)
 
 No issue either with Unix but not OS X - that's what I came up with for 
 lack of something better. Turns out Yichao has his own alternative to 
 HAVE_X11, I'll see if I can make do with that.
 
 *) or else I'll start making a ruckus to have kwin and more Plasma 
 goodies on OS X!! ;)
 
 Martin Gräßlin wrote:
 Yes, it's not about compile time checks, it's about introducing runtime 
 checks as Thomas and I wrote ;-)
 
 René J.V. Bertin wrote:
 Actually, Thomas wrote The compile time checks have no implication on 
 the runtime. Surely a typo, but those can have devastating consequences 
 around code ;)
 
 René J.V. Bertin wrote:
 (published too fast again)
 
 Actually, that blog post of yours also starts out by talking exclusively 
 about compile-time checks for about 2/3 of its length. It's only after the 
 screenshot that it becomes clear you actually use the compile-time check to 
 include a runtime-check or not. A casual reader might be tempted to stop 
 reading early, thinking he got the message ...
 
 And I can't stop thinking something that has been stamped into me: ifs 
 are expensive. Guess that shows my age ...
 
 Thomas Lübking wrote:
 That's not a typo. Meaning distorting partial quote.
 I wrote:
 The compile time checks have no implication on the runtime 
 *environment*.
 
 Ifs are expensive might be stamped into your mind and/or true, but 
 they're completely inavoidable in this context.
 
 Just that X11 was available at runtime does NOT (no more w/ Qt5) mean 
 that it's available at runtime.
 = Keep the branching out of hot loops (as always) ;-)
 
 René J.V. Bertin wrote:
 yes, I know I didn't copy the last word of your statement. That doesn't 
 change the fact that your 2nd word was *compile* instead of *run*, in a 
 context where you (at least) seemed to be saying that I apparently claimed 
 that those (= compile time) checks had an impact on runtime performance.
 
 Anyway, yes, I understood perfectly well that X11 might not be available 
 at runtime while it was when compiling, and that an application trying to do 
 X11 calls will exit with an error when trying to connect to an inexisting X11 
 server. (Or crash if X11 was actually uninstalled ... but it would take other 
 runtime checks to protect against that, and frankly that'd just be crazy.)
 
  Ifs are expensive might be stamped into your mind and/or true, but 
 they're completely inavoidable in this context.
 
 Not true, see my remarks about using function pointers above. Not that 
 that would be particularly clever and less expensive when X11 is the only 
 platform that provides a certain functionality ... :)
 (I do seem to recall that using function pointers instead of normal 
 functions was hardly more expensive on x86)
 
 Yichao Yu wrote:
 Sorry somehow my filter missed this review request and I've just seen it 
 today...
 
 To answer Martin's concern, I totally agree and it's in my mind the first 
 time I added X11 support back to the Qt5 version. The X11 related stuff in 
 `libqtcurve-utils` have also always had that check. All X11 related functions 
 are guarded by both a compile time check (e.g. if libxcb/X11 is not found or 
 somehow the user simply don't want to link to them...) and a runtime check 
 (i.e. the X11 related functions are no-ops if X11 is not initialized first at 
 runtime).
 
 Now (AFAIK) the compile failure on OSX seems to be related to some 
 sturture name conflict (or whatever it is that causes a forward declaration 
 of `Display` not working...). The real issue is already addressed in another 
 review request and it is not necessary to disable calls to X11 related 
 functions (which might be no-ops) on OSX anymore.
 
 In any case, the issue related to this request should already be resolved 
 now and the status is also monitored on build.kde.org (and AFAIK both Qt4 and 
 Qt5 versions build successfully now). I think this review request can be 
 discarded.
 
 Marko Käning wrote:
 Just for the record, QtCurve currently fails to build on OSX/CI:
 
 
 /Users/marko/WC/KDECI-builds/kf5-qt5/qtcurve/qt5/config/qtcurveconfig.cpp:1085:
  Warning: Macro argument mismatch.
 In file included from 
 /Users/marko/WC/KDECI-builds/kf5-qt5/qtcurve/lib/utils/dirs.cpp:22:
 /Users/marko/WC/KDECI-builds/kf5-qt5/qtcurve/lib/utils/dirs.h:68:1: 
 error: implicit instantiation of undefined template 
 'std::__1::basic_stringchar, std::__1::char_traitschar, std::__1::
 allocatorchar '
 getConfFile(const std::string file)
 ^
 
 Shall I send the full build log of this failure to you via PM?
 
 Marko Käning wrote:
 For completeness: I haven't THIS RR applied to my OSX/CI system as of 
 now

Re: [kio] /: Look for kdesu in the correct location

[Marko Käning]

Hi Marco,

I’ve seen your below commit for kio and wondered whether something similar
regarding CMAKE_INSTALL_FULL_LIBEXECDIR could be done for kconfig, since 
currently I need this OSX-specific configure option:
---
$ cat config/build/darwin-mavericks.cfg 
[DEFAULT]
configureExtraArgs=-DCMAKE_INSTALL_BUNDLEDIR=lib/libexec/kf5
---
to make sure that kconfig can actually find kconfig_compiler.app which
otherwise gets installed in an OSX-location [1].

Surely this application doesn’t need to be exposed to a user, thus the
location in $PREFIX/lib/libexec/kf5 is ok.

But in case cmake does install it - like in [1] below the path
/Applications/KDE - kconfig and kservice [2] should also be able to find
kconfig_compiler's application package.

Greets,
Marko




[1] https://paste.kde.org/pdubpj7nm
[2] https://mail.kde.org/pipermail/kde-frameworks-devel/2014-May/016059.html




On 09 Feb 2015, at 18:41 , Marco Martin notm...@gmail.com wrote:

 Git commit 5d70bd5de594ff40a009c0e783f9a0a7eed2f14e by Marco Martin.
 Committed on 09/02/2015 at 17:39.
 Pushed by mart into branch 'master'.
 
 Look for kdesu in the correct location
 
 Look for kdesu under CMAKE_INSTALL_FULL_LIBEXECDIR directory
 patch by Maarten De Meyer
 
 REVIEW:120185
 CCMAIL:de.meyer.maar...@gmail.com
 
 M  +2-2autotests/krununittest.cpp
 M  +11   -1src/core/desktopexecparser.cpp
 
 http://commits.kde.org/kio/5d70bd5de594ff40a009c0e783f9a0a7eed2f14e
 
 diff --git a/autotests/krununittest.cpp b/autotests/krununittest.cpp
 index 73a3932..03cbde8 100644
 --- a/autotests/krununittest.cpp
 +++ b/autotests/krununittest.cpp
 @@ -154,8 +154,8 @@ void KRunUnitTest::testProcessDesktopExec()
 int pt = ex + te * 2 + su * 4;
 QString exe;
 if (pt == 4 || pt == 5) {
 -exe = QStandardPaths::findExecutable(kdesu);
 -if (exe.isEmpty()) {
 +exe = 
 QFile::decodeName(CMAKE_INSTALL_FULL_LIBEXECDIR_KF5 /kdesu);
 +if (!QFile::exists(exe)) {
 qWarning()  kdesu not found, skipping test;
 continue;
 }
 diff --git a/src/core/desktopexecparser.cpp b/src/core/desktopexecparser.cpp
 index e20f046..7bb29ba 100644
 --- a/src/core/desktopexecparser.cpp
 +++ b/src/core/desktopexecparser.cpp
 @@ -393,7 +393,17 @@ QStringList KIO::DesktopExecParser::resultingArguments() 
 const
 if (d-service.terminal()) {
 result  su;
 } else {
 -result  QStandardPaths::findExecutable(kdesu)  -u;
 +QString kdesu = 
 QFile::decodeName(CMAKE_INSTALL_FULL_LIBEXECDIR_KF5 /kdesu);
 +if (!QFile::exists(kdesu)) {
 +kdesu = QStandardPaths::findExecutable(kdesu);
 +}
 +if (!QFile::exists(kdesu)) {
 +// Insert kdesu as string so we show a nice warning: 'Could 
 not launch kdesu'
 +result  QStringLiteral(kdesu);
 +return result;
 +} else {
 +result  kdesu  -u;
 +}
 }
 
 result  d-service.username()  -c;
 

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kde-baseapps fails to build for branch-group stable-kf5-qt5

[Marko Käning]

Hi Albert,

On 15 Feb 2015, at 23:12 , Albert Astals Cid aa...@kde.org wrote:

 El Divendres, 13 de febrer de 2015, a les 08:49:10, Marko Käning va escriure:
 Hi Albert,
 
 I just realised that kde-baseapps fails on OSX/CI when being build for
 branch group stable-kf5-qt5:
 
 Because there's no such thing as kde-baseapps stable-kf5-qt5, your scripts 
 assume there is, but that's in my opinion your scripts assuming too much on 
 what kde-build-metadata says.

yes, you’re absolutely right.


 OTOH Ben agrees with you and since he created the scritpts, fine, let's 
 assume 
 one can try to build branches of repos that don't make sense, so please fix 
 things to suit your way, but make sure you're not breaking things that we 
 have 
 actually released.

He has set this by now:
---
04833a43 (Ben Cooksley  2015-02-13 22:58:54 +1300  624)   stable-kf5-qt5: “
---
and OSX/CI is happy again - and NOT building anything which doesn’t make sense.

  So, after all, nothing to worry about! :)


More important was that two frameworks (attica and plasma-framework) had nothing
set for the stable-kf5-qt5 branch!

Obviously Linux/CI assumes ‘master' if nothing is set, but OSX/CI doesn’t and
thus stumbled over these two. This is now fixed in [1].

Greets,
Marko



[1] 
http://quickgit.kde.org/?p=kde-build-metadata.gita=blobdiffh=ecf795a6ae171b1804553386d574814c531a4c10hp=772dac0e613a754baa901e91954ff9d88ef0hb=7918a6119acbbce72d20052ef1ad14d75353a93ff=logical-module-structure
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kde-baseapps fails to build for branch-group stable-kf5-qt5

[Marko Käning]

OK, I understood only now, that kde-baseapps [1] and likely also the other two
projects are KDE4-only.

There is no EMPTY entry for “stable-kd5-qt5” branch group for these three 
projects
in our logical dependencies, which should be the reason for this.

   Should I add those? (I suspect also that I’ll stumble over more than these 
3…)




P.S.: Just now I ran into ark and pairs failing as well! ;-)
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kde-baseapps fails to build for branch-group stable-kf5-qt5

[Marko Käning]

Hi,

On 13 Feb 2015, at 10:15 , Kevin Funk kf...@kde.org wrote:
 Indeed, the kde/* rule in 'logical-module-structure' is wrong already:

yep, that’s what I wanted to express.  =)

Ben has fixed that in the meantime [1] and then changed it later again [2].

So, now one would have to introduce for all the below projects a separate
dependency block to ensure that “stable-kf5-qt5” is set to empty:

==

FAILURE SUMMARY:

 libkdcraw
 kqtquickcharts
 pairs
 ark
 cantor
 kmplot
 kolourpaint
 kmahjongg
 granatier
 killbots
 ktuberling
 knavalbattle
 lskat
 palapeli
 kreversi
 ksirk
 kturtle
 ksnakeduel
 knetwalk
 ksudoku
 kubrick
 ksquares
 kspaceduel
 katomic
 kbreakout
 kfourinline
 kgoldrunner
 kiriki
 kjumpingcube
 klickety
 kolf
 kollision
 konquest
 kpat
 kigo

==

It seems to me, though, that at least something like this
---
   kde/kdegames/*: {
stable-qt4: Applications/14.12,
latest-qt4: Applications/14.12,
kf5-qt5: frameworks,
stable-kf5-qt5: 
   }
---
might be more appropriate as a default setting, no!?


Greets,
Marko




[1] 
http://quickgit.kde.org/?p=kde-build-metadata.gita=commitdiffh=f2332e41a47184f43946675d01b05d3ece74d7ec
[2] 
http://quickgit.kde.org/?p=kde-build-metadata.gita=commitdiffh=04833a43f38bc5d316102b6fd675d0d177542e19


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: kde-baseapps fails to build for branch-group stable-kf5-qt5

[Marko Käning]

Hi Albert,

I just realised that kde-baseapps fails on OSX/CI when being build for branch 
group stable-kf5-qt5:

--
Group: stable-kf5-qt5
Project  : kde/applications/kde-baseapps
Branch   : Applications/14.12
Linux-CI : UNSTABLE
OSX/CI   : FAILURE
Prep...  
Build... : BUILD FAILED
==




This I find in the build log:
---
-- The C compiler identification is AppleClang 6.0.0.656
-- The CXX compiler identification is AppleClang 6.0.0.656
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Error at 
/opt/kde/install/darwin/mavericks/clang/shared/general/cmake/share/cmake-3.1/Modules/FindKDE4.cmake:71
 (message):
  ERROR: Could not find KDE4 kde4-config
Call Stack (most recent call first):
  CMakeLists.txt:10 (find_package)


CMake Warning (dev) in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

cmake_minimum_required(VERSION 3.1)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run cmake --help-policy CMP.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!
See also 
/Users/marko/WC/KDECI-builds/stable-kf5-qt5/kde-baseapps/build/CMakeFiles/CMakeOutput.log.

KDE Continuous Integration Build
== Building Project: kde-baseapps - Branch Applications/14.12
---


Any idea what goes wrong?

Regards,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kde-baseapps fails to build for branch-group stable-kf5-qt5

[Marko Käning]

I just realise that the same happens for these two projects:

--
Group: stable-kf5-qt5
Project  : kde/kdegraphics/libs/libkdcraw
Branch   : Applications/14.12
Linux-CI : SUCCESS
OSX/CI   : FAILURE
Prep...  
Build... : BUILD FAILED
==
--
Group: stable-kf5-qt5
Project  : kde/kdeedu/kqtquickcharts
Branch   : Applications/14.12
Linux-CI : SUCCESS
OSX/CI   : FAILURE
Prep...  
Build... : BUILD FAILED
==

while many other build just fine, like the kde-edu projects!
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kde-baseapps fails to build on branch frameworks

[Marko Käning]

Hi Albert,

On 10 Feb 2015, at 23:17 , Jeremy Whiting jpwhit...@kde.org wrote:
 Exactly, whoever added that code either needs to find a Qt 5.3 way to do the 
 same, or bump the requirement.

who is in charge of kde-baseapps?

I’d like to get this going on OSX with Qt 5.3.2 again, or at least see the 
project set its requirements correctly…

Greets,
Marko___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kde-baseapps fails to build on branch frameworks

[Marko Käning]

Hi Jeremy,

On 10 Feb 2015, at 23:10 , Jeremy Whiting jpwhit...@kde.org wrote:
 Seems that's from Qt 5.4 This enum was introduced or modified in Qt 5.4. in 
 the QUrl::UserInputResolutionOptions documentation.

Shouldn’t the project then require Qt 5.4, which I’d like to see avoided for 
now…

Greets,
Marko___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: kde-baseapps fails to build on branch frameworks

[Marko Käning]

To make kde-baseapps build again on OSX/CI I have removed poppler from its 
dependencies in config/base/kf5-qt5:
---
+# KDE/Applications
+kde/applications/kde-baseapps: -kde/kdelibs/baloo
+kde/applications/kde-baseapps: -kde/kdelibs/baloo-widgets
+kde/applications/kde-baseapps: -general/poppler
---


Yet, I am running in an unrelated problem, as it seems:
---
[ 75%] Building CXX object 
dolphin/src/CMakeFiles/kcm_dolphinviewmodes.dir/kcm_dolphinviewmodes_automoc.cpp.o
/Users/marko/WC/KDECI-builds/kf5-qt5/kde-baseapps/dolphin/src/main.cpp:108:68: 
error: no member named 'AssumeLocalFile' in 'QUrl'
const QUrl url = QUrl::fromUserInput(str, QString(), 
QUrl::AssumeLocalFile);
 ~~^
Scanning dependencies of target kitemlistselectionmanagertest
1 error generated.
make[2]: *** [dolphin/src/CMakeFiles/kdeinit_dolphin.dir/main.cpp.o] Error 1
make[1]: *** [dolphin/src/CMakeFiles/kdeinit_dolphin.dir/all] Error 2
---

Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 122493: Use qRound rather than C++11 std::lround.

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122493/#review75724
---


Yes, this lets it build on OSX/CI.

Thanks, Jeremy!

- Marko Käning


On Feb. 9, 2015, 4:31 p.m., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/122493/
 ---
 
 (Updated Feb. 9, 2015, 4:31 p.m.)
 
 
 Review request for KDE Frameworks and Marco Martin.
 
 
 Repository: kdeclarative
 
 
 Description
 ---
 
 Use qRound rather than C++11 std::lround.
 
 Removes dependency on C++11.
 
 
 Diffs
 -
 
   src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 
 67ce63a943234b167165b0f3986f974bba5ff0cf 
 
 Diff: https://git.reviewboard.kde.org/r/122493/diff/
 
 
 Testing
 ---
 
 kdeclarative is able to build on OS X 10.7 with the built in XCode compiler 
 and standard library.
 
 
 Thanks,
 
 Jeremy Whiting
 


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 122493: Use qRound rather than C++11 std::lround.

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122493/#review75725
---

Ship it!


Ship It!

- Marko Käning


On Feb. 9, 2015, 4:31 p.m., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/122493/
 ---
 
 (Updated Feb. 9, 2015, 4:31 p.m.)
 
 
 Review request for KDE Frameworks and Marco Martin.
 
 
 Repository: kdeclarative
 
 
 Description
 ---
 
 Use qRound rather than C++11 std::lround.
 
 Removes dependency on C++11.
 
 
 Diffs
 -
 
   src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 
 67ce63a943234b167165b0f3986f974bba5ff0cf 
 
 Diff: https://git.reviewboard.kde.org/r/122493/diff/
 
 
 Testing
 ---
 
 kdeclarative is able to build on OS X 10.7 with the built in XCode compiler 
 and standard library.
 
 
 Thanks,
 
 Jeremy Whiting
 


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: ark fails to build on branch frameworks

[Marko Käning]

Hi Raphael,

On 14 Jan 2015, at 22:11 , Raphael Kubo da Costa rak...@freebsd.org wrote:
 Is the full build log available somewhere, preferably with `make
 VERBOSE=1'? This really smells like OS X having an older ( 3.0) version
 of libarchive in its base system, a more recent version being
 installed by `port' (found by CMake) and the older version being picked
 up for linking.

yes, that’s correct. The system’s libarchive is being found.

Will send details as PM.

Thanks,
Marko

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: ark fails to build on branch frameworks

[Marko Käning]

I hadn’t built ark for quite a while (since I had activated it at some stage 
due to [1,2])
and only now I realise that it fails here on OSX:

---

[ 69%] [ 69%] Built target kerfuffle_clirar
Building CXX object 
plugins/clirarplugin/autotests/CMakeFiles/clirartest.dir/clirartest_automoc.cpp.o
Linking CXX shared module kerfuffle_libarchive.so
Scanning dependencies of target kerfuffle_clilha
Scanning dependencies of target kerfuffle_karchive
Undefined symbols for architecture x86_64:
  _archive_filter_code, referenced from:
  LibArchiveInterface::addFiles(QStringList const, QHashQString, 
QVariant const) in libarchivehandler.cpp.o
  LibArchiveInterface::deleteFiles(QListQVariant const) in 
libarchivehandler.cpp.o
  _archive_filter_name, referenced from:
  LibArchiveInterface::addFiles(QStringList const, QHashQString, 
QVariant const) in libarchivehandler.cpp.o
  LibArchiveInterface::deleteFiles(QListQVariant const) in 
libarchivehandler.cpp.o
  _archive_read_free, referenced from:
  LibArchiveInterface::ArchiveReadCustomDeleter::cleanup(archive*) in 
libarchivehandler.cpp.o
  _archive_read_support_filter_all, referenced from:
  LibArchiveInterface::list() in libarchivehandler.cpp.o
  LibArchiveInterface::copyFiles(QListQVariant const, QString const, 
QHashQString, QVariant) in libarchivehandler.cpp.o
  LibArchiveInterface::addFiles(QStringList const, QHashQString, 
QVariant const) in libarchivehandler.cpp.o
  LibArchiveInterface::deleteFiles(QListQVariant const) in 
libarchivehandler.cpp.o
  _archive_write_add_filter_bzip2, referenced from:
  LibArchiveInterface::addFiles(QStringList const, QHashQString, 
QVariant const) in libarchivehandler.cpp.o
  LibArchiveInterface::deleteFiles(QListQVariant const) in 
libarchivehandler.cpp.o
  _archive_write_add_filter_gzip, referenced from:
  LibArchiveInterface::addFiles(QStringList const, QHashQString, 
QVariant const) in libarchivehandler.cpp.o
  LibArchiveInterface::deleteFiles(QListQVariant const) in 
libarchivehandler.cpp.o
  _archive_write_add_filter_lzma, referenced from:
  LibArchiveInterface::addFiles(QStringList const, QHashQString, 
QVariant const) in libarchivehandler.cpp.o
  LibArchiveInterface::deleteFiles(QListQVariant const) in 
libarchivehandler.cpp.o
  _archive_write_add_filter_none, referenced from:
  LibArchiveInterface::addFiles(QStringList const, QHashQString, 
QVariant const) in libarchivehandler.cpp.o
  LibArchiveInterface::deleteFiles(QListQVariant const) in 
libarchivehandler.cpp.o
  _archive_write_add_filter_xz, referenced from:
  LibArchiveInterface::addFiles(QStringList const, QHashQString, 
QVariant const) in libarchivehandler.cpp.o
  LibArchiveInterface::deleteFiles(QListQVariant const) in 
libarchivehandler.cpp.o
  _archive_write_free, referenced from:
  LibArchiveInterface::ArchiveWriteCustomDeleter::cleanup(archive*) in 
libarchivehandler.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [plugins/libarchive/kerfuffle_libarchive.so] Error 1
make[1]: *** [plugins/libarchive/CMakeFiles/kerfuffle_libarchive.dir/all] Error 
2

---

I have this version of libarchive installed:
---
$ port installed libarchive
The following ports are currently installed:
  libarchive @3.1.2_0 (active)
$ port livecheck libarchive
---
which is up-to-date.


What’s going on?


Regards,
Marko




[1] https://bugreports.qt-project.org/browse/QTBUG-42605
[2] https://bugreports.qt-project.org/browse/QTBUG-42870





ark.log.gz
Description: GNU Zip compressed data
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kactivities fails to build on branch master

[Marko Käning]

Hi Ivan,

On 11 Jan 2015, at 22:02 , Ivan Čukić ivan.cu...@kde.org wrote:
 p.s. You can try building with -DKACTIVITIES_ENABLE_EXCEPTIONS

thanks very much!!!

Introducing a new config build file on the CI system solved this for me on OSX!

Regards,
Marko



---
$ git diff fd2d2caa5f640d4f416c7cc32e916eaa518b857f
diff --git a/config/build/kactivities/darwin-mavericks.cfg 
b/config/build/kactivities/darwin-mavericks.cfg
new file mode 100644
index 000..5512f48
--- /dev/null
+++ b/config/build/kactivities/darwin-mavericks.cfg
@@ -0,0 +1,2 @@
+[DEFAULT]
+configureExtraArgs=-DKACTIVITIES_ENABLE_EXCEPTIONS:BOOL=TRUE
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: kdeclarative fails to build on branch master

[Marko Käning]

Hi,

kdeclarative currently fails to build on OSX/CI because I haven’t installed 
port lib epoxy yet.

The question though is: is it really needed on OSX, as X11 isn’t really 
used with a native OSX/Qt install??

Regards,
Marko



-- The following REQUIRED packages have not been found:

 * epoxy , libepoxy , http://github.com/anholt/libepoxy
   OpenGL dispatch library

CMake Error at 
/opt/kde/install/darwin/mavericks/clang/shared/general/cmake/share/cmake-3.1/Modules/FeatureSummary.cmake:553
 (message):
  feature_summary() Error: REQUIRED package(s) are missing, aborting CMake
  run.
Call Stack (most recent call first):
  CMakeLists.txt:106 (feature_summary)


CMake Error: The following variables are used in this project, but they are set 
to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake 
files:
epoxy_LIBRARY (ADVANCED)
linked by target kquickcontrolsaddonsplugin in directory 
/Users/marko/WC/KDECI-builds/kf5-qt5/kdeclarative/src/qmlcontrols/kquickcontrolsaddons

-- Configuring incomplete, errors occurred!

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kdeclarative fails to build on branch master

[Marko Käning]

So, if I do install libepoxy on the OSX/CI system I get this:
---
[ 94%] Building CXX object 
src/qmlcontrols/kquickcontrolsaddons/CMakeFiles/kquickcontrolsaddonsplugin.dir/mimedatabase.cpp.o
Building CXX object 
src/qmlcontrols/kquickcontrolsaddons/CMakeFiles/kquickcontrolsaddonsplugin.dir/plotter.cpp.o
/Users/marko/WC/KDECI-builds/kf5-qt5/kdeclarative/src/qmlcontrols/kquickcontrolsaddons/plotter.cpp:23:10:
 fatal error: 'epoxy/gl.h' file not found
#include epoxy/gl.h
 ^
[ 96%] Scanning dependencies of target kdeclarativetest
---


So it looks as if the library cannot be located properly in the system, 
although it is present:
---
$ port contents libepoxy
Port libepoxy contains:
  /opt/local/include/epoxy/gl.h
  /opt/local/include/epoxy/gl_generated.h
  /opt/local/include/epoxy/glx.h
  /opt/local/include/epoxy/glx_generated.h
  /opt/local/lib/libepoxy.0.dylib
  /opt/local/lib/libepoxy.dylib
  /opt/local/lib/pkgconfig/epoxy.pc
---





Yet, I’d love to _avoid_ having to install this lib on OSX altogether, as it 
pulls in all these up to now still unneeded xorg libs:
---
$ sudo port activate libepoxy
Password:
---  Computing dependencies for libepoxy
---  Dependencies to be installed: mesa xorg-dri2proto xorg-glproto 
xorg-libXfixes xorg-fixesproto xorg-xextproto xorg-libXi xorg-inputproto 
xorg-libXext xorg-libXmu xorg-libXt
---
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: kactivities fails to build on branch master

[Marko Käning]

Sorry, this meant of course kactivities and not captivities. :)

Looks like a sole boost issue...

 Gesendet: Freitag, 09. Januar 2015 um 19:03 Uhr
 Von: Marko Käning mk-li...@email.de
 An: kde-frameworks-devel kde-frameworks-devel@kde.org
 Betreff: OSX/CI: captivities fails to build on branch master

 Linux/CI is quiet, but here on OSX/CI I see this:
 
 ---
 
 In file included from 
 /opt/local/include/boost/intrusive/circular_slist_algorithms.hpp:24:
 /opt/local/include/boost/intrusive/detail/common_slist_algorithms.hpp:146:16: 
 error: cannot use 'throw' with exceptions disabled
throw;
^
 [ 89%] Built target kactivitymanagerd_fileitem_linking_plugin
 10 warnings and 1 error generated.
 [ 90%] make[2]: *** 
 [src/imports/CMakeFiles/kactivitiesextensionplugin.dir/activitiesextensionplugin.cpp.o]
  Error 1
 ___
 Kde-frameworks-devel mailing list
 Kde-frameworks-devel@kde.org
 https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


kactivities.log.gz
Description: GNU Zip compressed data
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: captivities fails to build on branch master

[Marko Käning]

Linux/CI is quiet, but here on OSX/CI I see this:

---

In file included from 
/opt/local/include/boost/intrusive/circular_slist_algorithms.hpp:24:
/opt/local/include/boost/intrusive/detail/common_slist_algorithms.hpp:146:16: 
error: cannot use 'throw' with exceptions disabled
   throw;
   ^
[ 89%] Built target kactivitymanagerd_fileitem_linking_plugin
10 warnings and 1 error generated.
[ 90%] make[2]: *** 
[src/imports/CMakeFiles/kactivitiesextensionplugin.dir/activitiesextensionplugin.cpp.o]
 Error 1


kactivities.log.gz
Description: GNU Zip compressed data
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: qca-qt5 2.1.0.1

[Marko Käning]

Hi Harald,

should perhaps stg like this:
---
diff --git a/logical-module-structure b/logical-module-structure
index a2ef4e3..14d1f94 100644
--- a/logical-module-structure
+++ b/logical-module-structure
@@ -294,6 +300,12 @@
 kf5-qt5: master,
 stable-kf5-qt5: master
 },
+kdesupport/qca: {
+stable-qt4: KDE/4.14,
+latest-qt4: KDE/4.14,
+kf5-qt5: qt5,
+stable-kf5-qt5: qt5
+},
 playground/pim/akonadi-search: {
 kf5-qt5: master
 },
---
get committed to KDE’s build dependencies?

Regards,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Some more projects in need of respecting KF5_INSTALL_TARGETS_DEFAULT_ARGS

[Marko Käning]

Hi Alex,
Hi Ben,

Happy New Year, for a start! :)

On 07 Jan 2015, at 19:48 , Alex Merry alex.me...@kde.org wrote:

 On Tuesday 06 January 2015 23:55:48 Marko Käning wrote:
 P.P.S.: I realised by now that there are no changes on the production
 branch, which probably means that there was some change in ECM or wherever
 provoking these issues...
 
 I'm somewhat puzzled, as INSTALL_TARGET_DEFAULT_ARGS should still be set (to 
 the same value as KDE_INSTALL_TARGET_DEFAULT_ARGS) unless you have set 
 KDE_INSTALL_DIRS_NO_DEPRECATED to some TRUE-ish value. If not, that's a bug.


Hmmm...

Well, off-list I already had contacted Ben because of this issue. See this:


Begin forwarded message:
 On 07 Jan 2015, at 09:12 , David Faure fa...@kde.org wrote:
 KDEInstallDirs.cmake also has a KDE_INSTALL_TARGETS_DEFAULT_ARGS, which
 seems more appropriate.
 
 I think you're fully correct.
 
 Thus I tried KDE_INSTALL_TARGETS_DEFAULT_ARGS for the non-KF5 “systemsettings”
 project but it lead to the same error as the original 
 INSTALL_TARGETS_DEFAULT_ARGS
 variable in my initial post.
 
 Is this perhaps specific to the CI system?



So, I really wonder what’s going on here, as it doesn’t hit all projects! 
kstars fails,
but marble - for instance - still builds fine without the need to mess with 
these vars!

I can't find KDE_INSTALL_DIRS_NO_DEPRECATED in CMakeCache.txt of kstars at all, 
so I assume
that it is not set.

Does this mean it IS a bug for kstars and all the other projects after 
all?

Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Some more projects in need of respecting KF5_INSTALL_TARGETS_DEFAULT_ARGS

[Marko Käning]

On 07 Jan 2015, at 20:15 , Christoph Cullmann cullm...@absint.com wrote:
 will patch that ;=)

Thanks for patching this so promptly!

:-)
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Linux/CI OSX/CI: kglobalaccel is failing to build on branches stable and master

[Marko Käning]

Hi Martin,

On 06 Jan 2015, at 20:00 , Martin Klapetek martin.klape...@gmail.com wrote:
 Ahh yes, I prepared this and then got carried away by other work, this needs 
 to be done.

ok, I will commit these changes then right away.


 KGlobalAccel got the runtime daemon added into the framework today
 and is now tier3 (starting from 5.7 release).

Ah, ok, I see.
(This whole issue rang a bell for me, but I just couldn’t remember where and 
what I read about it…) 


 Ah humm..that would be my fault, builds fine here. I'll have a look.

Great!


 I'll have a look and fix it.

Thanks!


 Thanks for the investigation!

You are welcome.


Happy New Year to you!
Marko

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: kio-extras fails to build on branch master

[Marko Käning]

kio-extras fails due to this:
---
CMake Error at network/network/CMakeLists.txt:69 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  molletnetwork.
---
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Linux/CI OSX/CI: kglobalaccel is failing to build on branches stable and master

[Marko Käning]

Hi devs,

kglobalaccel is currently failing on Jenkins [1].


This can partially be fixed by inserting some dependencies for it:
---
diff --git a/dependency-data-kf5-qt5 b/dependency-data-kf5-qt5
index 55b4141..91ac810 100644
--- a/dependency-data-kf5-qt5
+++ b/dependency-data-kf5-qt5
@@ -16,6 +16,13 @@
 *: Qt5[stable]
 *: kdesupport/extra-cmake-modules
 
+# Frameworks, tier1
+frameworks/kglobalaccel: frameworks/kconfig
+frameworks/kglobalaccel: frameworks/kcoreaddons
+frameworks/kglobalaccel: frameworks/kcrash
+frameworks/kglobalaccel: frameworks/kdbusaddons
+frameworks/kglobalaccel: frameworks/ki18n
+
 # Frameworks, tier2
 frameworks/kauth: frameworks/kcoreaddons
 frameworks/kcompletion: frameworks/kconfig
---

... yet I wonder whether this is actually wanted!?! I thought that tier 1
frameworks won’t depend on any other framework, but kglobalaccel now seems
to be the 1st framework not being in correspondence with this!




But well, even with the above lines I run into this after all:
---
/Users/marko/WC/KDECI-builds/kglobalaccel/src/runtime/globalshortcutsregistry.cpp:38:10:
 fatal error: 'kglobalaccel_qws.h' file not found
#include kglobalaccel_qws.h
 ^
1 error generated.
make[2]: *** 
[src/runtime/CMakeFiles/kglobalaccel5.dir/globalshortcutsregistry.cpp.o] Error 1
---



This seems to be caused by the use of Q_WS_MACX. Replacing it by Q_OS_MAC in 
src/runtime/globalshortcutsregistry.cpp makes it build the OSX code path:
---
diff --git src/runtime/globalshortcutsregistry.cpp 
src/runtime/globalshortcutsregistry.cpp
index 532334a..3f84edb 100644
--- src/runtime/globalshortcutsregistry.cpp
+++ src/runtime/globalshortcutsregistry.cpp
@@ -30,7 +30,7 @@

 #if HAVE_X11
 #include kglobalaccel_x11.h
-#elif defined(Q_WS_MACX)
+#elif defined(Q_OS_MAC)
 #include kglobalaccel_mac.h
 #elif defined(Q_WS_WIN)
 #include kglobalaccel_win.h
---

Compiling now gets further, but unfortunately fails:
---

In file included from 
/Users/marko/WC/KDECI-builds/kglobalaccel/src/runtime/globalshortcutsregistry.cpp:34:
/Users/marko/WC/KDECI-builds/kglobalaccel/src/runtime/kglobalaccel_mac.h:25:10: 
fatal error: 'kshortcut.h' file not found
#include kshortcut.h
 ^
---

Ideas?

Greets,
Marko



[1] http://build.kde.org/view/FAILED/job/kglobalaccel_master_qt5/73/console
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: konsole fails to build on branch master

[Marko Käning]

Hi Christoph,

On 06 Jan 2015, at 22:10 , Christoph Cullmann cullm...@absint.com wrote:
 I think the problem is that it should be KF5_INSTALL_TARGETS_DEFAULT_ARGS,
 the prefix is missing in many cmake files.

yep, now I do remember one of your commits from a few days back…

So this is the same issue found in many projects then!

This would mean, that it DOES make sense to report these issues?!

Happy New Year to you,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: konsole fails to build on branch master

[Marko Käning]

Hi Christoph,

On 06 Jan 2015, at 22:18 , Christoph Cullmann cullm...@absint.com wrote:
 Just patch all occurences and avoid sending mails for that, I did only patch 
 the frameworks that I did try to build on the Mac.

ok, I personally don’t want to mess in all the projects the CI system is going 
to
fail on in the next few days, which is why I think sending an email listing all
the projects currently failing is perhaps the better idea, no?

Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

INSTALL_TARGETS_DEFAULT_ARGS (was OSX/CI: .* fails to build on branch .*)

[Marko Käning]

Hi Milian,

On 06 Jan 2015, at 21:57 , Milian Wolff m...@milianw.de wrote:
 On Tuesday 06 January 2015 21:43:03 Marko Käning wrote:
 CMake Error at src/CMakeLists.txt:178 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  konsoleprivate.
 
 Again, please stop this spamming. Group the mails, they _all_ show the same 
 error. And it's b/c INSTALL_TARGETS_DEFAULT_ARGS is empty on your machine, 
 for 
 some reason. Go figure out why before sending every compile error you 
 encounter to all lists please.

I am sorry, it wasn’t my intention to send spam to any list!

As I had run my local OSX/CI system before Christmas w/o any of these messages 
for
more than half a year. This is why I hadn’t expected a change in its 
functionality
and simply reported my findings promptly to the appropriate lists (with one 
exception
pointed out by Albert).

I have here tons of frameworks and projects which do NOT show this peculiarity, 
although
they had to be rebuilt as well.

OK, I’ll stop reporting for now and check whether there was some major 
change to 
build-kde-org’s production branch over Christmas, which I might have 
missed to merge.

Sorry again!

A Happy New Year to you,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: kde-baseapps fails to build on branch frameworks

[Marko Käning]

CMake Error at keditbookmarks/kbookmarkmodel/CMakeLists.txt:23 (install):
  install TARGETS given unknown argument BUNDLE.


CMake Error at keditbookmarks/CMakeLists.txt:48 (install):
  install TARGETS given unknown argument BUNDLE”.


CMake Error at keditbookmarks/CMakeLists.txt:82 (install):
  install TARGETS given unknown argument BUNDLE.


CMake Error at keditbookmarks/CMakeLists.txt:83 (install):
  install TARGETS given unknown argument BUNDLE.




___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Some more projects in need of respecting KF5_INSTALL_TARGETS_DEFAULT_ARGS

[Marko Käning]

Hi Christoph,

I’ve found that these projects do not make use of 
KF5_INSTALL_TARGETS_DEFAULT_ARGS
at the moment:

 - systemsettings
 - muon
 - rocs
 - libkdegames
 - kiten
 - cantor
 - kolourpaint
 - libkmahjongg

See for details below in order of appearance.

I figure this is only the beginning of it and more projects might turn up in 
the future.

Thanks for taking care of these.

Regards,
Marko




P.S.: I’ve tested locally to prepend KF5_” to INSTALL_TARGETS_DEFAULT_ARGS
  for project systemsettings only, which worked fine and made the project
  install successfully again here on my OSX/CI system.




P.P.S.: I realised by now that there are no changes on the production branch,
which probably means that there was some change in ECM or wherever
provoking these issues...




---

systemsettings:

CMake Error at core/CMakeLists.txt:37 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  systemsettingsview”.
---

muon:

CMake Error at libmuon/notifiers/CMakeLists.txt:7 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  MuonNotifiers.

CMake Error at libmuon/CMakeLists.txt:63 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  muonprivate”.
---

rocs:

CMake Error at libgraphtheory/CMakeLists.txt:106 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  rocsgraphtheory”.
---

libkdegames:

CMake Error at CMakeLists.txt:163 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  KF5KDEGames.

CMake Error at CMakeLists.txt:222 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  KF5KDEGamesPrivate”.
---

kiten:

CMake Error at lib/CMakeLists.txt:37 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  kiten.
---

cantor:

CMake Error at src/lib/CMakeLists.txt:75 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  cantorlibs”.

CMake Error at src/CMakeLists.txt:25 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  cantor_config.
---

kolourpaint:

CMake Error at CMakeLists.txt:579 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  kolourpaint_lgpl.
---

libkmahjongg:

CMake Error at CMakeLists.txt:64 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  KF5KMahjongglib.

CMake Error at CMakeLists.txt:67 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  KF5KMahjongglib.
---

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: kio placed files erroneously due to missing required backslash in path

[Marko Käning]

Hi,

on OSX it looks like some app places files directly in ~/Library, as it 
misses to insert a backslash in between the standard location 
~/Library/Application Support” and the 3 files (user-places.xbel*) to be 
generated in there:
---
$ ls -l1 Library/Application\ Supportuser-places.xbel*
-rw--- 1 marko staff 245 Dec 10 03:23 Library/Application 
Supportuser-places.xbel
-rw--- 1 marko staff 512 Dec 10 03:23 Library/Application 
Supportuser-places.xbel.bak
-rw--- 1 marko staff   0 Dec 10 03:23 Library/Application 
Supportuser-places.xbel.tbcache
---

Grep-ing the whole code base to figure out which app caused this shows:
---
$ find WC/KDECI-builds/ -name *.cpp -exec grep -H user-places.xbel {} \;
WC/KDECI-builds/kbookmarks/autotests/kbookmarktest.cpp:const QString 
placesFile = datadir + /user-places.xbel;
WC/KDECI-builds/kio/src/filewidgets/kfileplacesmodel.cpp:// 
~/.local/share/user-places.xbel (according to freedesktop bookmarks spec), and
WC/KDECI-builds/kio/src/filewidgets/kfileplacesmodel.cpp:// 
user-places.xbel will be filled later). (ereslibre)
WC/KDECI-builds/kio/src/filewidgets/kfileplacessharedbookmarks.cpp:const 
QString file = datadir + user-places.xbel;
—--
where the last line reveals the culprit as being kio!

Fixed in 
http://commits.kde.org/kio/c5522b6931908d3fd8ad97555a3edf2a3e859b50

Ooops, should I have pushed this through Gerrit before committing?

Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kde-baseapps fails to build on branch frameworks

[Marko Käning]

Hi Kevin,

 Note: That needs Qt 5.4 -- QSignalSpy can take a PMF only since that.

I guess that test's code should then be guarded appropriately, so that it
builds also on KDE CI's still being used Qt 5.3.2, right?

Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: lokalize fails to build on branch frameworks

[Marko Käning]

Hi David,

thanks for responding.

 I'm not sure the lokalize developers read kde-frameworks-devel.

I am afraid they are not.


 I guess they were relying on FindHUNSPELL.cmake from kdelibs 4
 which is now in extra-cmake-modules/attic/modules, i.e. it's disabled.
 You or the lokalize developers should ask kde-buildsystem or look in the 
 archives there (or in the wiki) for the procedure for reviving a cmake module.

OK, I will keep this on my TODO list for poking its devs.  - e.g. Jeremy?! ;-)

Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: kde-baseapps fails to build on branch frameworks

[Marko Käning]

/Users/marko/WC/KDECI-builds/kde-baseapps/dolphin/src/tests/kfileitemlistviewtest.cpp:91:16:
 error: no matching constructor for initialization of 'QSignalSpy'
QSignalSpy itemsRemovedSpy(m_model, KFileItemModel::itemsRemoved);
   ^   ~~
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtTest/qsignalspy.h:61:14:
 note: candidate constructor not viable: no known conversion from 'void 
(KItemModelBase::*)(const KItemRangeList )' to 'const char *' for 2nd argument
explicit QSignalSpy(const QObject *obj, const char *aSignal)
 ^
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtTest/qsignalspy.h:58:7:
 note: candidate constructor (the implicit copy constructor) not viable: 
requires 1 argument, but 2 were provided
class QSignalSpy: public QObject, public QListQListQVariant 
  ^
Building CXX object 
dolphin/src/CMakeFiles/kcm_dolphinviewmodes.dir/settings/viewmodes/viewsettingstab.cpp.o
2 errors generated.
[ 50%] make[2]: *** 
[dolphin/src/tests/CMakeFiles/kfileitemlistviewtest.dir/kfileitemlistviewtest.cpp.o]
 Error 1
make[1]: *** [dolphin/src/tests/CMakeFiles/kfileitemlistviewtest.dir/all] Error 
2


kde-baseapps.log.gz
Description: GNU Zip compressed data
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kmime fails to build on branch master

[Marko Käning]

Hi Aleix,

On 15 Dec 2014, at 03:01 , Aleix Pol aleix...@kde.org wrote:
 Thanks for looking into this! :)

I won’t look any deeper for now, as it is an issue with the build system itself.

I hope this can be clarified once an official OSX build slave is up and running.

Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: QSP patch ( was KF5 Update Meeting Minutes 2014-w28 )

[Marko Käning]

Hi David,

back to our discussion during this summer:

On 10 Jul 2014, at 11:57 , David Faure fa...@kde.org wrote:
 Wrong approach. XDG is a freedesktop thing which doesn't apply to Mac.
 
 This should be fixed the other way around:
 1) finding out how Mac OS lets people configure the location for their files,
 or if this isn't configurable, coming up with QT_* environment variables.
 2) patching QStandardPaths to use these
 3) setting these vars in the CT scripts


Since a fortnight we’re discussing the QStandardPaths patch needed for the 
OSX/CI
system [0] on KDE-MAC [1,2] and it would be good if you’d join this discussion 
now,
as Ben also wants to come up with a patch for Windows very soon.
(Ian actually had already included you in his last post [3] to thread [1].)

Can we have this discussion on KDE-MAC (or on both lists), as Ian and René 
aren’t
subscribed to K-F-D?!

Regards,
Marko




[0] 
http://quickgit.kde.org/?p=clones%2Fwebsites%2Fbuild-kde-org%2Fkaning%2Fmp-osx-ci.gita=blobh=27deb1cb8f8f70ea949fc241e049d9b47a10f6dfhb=8126ab8cb976f42a4ebe5d3b7d2cb7a3d42217d1f=patches%2Fqt5%2Fkf5-qt5%2Fpatch-qstandardpaths_mac.cpp.diff

[1] http://mail.kde.org/pipermail/kde-mac/2014-December/002590.html

[2] http://mail.kde.org/pipermail/kde-mac/2014-December/002705.html

[3] http://mail.kde.org/pipermail/kde-mac/2014-December/002737.html
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kio fails to build on branch master

[Marko Käning]

kio is still failing on OSX.

Any idea what’g going on with this XML file?



On 10 Dec 2014, at 21:02 , Marko Käning mk-li...@email.de wrote:

 [ 23%] Built target udsentrybenchmark_automoc
 Scanning dependencies of target ktelnetservice5
 Scanning dependencies of target lockingtest
 Cannot process input: 
 '/Users/marko/WC/KDECI-builds/kio/build/src/ioslaves/http/kcookiejar/org.kde.KCookieServer.xml'.
  Stop.
 make[2]: *** [src/ioslaves/http/kcookiejar/kcookieserverinterface.cpp] Error 1
 make[1]: *** [src/ioslaves/http/kcookiejar/CMakeFiles/kcookiejar5.dir/all] 
 Error 2
 make[1]: *** Waiting for unfinished jobs
 kio.log.gz___
 Kde-frameworks-devel mailing list
 Kde-frameworks-devel@kde.org
 https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: libkpeople fails to build on branch master

[Marko Käning]

Hi Aleix,

I tried to build all the PIM projects - which you brought recently to CI - on 
my OSX/CI system.
As a consequence I have pushed two additions to dependency-data-kf5-qt5 in [1] 
and have also
spotted a problem with libkpeople.

Is its porting to KF5 not yet finished?

Greets,
Marko


[1] 
http://commits.kde.org/kde-build-metadata/6baa179ab3ee40131d4604175e09924404649ad5


---

-- Detecting CXX compiler ABI info - done
CMake Error at 
/opt/kde/install/darwin/mavericks/clang/shared/general/cmake/share/cmake-3.1/Modules/FindKDE4.cmake:71
 (message):
  ERROR: Could not find KDE4 kde4-config
Call Stack (most recent call first):
  CMakeLists.txt:21 (find_package)


CMake Warning (dev) in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

cmake_minimum_required(VERSION 3.1)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run cmake --help-policy CMP.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!
See also 
/Users/marko/WC/KDECI-builds/libkpeople/build/CMakeFiles/CMakeOutput.log.

KDE Continuous Integration Build
== Building Project: libkpeople - Branch master




libkpeople.log.gz
Description: GNU Zip compressed data
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kmime fails to build on branch master

[Marko Käning]

Hi Aleix,

it DOES build on Jenkins master [1] with 2 failing tests.

So, this is clearly only an issue of how boost is installed and located
by the build system on OSX/MacPorts.

Greets,
Marko



[1] http://build.kde.org/view/FAILED/job/kmime_master_qt5/1/
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kio fails to build on branch master

[Marko Käning]

Hi Jan,

On 13 Dec 2014, at 14:11 , Jan Kundrát j...@kde.org wrote:

 On Saturday, 13 December 2014 13:55:25 CEST, Marko Käning wrote:
 Any idea what’g going on with this XML file?
 
 One option is to run make with VERBOSE=1 (either asn an env var, or as an 
 argument to make). That way, the output will contain information on what 
 commands are executed, and you should be able to run that single failing 
 command by hand and/or with extra options to see where the problem is.

thanks, Jan, for the hint. I’ve found a way how to get this done on the CI 
system,
but when I rebuilt the project I realised that it wasn’t failing anymore… :-/

Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: qt5's QSslSocket can't resolve transfer methods

[Marko Käning]

Turns out that this COULD BE due to the fact that qtdiag grabs the system’s 
openssl executable
in /usr/bin instead of the one installed via MacPorts in /opt/local/bin...
---
MVM2:scripts marko$ /usr/bin/openssl
OpenSSL version
OpenSSL 0.9.8za 5 Jun 2014
---

Since the system’s openssl version is below 1.0 the methods can’t be resolved!



Wondering how I could make qtdiag find the one installed in /opt/local/bin, as 
this
---
$ PATH=/opt/local/bin 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/bin/qtdiag 
$ echo $PATH
/Users/marko/bin:/opt/local/bin:/opt/local/sbin:/opt/local/libexec/gnubin:/opt/local/lib/mysql55/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
---
is NOT doing the job, as the PATH env var already has /opt/local/bin first.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: qt5's QSslSocket can't resolve transfer methods

[Marko Käning]

Hi Ben,

On 13 Dec 2014, at 21:39 , Ben Cooksley bcooks...@kde.org wrote:
 This is where DYLD_LIBRARY_PATH comes in - and it is a variable the CI
 scripts should already be setting for you.

yes, of course!

:)

Thanks for the reminder!
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: qt5's QSslSocket can't resolve transfer methods

[Marko Käning]

Hi,

on my OSX/CI system I realised that qtdiag reports that it cannot resolve
certain transfer methods and wonder which system path hasn’t been set
correctly here (see below).

This e.g. doesn’t allow me to run Trojita on the console [1], but its tests
at build time run flawlessly!

Any ideas?

Greets,
Marko

[1] http://mail.kde.org/pipermail/kde-mac/2014-December/002634.html



---

(This is WITHOUT setting the CI system’s XDG env vars!)


$ /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/bin/qtdiag 
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
'/var/folders/xd/_025xt7j6dggsjd0_6tczq18gn/T/runtime-marko'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
'/var/folders/xd/_025xt7j6dggsjd0_6tczq18gn/T/runtime-marko'
QSslSocket: cannot resolve TLSv1_1_client_method
QSslSocket: cannot resolve TLSv1_2_client_method
QSslSocket: cannot resolve TLSv1_1_server_method
QSslSocket: cannot resolve TLSv1_2_server_method
QSslSocket: cannot resolve SSL_select_next_proto
QSslSocket: cannot resolve SSL_CTX_set_next_proto_select_cb
QSslSocket: cannot resolve SSL_get0_next_proto_negotiated
Qt 5.3.1 (Dec 10 2014, Clang 6.0 (clang-600.0.56) (Apple), 64 bit, debug build) 
on cocoa little endian/
Mac OS version: 0xb

Library info:
  PrefixPath: /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst
  DocumentationPath: 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/doc
  HeadersPath: /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include
  LibrariesPath: /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/lib
  LibraryExecutablesPath: 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/libexec
  BinariesPath: /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/bin
  PluginsPath: /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/plugins
  ImportsPath: /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/imports
  Qml2ImportsPath: /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/qml
  ArchDataPath: /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst
  DataPath: /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst
  TranslationsPath: 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/translations
  ExamplesPath: 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/examples
  TestsPath: /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/tests

Standard paths [*...* denote writable entry]:
  DesktopLocation: Desktop */Users/marko/Desktop*
  DocumentsLocation: Documents */Users/marko/Documents*
  FontsLocation: Fonts **
  ApplicationsLocation: Applications ** /Library/Application 
Support/applications
  MusicLocation: Music */Users/marko/Music*
  MoviesLocation: Movies */Users/marko/Videos*
  PicturesLocation: Pictures */Users/marko/Pictures*
  TempLocation: TemporaryItems 
*/var/folders/xd/_025xt7j6dggsjd0_6tczq18gn/T*
  HomeLocation: Home */Users/marko*
  DataLocation: Application Support */Users/marko/Library/Application 
Support/Qt Project/qtdiag* /Library/Application Support/Qt Project/qtdiag 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/bin/
  CacheLocation: Caches */Users/marko/Library/Caches/Qt Project/qtdiag* 
/Library/Caches/Qt Project/qtdiag
  GenericDataLocation: Application Support */Users/marko/Library/Application 
Support* /Library/Application Support
  RuntimeLocation: Application Support 
*/var/folders/xd/_025xt7j6dggsjd0_6tczq18gn/T/runtime-marko*
  ConfigLocation: Preferences */Users/marko/Library/Preferences* 
/Library/Preferences
  DownloadLocation: Documents */Users/marko/Downloads*
  GenericCacheLocation: Caches */Users/marko/Library/Caches* /Library/Caches
  GenericConfigLocation: Preferences */Users/marko/Library/Preferences* 
/Library/Preferences


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: breeze fails on branch master

[Marko Käning]

Breeze suddenly fails to build here, as it now depends on X11, although the 
OSX/CI system globally sets 

-DCMAKE_DISABLE_FIND_PACKAGE_X11=ON

It fails due to xcb:

---

/Users/marko/WC/KDECI-builds/breeze/windec/kdecoration2/config/breezedetectwidget.h:43:10:
 fatal error: 'xcb/xcb.h' file not found
#include xcb/xcb.h
 ^
1 error generated.
make[2]: *** 
[windec/kdecoration2/CMakeFiles/breezedecoration.dir/config/breezedetectwidget.cpp.o]
 Error 1
make[2]: *** Waiting for unfinished jobs
In file included from 
/Users/marko/WC/KDECI-builds/breeze/windec/kdecoration2/config/breezeexceptiondialog.cpp:28:
/Users/marko/WC/KDECI-builds/breeze/windec/kdecoration2/config/breezedetectwidget.h:43:10:
 fatal error: 'xcb/xcb.h' file not found
#include xcb/xcb.h
 ^
1 error generated.
make[2]: *** 
[windec/kdecoration2/CMakeFiles/breezedecoration.dir/config/breezeexceptiondialog.cpp.o]
 Error 1

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: breeze fails on branch master

[Marko Käning]

Hi Martin,

On 12 Dec 2014, at 08:02 , Martin Gräßlin mgraess...@kde.org wrote:
 X11 and xcb are not the same.

oh, I see. :)


On 12 Dec 2014, at 08:12 , Martin Gräßlin mgraess...@kde.org wrote:
 I hope this fixes it: 
 http://commits.kde.org/breeze/d35fb88cd9d9a678a170f01d9643c8956c38aee5

Yep, that did it.

Thanks for taking care of this.

Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: kio fails to build on branch master

[Marko Käning]

[ 23%] Built target udsentrybenchmark_automoc
Scanning dependencies of target ktelnetservice5
Scanning dependencies of target lockingtest
Cannot process input: 
'/Users/marko/WC/KDECI-builds/kio/build/src/ioslaves/http/kcookiejar/org.kde.KCookieServer.xml'.
 Stop.
make[2]: *** [src/ioslaves/http/kcookiejar/kcookieserverinterface.cpp] Error 1
make[1]: *** [src/ioslaves/http/kcookiejar/CMakeFiles/kcookiejar5.dir/all] 
Error 2
make[1]: *** Waiting for unfinished jobs


kio.log.gz
Description: GNU Zip compressed data
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: Anyone interested in test results of all KF5 frameworks and many KF5 apps?

[Marko Käning]

Hi,

I am soon about to finalise the first complete rebuild of KF5 on my OSX/CI 
system

NOW INCLUDING ALL EXISTING TESTS !

Anyone interested in all those test results for FWs  apps with test failures?

Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: GenericConfigLocation missing in qtpaths tool

[Marko Käning]

Hi David  Ben,

On 06 Dec 2014, at 21:13 , David Faure fa...@kde.org wrote:
 Fixed 5 months ago:
 
 commit 3b102b026b6fdd8dfbc284741d8df7c1d6dcc9d3
 Author: David Faure david.fa...@kdab.com
 Date:   Sun Jul 6 15:30:58 2014 +0200
 
qtpaths: add missing GenericConfigLocation, exists since Qt 5.2.0  
   
  
 
Change-Id: I4d4ef2e0f33896984f436df6c9a033dd8985   
   
  
Reviewed-by: Sune Vuorela s...@vuorela.dk
   
  
Reviewed-by: Thiago Macieira thiago.macie...@intel.com
 
 $ git tag --contains 3b102b026b6fdd8dfbc284741d8df7c1d6dcc9d3
 v5.3.2
 v5.4.0-alpha1
 v5.4.0-beta1
 v5.4.0-rc1

oh, I thought that I am running a rather recent Qt5 installation on the OSX/CI 
system.
I built at the end of November, but I see now that it is 5.3.1:
---
$ gtdiag
Qt 5.3.1 (Nov 21 2014, Clang 6.0 (clang-600.0.54) (Apple), 64 bit, debug build) 
on cocoa little endian/

$ /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/bin/qtpaths --version
qtpaths 1.0
---

That explains it.

Greets,
Marko


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: phonon fails to INSTALL on branch master

[Marko Käning]

On 27 Nov 2014, at 08:59 , Marko Käning mk-li...@email.de wrote:

 Phonon built fine, but failed to install for some reason, as a file must be 
 missing:
 
 ---
 
 -- Installing: 
 /Users/marko/WC/KDECI-builds/phonon/local-inst/opt/kde/install/darwin/mavericks/clang/kf5-qt5/kdesupport/phonon/phonon/inst/include/phonon4qt5/phonon/VolumeSlider
 CMake Error at includes/cmake_install.cmake:88 (file):
  file INSTALL cannot find
  
 /Users/marko/WC/KDECI-builds/phonon/includes/old/Phonon/AbstractAudioOutput.
 Call Stack (most recent call first):
  cmake_install.cmake:69 (include)
 
 
 make: *** [install] Error 1
 
 KDE Continuous Integration Build

Just for the record, I saw this error once again!!!

Building phonon a 2nd time it was successful though.

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: One kde-baseapps test fails

[Marko Käning]

This is one of my first test results on OSX:

FAIL!  : KonqPopupMenuTest::testSubDirectory() Received a fatal error.

Full test results are attached.



kde-baseapps-test-results.tar.bz2
Description: BZip2 compressed data
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: All Kate tests failing

[Marko Käning]

All of Kate’s tests are failing on OSX/CI with this message:

Unable to find executable: session_test

Since other projects are able to run tests successfully, I gather
that this is a kate-specific issue. 

Test results attached.



kate-test-results.tar.bz2
Description: BZip2 compressed data
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: KFileMetaData fails to build on branch master

[Marko Käning]

Building CXX object 
src/CMakeFiles/KF5FileMetaData.dir/simpleextractionresult.cpp.o
Generating moc_office2007extractortest.cpp
Generating moc_office2007extractor.cpp
[ 41%] [ 41%] Built target officeextractortest_automoc
Building CXX object src/CMakeFiles/KF5FileMetaData.dir/typeinfo.cpp.o
[ 43%] Building CXX object src/CMakeFiles/KF5FileMetaData.dir/usermetadata.cpp.o
/Users/marko/WC/KDECI-builds/kfilemetadata/src/usermetadata.cpp:140:13: error: 
use of undeclared identifier 'errno'
return (errno != ENODATA);
^
/Users/marko/WC/KDECI-builds/kfilemetadata/src/usermetadata.cpp:140:22: error: 
use of undeclared identifier 'ENODATA'
return (errno != ENODATA);
 ^
/Users/marko/WC/KDECI-builds/kfilemetadata/src/usermetadata.cpp:156:13: error: 
use of undeclared identifier 'errno'
return (errno == ENOTSUP);
^
/Users/marko/WC/KDECI-builds/kfilemetadata/src/usermetadata.cpp:156:22: error: 
use of undeclared identifier 'ENOTSUP'
return (errno == ENOTSUP);
 ^
4 errors generated.
make[2]: *** [src/CMakeFiles/KF5FileMetaData.dir/usermetadata.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [src/CMakeFiles/KF5FileMetaData.dir/all] Error 2
make: *** [all] Error 2

KDE Continuous Integration Build
== Building Project: kfilemetadata - Branch master

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: KFileMetaData fails to build on branch master

[Marko Käning]

Hi David,

On 06 Dec 2014, at 14:53 , David Faure fa...@kde.org wrote:

 On Saturday 06 December 2014 13:08:19 Marko Käning wrote:
 /Users/marko/WC/KDECI-builds/kfilemetadata/src/usermetadata.cpp:140:13:
 error: use of undeclared identifier 'errno' return (errno != ENODATA);
^
 
 Fixed.

thanks for taking care of this one.


BUT, now I am back to the old taglib issue reported in September to 
KFileMetaData’s
developers… :-(

Will create a new post.

Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

OSX/CI: kfilemetadata fails to build on branch master

[Marko Käning]

The inclusion of MacPorts’ taglib fails on OSX.

See the below discussions about this problem from September.



kfilemetadata.log.gz
Description: GNU Zip compressed data


Begin forwarded message:

 From: Marko Käning mk-li...@email.de
 Subject: taglib inclusion on OSX
 Date: 13 Sep 2014 22:54:07 GMT+2
 To: j...@jriddell.org, handa.v...@gmail.com
 Cc: bhus...@gmail.com
 
 Hi Jonathan  Vishesh,
 
 Ben suggested to send our below conversation to you guys, as I am seeing 
 problems
 with including taglib on OSX for plasma-mediacenter, but also for the project
 KFileMetaData maintained by you two.
 
 Greets,
 Marko 
 
 P.S.: Separately I have already contacted PMC’s Bhushan Shah, who asked me to
  test building PMC while at Akademy, which I could do after some patching.
  We need a solution which does not require patching taglib’s sources.
 
 
 From: Ben Cooksley bcooks...@kde.org
 Subject: Re: Plasma Media Center - Build Success on OSX
 Date: 13 Sep 2014 22:09:33 GMT+2
 To: Marko Käning mk-li...@email.de
 
 On Sun, Sep 14, 2014 at 6:06 AM, Marko Käning mk-li...@email.de wrote:
 Hi Ben,
 
 Hi Marko,
 
 
 I am forwarding what I wrote to Bhushan earlier today.
 
 I wonder whether you might have a hint as to what is going on here.
 On MacPorts exists the an non-patched taglib version 1.9.1.
 
 Although I patched it regarding the pc files locally I didn’t succeed
 building plasma-mediacenter without patching is as well.
 
 This problem occurs just as well for kfilemetadata, where I also had
 to add /opt/local/include to the include directories.
 
 It seems as if TAGLIB_INCLUDES is not generated from any of taglib's
 pc files, right?
 
 TAGLIB_INCLUDES will probably be set by a FindTaglib.cmake or
 TaglibConfig.cmake file - either of which could potentially use the
 pkgconfig *.pc files provided by Taglib.
 
 This issue is a fairly routine case of include statements being
 inconsistent with where things are being installed. It only works for
 him and others because Taglib is usually installed in /usr on Linux
 (and if it isn't there, it probably co-exists with kdelibs/frameworks
 which add the $prefix/include directory to the include_directories).
 
 The proper way to fix this is to either:
 1) Adjust the PMC code to include the taglib headers without the taglib/ 
 prefix.
 2) Adjust the CMake code which locates taglib to add the
 $prefix/include directory in addition to the $prefix/include/taglib
 directory.
 
 
 Greets,
 Marko
 
 Thanks,
 Ben
 
 
 
 From: Marko Käning mk-li...@email.de
 Subject: Fwd: Plasma Media Center - Build Success on OSX
 Date: 13 Sep 2014 20:06:34 GMT+2
 To: Ben Cooksley bcooks...@kde.org
 
 Hi Ben,
 
 I am forwarding what I wrote to Bhushan earlier today.
 
 I wonder whether you might have a hint as to what is going on here.
 On MacPorts exists the an non-patched taglib version 1.9.1.
 
 Although I patched it regarding the pc files locally I didn’t succeed
 building plasma-mediacenter without patching is as well. 
 
 This problem occurs just as well for kfilemetadata, where I also had
 to add /opt/local/include to the include directories.
 
 It seems as if TAGLIB_INCLUDES is not generated from any of taglib's
 pc files, right?
 
 Greets,
 Marko
 
 
 
 Begin forwarded message:
 
 From: Marko Käning mk-li...@email.de
 Subject: Plasma Media Center - Build Success on OSX
 Date: 13 Sep 2014 15:21:57 GMT+2
 To: bhus...@gmail.com
 
 Hi Bhushan,
 
 just for your information, once I appended my local prefix here:
 ---
 message(STATUS TAGLIB_INCLUDES = ${TAGLIB_INCLUDES})
 
 include_directories(
  ${TAGLIB_INCLUDES}
  /opt/local/include
 )
 ---
 I was able to ***successfully*** build PMC on OSX. :-)
 For that to work I had to disable the deps to baloo and mockcpp,
 of course. :)
 
 Well, checking the contents of TAGLIB_INCLUDES - as shown above - I
 got this:
 ---
 TAGLIB_INCLUDES = ;/opt/local/include/taglib
 ---
 But your code prepends another taglib subfolder to every file
 included.
 
 This is indeed very weird and I don’t know why this is happening,
 as the pc files of my current taglib installation do NOT have that
 path appended, but taglib-config tells me otherwise
 ---
 $ taglib-config --cflags
 -I/opt/local/include/taglib
 
 $ grep Cflags /opt/local/lib/pkgconfig/taglib.pc
 Cflags: -I/opt/local/include
 ---
 
 What are you seeing on your Linux system here?
 
 (Actually I have manipulated those Cflags settings myself locally,
 as version 1.9.1 actually has “taglib” appended. See below!
 Looks like those changes in the pc files aren’t enough to make this
 work. I haven’t dived into the taglib-config code now, I must say.)
 
 I am puzzled and wonder what’s going on here… Has taglib messed up
 or is there some CMake problem in KDE’s build system here?
 
 Greets,
 Marko
 
 
 P.S.: BTW, I've run into the same problem with kfilemetadata - now that
I had to install taglib on my OSX/CI system. :-/
That’s why I am interested in finding a solution for this little,
but disturbing

GenericConfigLocation missing in qtpaths tool

[Marko Käning]

Hi folks,

there is a ConfigLocation path type:
---
$ /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/bin/qtpaths --paths 
ConfigLocation
/Users/marko/Library/Preferences
$ /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/bin/qtpaths --paths 
GenericConfigLocation
Unknown location: GenericConfigLocation
---
but for the path type GenericConfigLocation the result is _unknown_.

As I stumbled over this again I wanted to ask whether it is just a peculiarity 
of the qtpaths tool?

Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: phonon fails to INSTALL on branch master

[Marko Käning]

Hi Ben,

On 27 Nov 2014, at 10:40 , Harald Sitter sit...@kde.org wrote:

 On Thu, Nov 27, 2014 at 8:59 AM, Marko Käning mk-li...@email.de wrote:
 Phonon built fine, but failed to install for some reason, as a file must be 
 missing:
 
 I think that needs some more investigation. I can not reproduce this
 nor can I even think of how that would happen :/

as Harald could not reproduce this on Linux I wondered what I could do to 
diagnose this
issue further. Well - since I had no other ideas - I just tried installing once 
again and
see:
IT INSTALLED FINE AFTER ALL !!!

(The current log is attached.)

What could have been going on there? Perhaps some destination issue? Any hints 
for me?

Greets,
Marko



phonon.log.gz
Description: GNU Zip compressed data
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KDE-CI IRC meeting - Your possible KDE contributions in non-C++

[Marko Käning]

Hi Mario,

thanks for organizing this!

 Prospective agenda for the IRC meeting:
 - Ben: Short introduction to KDE CI
 - Everybody: Short introduction incl. their skills and wishes for KDE CI
 - Ben: What needs to be changed
 - Everybody: Work on a roadmap and distribute work till next meeting
 - Everybody: Determine date for the next IRC meeting

I could give a short presentation about my OSX/CI system and describe where
I'd need support. Hey, we should go through our list of topics for the IRC
meetings, which we created months ago! :-)

Greets,
Marko

P.S.: I already see that Jeremy has a shifted time-slot wrt me. I'll have
  to check whether I can make it 3pm my time some day. The bigger problem
  will be to synchronize with Ben...
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 120969: Fix build on OSX due to missing XDR functions.

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120969/#review70715
---

Ship it!


Ship It!

- Marko Käning


On Nov. 4, 2014, 4:58 p.m., Mathias Tillman wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120969/
 ---
 
 (Updated Nov. 4, 2014, 4:58 p.m.)
 
 
 Review request for KDE Frameworks and David Faure.
 
 
 Repository: kio-extras
 
 
 Description
 ---
 
 Due to some missing XDR functions on OSX (used to decode unsigned long long), 
 it failed to compile. This fixes that by doing some checks for the existence 
 of the 64-bit datatype functions (for some reason XDR have 5 different 
 functions that do the same thing).
 This patch also merges the mount3 rpc code with the nfs3 code as well as 
 remove the unused rpc mount2 code. 
 
 
 Diffs
 -
 
   nfs/rpc_mnt3.h cba4ff656a3d524f39cb7f607b8b4b331b41a0c5 
   nfs/rpc_mnt2_xdr.c b380f4f93853ba54112a68ddf851f8f04b251312 
   nfs/rpc_mnt2.x 4aaf97de9ade2655cd48ae460ba24ee322b57183 
   nfs/nfsv3.cpp 368a61febc778688507ffb3954caaf69fc18d371 
   nfs/rpc_nfs2_prot.x cd21123c7b57040d97245f22038153945abe88ee 
   nfs/rpc_nfs2_prot.h 62ab3056a51cc0e89536081c9d5741ff136dc804 
   nfs/rpc_nfs3_prot_xdr.c 57f4a8546ae697f41f98efb24c01b6de739d380f 
   nfs/rpc_nfs3_prot.x fba417c8cd6edb955e018a89dd38942f1e788c69 
   nfs/rpc_nfs3_prot.h 76b2f5becef9cbdc9fd3db08c540c065a43a89a6 
   nfs/rpc_nfs2_prot_xdr.c fb63b8ec2329730ef55c8f068e8abf47e865173b 
   nfs/rpc_mnt3_xdr.c 2016e688770e3753affe20923a8515f2427c5447 
   nfs/rpc_mnt2.h ed21256c4754ce861ff1f5ea5ddc4ca224a7da7e 
   nfs/kio_nfs.h 9943daf670e665121ea51419ea77599ec4d8d4f5 
   nfs/CMakeLists.txt 2ed2186e113dad9e9c178cbac680d7c96dff789a 
 
 Diff: https://git.reviewboard.kde.org/r/120969/diff/
 
 
 Testing
 ---
 
 I haven't personally tried to compile it on OSX, but Marko Käning (the one 
 who reported it, 
 https://www.mail-archive.com/kde-frameworks-devel@kde.org/msg19770.html) 
 confirmed that it's now compiling fine on OSX. 
 
 
 Thanks,
 
 Mathias Tillman
 


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel