Re: Review Request 121885: Properly check for systray being available
On Jan. 6, 2015, 6: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 Martin Gräßlin wrote: I cannot mentally construct a dead lock situation. Could you please elaborate on what would dead lock? David Edmundson wrote: we're the kded, it's starting up. We load the keyboard layout switching daemon That tries creates a Status Notifier Item lib knotification queries if we're using the legacy tray, it's using the QPA so it's using this code all in the same process That makes a DBus call to org.kde.StatusNotifierWatcher and blocks for a reply StatusNotifierWatcher is another kded module, it can't respond because we're blocked awaiting a reply from ourselves. Martin Gräßlin wrote: lib knotification queries if we're using the legacy tray, it's using the QPA so it's using this code all in the same process is that really the case? This code here should only be run if sni is not available. It must be, otherwise this patch wouldn't be solving anything. I imagine we're run when then is no SNI host (i.e plasmashell) available. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121885/#review73291 --- 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
Build failed in Jenkins: kglobalaccel_stable_qt5 #9
See http://build.kde.org/job/kglobalaccel_stable_qt5/9/changes
Changes:
[scripty] SVN_SILENT made messages (.desktop file)
--
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_stable_qt5/ws/
Running Prebuild steps
[kglobalaccel_stable_qt5] $ /bin/sh -xe /tmp/hudson180530346058897.sh
+ /home/jenkins/scripts/setup-env.sh
Preparing to perform KDE Continuous Integration build
== Setting Up Sources
From git://anongit.kde.org/kglobalaccel
c5b52e0..f9b0095 master - origin/master
Branch jenkins set up to track remote branch master from origin.
== Cleaning Source Tree
HEAD is now at c5b52e0 Upgrade ECM and KF5 version requirements for 5.6.0
release.
Removing build/
Removing dotdata/
Removing local-inst/
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 f9b00950ccc1f9816fad994fe3d60a6ae0989474
(refs/heads/jenkins)
git config core.sparsecheckout # timeout=10
git checkout -f f9b00950ccc1f9816fad994fe3d60a6ae0989474
git rev-list ab489851ac2ef3134b14540164a8db693c8119ac # timeout=10
git tag -a -f -m Jenkins Build #9 jenkins-kglobalaccel_stable_qt5-9 #
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/hudson450121532702402375.sh
+ /home/jenkins/scripts/execute-job.sh
KDE Continuous Integration Build
== Building Project: kglobalaccel - Branch master
== Build Dependencies:
dogtail - Branch master
qt5 - Branch stable
extra-cmake-modules - 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
Re: Review Request 121885: Properly check for systray being available
On Jan. 6, 2015, 6: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 Martin Gräßlin wrote: I cannot mentally construct a dead lock situation. Could you please elaborate on what would dead lock? we're the kded, it's starting up. We load the keyboard layout switching daemon That tries creates a Status Notifier Item lib knotification queries if we're using the legacy tray, it's using the QPA so it's using this code all in the same process That makes a DBus call to org.kde.StatusNotifierWatcher and blocks for a reply StatusNotifierWatcher is another kded module, it can't respond because we're blocked awaiting a reply from ourselves. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121885/#review73291 --- 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: 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 Martin Gräßlin wrote: I cannot mentally construct a dead lock situation. Could you please elaborate on what would dead lock? David Edmundson wrote: we're the kded, it's starting up. We load the keyboard layout switching daemon That tries creates a Status Notifier Item lib knotification queries if we're using the legacy tray, it's using the QPA so it's using this code all in the same process That makes a DBus call to org.kde.StatusNotifierWatcher and blocks for a reply StatusNotifierWatcher is another kded module, it can't respond because we're blocked awaiting a reply from ourselves. lib knotification queries if we're using the legacy tray, it's using the QPA so it's using this code all in the same process is that really the case? This code here should only be run if sni is not available. - 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
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121885/#review73331 --- src/platformtheme/kdeplatformsystemtrayicon.cpp https://git.reviewboard.kde.org/r/121885/#comment51002 I don't see a deadlock here, unless StatusNotifierWatcher calls this method itself :-) Just one thing though: this creation of a QDBusInterface will auto-start the service (i.e. autoload the kded module), if it wasn't loaded already. Is this desired? (so yeah, if the constructor calls this method we have a problem ;) - David Faure 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: Some more projects in need of respecting KF5_INSTALL_TARGETS_DEFAULT_ARGS
On Wednesday 07 January 2015 08:38:27 Kevin Funk wrote: 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. I think you're fully correct. -- 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 121885: Properly check for systray being available
On Jan. 7, 2015, 8:10 a.m., David Faure wrote: src/platformtheme/kdeplatformsystemtrayicon.cpp, line 330 https://git.reviewboard.kde.org/r/121885/diff/1/?file=338653#file338653line330 I don't see a deadlock here, unless StatusNotifierWatcher calls this method itself :-) Just one thing though: this creation of a QDBusInterface will auto-start the service (i.e. autoload the kded module), if it wasn't loaded already. Is this desired? (so yeah, if the constructor calls this method we have a problem ;) Martin Klapetek wrote: I don't know the implementation in detail but I think that the watcher is watching for new SNHost and tells SNIs that new host is available, so that they could register with it. So I'd say it is desired that this service always runs. Can I ask how would this be autostarted? It doesn't install dbus service file (also the .desktop has autoload=true so it should be always present) Ah OK, what I said doesn't apply then. I was assuming it had a .service file installed (and/or I was confusing with a call to org.kde.kded5 modules/foo, which would autoload it). But if it's loaded from the start then ok, it's either present (when kded5 is running) or not (no kded5, or no SNW module installed). - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121885/#review73331 --- 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: Review Request 121895: Fix local issues in KIO build
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121895/ --- (Updated Jan. 7, 2015, 1:41 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks. Repository: kio Description --- Fix KIO build, otherwise I get the following error: ``` /home/kde-devel/frameworks/kio/src/kioexec/main.cpp:47:24: fatal error: KStartupInfo: No such file or directory``` ``` #include KStartupInfo``` Diffs - src/kioexec/CMakeLists.txt 1f08845 Diff: https://git.reviewboard.kde.org/r/121895/diff/ Testing --- Now it builds. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121895: Fix local issues in KIO build
On Jan. 7, 2015, 5:35 a.m., Jeremy Whiting wrote: Ship It! Fixes it here. - Jeremy --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121895/#review73359 --- On Jan. 7, 2015, 4:52 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121895/ --- (Updated Jan. 7, 2015, 4:52 a.m.) Review request for KDE Frameworks. Repository: kio Description --- Fix KIO build, otherwise I get the following error: ``` /home/kde-devel/frameworks/kio/src/kioexec/main.cpp:47:24: fatal error: KStartupInfo: No such file or directory``` ``` #include KStartupInfo``` Diffs - src/kioexec/CMakeLists.txt 1f08845 Diff: https://git.reviewboard.kde.org/r/121895/diff/ Testing --- Now it builds. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121895: Fix local issues in KIO build
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121895/#review73359 --- Ship it! Ship It! - Jeremy Whiting On Jan. 7, 2015, 4:52 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121895/ --- (Updated Jan. 7, 2015, 4:52 a.m.) Review request for KDE Frameworks. Repository: kio Description --- Fix KIO build, otherwise I get the following error: ``` /home/kde-devel/frameworks/kio/src/kioexec/main.cpp:47:24: fatal error: KStartupInfo: No such file or directory``` ``` #include KStartupInfo``` Diffs - src/kioexec/CMakeLists.txt 1f08845 Diff: https://git.reviewboard.kde.org/r/121895/diff/ Testing --- Now it builds. Thanks, Aleix Pol Gonzalez ___ 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. 7, 2015, 9:10 a.m., David Faure wrote: src/platformtheme/kdeplatformsystemtrayicon.cpp, line 330 https://git.reviewboard.kde.org/r/121885/diff/1/?file=338653#file338653line330 I don't see a deadlock here, unless StatusNotifierWatcher calls this method itself :-) Just one thing though: this creation of a QDBusInterface will auto-start the service (i.e. autoload the kded module), if it wasn't loaded already. Is this desired? (so yeah, if the constructor calls this method we have a problem ;) I don't know the implementation in detail but I think that the watcher is watching for new SNHost and tells SNIs that new host is available, so that they could register with it. So I'd say it is desired that this service always runs. Can I ask how would this be autostarted? It doesn't install dbus service file (also the .desktop has autoload=true so it should be always present) - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121885/#review73331 --- 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: Jenkins build became unstable: frameworkintegration_master_qt5 #150
On Thu, Jan 8, 2015 at 3:10 PM, Aleix Pol aleix...@kde.org wrote: On Tue, Jan 6, 2015 at 2:12 PM, David Faure fa...@kde.org wrote: On Tuesday 06 January 2015 10:56:46 KDE CI System wrote: See http://build.kde.org/job/frameworkintegration_master_qt5/150/changes FAIL! : KdePlatformTheme_UnitTest::testPlatformHints() Compared values are not the same Actual (m_qpa-themeHint(QPlatformTheme::CursorFlashTime).toInt()): 1000 Expected (1042) : 1042 Loc: [/srv/jenkins/workspace/frameworkintegration_master_qt5/autotests/kdeplatformtheme_unittest.cpp(120)] This seems to fail randomly (or more precisely, 50% of the time), independently from any code changes Any ideas? ... The failure can be predicted - it fails on slave4 but succeeds on slave1 and slave3. This is probably due to some circumstances which have led to a given configuration being left behind in ~/.qttest on slave1 and slave3. Someone might want to compare the three instances... Hi, I just looked into it and realized that if I rm -rf ~/.qttest, I can reproduce the failure 100% of the times, locally. I don't know if I'll have time to give it a go, I'm tired now =.=. HTH, Aleix Cheers, Ben ___ 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
Jenkins build is back to normal : kglobalaccel_stable_qt5 #10
See http://build.kde.org/job/kglobalaccel_stable_qt5/10/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121908: Fix unit test failure on machines with an empty ~/.qttest.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121908/ --- Review request for KDE Frameworks. Repository: frameworkintegration Description --- To execute the KdePlatformTheme and the KStyle unit tests, a local kdeglobals test file is required inside the Qt test folders. If the Qt test folders don't exist when the test executable starts, this copy will silently fail, causing further failures. Now, attempt to pre-create this folder before the copy. Also abort the test if the folder creation or the file copy fail, to help diagnose this issue in the future. Diffs - autotests/kdeplatformtheme_unittest.cpp cc17ef6e3f3c0db3c4597105b32320f0aeb52b0f autotests/kstyle_unittest.cpp e0e0046100acc195b1a3c36bbbe67e5861d7b7ee Diff: https://git.reviewboard.kde.org/r/121908/diff/ Testing --- Executing the test suite locally now succeeds. Thanks, Matthew Dawson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121903: Clean up how we deal with debug input
On Jan. 7, 2015, 7:18 p.m., David Edmundson wrote: startkde/startkde.cmake, line 12 https://git.reviewboard.kde.org/r/121903/diff/1/?file=338977#file338977line12 Order of evaluation: QtProject/qtlogging.ini setFilterRules() QT_LOGGING_CONF QT_LOGGING_RULES This will block all of the other methods from working. I don't think we can really do that. I'd prefer making a template qtlogging.ini if the file doesn't exist; as that still allows apps to override libs on/off if they prefer and allows people to set a logging_conf if they prefer. Aleix Pol Gonzalez wrote: I'm unsure how to do that. Ideas? Martin Klapetek wrote: Maybe just replace it with QLoggingCategory::setFilterRules(*.debug=false) in main? That still gives QT_LOGGING_CONF and QT_LOGGING_RULES to overwrite it. Aleix Pol Gonzalez wrote: That's what I wanted to do initially, but then with this we still only do it for plasmashell. I think it's good to have it elsewhere as well (thinking about kded mainly). can't we ship a kconf update script to modify qtlogging.ini? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121903/#review73399 --- On Jan. 7, 2015, 6:57 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121903/ --- (Updated Jan. 7, 2015, 6:57 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-workspace Description --- At the moment we are having a very ugly setting in plasmashell called --shut-up to filter output by default. This patch tries to address that by defining, in startkde, by default: ```QT_LOGGING_RULES=*.debug=false``` This filters out all q*Debug calls. It's better because it won't filter warnings so they can be read from .xsession-errors in case we need to debug things (at the moment it was useless because we were filtering everything) and it will also work for other processes, which can also come in handy. Developers might want to ```unset QT_LOGGING_RULES``` after this Diffs - shell/main.cpp 005f908 startkde/startkde.cmake 046543e Diff: https://git.reviewboard.kde.org/r/121903/diff/ Testing --- Log out + log in seemed to work after the changes, I'm unsure how to test, especially the startkde part. Should be quite straightforward though. Thanks, Aleix Pol Gonzalez ___ 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 Wednesday 07 January 2015 20:15:54 Christoph Cullmann wrote:
Hi,
I see why KDE_INSTALL_TARGETS_DEFAULT_ARGS and INSTALL_TARGETS_DEFAULT_ARGS
fail on Mac, typo:
# on the Mac support an extra install directory for application bundles
if(APPLE)
set(KDE_INSTALL_TARGETS_DEFAULT_ARGS ${INSTALL_TARGETS_DEFAULT_ARGS}
BUNDLE DESTINATION
${BUNDLE_INSTALL_DIR} ) set(KF5_INSTALL_TARGETS_DEFAULT_ARGS
${KF5_INSTALL_TARGETS_DEFAULT_ARGS} BUNDLE DESTINATION
${BUNDLE_INSTALL_DIR} ) endif(APPLE)
should be
# on the Mac support an extra install directory for application bundles
if(APPLE)
set(KDE_INSTALL_TARGETS_DEFAULT_ARGS
${KDE_INSTALL_TARGETS_DEFAULT_ARGS} BUNDLE DESTINATION
${BUNDLE_INSTALL_DIR} ) set(KF5_INSTALL_TARGETS_DEFAULT_ARGS
${KF5_INSTALL_TARGETS_DEFAULT_ARGS} BUNDLE DESTINATION
${BUNDLE_INSTALL_DIR} ) endif(APPLE)
Oops. Well spotted! That wouldn't be caught by the unit tests, either, which
just check the variable is set.
Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Compile KF5 into Docker
Hi! 2015-01-07 2:25 GMT+01:00 Mathieu Tarral mathieu.tar...@gmail.com: Hi David, Le 04/01/2015 13:55, David Gil Oliva a écrit : Hi! El dia 04/01/2015 12:39, Mathieu Tarral mathieu.tar...@gmail.com mailto:mathieu.tar...@gmail.com va escriure: Hi, as you know, building KF5 from source may not be an easy task, due to build dependencies which may or may not be available for your distro. That's why I started to compile KF5 into a Docker container. This way you can keep your main system clean, and avoid to install a lot of *-dev packages. I would like to share a set of Dockerfiles which will build an image with all the necessary build dependencies already installed. Instead of a set of Dockerfiles, each one for a different distro, which makes for a lot of duplicated code, could it be written in a single Dockerfile which checks the OS and does as approppriate for that OS? Actually, a Dockerfile is just describing how to build a specific system image. It just gives the necessary instructions like DO something, then DO something else, and It has not been designed to receive parameters, nor handle conditions. OK, I see. I was confused because I have a Chef background. Furthermore, you cannot merge these Dockerfile into one because their base systems are different (Ubuntu, Archlinux, OpenSuse, Fedora). The first instruction of each Dockerfile is FROM base_system and it cannot be configured. Having one Dockerfile per distro is nice, because you can see the differences between them, mostly for package naming and default packages installed. Now that I understand how Docker works, I see why there's one Dockerfile per distro. Another issue that I see is the Qt version. Can we rely on always having the needed version from the ubuntu-sdk-team repository? This repository provides packages for Qt5, in version 5.2.1 It's not the latest version of Qt5, so one day you might have kf5 build issues because of this. But I haven't found an up-to-date repo for Qt5 yet. Maybe we should download Qt5 from qt.io in this case ? I have found a Dockerfile [1] that can be tweaked to install any released version of Qt5 from qt.io. [1] https://registry.hub.docker.com/u/rabits/qt/dockerfile/ Regards, David Gil Regards. -- Mathieu Tarral ___ 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: Review Request 121903: Clean up how we deal with debug input
On Jan. 7, 2015, 6:18 p.m., David Edmundson wrote: startkde/startkde.cmake, line 12 https://git.reviewboard.kde.org/r/121903/diff/1/?file=338977#file338977line12 Order of evaluation: QtProject/qtlogging.ini setFilterRules() QT_LOGGING_CONF QT_LOGGING_RULES This will block all of the other methods from working. I don't think we can really do that. I'd prefer making a template qtlogging.ini if the file doesn't exist; as that still allows apps to override libs on/off if they prefer and allows people to set a logging_conf if they prefer. Aleix Pol Gonzalez wrote: I'm unsure how to do that. Ideas? Martin Klapetek wrote: Maybe just replace it with QLoggingCategory::setFilterRules(*.debug=false) in main? That still gives QT_LOGGING_CONF and QT_LOGGING_RULES to overwrite it. That's what I wanted to do initially, but then with this we still only do it for plasmashell. I think it's good to have it elsewhere as well (thinking about kded mainly). - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121903/#review73399 --- On Jan. 7, 2015, 5:57 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121903/ --- (Updated Jan. 7, 2015, 5:57 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-workspace Description --- At the moment we are having a very ugly setting in plasmashell called --shut-up to filter output by default. This patch tries to address that by defining, in startkde, by default: ```QT_LOGGING_RULES=*.debug=false``` This filters out all q*Debug calls. It's better because it won't filter warnings so they can be read from .xsession-errors in case we need to debug things (at the moment it was useless because we were filtering everything) and it will also work for other processes, which can also come in handy. Developers might want to ```unset QT_LOGGING_RULES``` after this Diffs - shell/main.cpp 005f908 startkde/startkde.cmake 046543e Diff: https://git.reviewboard.kde.org/r/121903/diff/ Testing --- Log out + log in seemed to work after the changes, I'm unsure how to test, especially the startkde part. Should be quite straightforward though. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Compile KF5 into Docker
Hi David, Le 04/01/2015 13:55, David Gil Oliva a écrit : Hi! El dia 04/01/2015 12:39, Mathieu Tarral mathieu.tar...@gmail.com mailto:mathieu.tar...@gmail.com va escriure: Hi, as you know, building KF5 from source may not be an easy task, due to build dependencies which may or may not be available for your distro. That's why I started to compile KF5 into a Docker container. This way you can keep your main system clean, and avoid to install a lot of *-dev packages. I would like to share a set of Dockerfiles which will build an image with all the necessary build dependencies already installed. Instead of a set of Dockerfiles, each one for a different distro, which makes for a lot of duplicated code, could it be written in a single Dockerfile which checks the OS and does as approppriate for that OS? Actually, a Dockerfile is just describing how to build a specific system image. It just gives the necessary instructions like DO something, then DO something else, and It has not been designed to receive parameters, nor handle conditions. Furthermore, you cannot merge these Dockerfile into one because their base systems are different (Ubuntu, Archlinux, OpenSuse, Fedora). The first instruction of each Dockerfile is FROM base_system and it cannot be configured. Having one Dockerfile per distro is nice, because you can see the differences between them, mostly for package naming and default packages installed. Another issue that I see is the Qt version. Can we rely on always having the needed version from the ubuntu-sdk-team repository? This repository provides packages for Qt5, in version 5.2.1 It's not the latest version of Qt5, so one day you might have kf5 build issues because of this. But I haven't found an up-to-date repo for Qt5 yet. Maybe we should download Qt5 from qt.io in this case ? Regards. -- Mathieu Tarral ___ 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/ --- (Updated Jan. 7, 2015, 9:10 p.m.) Review request for KDE Frameworks. Changes --- Get list of registered service names - check if there's org.kde.StatusNotifierHost* 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 (updated) - 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: KF 5.6 changelog
* Depend on libgit2 0.21.0 rather than unreleased 0.22.0 This seems not to be the case, top changelog item in ktexteditor currently is Depend on libgit2 v0.22.0 (older version is broken) Jonathan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121907: Small code review
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121907/ --- Review request for KDE Frameworks. Repository: frameworkintegration Description --- Make sure the methods that access the hash are const. This way we make sure we don't create weird new hash members and we don't need to do a double look-up for the value. Diffs - src/platformtheme/khintssettings.h 1d9c1d2 Diff: https://git.reviewboard.kde.org/r/121907/diff/ Testing --- Test still passes, if I don't remove teh ~/.qt-test as discussed in the kde-frameworks list. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF 5.6 changelog
On Wednesday 07 January 2015 15:01:39 Jonathan Riddell wrote: * Depend on libgit2 0.21.0 rather than unreleased 0.22.0 This seems not to be the case, top changelog item in ktexteditor currently is Depend on libgit2 v0.22.0 (older version is broken) Yes that commit to depend on 0.21.0 was a mistake. /Kåre ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121903: Clean up how we deal with debug input
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121903/#review73399 --- +1 to removing the custom handler startkde/startkde.cmake https://git.reviewboard.kde.org/r/121903/#comment51110 Order of evaluation: QtProject/qtlogging.ini setFilterRules() QT_LOGGING_CONF QT_LOGGING_RULES This will block all of the other methods from working. I don't think we can really do that. I'd prefer making a template qtlogging.ini if the file doesn't exist; as that still allows apps to override libs on/off if they prefer and allows people to set a logging_conf if they prefer. - David Edmundson On Jan. 7, 2015, 5:57 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121903/ --- (Updated Jan. 7, 2015, 5:57 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-workspace Description --- At the moment we are having a very ugly setting in plasmashell called --shut-up to filter output by default. This patch tries to address that by defining, in startkde, by default: ```QT_LOGGING_RULES=*.debug=false``` This filters out all q*Debug calls. It's better because it won't filter warnings so they can be read from .xsession-errors in case we need to debug things (at the moment it was useless because we were filtering everything) and it will also work for other processes, which can also come in handy. Developers might want to ```unset QT_LOGGING_RULES``` after this Diffs - shell/main.cpp 005f908 startkde/startkde.cmake 046543e Diff: https://git.reviewboard.kde.org/r/121903/diff/ Testing --- Log out + log in seemed to work after the changes, I'm unsure how to test, especially the startkde part. Should be quite straightforward though. Thanks, Aleix Pol Gonzalez ___ 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 : kdelibs_stable #1253
See http://build.kde.org/job/kdelibs_stable/1253/ ___ 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
I hit the same issues reported by Marko here on OS X also, and have no KDE_INSTALL_DIRS_NO_DEPRECATED set either. Maybe the logic in ecm is broken somehow? On Wed, Jan 7, 2015 at 11:48 AM, Alex Merry alex.me...@kde.org wrote: On Tuesday 06 January 2015 23:55:48 Marko Käning wrote: P.P.S.: I realised by now that there are no changes on the production branch, which probably means that there was some change in ECM or wherever provoking these issues... I'm somewhat puzzled, as INSTALL_TARGET_DEFAULT_ARGS should still be set (to the same value as KDE_INSTALL_TARGET_DEFAULT_ARGS) unless you have set KDE_INSTALL_DIRS_NO_DEPRECATED to some TRUE-ish value. If not, that's a bug. Alex ___ 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: Review Request 121903: Clean up how we deal with debug input
On Jan. 7, 2015, 6:18 p.m., David Edmundson wrote: startkde/startkde.cmake, line 12 https://git.reviewboard.kde.org/r/121903/diff/1/?file=338977#file338977line12 Order of evaluation: QtProject/qtlogging.ini setFilterRules() QT_LOGGING_CONF QT_LOGGING_RULES This will block all of the other methods from working. I don't think we can really do that. I'd prefer making a template qtlogging.ini if the file doesn't exist; as that still allows apps to override libs on/off if they prefer and allows people to set a logging_conf if they prefer. I'm unsure how to do that. Ideas? - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121903/#review73399 --- On Jan. 7, 2015, 5:57 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121903/ --- (Updated Jan. 7, 2015, 5:57 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-workspace Description --- At the moment we are having a very ugly setting in plasmashell called --shut-up to filter output by default. This patch tries to address that by defining, in startkde, by default: ```QT_LOGGING_RULES=*.debug=false``` This filters out all q*Debug calls. It's better because it won't filter warnings so they can be read from .xsession-errors in case we need to debug things (at the moment it was useless because we were filtering everything) and it will also work for other processes, which can also come in handy. Developers might want to ```unset QT_LOGGING_RULES``` after this Diffs - shell/main.cpp 005f908 startkde/startkde.cmake 046543e Diff: https://git.reviewboard.kde.org/r/121903/diff/ Testing --- Log out + log in seemed to work after the changes, I'm unsure how to test, especially the startkde part. Should be quite straightforward though. Thanks, Aleix Pol Gonzalez ___ 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
Hi Alex, Hi Ben, Happy New Year, for a start! :) On 07 Jan 2015, at 19:48 , Alex Merry alex.me...@kde.org wrote: On Tuesday 06 January 2015 23:55:48 Marko Käning wrote: P.P.S.: I realised by now that there are no changes on the production branch, which probably means that there was some change in ECM or wherever provoking these issues... I'm somewhat puzzled, as INSTALL_TARGET_DEFAULT_ARGS should still be set (to the same value as KDE_INSTALL_TARGET_DEFAULT_ARGS) unless you have set KDE_INSTALL_DIRS_NO_DEPRECATED to some TRUE-ish value. If not, that's a bug. Hmmm... Well, off-list I already had contacted Ben because of this issue. See this: Begin forwarded message: On 07 Jan 2015, at 09:12 , David Faure fa...@kde.org wrote: KDEInstallDirs.cmake also has a KDE_INSTALL_TARGETS_DEFAULT_ARGS, which seems more appropriate. I think you're fully correct. Thus I tried KDE_INSTALL_TARGETS_DEFAULT_ARGS for the non-KF5 “systemsettings” project but it lead to the same error as the original INSTALL_TARGETS_DEFAULT_ARGS variable in my initial post. Is this perhaps specific to the CI system? So, I really wonder what’s going on here, as it doesn’t hit all projects! kstars fails, but marble - for instance - still builds fine without the need to mess with these vars! I can't find KDE_INSTALL_DIRS_NO_DEPRECATED in CMakeCache.txt of kstars at all, so I assume that it is not set. Does this mean it IS a bug for kstars and all the other projects after all? Marko ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Some more projects in need of respecting KF5_INSTALL_TARGETS_DEFAULT_ARGS
Hi,
I see why KDE_INSTALL_TARGETS_DEFAULT_ARGS and INSTALL_TARGETS_DEFAULT_ARGS
fail on Mac,
typo:
# on the Mac support an extra install directory for application bundles
if(APPLE)
set(KDE_INSTALL_TARGETS_DEFAULT_ARGS ${INSTALL_TARGETS_DEFAULT_ARGS}
BUNDLE DESTINATION
${BUNDLE_INSTALL_DIR} )
set(KF5_INSTALL_TARGETS_DEFAULT_ARGS ${KF5_INSTALL_TARGETS_DEFAULT_ARGS}
BUNDLE DESTINATION
${BUNDLE_INSTALL_DIR} )
endif(APPLE)
should be
# on the Mac support an extra install directory for application bundles
if(APPLE)
set(KDE_INSTALL_TARGETS_DEFAULT_ARGS ${KDE_INSTALL_TARGETS_DEFAULT_ARGS}
BUNDLE DESTINATION
${BUNDLE_INSTALL_DIR} )
set(KF5_INSTALL_TARGETS_DEFAULT_ARGS ${KF5_INSTALL_TARGETS_DEFAULT_ARGS}
BUNDLE DESTINATION
${BUNDLE_INSTALL_DIR} )
endif(APPLE)
will patch that ;=)
- Ursprüngliche Mail -
Hi Alex,
Hi Ben,
Happy New Year, for a start! :)
On 07 Jan 2015, at 19:48 , Alex Merry alex.me...@kde.org wrote:
On Tuesday 06 January 2015 23:55:48 Marko Käning wrote:
P.P.S.: I realised by now that there are no changes on the production
branch, which probably means that there was some change in ECM or wherever
provoking these issues...
I'm somewhat puzzled, as INSTALL_TARGET_DEFAULT_ARGS should still be set
(to
the same value as KDE_INSTALL_TARGET_DEFAULT_ARGS) unless you have set
KDE_INSTALL_DIRS_NO_DEPRECATED to some TRUE-ish value. If not, that's a
bug.
Hmmm...
Well, off-list I already had contacted Ben because of this issue. See this:
Begin forwarded message:
On 07 Jan 2015, at 09:12 , David Faure fa...@kde.org wrote:
KDEInstallDirs.cmake also has a KDE_INSTALL_TARGETS_DEFAULT_ARGS, which
seems more appropriate.
I think you're fully correct.
Thus I tried KDE_INSTALL_TARGETS_DEFAULT_ARGS for the non-KF5
“systemsettings”
project but it lead to the same error as the original
INSTALL_TARGETS_DEFAULT_ARGS
variable in my initial post.
Is this perhaps specific to the CI system?
So, I really wonder what’s going on here, as it doesn’t hit all projects!
kstars fails,
but marble - for instance - still builds fine without the need to mess with
these vars!
I can't find KDE_INSTALL_DIRS_NO_DEPRECATED in CMakeCache.txt of kstars at
all, so I assume
that it is not set.
Does this mean it IS a bug for kstars and all the other projects after
all?
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
--
- 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: Some more projects in need of respecting KF5_INSTALL_TARGETS_DEFAULT_ARGS
On Tuesday 06 January 2015 23:55:48 Marko Käning wrote: P.P.S.: I realised by now that there are no changes on the production branch, which probably means that there was some change in ECM or wherever provoking these issues... I'm somewhat puzzled, as INSTALL_TARGET_DEFAULT_ARGS should still be set (to the same value as KDE_INSTALL_TARGET_DEFAULT_ARGS) unless you have set KDE_INSTALL_DIRS_NO_DEPRECATED to some TRUE-ish value. If not, that's a bug. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121903: Clean up how we deal with debug input
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121903/ --- Review request for KDE Frameworks and Plasma. Repository: plasma-workspace Description --- At the moment we are having a very ugly setting in plasmashell called --shut-up to filter output by default. This patch tries to address that by defining, in startkde, by default: ```QT_LOGGING_RULES=*.debug=false``` This filters out all q*Debug calls. It's better because it won't filter warnings so they can be read from .xsession-errors in case we need to debug things (at the moment it was useless because we were filtering everything) and it will also work for other processes, which can also come in handy. Developers might want to ```unset QT_LOGGING_RULES``` after this Diffs - shell/main.cpp 005f908 startkde/startkde.cmake 046543e Diff: https://git.reviewboard.kde.org/r/121903/diff/ Testing --- Log out + log in seemed to work after the changes, I'm unsure how to test, especially the startkde part. Should be quite straightforward though. Thanks, Aleix Pol Gonzalez ___ 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 : kio_master_qt5 #512
See http://build.kde.org/job/kio_master_qt5/512/changes ___ 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 Wednesday 07 January 2015 08:38:27 Kevin Funk wrote: 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. Nope, any variable from KDEInstallDirs.cmake with KF5 in the name is only for the use of Frameworks. They all have a non-KF5 equivalent - in this case, KDE_INSTALL_TARGETS_DEFAULT_ARGS, as you noticed. I think KF5_INSTALL_TARGETS_DEFAULT_ARGS should actually be KDE_INSTALL_TARGETS_DEFAULT_ARGS_KF5 for consistency with other variables, now I look again. Alex ___ 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 07 Jan 2015, at 20:15 , Christoph Cullmann cullm...@absint.com wrote: will patch that ;=) Thanks for patching this so promptly! :-) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121903: Clean up how we deal with debug input
On Jan. 7, 2015, 7:18 p.m., David Edmundson wrote: startkde/startkde.cmake, line 12 https://git.reviewboard.kde.org/r/121903/diff/1/?file=338977#file338977line12 Order of evaluation: QtProject/qtlogging.ini setFilterRules() QT_LOGGING_CONF QT_LOGGING_RULES This will block all of the other methods from working. I don't think we can really do that. I'd prefer making a template qtlogging.ini if the file doesn't exist; as that still allows apps to override libs on/off if they prefer and allows people to set a logging_conf if they prefer. Aleix Pol Gonzalez wrote: I'm unsure how to do that. Ideas? Maybe just replace it with QLoggingCategory::setFilterRules(*.debug=false) in main? That still gives QT_LOGGING_CONF and QT_LOGGING_RULES to overwrite it. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121903/#review73399 --- On Jan. 7, 2015, 6:57 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121903/ --- (Updated Jan. 7, 2015, 6:57 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-workspace Description --- At the moment we are having a very ugly setting in plasmashell called --shut-up to filter output by default. This patch tries to address that by defining, in startkde, by default: ```QT_LOGGING_RULES=*.debug=false``` This filters out all q*Debug calls. It's better because it won't filter warnings so they can be read from .xsession-errors in case we need to debug things (at the moment it was useless because we were filtering everything) and it will also work for other processes, which can also come in handy. Developers might want to ```unset QT_LOGGING_RULES``` after this Diffs - shell/main.cpp 005f908 startkde/startkde.cmake 046543e Diff: https://git.reviewboard.kde.org/r/121903/diff/ Testing --- Log out + log in seemed to work after the changes, I'm unsure how to test, especially the startkde part. Should be quite straightforward though. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121895: Fix local issues in KIO build
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121895/ --- Review request for KDE Frameworks. Repository: kio Description --- Fix KIO build, otherwise I get the following error: ``` /home/kde-devel/frameworks/kio/src/kioexec/main.cpp:47:24: fatal error: KStartupInfo: No such file or directory``` ``` #include KStartupInfo``` Diffs - src/kioexec/CMakeLists.txt 1f08845 Diff: https://git.reviewboard.kde.org/r/121895/diff/ Testing --- Now it builds. Thanks, Aleix Pol Gonzalez ___ 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 Martin Gräßlin wrote: I cannot mentally construct a dead lock situation. Could you please elaborate on what would dead lock? David Edmundson wrote: we're the kded, it's starting up. We load the keyboard layout switching daemon That tries creates a Status Notifier Item lib knotification queries if we're using the legacy tray, it's using the QPA so it's using this code all in the same process That makes a DBus call to org.kde.StatusNotifierWatcher and blocks for a reply StatusNotifierWatcher is another kded module, it can't respond because we're blocked awaiting a reply from ourselves. Martin Gräßlin wrote: lib knotification queries if we're using the legacy tray, it's using the QPA so it's using this code all in the same process is that really the case? This code here should only be run if sni is not available. David Edmundson wrote: It must be, otherwise this patch wouldn't be solving anything. I imagine we're run when then is no SNI host (i.e plasmashell) available. Ah right, I just realized I have no SNIs from kded, so I never hit the actual block, but on the initial startup after login, this might indeed be a problem. So the only other option I see then is to retrieve a list of registered names and contains(org.kde.StatusNotifierHost-*); - 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: Baloo Framework - License Exception
Hello people It seems that some people really do not want Baloo to become a framework as long as it is effectively GPL. We might want to think about not restricting ourselves in this way. If we didn't have plans to move away from Xapian it would effectively become a core library that a lot of applications use that has its own independent versioning and release schedule. For now, Baloo will continue to be released part of Plasma. However, we will be spoofing our version number to 5.6. So, everyone is will continue using it as if it were a framework (the finder, library names, etc), but it will not be released with frameworks. -- Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
