2014-06-27 20:59 GMT-03:00 David Faure :
> On Friday 27 June 2014 23:01:33 Marko Käning wrote:
>> I guess I’ve spotted that one of the frameworks obviously messes up when
>> writing to the standard location below “Library/Application Support/“
>> because it omits the trailing slash leading to this
Hi David,
On 28 Jun 2014, at 01:59 , David Faure wrote:
> That was one of the kbookmarks autotest. Fixed, thanks for the report.
oh, I am glad you spotted that so quickly.
Thanks for fixing it right away.
Greets,
Marko
___
Kde-frameworks-devel mailin
On Friday 27 June 2014 23:01:33 Marko Käning wrote:
> I guess I’ve spotted that one of the frameworks obviously messes up when
> writing to the standard location below “Library/Application Support/“
> because it omits the trailing slash leading to this mess-up:
> ---
Hi Ben,Hi Olivier,Hi KF5 devs,Hi folks on KDE-MAC,I finally came up with a patch for QStandardPaths:--MVM2:scripts marko$ ls -l patches/qt5/kf5-qt5/patch-qstandardpaths_mac.cp
Hi David,
I am afraid I am not able to debug this, as I am not a KDE dev by any means. ;)
So, well, I guess I should submit a bug report at b.k.o. for these two KF5
frameworks...
Greets,
Marko
On 23 Jun 2014, at 10:05 , David Faure wrote:
> On Wednesday 04 June 2014 10:31:28 Marko Käning w
On Wednesday 04 June 2014 10:31:28 Marko Käning wrote:
> Turns out thought that these aren’t all yet, since two frameworks (khtml &
> ktexteditor) actually place their stuff outside of the actually configured
> kf5 subdirectory: ---
> which is probably unintended! Can this be considered a glitch of
It turns out that there are indeed a few more KF5 framework trying to install
their files in “/Library/Application Support”, here’s the full list of kf5
folders
found in the install environment:
---
./frameworkintegration/local-inst/opt/kde/install/darwin/mavericks/clang/kf5-qt5/frameworks/framewo
Hi folks,
there is eventually unexpected SUCCESS ...
(... although I didn’t manage to patch Qt's sources to handle a non-standard
path ...)
... since as a work-around I have simply copied the file tree installed by
kdoctools into the KDE/CI system’s “/Library/Application Support/” folder:
-
On 3 June 2014 09:08, Marko Käning wrote:
> Hi Ben,
>
> On 01 Jun 2014, at 23:05 , Ben Cooksley wrote:
>> That is caused by the patch. It assumes you have kdoctools installed
>> within the sources of kconfigwidgets. This won't work.
> I see.
>
>> The solution in this case is to ensure that Qt is
Hi Ben,
On 01 Jun 2014, at 23:05 , Ben Cooksley wrote:
> That is caused by the patch. It assumes you have kdoctools installed
> within the sources of kconfigwidgets. This won't work.
I see.
> The solution in this case is to ensure that Qt is made aware of
> locations other than the two hardcoded
On 31 May 2014 11:37, Marko Käning wrote:
> So, I have figured that kdoctools has found docbook and docbook-xsl just fine
> when installing it via MacPorts:
> ---
> -- Performing Test _OFFT_IS_64BIT - Success
> -- Found LibXslt: /opt/local/lib/libxslt.dylib (found version "1.1.28")
> -- Found LibX
So, I have figured that kdoctools has found docbook and docbook-xsl just fine
when installing it via MacPorts:
---
-- Performing Test _OFFT_IS_64BIT - Success
-- Found LibXslt: /opt/local/lib/libxslt.dylib (found version "1.1.28")
-- Found LibXml2: /opt/local/lib/libxml2.dylib (found version "2.9.
Hi,
I’ve given the first part of the patch from [1] a quick try:
On 29 May 2014, at 15:17 , Marko Käning wrote:
> as well as a patch for
>
> KF5DocToolsConfig.cmake.in
>
> but I haven’t tried anything of it yet, because I’ve got no clue as to how
> much of it is specific for a Homebrew s
Hi all,
Going to respond to everything in one email.
> to kdoctools’ search path on the KDE/CI system.
>
> Question is, how to achieve it?
> Will we indeed have to patch its sources?
Patching of the sources by the CI system is considered unacceptable
for KDE projects. Particularly as these are p
Hi Ben,
On 29 May 2014, at 09:05 , Ben Cooksley wrote:
> In terms of the value of DATA_INSTALL_DIR, I suggest you examine the
> install jail (located at $WORKSPACE/install/) to determine where the
> files are actually being placed and act accordingly.
Those files go into share/kf5 as you’ve poin
Hi Ben,
On 29 May 2014, at 09:05 , Ben Cooksley wrote:
> It is nothing to do with the installation parameters now. What needs
> to be adjusted is kdoctools - we'll need to help it find things within
> the install prefix. Is there a environment variable which we can set
> which the code in questio
On 27 May 2014, at 06:51 , Matthew Dawson wrote:
> I'd consider kconfig_compiler a developer tool, similar to Google's protocol
> buffer compiler. Where do such tools belong in the OSX world?
I’m currently using
---
$ cat ~/scripts/config/build/kconfig/darwin-mavericks.cfg
[DEFAULT]
configure
Hi Luigi,
> I'm not sure about this. KDocTools relies on QStandardPaths to find resources
> in common paths; our Windows developers hacked QStandardPaths.
>
> You can take a look in the discussion of the RR I mentioned many times:
> https://git.reviewboard.kde.org/r/115752/
yep, I know this one a
On 28 May 2014, at 13:09 , Alex Merry wrote:
> configureExtraArgs=-DCMAKE_INSTALL_BUNDLEDIR=“Applications”
I have used
---
configurePlatformArgs=-DCMAKE_INSTALL_BUNDLEDIR="Applications/KF5”
---
since I wanted to keep all KF5 apps in another directory than the usual
applications.
I neither wanted
Hi Ben,
Hi Olivier,
On 28 May 2014, at 08:48 , Ben Cooksley wrote:
> Hmm. What about "Application Support" which kdoctools appears to use?
as documented on [1] I have reconfigured the KDE/CI system along the lines of
the recent
discussion on this thread and rebuilt kconfig and kdoctools:
---
$
Ben Cooksley ha scritto:
> On Thu, May 29, 2014 at 8:08 AM, Marko Käning wrote:
>> Hi Ben,
>> Hi Olivier,
>
> Hi Marko,
>
>>
>> On 28 May 2014, at 08:48 , Ben Cooksley wrote:
>>> Hmm. What about "Application Support" which kdoctools appears to use?
>>
>> as documented on [1] I have reconfigured
On 29/05/14 08:05, Ben Cooksley wrote:
> On Thu, May 29, 2014 at 8:08 AM, Marko Käning wrote:
>> Could not locate file "kf5/kdoctools/customization" in
>> ("/Users/kdeci/Library/Application Support", "/Library/Application Support")
>> ---
>> which leaves me a little puzzled now.
>
> It is nothin
On Thu, May 29, 2014 at 8:08 AM, Marko Käning wrote:
> Hi Ben,
> Hi Olivier,
Hi Marko,
>
> On 28 May 2014, at 08:48 , Ben Cooksley wrote:
>> Hmm. What about "Application Support" which kdoctools appears to use?
>
> as documented on [1] I have reconfigured the KDE/CI system along the lines of
>
On 28/05/14 07:47, Ben Cooksley wrote:
> On Tue, May 27, 2014 at 9:55 PM, Alex Merry wrote:
>> On Monday 26 May 2014 20:37:23 mk-li...@email.de wrote:
>>> I hope that Ben can give me a hint about how to make use of proper variable
>>> substitution in that cfg file, since the following unfortunatel
On 28/05/14 07:48, Ben Cooksley wrote:
> On Tue, May 27, 2014 at 9:59 PM, Alex Merry wrote:
>> On Tuesday 27 May 2014 17:30:56 Ben Cooksley wrote:
>>> Thanks for those details. I'm not sure what the defaults should be -
>>> but I do agree that they should be usable outside the CI system.
>>> Are t
On Tue, May 27, 2014 at 9:59 PM, Alex Merry wrote:
> On Tuesday 27 May 2014 17:30:56 Ben Cooksley wrote:
>> On Mon, May 26, 2014 at 9:04 PM, Alex Merry wrote:
>> > On Monday 26 May 2014 19:41:33 Ben Cooksley wrote:
>> >> On Mon, May 26, 2014 at 7:38 PM, wrote:
>> >> > On 26 May 2014, at 09:35 ,
On Tue, May 27, 2014 at 9:55 PM, Alex Merry wrote:
> On Monday 26 May 2014 20:37:23 mk-li...@email.de wrote:
>> I hope that Ben can give me a hint about how to make use of proper variable
>> substitution in that cfg file, since the following unfortunately doesn’t
>> work:
>> ---
>> #configureExtra
On Tue, May 27, 2014 at 5:59 PM, Marko Käning wrote:
> On 27 May 2014, at 07:29 , Ben Cooksley wrote:
>> configurePlatformArgs=-DCMAKE_INSTALL_BUNDLEDIR="{installPrefix}/Applications”
>
> I ran into stg I had seen with my own trials to access the installPrefix
> variable via %(*)s:
> ---
> Trace
On Tue, May 27, 2014 at 5:53 PM, Marko Käning wrote:
> On 27 May 2014, at 07:29 , Ben Cooksley wrote:
>
>> Please try the following syntax instead.
>> Note that I recommend you override this in
>> config/build/darwin-mavericks.cfg instead to ensure all CMake projects
>> on OS X are affected by it
On Tuesday 27 May 2014 17:30:56 Ben Cooksley wrote:
> On Mon, May 26, 2014 at 9:04 PM, Alex Merry wrote:
> > On Monday 26 May 2014 19:41:33 Ben Cooksley wrote:
> >> On Mon, May 26, 2014 at 7:38 PM, wrote:
> >> > On 26 May 2014, at 09:35 , Ben Cooksley wrote:
> >> >> For reasons stated above, ap
On Monday 26 May 2014 20:37:23 mk-li...@email.de wrote:
> I hope that Ben can give me a hint about how to make use of proper variable
> substitution in that cfg file, since the following unfortunately doesn’t
> work:
> ---
> #configureExtraArgs=-DCMAKE_INSTALL_BUNDLEDIR="%(installPrefix)s/lib/libex
On May 27, 2014 07:53:03 AM Marko Käning wrote:
> On 27 May 2014, at 07:29 , Ben Cooksley wrote:
> > Please try the following syntax instead.
> > Note that I recommend you override this in
> > config/build/darwin-mavericks.cfg instead to ensure all CMake projects
> > on OS X are affected by it.
>
Hi Alex & Ben,
On 26 May 2014, at 11:04 , Alex Merry wrote:
> -DCMAKE_INSTALL_BUNDLEDIR=some/relative/path
thanks to your hint I was able to insert a temporary workaround here on my CI
system
by supplying an additional configuration file for kconfig as this:
---
$ cat ~/scripts/config/build/kco
On 27 May 2014, at 07:29 , Ben Cooksley wrote:
> configurePlatformArgs=-DCMAKE_INSTALL_BUNDLEDIR="{installPrefix}/Applications”
I ran into stg I had seen with my own trials to access the installPrefix
variable via %(*)s:
---
Traceback (most recent call last):
File "tools/perform-build.py", lin
On 27 May 2014, at 07:29 , Ben Cooksley wrote:
> Please try the following syntax instead.
> Note that I recommend you override this in
> config/build/darwin-mavericks.cfg instead to ensure all CMake projects
> on OS X are affected by it.
>
> configurePlatformArgs=-DCMAKE_INSTALL_BUNDLEDIR="{inst
On Mon, May 26, 2014 at 9:04 PM, Alex Merry wrote:
> On Monday 26 May 2014 19:41:33 Ben Cooksley wrote:
>> On Mon, May 26, 2014 at 7:38 PM, wrote:
>> > On 26 May 2014, at 09:35 , Ben Cooksley wrote:
>> >> For reasons stated above, application packages cannot reside within
>> >> /Applications.
>
On Tue, May 27, 2014 at 6:37 AM, wrote:
> Hi Alex & Ben,
Hi Marko,
>
> On 26 May 2014, at 11:04 , Alex Merry wrote:
>> -DCMAKE_INSTALL_BUNDLEDIR=some/relative/path
>
> thanks to your hint I was able to insert a temporary workaround here on my CI
> system
> by supplying an additional configura
On Monday 26 May 2014 19:41:33 Ben Cooksley wrote:
> On Mon, May 26, 2014 at 7:38 PM, wrote:
> > On 26 May 2014, at 09:35 , Ben Cooksley wrote:
> >> For reasons stated above, application packages cannot reside within
> >> /Applications.
> >> If they need to reside within a separate directory, we
Hi Allen,
On 25 May 2014, at 00:43 , Allen Winter wrote:
> I have local patches to commit yet that fixes some of the issues you mention
> below.
great!
I am looking forward to hear from you.
Peeking into Harald Fernengel’s Homebrew recipe for kauth [1] I found out that
there seems to be no need
Hi Alex,
On 24 May 2014, at 14:57 , Alex Merry wrote:
> Where *is* kconfig_compiler_kf5 installed?
thanks again for pointing that out!
I’ve found it here:
---
$ find /opt/kde -name kconfig_compiler_kf5.app
$ find /Users/marko/WC/KDECI-builds/ -name kconfig_compiler_kf5.app
/Users/marko/WC/KDECI
I see now that Harald installed in the application package below
PREFIX/lib/kde5/libexec/ [1].
Here on the CI system I already do find an executable in an equivalent folder:
---
$ ls -l
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/frameworks/kconfig/inst/lib/libexec/kf5
total 136
-rwxr-xr-x 1
Hi Ben,
On 26 May 2014, at 09:03 , Ben Cooksley wrote:
> This is because it was installed to /Applications/ within the
> installation jail (located at
> /Users/marko/WC/KDECI-builds/kconfig/local-inst in this instance).
Yep.
> I've no idea how OS X handles applications/executables - but a
> solu
Hi Luigi,
On 24 May 2014, at 17:10 , Luigi Toscano wrote:
> Maybe, but there is a reason if it was discarded; it's not the "final"
yes, because that patch doesn’t work anymore with the current file.
But it shouldn’t be hard to come up with a new patch.
Greets,
Marko
___
On 26 May 2014, at 09:35 , Ben Cooksley wrote:
> For reasons stated above, application packages cannot reside within
> /Applications.
> If they need to reside within a separate directory, we'll need to
> arrange this - however it needs to be within the installation prefix.
Well, sure, I don’t wan
On Mon, May 26, 2014 at 7:38 PM, wrote:
> On 26 May 2014, at 09:35 , Ben Cooksley wrote:
>> For reasons stated above, application packages cannot reside within
>> /Applications.
>> If they need to reside within a separate directory, we'll need to
>> arrange this - however it needs to be within t
On Mon, May 26, 2014 at 7:32 PM, wrote:
> Hi Ben,
Hi Marko,
>
> On 26 May 2014, at 09:03 , Ben Cooksley wrote:
>> This is because it was installed to /Applications/ within the
>> installation jail (located at
>> /Users/marko/WC/KDECI-builds/kconfig/local-inst in this instance).
> Yep.
>
>> I'v
On Mon, May 26, 2014 at 3:59 AM, wrote:
> Hi Alex,
>
> On 24 May 2014, at 14:57 , Alex Merry wrote:
>> Where *is* kconfig_compiler_kf5 installed?
>
> thanks again for pointing that out!
>
> I’ve found it here:
> ---
> $ find /opt/kde -name kconfig_compiler_kf5.app
> $ find /Users/marko/WC/KDECI-
On Saturday 24 May 2014 14:29:43 mk-li...@email.de wrote:
> On 24 May 2014, at 13:31 , Martin Graesslin wrote:
> > The plan is to move the daemon back into the framework, but that requires
> > some more work to not have it end as a tier3.
>
> The irritation arises on my end only because the frame
On Sunday, May 25, 2014 06:08:37 PM mk-li...@email.de wrote:
> Hi Allen,
>
> On 25 May 2014, at 00:43 , Allen Winter wrote:
> > I have local patches to commit yet that fixes some of the issues you
> > mention below.
> great!
> I am looking forward to hear from you.
>
but first I need to bu
> Where *is* kconfig_compiler_kf5 installed?
I'll check it out and report back.
> PS: please don't use pastebin in mailing list posts.
You are right, I'm sorry.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailm
On Saturday, May 24, 2014 02:09:13 AM mk-li...@email.de wrote:
> Hi,
>
> I am trying to set up a KDE Continuous Integration system on OSX/MacPorts [1]
> and thanks to Ben Cooksley I managed to get it going quite far, since Qt5 and
> all tier 1 frameworks are installing just fine! :-)
>
>
Very
In data sabato 24 maggio 2014 14:30:03, mk-li...@email.de ha scritto:
> On 24 May 2014, at 12:43 , Luigi Toscano wrote:
> > See for example: https://git.reviewboard.kde.org/r/115752/
>
> Yep, I think Harald’s patch should do the job, also on MacPorts!
> Will test it myself.
Maybe, but there is a
On 24 May 2014, at 12:43 , Luigi Toscano wrote:
> See for example: https://git.reviewboard.kde.org/r/115752/
Yep, I think Harald’s patch should do the job, also on MacPorts!
Will test it myself.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel
On 24 May 2014, at 13:31 , Martin Graesslin wrote:
> The plan is to move the daemon back into the framework, but that requires
> some
> more work to not have it end as a tier3.
The irritation arises on my end only because the framework does actually build
on OSX…
Does it mean it just wouldn’t
On Saturday 24 May 2014 02:09:13 mk-li...@email.de wrote:
> 2.2) kcompletion using
> /Applications/KDE/kconfig_compiler_kf5.app/Contents/MacOS/kconfig_compiler_
> kf5 as location is wrong [3]
The issue here is with the KConfig framework, and specifically something in
src/kconfig_compiler/CMakeLi
On Saturday 24 May 2014 12:28:52 mk-li...@email.de wrote:
> 2)
> KGlobalAccel is also marked invalid for OSX:
>
> This framework also builds and deploys, but we had quite a discussion
> lately about kglobalaccel integration on MacPorts/KDE 4.12.* in order to
> get KDE build fine on MacPorts
In data sabato 24 maggio 2014 02:09:13, mk-li...@email.de ha scritto:
> 3.3) kjsembed (kdoctools can't find its catalogs) [5]
>
>
> I could imagine that 2.2, 3.2 and 3.3 can be fixed easily.
> [...]
> [5] http://paste.kde.org/rev/pmjob21rt
I suspect this is the (still undecided) issue with the
Some additional questions:
1)
KDE’s apidoc states that kcrash and kpty are invalid for MacOSX [1]:
But I am able to build and deploy those frameworks no problem.
(Not sure about tests now, though.)
2)
KGlobalAccel is also marked invalid for OSX:
This framework also bui
Hi,
I am trying to set up a KDE Continuous Integration system on OSX/MacPorts [1]
and thanks to Ben Cooksley I managed to get it going quite far, since Qt5 and
all tier 1 frameworks are installing just fine! :-)
But I have trouble with the next tiers:
Tier 2:
2.1) kauth depends on currentl
59 matches
Mail list logo
