D5983: Check error status after every PolKitAuthority usage
aacid added a comment. Have you had these errors happen to you? How can one reproduce them? Or is it more of a "this should be the right code but i don't know how to trigger it" case? REPOSITORY R283 KAuth REVISION DETAIL https://phabricator.kde.org/D5983 To: skalinichev Cc: aacid, #frameworks
D5975: breeze-icons: don't look for bash on Windows
aacid added a comment. You want the impossible to remember Differential Revision: https://phabricator.kde.org/D https://community.kde.org/Policies/Commit_Policy#Special_keywords_in_GIT_and_SVN_log_messages REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabricator.kde.org/D5975 To: winterz, aacid Cc: aacid, #frameworks
D5975: breeze-icons: don't look for bash on Windows
winterz closed this revision. winterz added a comment. committed in https://phabricator.kde.org/R266:09291a2b3ecf03577b93c6d4cedc28927668e571 REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabricator.kde.org/D5975 To: winterz, aacid Cc: aacid, #frameworks
D5856: Use KDirWatch removeDir/addDir instead of stopDirScan/restartDirScan
aacid requested changes to this revision. This revision now requires changes to proceed. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D5856 To: dfaure, aacid Cc: #frameworks
D5975: breeze-icons: don't look for bash on Windows
aacid accepted this revision. This revision is now accepted and ready to land. REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabricator.kde.org/D5975 To: winterz, aacid Cc: aacid, #frameworks
D6002: Identify PIE binaries (application/x-sharedlib) as executable files
fvogt created this revision. Restricted Application added a project: Frameworks. REVISION SUMMARY x86_64 binaries compiled with PIE are just shared objects with the executable bit set. Without this patch, kio does not know that they can be executed as well, causing "kioclient5 exec" to ask for an application that can handle application/x-sharedlib. BUG: 350018 TEST PLAN Can run applications fine again. REPOSITORY R241 KIO BRANCH master REVISION DETAIL https://phabricator.kde.org/D6002 AFFECTED FILES src/widgets/krun.cpp src/widgets/krun.h To: fvogt, dfaure, aacid Cc: #frameworks
D5289: Import Find{Clang,LLVM} from KDevelop for Python bindings generation
skelly added a comment. My preference would be to use the ClangConfig.cmake instead of introducing these new files. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D5289 To: heikobecker, #frameworks, #build_system, skelly, kfunk Cc: rdieter, shaheed, kde-buildsystem, lbeltrame
Re: Problems with Python bindings in KF5
On 05/26/2017 10:21 PM, Albert Astals Cid wrote: > El dijous, 25 de maig de 2017, a les 1:02:58 CEST, Stephen Kelly va escriure: >> On 04/15/2017 10:53 PM, Luca Beltrame wrote: >>> I can't understand the error thrown by ki18n (when it does not build) or >>> I'd have attempted to fix it myself... >> Hi, sorry for my delayed response. >> >> Should we disable the ki18n bindings at this point? I'm fine with doing >> that until someone can reproduce the problem and can dig into the root >> cause. > Fixed, please approve. > > https://phabricator.kde.org/D5981 > > Cheers, > Albert Great, thanks!
Re: Compilation failure on Windows: kpeople
Am 27.05.2017 um 23:31 schrieb Ben Cooksley: > On Wed, May 17, 2017 at 7:33 AM, Ralf Habacker > wrote: >> Hi >>> When someone gets the chance, could they please look into the build >>> log at >>> https://build-sandbox.kde.org/job/Frameworks%20kpeople%20kf5-qt5%20WindowsQt5.7/4/console >>> to see why this Framework isn't building on Windows? >> from my recent experience with building kmymoney on Windows this may be >> caused by compiling code using a class located in a different shared >> library and therefore declared as dllimport, but later included in the >> same dll as static library. >> >> I dealed with this by undefining the related export macro as target >> definition [1]. Something like this >> >> +if( WIN32 ) >> + target_compile_definitions(reports PUBLIC KMM_MYMONEY_EXPORT=) >> +endif() > Sorry, i've only just now had time to take a look into this. > > As it turns out Pino fixed the build of kpeople in > https://cgit.kde.org/kpeople.git/commit/?id=dde883a272208ad4e3d01c223cd4ea59a0ae856d It is indeed the same reason and has been fixed in the same way by removing KPEOPLE_EXPORT. Ralf
D5856: Use KDirWatch removeDir/addDir instead of stopDirScan/restartDirScan
dfaure added a comment. I know what the problem is with this. Previously, if nobody was watching the directory, stopDirScan/restartDirScan would basically do nothing. Now, after running a kio job in that directory, KDirWatch will start watching it, for no purpose, due to the unconditional addDir(). I guess this needs checks with KDirWatch::contains() before removeDir to only call addDir on dirs that were actually watched in the first place... REPOSITORY R241 KIO BRANCH master REVISION DETAIL https://phabricator.kde.org/D5856 To: dfaure, aacid Cc: #frameworks
D5983: Check error status after every PolKitAuthority usage
skalinichev added inline comments. INLINE COMMENTS > aacid wrote in Polkit1Backend.cpp:220 > This seems a bit weird since we have done nothing with authority here, so how > would it have an error? Thinking a bit more about it, it can actually happen if enumerateActions call failed. REPOSITORY R283 KAuth REVISION DETAIL https://phabricator.kde.org/D5983 To: skalinichev Cc: aacid, #frameworks
D5983: Check error status after every PolKitAuthority usage
skalinichev updated this revision to Diff 14908. REPOSITORY R283 KAuth CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D5983?vs=14871&id=14908 REVISION DETAIL https://phabricator.kde.org/D5983 AFFECTED FILES src/backends/polkit-1/Polkit1Backend.cpp To: skalinichev Cc: aacid, #frameworks
