Change in kio[master]: KRun: make klauncher dependency optional.
David Faure has uploaded a new change for review.
https://gerrit.vesnicky.cesnet.cz/r/248
Change subject: KRun: make klauncher dependency optional.
..
KRun: make klauncher dependency optional.
If klauncher can't be started, then start the service by hand;
we already had a code path for that for other cases.
Change-Id: I058221aaeb8a6b3e583a16e5b377280a5660ebc6
---
M src/widgets/krun.cpp
1 file changed, 14 insertions(+), 1 deletion(-)
git pull ssh://gerrit.vesnicky.cesnet.cz:29418/kio refs/changes/48/248/1
diff --git a/src/widgets/krun.cpp b/src/widgets/krun.cpp
index 8f77901..89ae26d 100644
--- a/src/widgets/krun.cpp
+++ b/src/widgets/krun.cpp
@@ -40,6 +40,8 @@
#include QDesktopWidget
#include qmimedatabase.h
#include QDebug
+#include QDBusConnection
+#include QDBusConnectionInterface
#include kiconloader.h
#include kjobuidelegate.h
@@ -709,7 +711,18 @@
}
}
-if (tempFiles || _service.entryPath().isEmpty() ||
!suggestedFileName.isEmpty()) {
+bool useKToolInvocation = !(tempFiles || _service.entryPath().isEmpty() ||
!suggestedFileName.isEmpty());
+
+if (useKToolInvocation) {
+// Is klauncher installed? Let's try to start it, if it fails, then we
won't use it.
+KToolInvocation::ensureKdeinitRunning();
+QDBusConnectionInterface *dbusDaemon =
QDBusConnection::sessionBus().interface();
+if
(!dbusDaemon-isServiceRegistered(QString::fromLatin1(org.kde.klauncher5))) {
+useKToolInvocation = false;
+}
+}
+
+if (!useKToolInvocation) {
return runTempService(_service, _urls, window, tempFiles,
suggestedFileName, asn);
}
--
To view, visit https://gerrit.vesnicky.cesnet.cz/r/248
To unsubscribe, visit https://gerrit.vesnicky.cesnet.cz/r/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: I058221aaeb8a6b3e583a16e5b377280a5660ebc6
Gerrit-PatchSet: 1
Gerrit-Project: kio
Gerrit-Branch: master
Gerrit-Owner: David Faure fa...@kde.org
Gerrit-Reviewer: Sysadmin Testing Account n...@kde.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121575: FindEpoxy.cmake
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121575/ --- Review request for KDE Frameworks, kwin and Martin Gräßlin. Repository: extra-cmake-modules Description --- Both Plasma and KWin now depend from the epoxy opengl library. So would be better to have the necessary cmake stuff in ecm instead of having it copied in the two repos. This is the file coming from KWin Diffs - find-modules/Findepoxy.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121575/diff/ Testing --- Thanks, Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
qca-qt5 package name
alohas. recently the QCA maintainer and I got into a discussion [1] whether a qca-qt5 library should be a different config inside the same cmake package or an independent one (detailed discussion in the longest comment thread of the review). find_package(Qca NAMES Qca-qt5 Qca-QT5 Qca-5 Qca REQUIRES) or find_package(Qca-qt5) former is very much in line with the maintainer's expectation of how qca is supposed to have any odd suffix supplied by the distro [2] that would eventually disappear, whereas my thinking in latter is that if distros start shipping a suffixed version it is here to stay and really should not be considered a configuration within the regular QCA package. any thoughts on whether one is more desirable than the other? I am not quite sure what one would generally consider proper here. [1] https://git.reviewboard.kde.org/r/121323/ [2] https://git.reviewboard.kde.org/r/121168/ HS ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Baloo Framework - License Exception
On Mon, Dec 15, 2014 at 9:27 AM, Martin Gräßlin mgraess...@kde.org wrote: I think Jonathan should respond to it. Your argumentation makes sense to me, but the question is whether Baloo is currently derived work of Xapian or not. If there is baloo internal an abstraction allowing to easily swap out Xapian by something different I would say it's not derived work. But if Xapian is deeply wired into Baloo I would say it's derived work. It's not deeply wired but it is a very important component. We can easily replace Xapian if we want to / find something nicer. -- Vishesh Handa ___ 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
--- 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. Changes --- Added more people. 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 success . 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: Re: Baloo Framework - License Exception
On Mon, Dec 15, 2014 at 9:27 AM, Martin Gräßlin mgraess...@kde.org wrote: I think Jonathan should respond to it. Your argumentation makes sense to me, but the question is whether Baloo is currently derived work of Xapian or not. If there is baloo internal an abstraction allowing to easily swap out Xapian by something different I would say it's not derived work. But if Xapian is deeply wired into Baloo I would say it's derived work. I've thought about this some more. Here is the current situation - * We have the baloo_file executable which has a lot of Xapian code, which is not trivial to replace. * We have the Baloo library, which does the searching through Xapian. This part is very very well abstracted out. In fact it started out allowing other search providers. However, Johnathon tells me that just the fact that the Baloo library is linking against Xapian is enough to make it GPL. -- Vishesh Handa ___ 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 Wednesday 17 December 2014 12:58:27 Vishesh Handa wrote: On Mon, Dec 15, 2014 at 9:27 AM, Martin Gräßlin mgraess...@kde.org wrote: I think Jonathan should respond to it. Your argumentation makes sense to me, but the question is whether Baloo is currently derived work of Xapian or not. If there is baloo internal an abstraction allowing to easily swap out Xapian by something different I would say it's not derived work. But if Xapian is deeply wired into Baloo I would say it's derived work. I've thought about this some more. Here is the current situation - * We have the baloo_file executable which has a lot of Xapian code, which is not trivial to replace. * We have the Baloo library, which does the searching through Xapian. This part is very very well abstracted out. In fact it started out allowing other search providers. However, Johnathon tells me that just the fact that the Baloo library is linking against Xapian is enough to make it GPL. May I ask the question why Baloo should become a framework in the first place? On Windows or Mac, people won't use it anyways, no? Or is it required there for e.g. searches in KMail? Bye -- 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: qca-qt5 package name
On 17/12/14 22:47, Harald Sitter wrote: alohas. recently the QCA maintainer and I got into a discussion [1] whether a qca-qt5 library should be a different config inside the same cmake package or an independent one (detailed discussion in the longest comment thread of the review). find_package(Qca NAMES Qca-qt5 Qca-QT5 Qca-5 Qca REQUIRES) or find_package(Qca-qt5) former is very much in line with the maintainer's expectation of how qca is supposed to have any odd suffix supplied by the distro [2] that would eventually disappear, whereas my thinking in latter is that if distros start shipping a suffixed version it is here to stay and really should not be considered a configuration within the regular QCA package. any thoughts on whether one is more desirable than the other? I am not quite sure what one would generally consider proper here. [1] https://git.reviewboard.kde.org/r/121323/ [2] https://git.reviewboard.kde.org/r/121168/ HS The latter is consistent with many other libraries (eg. phonon) and is the best solution from a practical point of view. The maintainer's solution makes it very difficult for downstream as it requires every single consuming package in mixed Qt4/Qt5 system to be patched (as well as other reasons I won't rehash here). I believe a good compromise is to replace QCA_SUFFIX=whatever with some new option like QCA_QT5_SUFFIX which sets a static suffix. A common suffix will improve compatibility between distributions as well as make it easier for consuming applications that support both Qt4/Qt5 build. Plus, it's still in the spirit of the maintainer's preferred solution (prefix-based, optional, easily removed in the future if/when Qt4 support is dropped). ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121581: Plotter in kdeclarative
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121581/ --- Review request for KDE Frameworks and Plasma. Repository: kdeclarative Description --- This is an alternative, mutually exclusive to https://gerrit.vesnicky.cesnet.cz/r/#/c/244 and dependent from https://git.reviewboard.kde.org/r/121575/ since the plotter component doesn't depend from libplasma, it may be useful to have it outside of libplasma, so any applciation that wants it may use it. Any opinion whether this should go here or in libplasma is welcome. Diffs - CMakeLists.txt 233ccce src/qmlcontrols/kquickcontrols/CMakeLists.txt eef0420 src/qmlcontrols/kquickcontrols/kquickcontrolsplugin.h PRE-CREATION src/qmlcontrols/kquickcontrols/kquickcontrolsplugin.cpp PRE-CREATION src/qmlcontrols/kquickcontrols/plotter.h PRE-CREATION src/qmlcontrols/kquickcontrols/plotter.cpp PRE-CREATION src/qmlcontrols/kquickcontrols/qmldir 31d8b14 Diff: https://git.reviewboard.kde.org/r/121581/diff/ Testing --- Thanks, Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : kservice_stable_qt5 #14
See http://build.kde.org/job/kservice_stable_qt5/14/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kwindowsystem_stable_qt5 » All,LINBUILDER #4
See http://build.kde.org/job/kwindowsystem_stable_qt5/Variation=All,label=LINBUILDER/4/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kwindowsystem_master_qt5 » All,LINBUILDER #123
See http://build.kde.org/job/kwindowsystem_master_qt5/Variation=All,label=LINBUILDER/123/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Monday 15 of December 2014 13:55:04 Martin Gräßlin wrote: On Friday 12 December 2014 12:38:20 Martin Klapetek wrote: On Fri, Oct 3, 2014 at 1:16 PM, Alex Merry alex.me...@kde.org wrote: On 2014-09-17 10:47, Martin Gräßlin wrote: Hi all, I just prepared moving kglobalacceld from plasma-workspace into kglobalaccel. You can find the code in my personal clone of kglobalaccel at [1] in branch master. The following steps were performed so far: * filter-branch on plasma-workspace to just have all kglobalacceld commits * move all files to src/runtime * merge code in kglobalaccel * adjust CMakeLists to find additionally needed dependencies for runtime part * raise tier to 3 in metadata Please have a look at it, whether I have forgotten something or should do something differently. Git history looks sensible. Things I'm unsure about is: * how does the raise of framework needs to be reflected in cmake It doesn't. * how do one expose the different licences? A License section in README.md? * is it needed to export the new dependencies? After all they are just runtime deps? No, because they are not needed at compile-time by software that uses KGlobalAccel. Do we want an option to disable compilation of the runtime? Is the runtime needed on all platforms? I seem to remember some discussion suggesting it either wasn't or needn't be, but I can't remember the details. Alex Quoting from IRC just now: jleclanche we'd like to use it [kglobalaccel] in lxqt, but the framework is useless without its client atm Martin - what's the status of this? Is any help needed? Can we get this into Frameworks 5.6? Given the basically non-existing feedback on the thread (modulo Alex's reply) I would assume that everything is fine and we can just move the code. If you want to take care of it, I would certainly appreciate this. Hi, i've checked your clone, and what new requirements will that bring, and if the CMakeLists there are accurate, that will create a problem. We will have a dependency circle between kglobalaccel, kinit, kio and kxmlgui. Cheers, Hrvoje Cheers Martin 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: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Wednesday 17 of December 2014 21:11:04 šumski wrote: On Monday 15 of December 2014 13:55:04 Martin Gräßlin wrote: On Friday 12 December 2014 12:38:20 Martin Klapetek wrote: On Fri, Oct 3, 2014 at 1:16 PM, Alex Merry alex.me...@kde.org wrote: On 2014-09-17 10:47, Martin Gräßlin wrote: Hi all, I just prepared moving kglobalacceld from plasma-workspace into kglobalaccel. You can find the code in my personal clone of kglobalaccel at [1] in branch master. The following steps were performed so far: * filter-branch on plasma-workspace to just have all kglobalacceld commits * move all files to src/runtime * merge code in kglobalaccel * adjust CMakeLists to find additionally needed dependencies for runtime part * raise tier to 3 in metadata Please have a look at it, whether I have forgotten something or should do something differently. Git history looks sensible. Things I'm unsure about is: * how does the raise of framework needs to be reflected in cmake It doesn't. * how do one expose the different licences? A License section in README.md? * is it needed to export the new dependencies? After all they are just runtime deps? No, because they are not needed at compile-time by software that uses KGlobalAccel. Do we want an option to disable compilation of the runtime? Is the runtime needed on all platforms? I seem to remember some discussion suggesting it either wasn't or needn't be, but I can't remember the details. Alex Quoting from IRC just now: jleclanche we'd like to use it [kglobalaccel] in lxqt, but the framework is useless without its client atm Martin - what's the status of this? Is any help needed? Can we get this into Frameworks 5.6? Given the basically non-existing feedback on the thread (modulo Alex's reply) I would assume that everything is fine and we can just move the code. If you want to take care of it, I would certainly appreciate this. Hi, i've checked your clone, and what new requirements will that bring, and if the CMakeLists there are accurate, that will create a problem. We will have a dependency circle between kglobalaccel, kinit, kio and kxmlgui. Another issue is the translation domain. It collides with kde-runtime's kglobalaccel translations, which would break KF5 co-installability... Cheers, Hrvoje Cheers Martin 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 121581: Plotter in kdeclarative
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121581/#review72219 --- I think it's a useful component that can end up being really useful elsewhere, therefore I think kdeclarative it's a good place to be. I'd say it would be better to have it in a separate qml module. IIRC, the idea of kquickcontrols was to provide components that extend QtQuick Controls, rather than such generic components (see the KeySequenceButton). In fact, I would expect that to use something like that, I'd have to import org.kde.plotter or import QtQuick.Plotter rather than something else that happens to provide a Plotter class. Also I miss some more development over it, to get started some unit tests would be perfect, or at least an example application we can look at to test small things or just learn how to use it. Last, have you looked at the plotting component developed for ktouch? Is it comparable in any way? I'd love to duplicate there. https://projects.kde.org/projects/kde/kdeedu/kqtquickcharts/repository Thanks! - Aleix Pol Gonzalez On Dec. 17, 2014, 4:20 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121581/ --- (Updated Dec. 17, 2014, 4:20 p.m.) Review request for KDE Frameworks and Plasma. Repository: kdeclarative Description --- This is an alternative, mutually exclusive to https://gerrit.vesnicky.cesnet.cz/r/#/c/244 and dependent from https://git.reviewboard.kde.org/r/121575/ since the plotter component doesn't depend from libplasma, it may be useful to have it outside of libplasma, so any applciation that wants it may use it. Any opinion whether this should go here or in libplasma is welcome. Diffs - CMakeLists.txt 233ccce src/qmlcontrols/kquickcontrols/CMakeLists.txt eef0420 src/qmlcontrols/kquickcontrols/kquickcontrolsplugin.h PRE-CREATION src/qmlcontrols/kquickcontrols/kquickcontrolsplugin.cpp PRE-CREATION src/qmlcontrols/kquickcontrols/plotter.h PRE-CREATION src/qmlcontrols/kquickcontrols/plotter.cpp PRE-CREATION src/qmlcontrols/kquickcontrols/qmldir 31d8b14 Diff: https://git.reviewboard.kde.org/r/121581/diff/ Testing --- Thanks, Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Thinking together
Hello folks, I've been reading the very intense discussion about the future of our infrastructure, and the passion is good to see. I hope all of the participants will keep in mind that we are thinking together about the future of KDE, not supporting products or positions. Already I've heard one participant say that he will no longer speak up after being made to feel like a nobody, and another who was very angry after being faced with an intractable position. Remember that this discussion is taking place in multiple places, not just here on the list, but also in IRC channels, publicly and privately. So please sum up what has been discussed elsewhere before taking the next step in your thinking here. Always, no matter where, we need to take time to breathe, to think, to reflect, and not just *convince*. We all have the best interests of the larger community at heart. Valorie -- http://about.me/valoriez
Re: Review Request 120761: Added support for NFSv3, major refactoring, fixed bugs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120761/ --- (Updated Dec. 17, 2014, 10:05 a.m.) Status -- This change has been marked as submitted. Review request for KDE Runtime and Albert Astals Cid. Repository: kde-runtime Description --- This patch adds proper support for NFSv3 in the kio module, it still supports NFSv2 servers of course. I implemented it in such a way that it loops through the versions trying to find a compatible one. I also found when working with it that the code was far from optimal, so I have done some major refactoring and optimisation work which also fixes a couple of bugs. That's why the patch is so big. This is a backport of https://git.reviewboard.kde.org/r/120343/. Diffs - kioslave/nfs/rpc_mnt2_xdr.c PRE-CREATION kioslave/nfs/rpc_mnt3.h PRE-CREATION kioslave/nfs/rpc_mnt3_xdr.c PRE-CREATION kioslave/nfs/rpc_nfs2_prot.h PRE-CREATION kioslave/nfs/rpc_nfs2_prot_xdr.c PRE-CREATION kioslave/nfs/rpc_nfs3_prot.h PRE-CREATION kioslave/nfs/rpc_nfs3_prot.x PRE-CREATION kioslave/nfs/rpc_nfs3_prot_xdr.c PRE-CREATION kioslave/nfs/nfsv2.h PRE-CREATION kioslave/nfs/nfsv2.cpp PRE-CREATION kioslave/nfs/nfsv3.h PRE-CREATION kioslave/nfs/nfsv3.cpp PRE-CREATION kioslave/nfs/nfs_prot.h 5ed218f20d2fda219adda6899a1321fc3d384d1e kioslave/nfs/nfs_prot.x kioslave/nfs/nfs_prot_xdr.c cd1354668d40616a0a0864bc6b3d68ccc5ef3e4f kioslave/nfs/mount_xdr.c 433a8596884bdb4fe05795c74de21767ed88d6eb kioslave/nfs/nfs.protocol 4781b3ca1424473c913e7ee265ee6fffa50cce39 kioslave/nfs/mount.h c3b8c217f3574c8afd2410ad2b50ec98828e31bb kioslave/nfs/mount.x kioslave/nfs/kio_nfs.h ec52564f5fa2c5ce38f354bbe94b86a75fb7f6b0 kioslave/nfs/kio_nfs.cpp 3f94b9129bf9f126aef1e4356dc533420151ae2a kioslave/nfs/CMakeLists.txt b973a736393388af5d66b8b7d6b055f497f3bdf8 kioslave/nfs/README 9d92d73104ede629e617aeb8e117802ebf4190c2 kioslave/nfs/TODO 6e5525127454c936f829028c521999ba4f046c08 Diff: https://git.reviewboard.kde.org/r/120761/diff/ Testing --- I've tried browsing NFS servers that are compatible with both version 2 and 3, as well as one server that was only compatible with version 3 (see bug #309113). In addition to that I've tried most things I can think of like copying, changing permissions, creating files and directories etc. Due to its size it will most likely require more testing, but my tests have so far been successful. Thanks, Mathias Tillman
Re: [Kde-pim] Problems with infrastructure
On 17 Dec 2014, at 6:01, Jan Kundrát wrote: Hi Jeff, thanks for a very reasonable mail, I don't have much to add to it in general, except for one item: But it's not reasonable to expect the sysadmins to support multiple parallel systems Maybe there is a misunderstanding of some kind -- I do not expect sysadmins to take care of a system like Gerrit. I'm volunteering for doing this work, and at Akademy some other people expressed general interest in helping out, too. I do not forsee any increased load on our sysadmins due to Gerrit. Hi Jan, I understood that to be the case -- I'm really meaning for a general, KDE-wide solution. Personally I don't have an issue with volunteers taking care of non-official systems if it helps their productivity. If Gerrit wasn't where KDE as a whole went, and you wanted to put the effort in to keep Gerrit working for you and integrated with the rest of the KDE systems, more power to you. The issue I see (which doesn't necessarily reflect my personal views) is that KDE projects have been required to use KDE infrastructure. I forget where that's written/required, but I do know that that it exists. The purpose of this was to avoid fragmentation or making it difficult to find the full breadth of KDE projects, or requiring KDE developers to sign up for multiple e.g. bugtracking systems just to comment on another KDE project. I tend to be productivity-oriented rather than dogmatic, but I certainly don't speak for everyone on that point. --Jeff
Re: cppcheck on build.kde.org
On Thu, Dec 18, 2014 at 6:30 AM, Jan Kundrát j...@kde.org wrote: On Tuesday, 16 December 2014 23:58:02 CEST, Ben Cooksley wrote: If we were to replace Jenkins, you have indicated that custom work would be required to get reports for tests and tools like cppcheck generated and published. Hi Ben, what I said is that generating pretty plots about historical trends of the number of build warnings and the number of cppcheck issues is something which Jenkins excells at, that I do not see any value in having these graphs, and that they do not make sense in case of pre-merge CI. With a pre-merge CI, there's no linear history anymore, so having Jenkins-style graph showing how many warnings were produced over the course of last week is a metric which, IMHO, doesn't make sense. How should such a graph look like, considering that the history might have many dead-ends? The graph is more useful for the post-merge phase I will admit. It is used by developers to track their progress and to watch for deviations, so I know it is useful. Please remember to see both sides of the coin here. Pre-merge CI is not the only type of CI. Regardless - we should only have *one* system for doing CI runs, regardless of whether they are post or pre merge. Two systems would mean twice the maintenance effort (projects have to be registered with it, etc) - and need twice the infrastructure unless they can somehow collaborate on who is using which resources. That is simply wasteful. I made a quick look into getting the cppcheck data published into Gerrit, but when testing this, I got back data which I cannot interpret properly. 1) For KIO's master branch with Qt5 (this is KF5, right?), the website [1] says that there are no errors, no warnings. However, if I run the tool locally on my laptop with no arguments, I get: [src/widgets/jobuidelegate.cpp:78] - [src/widgets/jobuidelegate.cpp:75]: (error, inconclusive) Possible null pointer dereference: w - otherwise it is redundant to check it against null. If I use the same arguments as specified in websites/build.kde.org's config/build/global.cfg, I get a *ton* of warnings. Even after filtering out missing include files, I still get quite a few warnings, such as: error id=uninitMemberVar severity=warning msg=Member variable 'KUrlCompletionPrivate::list_urls_no_hidden' is not initialized in the constructor. verbose=Member variable 'KUrlCompletionPrivate::list_urls_no_hidden' is not initialized in the constructor. 2) I don't see any cppcheck results for Trojita. The web page at [2] says This plugin will not report Cppcheck result until there is at least one success or unstable build., but there have been 278 such builds so far. I got similar results for the other build variations. Now, I might be doing something terribly wrong. Could you please point me in a right direction? - Are you sure that the version of cppcheck on build.k.o works properly right now? All projects which I ranodmly picked report 0 warnings; that's surprising given that there are some compiler warnings and I've always got more invalid warnings from cppcheck than from my compiler(s). The version works perfectly fine. cppcheck simply is not run for the majority of projects as it is not enabled to conserve resources. cppcheck, much like gcovr (Cobertura in Jenkins) are only enabled on request for a project. See various files in config/build/ for an example of how this is done. Zanshin and Skrooge use this. It is also disabled by default as for some projects it can make builds take an extremely long time to finish - due to the copying over to the Jenkins master of materials needed to produce the reports. This affects kdelibs in particular. - How are the custom include directories passed to cppcheck? Can it find the headers of the dependencies? Not sure if this is needed - previously it has worked fine. This could be due to our environment variables though. Cheers, Jan Regards, Ben [1] http://build.kde.org/job/kio_master_qt5/470/cppcheckResult/ [2] http://build.kde.org/job/trojita_master_qt5/cppcheckResult/nodata -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Review Request 121584: Make the webapp manager run again.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121584/ --- Review request for Bodega, kdelibs, Aaron J. Seigo, and Marco Martin. Repository: bodega-webapp-manager Description --- Make the webapp manager run again. Diffs - app.js ceede62c192451f2ac2bba8848a97f9bcc4a2f4a package.json 715d01c3fa9e9f3a890ee9e047093fdfb528095f public/favicon.ico PRE-CREATION routes.js 891660f7fb3d036b5907114c58bd17f1128b1efe views/layout.jade 423a37493acac482369693168cce32886a71f0bb Diff: https://git.reviewboard.kde.org/r/121584/diff/ Testing --- It runs now, and gives 200 or 304 responses, though the browser currently shows Page Not Found Thanks, Jeremy Whiting
kruler master is now based on KF5
frameworks branch can be deleted. Please rewire CI, translations or whatever else is needed. Merci :) Christoph Feck (kdepepo)
Re: kruler master is now based on KF5
Christoph Feck ha scritto: frameworks branch can be deleted. Please rewire CI, translations or whatever else is needed. (cc for kde-i18n-doc@) i18n hopefully fixed (please check): http://websvn.kde.org/?view=revisionrevision=1409082 Ciao -- Luigi
Re: kruler master is now based on KF5
El Dimecres, 17 de desembre de 2014, a les 23:11:01, Christoph Feck va escriure: frameworks branch can be deleted. Please rewire CI, translations or whatever else is needed. Fixed CI, killed the branch. Cheers, Albert Merci :) Christoph Feck (kdepepo)
Do we continue releasing kdelibs 4.14?
Hi, The Applications 14.12 release includes kde-runtime, but not kdelibs. Its 4.14 branch contains at least one import KHTML crash fix, and we should get those out to users that still use long term supported Workspaces 4.11. Could we create tarballs of the kdelibs repo for future Workspaces 4.11 or Applications releases, until everything is ported? Christoph Feck (kdepepo)
Re: Do we continue releasing kdelibs 4.14?
It's the plan. It'll be released the same day than applications 14.12.1 together with kde-workspace 4.11.lots and kdepim* 4.14.4 Enviat des del meu telèfon intel·ligent BlackBerry 10. Missatge original De: Christoph Feck Enviat: jueves, 18 de diciembre de 2014 01:58 Per a: kde-core-devel@kde.org Tema: Do we continue releasing kdelibs 4.14? Hi, The Applications 14.12 release includes kde-runtime, but not kdelibs. Its 4.14 branch contains at least one import KHTML crash fix, and we should get those out to users that still use long term supported Workspaces 4.11. Could we create tarballs of the kdelibs repo for future Workspaces 4.11 or Applications releases, until everything is ported? Christoph Feck (kdepepo)
kubuntu plasma 5 login error
Hi everyone, I have been using kubuntu plasma 5 via VMware Workstation 9.0 for porting an application to kf5,everything was working perfectly but when i tried logging in kubuntu today via same vmware, after accepting the login password and loading the system the screen faded and turned blank. The error message which i got from .xsession-error was: kded5 : org.kde.powerdevil.backlighthelper.brightnessvaluemax failed list is empty lock called I would like to know if there any solution for it or should i dual boot my laptops's main memory and try working on kubuntu from there.? -- Regards, Anu. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
[ANNOUNCE] CMake 3.1.0 Released!
I am proud to announce that CMake 3.1 is now available for download at:
http://www.cmake.org/download
http://www.cmake.org/files/v3.1/?C=M;O=D
Documentation is available at:
http://www.cmake.org/cmake/help/v3.1
Release notes appear below and are also published at
http://www.cmake.org/cmake/help/v3.1/release/3.1.0.html
Some of the more significant features of CMake 3.1 are:
* Windows Phone and Windows Store support has been added to Visual Studio 11
(2012) and above Generators.
* NVIDIA Nsight Tegra support has been added to Visual Studio 10 (2010) and
above Generators.
* New target_compile_features command allows populating target based compile
features. CMake uses this information to ensure that the compiler in use is
capable of building the target, and to add any necessary compile flags
such as -std=gnu++11 to support language features.
More information on this is found at:
- http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html
* The syntax for *Variable References* and *Escape Sequences* was simplified in
order to allow a much faster implementation. See policy CMP0053.
* The if command no longer automatically dereferences variables named in
quoted or bracket arguments. See policy CMP0054.
* The target property SOURCES now generally supports Generator Expressions.
The generator expressions may be used in the add_library and
add_executable commands.
* It is now possible to write and append to the target property SOURCES.
The variable CMAKE_DEBUG_TARGET_PROPERTIES can be used to trace the
origin of sources.
* CPack gained 7Z and TXZ generators supporting lzma-compressed archives.
* The ExternalProject module has learned to support lzma-compressed
source tarballs with .7z, .tar.xz, and .txz extensions.
* The ExternalProject module ExternalProject_Add command learned a new
BUILD_ALWAYS option to cause the external project build step to run every
time the host project is built.
* The ctest_coverage command learned to support Intel coverage files with the
codecov tool.
* The ctest_memcheck command learned to support sanitizer modes, including
AddressSanitizer, MemorySanitizer, ThreadSanitizer, and
UndefinedBehaviorSanitizer.
Deprecated and Removed Features:
* In CMake 3.0 the target_link_libraries command accidentally began allowing
unquoted arguments to use Generator Expressions containing a semicolon
separated list within them. For example:
set(libs B C)
target_link_libraries(A PUBLIC $BUILD_INTERFACE:${libs})
This is equivalent to writing:
target_link_libraries(A PUBLIC $BUILD_INTERFACE:B C)
and was never intended to work. It did not work in CMake 2.8.12.
Such generator expressions should be in quoted arguments:
set(libs B C)
target_link_libraries(A PUBLIC $BUILD_INTERFACE:${libs})
CMake 3.1 again requires the quotes for this to work correctly.
CMake 3.1.0 Release Notes
*
Changes made since CMake 3.0.0 include the following.
Documentation Changes
=
* A new cmake-compile-features(7) manual was added.
New Features
Generators
--
* The Visual Studio 14 2015 generator was added.
Windows Phone and Windows Store
~~~
* Generators for Visual Studio 11 (2012) and above learned to
generate projects for Windows Phone and Windows Store. One may set
the CMAKE_SYSTEM_NAME variable to WindowsPhone or WindowsStore
on the cmake(1) command-line or in a CMAKE_TOOLCHAIN_FILE to
activate these platforms. Also set CMAKE_SYSTEM_VERSION to 8.0
or 8.1 to specify the version of Windows to be targeted.
NVIDIA Nsight Tegra
~~~
* Generators for Visual Studio 10 (2010) and above learned to
generate projects for NVIDIA Nsight Tegra Visual Studio Edition.
One may set the CMAKE_SYSTEM_NAME variable to Android on the
cmake(1) command-line or in a CMAKE_TOOLCHAIN_FILE to activate
this platform.
Syntax
--
* The cmake-language(7) syntax for *Variable References* and
*Escape Sequences* was simplified in order to allow a much faster
implementation. See policy CMP0053.
* The if() command no longer automatically dereferences variables
named in quoted or bracket arguments. See policy CMP0054.
Commands
* The add_custom_command() command learned to interpret cmake-
generator-expressions(7) in arguments to DEPENDS.
* The export(PACKAGE) command learned to check the
CMAKE_EXPORT_NO_PACKAGE_REGISTRY variable to skip exporting the
package.
* The file(STRINGS) command gained a new ENCODING option to
enable extraction of UTF-8 strings.
* The find_package() command learned to check the
CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY and
CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY variables to skip
searching the package registries.
* The get_property() command learned a new INSTALL scope for
properties.
* The install() command learned a MESSAGE_NEVER
Re: kubuntu plasma 5 login error
On Wed, Dec 17, 2014 at 7:35 PM, anu mittal anu22mit...@gmail.com wrote: Hi everyone, I have been using kubuntu plasma 5 via VMware Workstation 9.0 for porting an application to kf5,everything was working perfectly but when i tried logging in kubuntu today via same vmware, after accepting the login password and loading the system the screen faded and turned blank. The error message which i got from .xsession-error was: kded5 : org.kde.powerdevil.backlighthelper.brightnessvaluemax failed list is empty lock called I would like to know if there any solution for it or should i dual boot my laptops's main memory and try working on kubuntu from there.? -- Regards, Anu. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Something I've seen doing a plasma 5 kubuntu user today is: - getting the blank screen. - opening a konsole - killall plasmashell - plasmashell It worked for him, still it seems to be a downstream problem. Aleix Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
