Re: Baloo Framework - License Exception
Well, that's interesting, I didn't expect you would reply that :-) That's assuming people will look for those details. I'm unsure they will. My suggestion is to make this fact as pro-eminent as possible. If the framework code itself was GPL, I would advocate calling the framework baloo-gpl. I think this should appease fears of the slippery slope, because if one day we want to have a real GPL framework, we can make it part of the name everywhere (not just the git repo, but really everywhere, cmake targets etc.) With baloo it's a bit more tricky, since it's only effectively GPL and we surely want to keep the possibility to make it really LGPL. Still, I'm sure we can plaster the documentation, README, header files etc. with this code is GPL!!!. You know, the same issue exists even if it's not released as part of KF5. On most distros it will be just another package whichever way we release it on our side. https://launchpad.net/~kubuntu-ci/+archive/ubuntu/unstable-daily has attica-kf5 and baloo-kf5. From there you can't really tell that it's not a framework, or that it's not LGPL... But what will people do as soon as they start using a lib and writing code that uses it? Opening the api docs. So let's make it very clear there. This is needed, whether or not baloo is released with KF5 or separately. KDE app developers, not third parties... which actually begs the question: does Baloo provide any value outside of the KDE community? if not there's no rush to put it in KF5 as sebas highlighted. The problem (and the reason I talk about shooting ourselves in the foot) is ... what do we do instead, then, to solve the KDE issue? We need to be able to use baloo in both KDE Workspace and KDE applications, which are released separately and cannot depend on each other. In fact, this is just like the portingAids subdir of the frameworks releases. It's stuff that we release as part of frameworks but that is not intended for the outside world (= outside the KDE community). Can we have a similar section for GPL frameworks? I completely agree that the goal is to hide it from the outside world, but we still need to release it so that we can use it, for our own purposes. Bottom line: since there's the possibility of a non-xapian backend making Baloo effectively LGPL and not effectively GPL, I'd be in favor of waiting for it to be reality. We need a much shorter term solution than that, for practical purposes. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121862: Move the kglobalaccel runtime into the framework
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/#review73243 --- Ship it! Looks good to me, apart from these few things. src/runtime/CMakeLists.txt https://git.reviewboard.kde.org/r/121862/#comment50941 Is this one really necessary? Casting QString to char* is EVIL. src/runtime/CMakeLists.txt https://git.reviewboard.kde.org/r/121862/#comment50942 Hmm, this can be killed, no? :) QWS no longer exists. src/runtime/CMakeLists.txt https://git.reviewboard.kde.org/r/121862/#comment50943 This should be KF5_INSTALL_TARGETS_DEFAULT_ARGS instead. - David Faure On Jan. 5, 2015, 3:22 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/ --- (Updated Jan. 5, 2015, 3:22 p.m.) Review request for KDE Frameworks, David Faure, Martin Gräßlin, and Hrvoje Senjan. Repository: kglobalaccel Description --- This is a review request for the final move, I intentionally left out all the runtime/ files to not clutter this review (it's direct move from the workspace) and posting only the buildsystem and related changes. The runtime daemon is now no longer a kdeinit executable, meaning the circular dependency should be no more. Would be pretty awesome to get this into 5.6, so Plasma 5.2 can be shipped without it's own daemon copy. Diffs - CMakeLists.txt 4077f69 metainfo.yaml d02975f src/CMakeLists.txt 03fcbb9 src/runtime/CMakeLists.txt PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121862/diff/ Testing --- kglobalaccel daemon works as expected Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121838: Fix KCoreConfigSkeleton when toggling a value with saves in between
On Jan. 4, 2015, 5:02 p.m., David Faure wrote: This undoes 4846b50aea0bc2262238963a85ab3556c22412e4 (https://git.reviewboard.kde.org/r/117010/), basically. However looking back at the discussions with Alexander Richardson, this might be only a revert of the part that went further than what *I* was asking for ;) My problem was that save called reparseConfiguration (see 7af829a341c1ff04f9499336a28b6a4dd20bdbdc). But nowadays read which doesn't call reparseConfiguration (right?), so maybe it's fine to call it from save. I'll let Alexander remind us why he removed the read call. Matthew Dawson wrote: The read call was removed to avoid changing the KCoreConfigSekleton during the save call, as it wasn't documented as doing that and may surprise some people that flushing their changes may load other unrelated changes. I would prefer to keep that, for the same reason. I do agree there is a bug that needs fixing, I'm just not sure how to fix it. As the API stands now, the check with mLoadValue only works if the KConfig used with the KCoreConfigSkeletonItem doesn't change (never mind people manually calling those functions). Otherwise, the value of mReference gets out of sync with KConfig, and breaks saving in general. It appears removing the mLoadValue variable solves the bug, and avoids changing the underlying KConfig, assuming its loaded value hasn't changed. The only benfit I see of keeping the check is avoiding the more complicated checks carried out by KConfig to verify the value is unchanged. I think the best course of action is to remove the check for now, as it create subtle issues. The way KCoreConfigSkeletonItem works may need to be changed, but that can be done later. Thoughts? Albert Astals Cid wrote: I disagree, the easiest thing is adding back the read, it's been there in kdelibs for years, it works and has been tested by the time. Users can't be suprised by it, since it's been there forever. OTOH yes, it changes the KCoreConfigSekleton because someone added the possibility of modifying it, like the removeItem and stuff, before it was all static and fine. Honestly before removing the mLoadedValue variable i think i'd prefer adding mLoadedValue = mReference; in all the ::writeConfig Matthew Dawson wrote: Regarding surprise, yes an existing user is unlikely to be surprised as they have probably been using the api and figured out its warts. I was firstly thinking more of new users coming to KConfig, who read the documentation and don't learn of the fact the value can change when saving (easily fixed with a documentation string). Secondly, I'd expect most people to expect the save call to not modify the values in any way, but that's my belief and can be changed. Due to point two, I'd prefer not to put the read call back in the save path just to fix this bug, but I'm happy to reconsider as a general aspect of the code. I'm not sold on removing either mLoadedValue, as that means KEntryMap can be modified when it isn't expected. If you think adding that extra line in all the saves paths is better then removing mLoadedValue checks, I think that is probably the best route for now. Ideally I think mLoadedValue should be tied to the KConfig used, but I don't see an easy way to do that while maintaining binary compatibility so I'm not worried about that to fix this bug. Since you're talking about expectations for users of the API, can you explain the issue in user terms for those who don't know all the implementation details? This is about what happens when modifying the KConfig object (in memory) directly (by passing the KConfigXT layer) -- or is this about modifying the file on disk (from another process)? Let's find out what would be the most logical behavior, the reasoning it has been in kdelibs for years doesn't hold given that we renamed the functions on purpose, to reflect a behavior change. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121838/#review73083 --- On Jan. 4, 2015, 4:04 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121838/ --- (Updated Jan. 4, 2015, 4:04 p.m.) Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- We need to refresh mLoadedValue after a save, otherwise the value is stale. I'm doing this by adding back the read() call in KCoreConfigSkeleton::save (which is what kdelibs did). Another option would be adding lots of mLoadedValue = mReference; in all the
Re: Baloo Framework - License Exception
El Dimarts, 6 de gener de 2015, a les 11:01:19, David Faure va escriure: The problem (and the reason I talk about shooting ourselves in the foot) is ... what do we do instead, then, to solve the KDE issue? We need to be able to use baloo in both KDE Workspace and KDE applications, which are released separately and cannot depend on each other. Why not? I'd don't think some KDE Applications optionally depending on Plasma to give higher workspace integration (and optionally depending on other workspace libs for the same). Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121838: Fix KCoreConfigSkeleton when toggling a value with saves in between
On gen. 4, 2015, 5:02 p.m., David Faure wrote: This undoes 4846b50aea0bc2262238963a85ab3556c22412e4 (https://git.reviewboard.kde.org/r/117010/), basically. However looking back at the discussions with Alexander Richardson, this might be only a revert of the part that went further than what *I* was asking for ;) My problem was that save called reparseConfiguration (see 7af829a341c1ff04f9499336a28b6a4dd20bdbdc). But nowadays read which doesn't call reparseConfiguration (right?), so maybe it's fine to call it from save. I'll let Alexander remind us why he removed the read call. Matthew Dawson wrote: The read call was removed to avoid changing the KCoreConfigSekleton during the save call, as it wasn't documented as doing that and may surprise some people that flushing their changes may load other unrelated changes. I would prefer to keep that, for the same reason. I do agree there is a bug that needs fixing, I'm just not sure how to fix it. As the API stands now, the check with mLoadValue only works if the KConfig used with the KCoreConfigSkeletonItem doesn't change (never mind people manually calling those functions). Otherwise, the value of mReference gets out of sync with KConfig, and breaks saving in general. It appears removing the mLoadValue variable solves the bug, and avoids changing the underlying KConfig, assuming its loaded value hasn't changed. The only benfit I see of keeping the check is avoiding the more complicated checks carried out by KConfig to verify the value is unchanged. I think the best course of action is to remove the check for now, as it create subtle issues. The way KCoreConfigSkeletonItem works may need to be changed, but that can be done later. Thoughts? Albert Astals Cid wrote: I disagree, the easiest thing is adding back the read, it's been there in kdelibs for years, it works and has been tested by the time. Users can't be suprised by it, since it's been there forever. OTOH yes, it changes the KCoreConfigSekleton because someone added the possibility of modifying it, like the removeItem and stuff, before it was all static and fine. Honestly before removing the mLoadedValue variable i think i'd prefer adding mLoadedValue = mReference; in all the ::writeConfig Matthew Dawson wrote: Regarding surprise, yes an existing user is unlikely to be surprised as they have probably been using the api and figured out its warts. I was firstly thinking more of new users coming to KConfig, who read the documentation and don't learn of the fact the value can change when saving (easily fixed with a documentation string). Secondly, I'd expect most people to expect the save call to not modify the values in any way, but that's my belief and can be changed. Due to point two, I'd prefer not to put the read call back in the save path just to fix this bug, but I'm happy to reconsider as a general aspect of the code. I'm not sold on removing either mLoadedValue, as that means KEntryMap can be modified when it isn't expected. If you think adding that extra line in all the saves paths is better then removing mLoadedValue checks, I think that is probably the best route for now. Ideally I think mLoadedValue should be tied to the KConfig used, but I don't see an easy way to do that while maintaining binary compatibility so I'm not worried about that to fix this bug. David Faure wrote: Since you're talking about expectations for users of the API, can you explain the issue in user terms for those who don't know all the implementation details? This is about what happens when modifying the KConfig object (in memory) directly (by passing the KConfigXT layer) -- or is this about modifying the file on disk (from another process)? Let's find out what would be the most logical behavior, the reasoning it has been in kdelibs for years doesn't hold given that we renamed the functions on purpose, to reflect a behavior change. Honestly i don't understand why issuing a read after a save would change my object, that's unexpected to me, on every other API I used that had save/read, doing a read after save got me the same, since i had just saved, so why would it be different? I this case seems Matthew says it's not the same? Why? - Albert --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121838/#review73083 --- On gen. 4, 2015, 4:04 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121838/ --- (Updated gen. 4, 2015, 4:04 p.m.) Review request for
Re: Baloo Framework - License Exception
On Tuesday 06 January 2015 12:04:02 Albert Astals Cid wrote: El Dimarts, 6 de gener de 2015, a les 11:01:19, David Faure va escriure: The problem (and the reason I talk about shooting ourselves in the foot) is ... what do we do instead, then, to solve the KDE issue? We need to be able to use baloo in both KDE Workspace and KDE applications, which are released separately and cannot depend on each other. Why not? I'd don't think some KDE Applications optionally depending on Plasma to give higher workspace integration (and optionally depending on other workspace libs for the same). I don't see why applications should be tied to the KDE workspace just to benefit from searching features. Surely searching is useful on Windows, Mac OS X, Gnome, etc. as well. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121838: Fix KCoreConfigSkeleton when toggling a value with saves in between
On Jan. 4, 2015, 5:02 p.m., David Faure wrote: This undoes 4846b50aea0bc2262238963a85ab3556c22412e4 (https://git.reviewboard.kde.org/r/117010/), basically. However looking back at the discussions with Alexander Richardson, this might be only a revert of the part that went further than what *I* was asking for ;) My problem was that save called reparseConfiguration (see 7af829a341c1ff04f9499336a28b6a4dd20bdbdc). But nowadays read which doesn't call reparseConfiguration (right?), so maybe it's fine to call it from save. I'll let Alexander remind us why he removed the read call. Matthew Dawson wrote: The read call was removed to avoid changing the KCoreConfigSekleton during the save call, as it wasn't documented as doing that and may surprise some people that flushing their changes may load other unrelated changes. I would prefer to keep that, for the same reason. I do agree there is a bug that needs fixing, I'm just not sure how to fix it. As the API stands now, the check with mLoadValue only works if the KConfig used with the KCoreConfigSkeletonItem doesn't change (never mind people manually calling those functions). Otherwise, the value of mReference gets out of sync with KConfig, and breaks saving in general. It appears removing the mLoadValue variable solves the bug, and avoids changing the underlying KConfig, assuming its loaded value hasn't changed. The only benfit I see of keeping the check is avoiding the more complicated checks carried out by KConfig to verify the value is unchanged. I think the best course of action is to remove the check for now, as it create subtle issues. The way KCoreConfigSkeletonItem works may need to be changed, but that can be done later. Thoughts? Albert Astals Cid wrote: I disagree, the easiest thing is adding back the read, it's been there in kdelibs for years, it works and has been tested by the time. Users can't be suprised by it, since it's been there forever. OTOH yes, it changes the KCoreConfigSekleton because someone added the possibility of modifying it, like the removeItem and stuff, before it was all static and fine. Honestly before removing the mLoadedValue variable i think i'd prefer adding mLoadedValue = mReference; in all the ::writeConfig Matthew Dawson wrote: Regarding surprise, yes an existing user is unlikely to be surprised as they have probably been using the api and figured out its warts. I was firstly thinking more of new users coming to KConfig, who read the documentation and don't learn of the fact the value can change when saving (easily fixed with a documentation string). Secondly, I'd expect most people to expect the save call to not modify the values in any way, but that's my belief and can be changed. Due to point two, I'd prefer not to put the read call back in the save path just to fix this bug, but I'm happy to reconsider as a general aspect of the code. I'm not sold on removing either mLoadedValue, as that means KEntryMap can be modified when it isn't expected. If you think adding that extra line in all the saves paths is better then removing mLoadedValue checks, I think that is probably the best route for now. Ideally I think mLoadedValue should be tied to the KConfig used, but I don't see an easy way to do that while maintaining binary compatibility so I'm not worried about that to fix this bug. David Faure wrote: Since you're talking about expectations for users of the API, can you explain the issue in user terms for those who don't know all the implementation details? This is about what happens when modifying the KConfig object (in memory) directly (by passing the KConfigXT layer) -- or is this about modifying the file on disk (from another process)? Let's find out what would be the most logical behavior, the reasoning it has been in kdelibs for years doesn't hold given that we renamed the functions on purpose, to reflect a behavior change. Albert Astals Cid wrote: Honestly i don't understand why issuing a read after a save would change my object, that's unexpected to me, on every other API I used that had save/read, doing a read after save got me the same, since i had just saved, so why would it be different? I this case seems Matthew says it's not the same? Why? I can't answer because you haven't explained to me what this is about, as I requested... Please answer my question, so I can answer yours :) (but I assume read will change member vars in the KConfigSkeleton, for one reason or another, surely it's not a no-op ;) ) - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121838/#review73083 --- On Jan. 4, 2015, 4:04 p.m., Albert
Re: Review Request 121862: Move the kglobalaccel runtime into the framework
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/#review73263 --- src/runtime/CMakeLists.txt https://git.reviewboard.kde.org/r/121862/#comment50950 QString(..) is fine as long as you don't remove the other one, QT_NO_CAST_FROM_ASCII. It's this one, QT_NO_CAST_TO_ASCII that looks very suspicious to me, and that you should be able to remove without any code changes (unless the code is really awful) - David Faure On Jan. 5, 2015, 3:22 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/ --- (Updated Jan. 5, 2015, 3:22 p.m.) Review request for KDE Frameworks, David Faure, Martin Gräßlin, and Hrvoje Senjan. Repository: kglobalaccel Description --- This is a review request for the final move, I intentionally left out all the runtime/ files to not clutter this review (it's direct move from the workspace) and posting only the buildsystem and related changes. The runtime daemon is now no longer a kdeinit executable, meaning the circular dependency should be no more. Would be pretty awesome to get this into 5.6, so Plasma 5.2 can be shipped without it's own daemon copy. Diffs - CMakeLists.txt 4077f69 metainfo.yaml d02975f src/CMakeLists.txt 03fcbb9 src/runtime/CMakeLists.txt PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121862/diff/ Testing --- kglobalaccel daemon works as expected Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121862: Move the kglobalaccel runtime into the framework
On Jan. 6, 2015, 2:35 p.m., Martin Klapetek wrote: What should I do with the framework version number? Right now it says 5.6 but given this won't be in 5.6, should this be bumped now? That way we can put a check in plasma for it and disable building the internal copy. Also is less confusing for other potential uses. I'll mass-update all the framework version numbers to 5.7 as soon as 5.6 is out (i.e. Thursday). But if you have a need for this one to say KF5_VERSION 5.7 right now, go for it (don't update the KF5_DEP_VERSION!). - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/#review73267 --- On Jan. 5, 2015, 3:22 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/ --- (Updated Jan. 5, 2015, 3:22 p.m.) Review request for KDE Frameworks, David Faure, Martin Gräßlin, and Hrvoje Senjan. Repository: kglobalaccel Description --- This is a review request for the final move, I intentionally left out all the runtime/ files to not clutter this review (it's direct move from the workspace) and posting only the buildsystem and related changes. The runtime daemon is now no longer a kdeinit executable, meaning the circular dependency should be no more. Would be pretty awesome to get this into 5.6, so Plasma 5.2 can be shipped without it's own daemon copy. Diffs - CMakeLists.txt 4077f69 metainfo.yaml d02975f src/CMakeLists.txt 03fcbb9 src/runtime/CMakeLists.txt PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121862/diff/ Testing --- kglobalaccel daemon works as expected Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121862: Move the kglobalaccel runtime into the framework
On Jan. 6, 2015, 9:19 a.m., David Faure wrote: src/runtime/CMakeLists.txt, line 4 https://git.reviewboard.kde.org/r/121862/diff/1/?file=338455#file338455line4 Is this one really necessary? Casting QString to char* is EVIL. There's quite some usage of QString(..)s in the runtime component, but I guess I can fix that. On Jan. 6, 2015, 9:19 a.m., David Faure wrote: src/runtime/CMakeLists.txt, line 27 https://git.reviewboard.kde.org/r/121862/diff/1/?file=338455#file338455line27 Hmm, this can be killed, no? :) QWS no longer exists. Yup, the implementation is just a stub anyway. I'll remove it. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/#review73243 --- On Jan. 5, 2015, 4:22 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/ --- (Updated Jan. 5, 2015, 4:22 p.m.) Review request for KDE Frameworks, David Faure, Martin Gräßlin, and Hrvoje Senjan. Repository: kglobalaccel Description --- This is a review request for the final move, I intentionally left out all the runtime/ files to not clutter this review (it's direct move from the workspace) and posting only the buildsystem and related changes. The runtime daemon is now no longer a kdeinit executable, meaning the circular dependency should be no more. Would be pretty awesome to get this into 5.6, so Plasma 5.2 can be shipped without it's own daemon copy. Diffs - CMakeLists.txt 4077f69 metainfo.yaml d02975f src/CMakeLists.txt 03fcbb9 src/runtime/CMakeLists.txt PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121862/diff/ Testing --- kglobalaccel daemon works as expected Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: kglobalaccel_master_qt5 #73
See http://build.kde.org/job/kglobalaccel_master_qt5/73/changes
Changes:
[mklapetek] Move the runtime component into the framework
[mklapetek] Upgrade KF5 version to 5.7.0.
[mklapetek] Remove the QWS part of the runtime module
--
Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit
Building remotely on LinuxSlave - 4 (PACKAGER LINBUILDER) in workspace
http://build.kde.org/job/kglobalaccel_master_qt5/ws/
Running Prebuild steps
[kglobalaccel_master_qt5] $ /bin/sh -xe /tmp/hudson7173390765436113329.sh
+ /home/jenkins/scripts/setup-env.sh
Preparing to perform KDE Continuous Integration build
== Setting Up Sources
Cloning into '.'...
Branch jenkins set up to track remote branch master from origin.
== Cleaning Source Tree
HEAD is now at 504446f Remove the QWS part of the runtime module
Success build forhudson.tasks.Shell@5fb4fc07
git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
git config remote.origin.url git://anongit.kde.org/kglobalaccel # timeout=10
Fetching upstream changes from git://anongit.kde.org/kglobalaccel
git --version # timeout=10
git fetch --tags --progress git://anongit.kde.org/kglobalaccel
+refs/heads/*:refs/remotes/origin/*
git rev-parse refs/remotes/origin/jenkins^{commit} # timeout=10
git rev-parse refs/remotes/origin/refs/heads/jenkins^{commit} # timeout=10
git rev-parse refs/heads/jenkins^{commit} # timeout=10
Checking out Revision 504446f2f82ca450933a73f57fe5739ab82b89a3
(refs/heads/jenkins)
git config core.sparsecheckout # timeout=10
git checkout -f 504446f2f82ca450933a73f57fe5739ab82b89a3
git rev-list c5b52e094f83ea3df25ef099f46ba10589371650 # timeout=10
git tag -a -f -m Jenkins Build #73 jenkins-kglobalaccel_master_qt5-73 #
timeout=10
Run condition [File exists] enabling prebuild for step [Publish JUnit test
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck
results]
[kglobalaccel_master_qt5] $ /bin/sh -xe /tmp/hudson1171957221965971208.sh
+ /home/jenkins/scripts/execute-job.sh
KDE Continuous Integration Build
== Building Project: kglobalaccel - Branch master
== Build Dependencies:
dogtail - Branch master
extra-cmake-modules - Branch master
cmake - Branch master
qt5 - Branch 5.3.2
== Applying Patches
=== No patches to apply
== Syncing Dependencies from Master Server
== Configuring Build
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /home/jenkins/bin/c++
-- Check for working CXX compiler: /home/jenkins/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - found
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
CMake Error at CMakeLists.txt:34 (find_package):
By not providing FindKF5Config.cmake in CMAKE_MODULE_PATH this project
has asked CMake to find a package configuration file provided by
KF5Config, but CMake did not find one.
Could not find a package configuration file provided by KF5Config
(requested version 5.6.0) with any of the following names:
KF5ConfigConfig.cmake
kf5config-config.cmake
Add the installation prefix of KF5Config to CMAKE_PREFIX_PATH or set
KF5Config_DIR to a directory containing one of the above files. If
KF5Config provides a separate development package or SDK, be sure it has
been installed.
-- Configuring incomplete, errors occurred!
See also
http://build.kde.org/job/kglobalaccel_master_qt5/ws/build/CMakeFiles/CMakeOutput.log;.
Configure step exited with non-zero code, assuming failure to configure for
project kglobalaccel.
Build step 'Execute shell' marked build as failure
[File exists] check if file exists [build/JUnitTestResults.xml]
Run condition [File exists] preventing perform for step [Publish JUnit test
result report]
[File exists] check if file exists [build/cppcheck.xml]
Run condition [File exists] preventing perform for step [Publish Cppcheck
results]
[WARNINGS] Skipping publisher since build result is FAILURE
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121862: Move the kglobalaccel runtime into the framework
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/ --- (Updated Jan. 6, 2015, 2:56 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, David Faure, Martin Gräßlin, and Hrvoje Senjan. Repository: kglobalaccel Description --- This is a review request for the final move, I intentionally left out all the runtime/ files to not clutter this review (it's direct move from the workspace) and posting only the buildsystem and related changes. The runtime daemon is now no longer a kdeinit executable, meaning the circular dependency should be no more. Would be pretty awesome to get this into 5.6, so Plasma 5.2 can be shipped without it's own daemon copy. Diffs - CMakeLists.txt 4077f69 metainfo.yaml d02975f src/CMakeLists.txt 03fcbb9 src/runtime/CMakeLists.txt PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121862/diff/ Testing --- kglobalaccel daemon works as expected Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121862: Move the kglobalaccel runtime into the framework
On Jan. 6, 2015, 3:35 p.m., Martin Klapetek wrote: What should I do with the framework version number? Right now it says 5.6 but given this won't be in 5.6, should this be bumped now? That way we can put a check in plasma for it and disable building the internal copy. Also is less confusing for other potential uses. David Faure wrote: I'll mass-update all the framework version numbers to 5.7 as soon as 5.6 is out (i.e. Thursday). But if you have a need for this one to say KF5_VERSION 5.7 right now, go for it (don't update the KF5_DEP_VERSION!). Thanks, I bumped the version and made use of it in https://git.reviewboard.kde.org/r/121882/ - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/#review73267 --- On Jan. 6, 2015, 3:56 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/ --- (Updated Jan. 6, 2015, 3:56 p.m.) Review request for KDE Frameworks, David Faure, Martin Gräßlin, and Hrvoje Senjan. Repository: kglobalaccel Description --- This is a review request for the final move, I intentionally left out all the runtime/ files to not clutter this review (it's direct move from the workspace) and posting only the buildsystem and related changes. The runtime daemon is now no longer a kdeinit executable, meaning the circular dependency should be no more. Would be pretty awesome to get this into 5.6, so Plasma 5.2 can be shipped without it's own daemon copy. Diffs - CMakeLists.txt 4077f69 metainfo.yaml d02975f src/CMakeLists.txt 03fcbb9 src/runtime/CMakeLists.txt PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121862/diff/ Testing --- kglobalaccel daemon works as expected Thanks, Martin Klapetek ___ 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
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
Re: Linux/CI OSX/CI: kglobalaccel is failing to build on branches stable and master
Hey, On Tue, Jan 6, 2015 at 7:56 PM, Marko Käning mk-li...@email.de wrote: 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 --- Ahh yes, I prepared this and then got carried away by other work, this needs to be done. ... 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! KGlobalAccel got the runtime daemon added into the framework today and is now tier3 (starting from 5.7 release). 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 --- Ah humm..that would be my fault, builds fine here. I'll have a look. 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? I'll have a look and fix it. Thanks for the investigation! Cheers -- Martin Klapetek | KDE Developer ___ 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
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
Build failed in Jenkins: kglobalaccel_stable_qt5 #7
See http://build.kde.org/job/kglobalaccel_stable_qt5/7/changes
Changes:
[mklapetek] Set the translation domain of the daemon to kglobalaccel5
--
Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit
Building remotely on LinuxSlave - 1 (PACKAGER LINBUILDER) in workspace
http://build.kde.org/job/kglobalaccel_stable_qt5/ws/
Running Prebuild steps
[kglobalaccel_stable_qt5] $ /bin/sh -xe /tmp/hudson3162139406125384128.sh
+ /home/jenkins/scripts/setup-env.sh
Preparing to perform KDE Continuous Integration build
== Setting Up Sources
From git://anongit.kde.org/kglobalaccel
682929b..41b7fb4 master - origin/master
Branch jenkins set up to track remote branch master from origin.
== Cleaning Source Tree
HEAD is now at 682929b Extract i18n strings into kglobalaccel5.pot
Removing build/
Success build forhudson.tasks.Shell@5963f6ec
git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
git config remote.origin.url git://anongit.kde.org/kglobalaccel # timeout=10
Fetching upstream changes from git://anongit.kde.org/kglobalaccel
git --version # timeout=10
git fetch --tags --progress git://anongit.kde.org/kglobalaccel
+refs/heads/*:refs/remotes/origin/*
git rev-parse refs/remotes/origin/jenkins^{commit} # timeout=10
git rev-parse refs/remotes/origin/refs/heads/jenkins^{commit} # timeout=10
git rev-parse refs/heads/jenkins^{commit} # timeout=10
Checking out Revision 41b7fb45a8f0b8f3728740089bd0f5cc0934361f
(refs/heads/jenkins)
git config core.sparsecheckout # timeout=10
git checkout -f 41b7fb45a8f0b8f3728740089bd0f5cc0934361f
git rev-list 682929b038babb65caa524382f8f283173e94343 # timeout=10
git tag -a -f -m Jenkins Build #7 jenkins-kglobalaccel_stable_qt5-7 #
timeout=10
Run condition [File exists] enabling prebuild for step [Publish JUnit test
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck
results]
[kglobalaccel_stable_qt5] $ /bin/sh -xe /tmp/hudson8618429936879423435.sh
+ /home/jenkins/scripts/execute-job.sh
KDE Continuous Integration Build
== Building Project: kglobalaccel - Branch master
== Build Dependencies:
extra-cmake-modules - Branch master
qt5 - Branch stable
dogtail - Branch master
cmake - Branch master
== Applying Patches
=== No patches to apply
== Syncing Dependencies from Master Server
== Configuring Build
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /home/jenkins/bin/c++
-- Check for working CXX compiler: /home/jenkins/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - found
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
CMake Error at CMakeLists.txt:34 (find_package):
By not providing FindKF5Config.cmake in CMAKE_MODULE_PATH this project
has asked CMake to find a package configuration file provided by
KF5Config, but CMake did not find one.
Could not find a package configuration file provided by KF5Config
(requested version 5.6.0) with any of the following names:
KF5ConfigConfig.cmake
kf5config-config.cmake
Add the installation prefix of KF5Config to CMAKE_PREFIX_PATH or set
KF5Config_DIR to a directory containing one of the above files. If
KF5Config provides a separate development package or SDK, be sure it has
been installed.
-- Configuring incomplete, errors occurred!
See also
http://build.kde.org/job/kglobalaccel_stable_qt5/ws/build/CMakeFiles/CMakeOutput.log;.
Configure step exited with non-zero code, assuming failure to configure for
project kglobalaccel.
Build step 'Execute shell' marked build as failure
[File exists] check if file exists [build/JUnitTestResults.xml]
Run condition [File exists] preventing perform for step [Publish JUnit test
result report]
[File exists] check if file exists [build/cppcheck.xml]
Run condition [File exists] preventing perform for step [Publish Cppcheck
results]
[WARNINGS] Skipping publisher since build result is FAILURE
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: kglobalaccel_master_qt5 #74
See http://build.kde.org/job/kglobalaccel_master_qt5/74/
--
Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit
Building remotely on LinuxSlave - 4 (PACKAGER LINBUILDER) in workspace
http://build.kde.org/job/kglobalaccel_master_qt5/ws/
Running Prebuild steps
[kglobalaccel_master_qt5] $ /bin/sh -xe /tmp/hudson8175951207137323770.sh
+ /home/jenkins/scripts/setup-env.sh
Preparing to perform KDE Continuous Integration build
== Setting Up Sources
Branch jenkins set up to track remote branch master from origin.
== Cleaning Source Tree
HEAD is now at 504446f Remove the QWS part of the runtime module
Removing build/
Success build forhudson.tasks.Shell@5fb4fc07
git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
git config remote.origin.url git://anongit.kde.org/kglobalaccel # timeout=10
Fetching upstream changes from git://anongit.kde.org/kglobalaccel
git --version # timeout=10
git fetch --tags --progress git://anongit.kde.org/kglobalaccel
+refs/heads/*:refs/remotes/origin/*
git rev-parse refs/remotes/origin/jenkins^{commit} # timeout=10
git rev-parse refs/remotes/origin/refs/heads/jenkins^{commit} # timeout=10
git rev-parse refs/heads/jenkins^{commit} # timeout=10
Checking out Revision 504446f2f82ca450933a73f57fe5739ab82b89a3
(refs/heads/jenkins)
git config core.sparsecheckout # timeout=10
git checkout -f 504446f2f82ca450933a73f57fe5739ab82b89a3
git rev-list 504446f2f82ca450933a73f57fe5739ab82b89a3 # timeout=10
git tag -a -f -m Jenkins Build #74 jenkins-kglobalaccel_master_qt5-74 #
timeout=10
Run condition [File exists] enabling prebuild for step [Publish JUnit test
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck
results]
[kglobalaccel_master_qt5] $ /bin/sh -xe /tmp/hudson1986221980377265506.sh
+ /home/jenkins/scripts/execute-job.sh
KDE Continuous Integration Build
== Building Project: kglobalaccel - Branch master
== Build Dependencies:
dogtail - Branch master
extra-cmake-modules - Branch master
cmake - Branch master
qt5 - Branch 5.3.2
== Applying Patches
=== No patches to apply
== Syncing Dependencies from Master Server
== Configuring Build
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /home/jenkins/bin/c++
-- Check for working CXX compiler: /home/jenkins/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - found
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
CMake Error at CMakeLists.txt:34 (find_package):
By not providing FindKF5Config.cmake in CMAKE_MODULE_PATH this project
has asked CMake to find a package configuration file provided by
KF5Config, but CMake did not find one.
Could not find a package configuration file provided by KF5Config
(requested version 5.6.0) with any of the following names:
KF5ConfigConfig.cmake
kf5config-config.cmake
Add the installation prefix of KF5Config to CMAKE_PREFIX_PATH or set
KF5Config_DIR to a directory containing one of the above files. If
KF5Config provides a separate development package or SDK, be sure it has
been installed.
-- Configuring incomplete, errors occurred!
See also
http://build.kde.org/job/kglobalaccel_master_qt5/ws/build/CMakeFiles/CMakeOutput.log;.
Configure step exited with non-zero code, assuming failure to configure for
project kglobalaccel.
Build step 'Execute shell' marked build as failure
[File exists] check if file exists [build/JUnitTestResults.xml]
Run condition [File exists] preventing perform for step [Publish JUnit test
result report]
[File exists] check if file exists [build/cppcheck.xml]
Run condition [File exists] preventing perform for step [Publish Cppcheck
results]
[WARNINGS] Skipping publisher since build result is FAILURE
___
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
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
Build failed in Jenkins: kglobalaccel_stable_qt5 #6
See http://build.kde.org/job/kglobalaccel_stable_qt5/6/changes
Changes:
[mklapetek] Remove #include for removed header
[mklapetek] Extract i18n strings into kglobalaccel5.pot
--
Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit
Building remotely on LinuxSlave - 1 (PACKAGER LINBUILDER) in workspace
http://build.kde.org/job/kglobalaccel_stable_qt5/ws/
Running Prebuild steps
[kglobalaccel_stable_qt5] $ /bin/sh -xe /tmp/hudson6789938949958106668.sh
+ /home/jenkins/scripts/setup-env.sh
Preparing to perform KDE Continuous Integration build
== Setting Up Sources
Cloning into '.'...
From git://anongit.kde.org/kglobalaccel
504446f..682929b master - origin/master
Branch jenkins set up to track remote branch master from origin.
== Cleaning Source Tree
HEAD is now at 504446f Remove the QWS part of the runtime module
Success build forhudson.tasks.Shell@5963f6ec
git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
git config remote.origin.url git://anongit.kde.org/kglobalaccel # timeout=10
Fetching upstream changes from git://anongit.kde.org/kglobalaccel
git --version # timeout=10
git fetch --tags --progress git://anongit.kde.org/kglobalaccel
+refs/heads/*:refs/remotes/origin/*
git rev-parse refs/remotes/origin/jenkins^{commit} # timeout=10
git rev-parse refs/remotes/origin/refs/heads/jenkins^{commit} # timeout=10
git rev-parse refs/heads/jenkins^{commit} # timeout=10
Checking out Revision 682929b038babb65caa524382f8f283173e94343
(refs/heads/jenkins)
git config core.sparsecheckout # timeout=10
git checkout -f 682929b038babb65caa524382f8f283173e94343
git rev-list 504446f2f82ca450933a73f57fe5739ab82b89a3 # timeout=10
git tag -a -f -m Jenkins Build #6 jenkins-kglobalaccel_stable_qt5-6 #
timeout=10
Run condition [File exists] enabling prebuild for step [Publish JUnit test
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck
results]
[kglobalaccel_stable_qt5] $ /bin/sh -xe /tmp/hudson498500270795481549.sh
+ /home/jenkins/scripts/execute-job.sh
KDE Continuous Integration Build
== Building Project: kglobalaccel - Branch master
== Build Dependencies:
extra-cmake-modules - Branch master
qt5 - Branch stable
dogtail - Branch master
cmake - Branch master
== Applying Patches
=== No patches to apply
== Syncing Dependencies from Master Server
== Configuring Build
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /home/jenkins/bin/c++
-- Check for working CXX compiler: /home/jenkins/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - found
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
CMake Error at CMakeLists.txt:34 (find_package):
By not providing FindKF5Config.cmake in CMAKE_MODULE_PATH this project
has asked CMake to find a package configuration file provided by
KF5Config, but CMake did not find one.
Could not find a package configuration file provided by KF5Config
(requested version 5.6.0) with any of the following names:
KF5ConfigConfig.cmake
kf5config-config.cmake
Add the installation prefix of KF5Config to CMAKE_PREFIX_PATH or set
KF5Config_DIR to a directory containing one of the above files. If
KF5Config provides a separate development package or SDK, be sure it has
been installed.
-- Configuring incomplete, errors occurred!
See also
http://build.kde.org/job/kglobalaccel_stable_qt5/ws/build/CMakeFiles/CMakeOutput.log;.
Configure step exited with non-zero code, assuming failure to configure for
project kglobalaccel.
Build step 'Execute shell' marked build as failure
[File exists] check if file exists [build/JUnitTestResults.xml]
Run condition [File exists] preventing perform for step [Publish JUnit test
result report]
[File exists] check if file exists [build/cppcheck.xml]
Run condition [File exists] preventing perform for step [Publish Cppcheck
results]
[WARNINGS] Skipping publisher since build result is FAILURE
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to normal : kglobalaccel_master_qt5 #75
See http://build.kde.org/job/kglobalaccel_master_qt5/75/changes ___ 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
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
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
Re: OSX/CI: kio-extras fails to build on branch master
Well, I just attempted to try building kio-extras (I guess it's in kde/workspace in projects.kde.org right? And my qt build doesn't have dbus somehow, what do you use when you configure Qt to build in the CI system ? I've been talking to thiago in #qt and he said some of his changes just hit the 5.4 branch to make it default but I tried with configure with -dbus which said it would build dbus runtime but I have no QtDBusConfig.cmake for kio-extras to find and build with still. thanks, Jeremy On Tue, Jan 6, 2015 at 2:41 PM, Marko Käning mk-li...@email.de wrote: Hi Jeremy, On 06 Jan 2015, at 22:39 , Jeremy Whiting jpwhit...@kde.org wrote: I think this is the same problem that kconfig had last week. i.e. we need to change INSTALL_TARGET_ARGS to KDE_INSTALL_TARGET_ARGS. I'll take a look. yes, see the discussion with Milian and Christopher in thread “OSX/CI: konsole fails to build on branch master”. Thanks for taking care of this, 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
Yes, ecm changed recently. On Tue, Jan 6, 2015 at 3:55 PM, Marko Käning mk-li...@email.de wrote: 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 ___ 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
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 think the problem is that it should be KF5_INSTALL_TARGETS_DEFAULT_ARGS, the prefix is missing in many cmake files. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ 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
On Tuesday 06 January 2015 21:46:16 Marko Käning wrote: Hi David, thanks for taking care of the taglib issue. The kfilemetadata FW eventually built successfully on OSX/MacPorts. Thanks, but now I think it was the wrong fix. The right fix is https://github.com/taglib/taglib/pull/495 Once that's in, I'll revert my changes to kfilemetadata and plasma- mediacenter. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121838: Fix KCoreConfigSkeleton when toggling a value with saves in between
On gen. 6, 2015, 11:55 p.m., Aleix Pol Gonzalez wrote: CMakeLists.txt, line 5 https://git.reviewboard.kde.org/r/121838/diff/2/?file=338706#file338706line5 Unrelated. And why? Because not all of us are bleeding edge that have everything up to date and requiring ecm 1.6 here is not needed at all so i have to revert it so i can compile without having to install something that is unneeded. And yes, it being part of the diff was a mistake on my side, it hasn't been commited. - Albert --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121838/#review73316 --- On gen. 6, 2015, 11:55 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121838/ --- (Updated gen. 6, 2015, 11:55 p.m.) Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- We need to refresh mLoadedValue after a save, otherwise the value is stale. I'm doing this by resetting mLoadedValue to mReference in all the ::writeConfig. I've also refactored the tests so they can be run independently now just fine. Diffs - autotests/kconfigskeletontest.cpp f401b9f src/core/kcoreconfigskeleton.h f8313d1 src/core/kcoreconfigskeleton.cpp e4255a6 CMakeLists.txt 205c38b autotests/kconfigskeletontest.h c54c7b0 Diff: https://git.reviewboard.kde.org/r/121838/diff/ Testing --- My tests now pass. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121838: Fix KCoreConfigSkeleton when toggling a value with saves in between
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121838/#review73314 --- Ship it! Thanks, LGTM. If possible, could you please split the unit test refactoring out to a separate commit just before the bug fix commit? If not, just push it as is. - Matthew Dawson On Jan. 6, 2015, 5:41 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121838/ --- (Updated Jan. 6, 2015, 5:41 p.m.) Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- We need to refresh mLoadedValue after a save, otherwise the value is stale. I'm doing this by resetting mLoadedValue to mReference in all the ::writeConfig. I've also refactored the tests so they can be run independently now just fine. Diffs - autotests/kconfigskeletontest.cpp f401b9f src/core/kcoreconfigskeleton.h f8313d1 src/core/kcoreconfigskeleton.cpp e4255a6 CMakeLists.txt 205c38b autotests/kconfigskeletontest.h c54c7b0 Diff: https://git.reviewboard.kde.org/r/121838/diff/ Testing --- My tests now pass. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121838: Fix KCoreConfigSkeleton when toggling a value with saves in between
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121838/ --- (Updated Jan. 6, 2015, 11:55 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- We need to refresh mLoadedValue after a save, otherwise the value is stale. I'm doing this by resetting mLoadedValue to mReference in all the ::writeConfig. I've also refactored the tests so they can be run independently now just fine. Diffs - autotests/kconfigskeletontest.cpp f401b9f src/core/kcoreconfigskeleton.h f8313d1 src/core/kcoreconfigskeleton.cpp e4255a6 CMakeLists.txt 205c38b autotests/kconfigskeletontest.h c54c7b0 Diff: https://git.reviewboard.kde.org/r/121838/diff/ Testing --- My tests now pass. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121838: Fix KCoreConfigSkeleton when toggling a value with saves in between
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121838/#review73316 --- CMakeLists.txt https://git.reviewboard.kde.org/r/121838/#comment50989 Unrelated. And why? Other than that, +1. - Aleix Pol Gonzalez On Jan. 6, 2015, 11:55 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121838/ --- (Updated Jan. 6, 2015, 11:55 p.m.) Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- We need to refresh mLoadedValue after a save, otherwise the value is stale. I'm doing this by resetting mLoadedValue to mReference in all the ::writeConfig. I've also refactored the tests so they can be run independently now just fine. Diffs - autotests/kconfigskeletontest.cpp f401b9f src/core/kcoreconfigskeleton.h f8313d1 src/core/kcoreconfigskeleton.cpp e4255a6 CMakeLists.txt 205c38b autotests/kconfigskeletontest.h c54c7b0 Diff: https://git.reviewboard.kde.org/r/121838/diff/ Testing --- My tests now pass. Thanks, Albert Astals Cid ___ 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 .*)
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
Re: OSX/CI: konsole fails to build on branch master
On Tuesday 06 January 2015 22:14:06 Marko Käning wrote: 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?! It of course makes sense to report them, but not with one mail per project. They all have the same issue after all... 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. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ 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
On Tuesday 06 January 2015 22:14:06 Marko Käning wrote: 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?! It of course makes sense to report them, but not with one mail per project. They all have the same issue after all... -- Milian Wolff m...@milianw.de http://milianw.de ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121838: Fix KCoreConfigSkeleton when toggling a value with saves in between
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121838/ --- (Updated gen. 6, 2015, 10:41 p.m.) Review request for KDE Frameworks and Matthew Dawson. Changes --- Go the mLoadedValue=mReference way Repository: kconfig Description (updated) --- We need to refresh mLoadedValue after a save, otherwise the value is stale. I'm doing this by resetting mLoadedValue to mReference in all the ::writeConfig. I've also refactored the tests so they can be run independently now just fine. Diffs (updated) - autotests/kconfigskeletontest.cpp f401b9f src/core/kcoreconfigskeleton.h f8313d1 src/core/kcoreconfigskeleton.cpp e4255a6 CMakeLists.txt 205c38b autotests/kconfigskeletontest.h c54c7b0 Diff: https://git.reviewboard.kde.org/r/121838/diff/ Testing --- My tests now pass. Thanks, Albert Astals Cid ___ 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
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
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
Re: Review Request 121885: Properly check for systray being available
On Jan. 6, 2015, 7:20 p.m., David Edmundson wrote: src/platformtheme/kdeplatformsystemtrayicon.cpp, line 330 https://git.reviewboard.kde.org/r/121885/diff/1/?file=338653#file338653line330 the statusnotifierwatcher is a kded module, which means if another kded module tries to create an SNI (and at least one does) we're going to deadlock I think? Martin Klapetek wrote: Are we? I'm not sure really...how else could we do this then? Martin Klapetek wrote: Possibly we could cut off the $PID part of the service name and then simply check for that service, though this API seems more robust I cannot mentally construct a dead lock situation. Could you please elaborate on what would dead lock? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121885/#review73291 --- On Jan. 6, 2015, 7:16 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121885/ --- (Updated Jan. 6, 2015, 7:16 p.m.) Review request for KDE Frameworks. Bugs: 339707 https://bugs.kde.org/show_bug.cgi?id=339707 Repository: frameworkintegration Description --- The org.kde.StatusNotifierWatcher is just a watcher/helper, not the actual systray object, that's org.kde.StatusNotifierHost-$PID. Because Plasma appends the PID, we cannot check directly for it being present on the bus, so we check the org.kde.StatusNotifierWatcher.IsStatusNotifierHostRegistered property that's meant to be used for this. Plus QSystemTrayIcon::isSystemTrayAvailable() is actually returning always true, because the Watcher is in kded and is /always/ present. This also fixes many apps with KSNI crashing on plasma exit, bug 339707 (though I believe this is not the direct cause for that bug) Diffs - src/platformtheme/kdeplatformsystemtrayicon.cpp b5e207c Diff: https://git.reviewboard.kde.org/r/121885/diff/ Testing --- Things do not crash anymore and the ::isSystemTrayAvailable() now returns correct value. Thanks, Martin Klapetek ___ 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
On Tuesday 06 January 2015 23:55:48 Marko Käning wrote: 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. Is KF5_INSTALL_TARGETS_DEFAULT_ARGS even correct for non-frameworks projects? KF5_INSTALL_TARGETS_DEFAULT_ARGS's INCLUDES location points to $SOMETHING/KF5. KDEInstallDirs.cmake also has a KDE_INSTALL_TARGETS_DEFAULT_ARGS, which seems more appropriate. @Alex, please elaborate. 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 -- Kevin Funk | kf...@kde.org | http://kfunk.org ___ 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
On Tuesday 06 January 2015 23:55:48 Marko Käning wrote: 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. Is KF5_INSTALL_TARGETS_DEFAULT_ARGS even correct for non-frameworks projects? KF5_INSTALL_TARGETS_DEFAULT_ARGS's INCLUDES location points to $SOMETHING/KF5. KDEInstallDirs.cmake also has a KDE_INSTALL_TARGETS_DEFAULT_ARGS, which seems more appropriate. @Alex, please elaborate. Yeah, for non-framework repos, I am not sure of that, true. Greetings Christoph 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 -- Kevin Funk | kf...@kde.org | http://kfunk.org -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121885: Properly check for systray being available
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121885/ --- Review request for KDE Frameworks. Bugs: 339707 https://bugs.kde.org/show_bug.cgi?id=339707 Repository: frameworkintegration Description --- The org.kde.StatusNotifierWatcher is just a watcher/helper, not the actual systray object, that's org.kde.StatusNotifierHost-$PID. Because Plasma appends the PID, we cannot check directly for it being present on the bus, so we check the org.kde.StatusNotifierWatcher.IsStatusNotifierHostRegistered property that's meant to be used for this. Plus QSystemTrayIcon::isSystemTrayAvailable() is actually returning always true, because the Watcher is in kded and is /always/ present. This also fixes many apps with KSNI crashing on plasma exit, bug 339707 (though I believe this is not the direct cause for that bug) Diffs - src/platformtheme/kdeplatformsystemtrayicon.cpp b5e207c Diff: https://git.reviewboard.kde.org/r/121885/diff/ Testing --- Things do not crash anymore and the ::isSystemTrayAvailable() now returns correct value. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121471: Port KDirSelectDialog to QFileDialog
On Led. 4, 2015, 5:12 odp., David Faure wrote: Just like we have KFileWidget for an embeddable file-selection-widget, we could very well have a KDirSelectWidget for an embeddable dir-selection-widget. The code is currently in frameworkintegration/src/platformtheme/kdirselectdialog.cpp (and duplicated in kdelibs4support). I think it would be a valid solution to extract a widget out of it and put it in kio/src/filewidgets. The design should match KFileWidget as much as possible. Ok, I'll try to separate KDirSelectDialog and transform it to KDirSelectWidget with design similar to KFileWidget. - Jan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121471/#review73086 --- On Pro. 17, 2014, 11:58 dop., Jan Grulich wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121471/ --- (Updated Pro. 17, 2014, 11:58 dop.) Review request for KDE Frameworks, Bhushan Shah, David Faure, Lukáš Tinkl, and Laurent Montel. Repository: ark Description --- I ported KDirSelectDialog to QFileDialog to get rid of kdelibs4support in ExtractionDialog, but I run into one problem. This dialog needs to add additional config widget, this is possible with using setExtension(widget) or directly accessing layout and adding this widget directly to the layout. Problem is that both options work only when I don't use native file dialog, not mentioning that setExtension() is obsoleted and accesing directly to layout of QFileDialog relies on knowning internal implementation in Qt so if they change it, i.e they switch to another layout then QGridLayout, then it will be broken again. I also tried to implement own QFileDialog using KFileWidget, but problem is that KFileWidget works only for files and I need to select a directory. You can set option to display just directories, but selecting directories is unfortunately ignored. I'm open to a better solution, but I've spent quite a lot of time trying to find it, but unfortunately without any succe ss. Diffs - app/batchextract.cpp 9480e99 kerfuffle/extractiondialog.h 5907403 kerfuffle/extractiondialog.cpp f602861 part/part.cpp 82d6f9c Diff: https://git.reviewboard.kde.org/r/121471/diff/ Testing --- Thanks, Jan Grulich ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121862: Move the kglobalaccel runtime into the framework
On Jan. 6, 2015, 5:35 p.m., Hrvoje Senjan wrote: src/runtime/CMakeLists.txt, line 1 https://git.reviewboard.kde.org/r/121862/diff/1/?file=338455#file338455line1 i guess this should now be kglobalaccel5? The Messages.sh extracts it to kglobalaccel.pot, so this is correct. Do I remember correctly that coinstability of po files is not possible? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/#review73277 --- On Jan. 6, 2015, 3:56 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/ --- (Updated Jan. 6, 2015, 3:56 p.m.) Review request for KDE Frameworks, David Faure, Martin Gräßlin, and Hrvoje Senjan. Repository: kglobalaccel Description --- This is a review request for the final move, I intentionally left out all the runtime/ files to not clutter this review (it's direct move from the workspace) and posting only the buildsystem and related changes. The runtime daemon is now no longer a kdeinit executable, meaning the circular dependency should be no more. Would be pretty awesome to get this into 5.6, so Plasma 5.2 can be shipped without it's own daemon copy. Diffs - CMakeLists.txt 4077f69 metainfo.yaml d02975f src/CMakeLists.txt 03fcbb9 src/runtime/CMakeLists.txt PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121862/diff/ Testing --- kglobalaccel daemon works as expected Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121885: Properly check for systray being available
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121885/#review73291 --- src/platformtheme/kdeplatformsystemtrayicon.cpp https://git.reviewboard.kde.org/r/121885/#comment50966 the statusnotifierwatcher is a kded module, which means if another kded module tries to create an SNI (and at least one does) we're going to deadlock I think? - David Edmundson On Jan. 6, 2015, 6:16 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121885/ --- (Updated Jan. 6, 2015, 6:16 p.m.) Review request for KDE Frameworks. Bugs: 339707 https://bugs.kde.org/show_bug.cgi?id=339707 Repository: frameworkintegration Description --- The org.kde.StatusNotifierWatcher is just a watcher/helper, not the actual systray object, that's org.kde.StatusNotifierHost-$PID. Because Plasma appends the PID, we cannot check directly for it being present on the bus, so we check the org.kde.StatusNotifierWatcher.IsStatusNotifierHostRegistered property that's meant to be used for this. Plus QSystemTrayIcon::isSystemTrayAvailable() is actually returning always true, because the Watcher is in kded and is /always/ present. This also fixes many apps with KSNI crashing on plasma exit, bug 339707 (though I believe this is not the direct cause for that bug) Diffs - src/platformtheme/kdeplatformsystemtrayicon.cpp b5e207c Diff: https://git.reviewboard.kde.org/r/121885/diff/ Testing --- Things do not crash anymore and the ::isSystemTrayAvailable() now returns correct value. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Baloo Framework - License Exception
On Tuesday 06 January 2015 11:01:19 David Faure wrote: Well, that's interesting, I didn't expect you would reply that :-) You probably picture me as wanting KF to grow wide and large as much as possible. That'd be wrong. I actually have this concern that we might reach a point of too much stuff in there. That's assuming people will look for those details. I'm unsure they will. My suggestion is to make this fact as pro-eminent as possible. If the framework code itself was GPL, I would advocate calling the framework baloo-gpl. I think this should appease fears of the slippery slope, because if one day we want to have a real GPL framework, we can make it part of the name everywhere (not just the git repo, but really everywhere, cmake targets etc.) Let's not violate our own licensing policy for a start. ;-) With baloo it's a bit more tricky, since it's only effectively GPL and we surely want to keep the possibility to make it really LGPL. Still, I'm sure we can plaster the documentation, README, header files etc. with this code is GPL!!!. You know, the same issue exists even if it's not released as part of KF5. On most distros it will be just another package whichever way we release it on our side. https://launchpad.net/~kubuntu-ci/+archive/ubuntu/unstable-daily has attica-kf5 and baloo-kf5. From there you can't really tell that it's not a framework, or that it's not LGPL... Sure, but it's not our responsibility then. :-) But what will people do as soon as they start using a lib and writing code that uses it? Opening the api docs. So let's make it very clear there. This is needed, whether or not baloo is released with KF5 or separately. Agreed. KDE app developers, not third parties... which actually begs the question: does Baloo provide any value outside of the KDE community? if not there's no rush to put it in KF5 as sebas highlighted. The problem (and the reason I talk about shooting ourselves in the foot) is ... what do we do instead, then, to solve the KDE issue? We need to be able to use baloo in both KDE Workspace and KDE applications, which are released separately and cannot depend on each other. In fact, this is just like the portingAids subdir of the frameworks releases. It's stuff that we release as part of frameworks but that is not intended for the outside world (= outside the KDE community). Yep, it smells a lot like it indeed. Can we have a similar section for GPL frameworks? I completely agree that the goal is to hide it from the outside world, but we still need to release it so that we can use it, for our own purposes. I wouldn't draw the line on the license to be honest. It's stuff we keep for ourselves for whatever reason, be warned!. It's private to the community. Bottom line: since there's the possibility of a non-xapian backend making Baloo effectively LGPL and not effectively GPL, I'd be in favor of waiting for it to be reality. We need a much shorter term solution than that, for practical purposes. And that bothers me to be honest... How come suddenly it *has* to be part of KF? Especially when it is said that a) there's a license problem because of Xapian and b) we have other problems because of Xapian so we'll switch and it will be a larger change. IOW: If it's not ready... it's not ready. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121862: Move the kglobalaccel runtime into the framework
On Jan. 6, 2015, 5:35 p.m., Hrvoje Senjan wrote: src/runtime/CMakeLists.txt, line 1 https://git.reviewboard.kde.org/r/121862/diff/1/?file=338455#file338455line1 i guess this should now be kglobalaccel5? Martin Klapetek wrote: The Messages.sh extracts it to kglobalaccel.pot, so this is correct. Do I remember correctly that coinstability of po files is not possible? well, let's say that for Frameworks *everything* is coinstallable, and for Plasma po coinstallability is resolved wontfix - Hrvoje --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/#review73277 --- On Jan. 6, 2015, 3:56 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/ --- (Updated Jan. 6, 2015, 3:56 p.m.) Review request for KDE Frameworks, David Faure, Martin Gräßlin, and Hrvoje Senjan. Repository: kglobalaccel Description --- This is a review request for the final move, I intentionally left out all the runtime/ files to not clutter this review (it's direct move from the workspace) and posting only the buildsystem and related changes. The runtime daemon is now no longer a kdeinit executable, meaning the circular dependency should be no more. Would be pretty awesome to get this into 5.6, so Plasma 5.2 can be shipped without it's own daemon copy. Diffs - CMakeLists.txt 4077f69 metainfo.yaml d02975f src/CMakeLists.txt 03fcbb9 src/runtime/CMakeLists.txt PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121862/diff/ Testing --- kglobalaccel daemon works as expected Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121885: Properly check for systray being available
On Jan. 6, 2015, 7:20 p.m., David Edmundson wrote: src/platformtheme/kdeplatformsystemtrayicon.cpp, line 330 https://git.reviewboard.kde.org/r/121885/diff/1/?file=338653#file338653line330 the statusnotifierwatcher is a kded module, which means if another kded module tries to create an SNI (and at least one does) we're going to deadlock I think? Are we? I'm not sure really...how else could we do this then? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121885/#review73291 --- On Jan. 6, 2015, 7:16 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121885/ --- (Updated Jan. 6, 2015, 7:16 p.m.) Review request for KDE Frameworks. Bugs: 339707 https://bugs.kde.org/show_bug.cgi?id=339707 Repository: frameworkintegration Description --- The org.kde.StatusNotifierWatcher is just a watcher/helper, not the actual systray object, that's org.kde.StatusNotifierHost-$PID. Because Plasma appends the PID, we cannot check directly for it being present on the bus, so we check the org.kde.StatusNotifierWatcher.IsStatusNotifierHostRegistered property that's meant to be used for this. Plus QSystemTrayIcon::isSystemTrayAvailable() is actually returning always true, because the Watcher is in kded and is /always/ present. This also fixes many apps with KSNI crashing on plasma exit, bug 339707 (though I believe this is not the direct cause for that bug) Diffs - src/platformtheme/kdeplatformsystemtrayicon.cpp b5e207c Diff: https://git.reviewboard.kde.org/r/121885/diff/ Testing --- Things do not crash anymore and the ::isSystemTrayAvailable() now returns correct value. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121885: Properly check for systray being available
On Jan. 6, 2015, 7:20 p.m., David Edmundson wrote: src/platformtheme/kdeplatformsystemtrayicon.cpp, line 330 https://git.reviewboard.kde.org/r/121885/diff/1/?file=338653#file338653line330 the statusnotifierwatcher is a kded module, which means if another kded module tries to create an SNI (and at least one does) we're going to deadlock I think? Martin Klapetek wrote: Are we? I'm not sure really...how else could we do this then? Possibly we could cut off the $PID part of the service name and then simply check for that service, though this API seems more robust - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121885/#review73291 --- On Jan. 6, 2015, 7:16 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121885/ --- (Updated Jan. 6, 2015, 7:16 p.m.) Review request for KDE Frameworks. Bugs: 339707 https://bugs.kde.org/show_bug.cgi?id=339707 Repository: frameworkintegration Description --- The org.kde.StatusNotifierWatcher is just a watcher/helper, not the actual systray object, that's org.kde.StatusNotifierHost-$PID. Because Plasma appends the PID, we cannot check directly for it being present on the bus, so we check the org.kde.StatusNotifierWatcher.IsStatusNotifierHostRegistered property that's meant to be used for this. Plus QSystemTrayIcon::isSystemTrayAvailable() is actually returning always true, because the Watcher is in kded and is /always/ present. This also fixes many apps with KSNI crashing on plasma exit, bug 339707 (though I believe this is not the direct cause for that bug) Diffs - src/platformtheme/kdeplatformsystemtrayicon.cpp b5e207c Diff: https://git.reviewboard.kde.org/r/121885/diff/ Testing --- Things do not crash anymore and the ::isSystemTrayAvailable() now returns correct value. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121862: Move the kglobalaccel runtime into the framework
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/#review73277 --- src/runtime/CMakeLists.txt https://git.reviewboard.kde.org/r/121862/#comment50954 i guess this should now be kglobalaccel5? - Hrvoje Senjan On Jan. 6, 2015, 3:56 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/ --- (Updated Jan. 6, 2015, 3:56 p.m.) Review request for KDE Frameworks, David Faure, Martin Gräßlin, and Hrvoje Senjan. Repository: kglobalaccel Description --- This is a review request for the final move, I intentionally left out all the runtime/ files to not clutter this review (it's direct move from the workspace) and posting only the buildsystem and related changes. The runtime daemon is now no longer a kdeinit executable, meaning the circular dependency should be no more. Would be pretty awesome to get this into 5.6, so Plasma 5.2 can be shipped without it's own daemon copy. Diffs - CMakeLists.txt 4077f69 metainfo.yaml d02975f src/CMakeLists.txt 03fcbb9 src/runtime/CMakeLists.txt PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121862/diff/ Testing --- kglobalaccel daemon works as expected Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121862: Move the kglobalaccel runtime into the framework
On Jan. 6, 2015, 5:35 p.m., Hrvoje Senjan wrote: src/runtime/CMakeLists.txt, line 1 https://git.reviewboard.kde.org/r/121862/diff/1/?file=338455#file338455line1 i guess this should now be kglobalaccel5? Martin Klapetek wrote: The Messages.sh extracts it to kglobalaccel.pot, so this is correct. Do I remember correctly that coinstability of po files is not possible? Hrvoje Senjan wrote: well, let's say that for Frameworks *everything* is coinstallable, and for Plasma po coinstallability is resolved wontfix alright, I can change it. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/#review73277 --- On Jan. 6, 2015, 3:56 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121862/ --- (Updated Jan. 6, 2015, 3:56 p.m.) Review request for KDE Frameworks, David Faure, Martin Gräßlin, and Hrvoje Senjan. Repository: kglobalaccel Description --- This is a review request for the final move, I intentionally left out all the runtime/ files to not clutter this review (it's direct move from the workspace) and posting only the buildsystem and related changes. The runtime daemon is now no longer a kdeinit executable, meaning the circular dependency should be no more. Would be pretty awesome to get this into 5.6, so Plasma 5.2 can be shipped without it's own daemon copy. Diffs - CMakeLists.txt 4077f69 metainfo.yaml d02975f src/CMakeLists.txt 03fcbb9 src/runtime/CMakeLists.txt PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121862/diff/ Testing --- kglobalaccel daemon works as expected Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
