KDE CI: Frameworks kio kf5-qt5 FreeBSDQt5.9 - Build # 73 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kio%20kf5-qt5%20FreeBSDQt5.9/73/
 Project:
Frameworks kio kf5-qt5 FreeBSDQt5.9
 Date of build:
Fri, 19 Jan 2018 04:08:15 +
 Build duration:
18 min and counting
   JUnit Tests
  Name: (root) Failed: 1 test(s), Passed: 56 test(s), Skipped: 0 test(s), Total: 57 test(s)Failed: TestSuite.kiofilewidgets-kfilecopytomenutest

D9824: Optimize inotify KDirWatch backend: map inotify wd to Entry

[René J . V . Bertin]

rjvbb added a comment.


  > That's not applicable.
  
  Did you read my actual, original request? If so you'd have seen that it's 
satisfied by this answer. Also please note the final remark in the author's 
summary, `Note that the other backends could leverage a similar trick to speed 
them up.`
  
  >   The benchmark is not synthetic, it measures exactly the use case of 
monitoring a large number of files and touching them all (like `git checkout 
anotherbranch` would do).
  
  What's the use of an application that watches the amount of files we're 
talking about here for changes with which it does nothing, other than 
benchmarking or unit-testing? We don't know how many files we're talking about 
here (the benchmark results only show the total amount of CPU cycles spent). I 
suppose it must be a really large number if walking the list takes 7 minutes. 
I'm pretty certain that simultaneous change of only a fraction of that number 
of files will cause a very significant CPU load when KDevelop starts 
clang-parsing them all.

REPOSITORY
  R244 KCoreAddons

REVISION DETAIL
  https://phabricator.kde.org/D9824

To: mwolff, dfaure, rjvbb, #kdevelop, markg
Cc: aaronpuchert, bcooksley, zimmerman, markg, #frameworks

D9973: [kwidgetsaddons] Fix tooltip positioning

[Christoph Feck]

cfeck added inline comments.

INLINE COMMENTS

> ktooltipwidget.cpp:32
>  #include 
> +#include 
>  

remove unneeded include

> ktooltipwidget.cpp:155
>  } else {
>  x = rect.left() - size.width() - margin;
>  }

Does this also need to be adjusted to ' + margin'? Or was the change above 
accidential?

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D9973

To: michaelh, elvisangelaccio, #frameworks, #dolphin, ngraham
Cc: cfeck

D9824: Optimize inotify KDirWatch backend: map inotify wd to Entry

[Mark Gaiser]

markg accepted this revision.
markg added a comment.


  Ship it from my side.

REPOSITORY
  R244 KCoreAddons

REVISION DETAIL
  https://phabricator.kde.org/D9824

To: mwolff, dfaure, rjvbb, #kdevelop, markg
Cc: aaronpuchert, bcooksley, zimmerman, markg, #frameworks

D9824: Optimize inotify KDirWatch backend: map inotify wd to Entry

[David Faure]

dfaure accepted this revision.
dfaure added a comment.


  This patch fixes a O(n) performance issue in the inotify backend using a 
cache, which makes KDirWatch *better* suited for applications that use 
KDirWatch heavily. Clearly a step in the right direction. Yes a cache needs 
memory, like all caches, how else is one going to optimize linear searches [in 
unsorted data]...
  
  I looked at whether other backends have a similar linear search, and only 
KDirWatchPrivate::checkFAMEvent has something similar, so FAM could use a cache 
where the key would be the "request number" as obtained with 
FAMREQUEST_GETREQNUM. That's a different patch though. The other backends don't 
have such a linear search, why are we even talking of "doing the same for the 
QSFW backend"? That's not applicable. How about taking a look at the code 
before requesting to optimize linear searches that don't exist?
  
  The benchmark is not synthetic, it measures exactly the use case of 
monitoring a large number of files and touching them all (like `git checkout 
anotherbranch` would do).
  
  +2 from me.

REPOSITORY
  R244 KCoreAddons

REVISION DETAIL
  https://phabricator.kde.org/D9824

To: mwolff, dfaure, rjvbb, #kdevelop, markg
Cc: aaronpuchert, bcooksley, zimmerman, markg, #frameworks

D9824: Optimize inotify KDirWatch backend: map inotify wd to Entry

[René J . V . Bertin]

rjvbb added a comment.


  >   Also we know at least one person that isn't going to forget about this, 
don't we?
  
  If you thought it'd be me *who* would keep nagging about this you can forget 
about that.
  
  >   and you don't seem to dispute that it is an improvement
  
  Because I simply don't know. It's apparently an improvement for a synthetic 
benchmark but I've seen too many examples where similar off-the-charts 
differences in a simple benchmark were completely unnoticeable IRL. The gains 
might be crucial in realtime applications (but who would use KDW there...), in 
other cases it might be as underwhelming as the memory overhead that comes with 
it.

REPOSITORY
  R244 KCoreAddons

REVISION DETAIL
  https://phabricator.kde.org/D9824

To: mwolff, dfaure, rjvbb, #kdevelop
Cc: aaronpuchert, bcooksley, zimmerman, markg, #frameworks

D9973: [kwidgetsaddons] Fix tooltip positioning

[Michael Heidelbach]

michaelh created this revision.
michaelh added reviewers: elvisangelaccio, Frameworks, Dolphin, ngraham.
Restricted Application added a project: Frameworks.
michaelh requested review of this revision.

REVISION SUMMARY
  Partial fix of Bug 388583 
  Corrected tooltip position in dolphin when
  
  1. Tooltip is displayed above file item
  2. Content width exceeds screen width

TEST PLAN
  Visual inspection specially for equal distance to file item (3px)
  Patch applied:
  F5662669: tt-patch-above.png 
  
  Currently partial display:
  F5662680: tt-placement-outside.png 
  Patch applied:
  F5662688: tt-placement-outside-patched.png 

  
  Currently invisible tooltip (displayed off-screen).
  Patch applied:
  F5662675: tt-too-wide.png 

REPOSITORY
  R236 KWidgetsAddons

BRANCH
  tooltip (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D9973

AFFECTED FILES
  src/ktooltipwidget.cpp

To: michaelh, elvisangelaccio, #frameworks, #dolphin, ngraham

D9824: Optimize inotify KDirWatch backend: map inotify wd to Entry

[Aaron Puchert]

aaronpuchert added a comment.


  In https://phabricator.kde.org/D9824#192793, @rjvbb wrote:
  
  > If real-world impact is in the order of a highly significant but 
millisecond-order reduction of reaction time to file change there may be little 
reason to commit this improvement now (and then risk forgetting about the rest 
again). My hunch is that it could be more effective then to keep this change 
pending and use it as a motivation to work on a more complete overhaul of the 
class.
  
  
  You know how they say, “perfect is the enemy of good.” Also we know at least 
one person that isn't going to forget about this, don't we? To keep an 
improvement — and you don't seem to dispute that it is an improvement — pending 
as “motivation to work on a more complete overhaul” is an argument I can't 
follow. I guess this is what Uncle Bob calls the Grand Redesign in the Sky 
.
  
  In https://phabricator.kde.org/D9824#191203, @dfaure wrote:
  
  > I'm 100% sure the same rules applies, because the "limitations" of 
operator[] come from C++ and therefore apply to all associative containers.
  
  
  The limitation is that with `operator[]` followed by an assignment the 
associated value is first value-initialized (here zero-initialized), before 
later the actual value is written. Since the value has type `Entry*`, “a hair 
faster” is quite accurate. I doubt this is even measurable, taking into account 
the cost of allocation, computing the hash value, and possible cache misses, 
that are associated with adding a new element.
  
  I'm not saying we shouldn't use `insert`, but it's probably a 
micro-optimization.

REPOSITORY
  R244 KCoreAddons

REVISION DETAIL
  https://phabricator.kde.org/D9824

To: mwolff, dfaure, rjvbb, #kdevelop
Cc: aaronpuchert, bcooksley, zimmerman, markg, #frameworks

D9966: [KIO] Fix issues with sharing of file descriptor

[Fabian Vogt]

fvogt added a comment.


  Thanks for the quick reaction!
  
  > 1.Fixes buffer overflow due to strcpy.
  
  Looks good, but I would prefer an exception or abort instead of silent 
truncation.
  
  Also note that this makes it possible to delete an arbitrary file on 
non-linux platforms if `path` is attacker-controlled, which needs to be fixed.
  
  > (BTW, SocketAddress::length should return the actual length of the buffer,  
currently it adds ~100 '\0' bytes to the end)
  
  Is not fixed, is this intentional?
  
  > 2.Adds checks for socket credentials. Now a file descriptor will be 
received only if it was sent by a root owned process.
  
  Looks sensible, but it doesn't fix the other direction, which is:
  
  1. User asks the kauth helper to open a file as root
  2. The kauth helper receives the socket address
  3. file.so dies (reason does not matter)
  4. Any process can now create a socket with the address the kauth helper 
connects to and receive the fd
  
  IMO the correct fix (which only applies to linux, according to the manpage) 
is to use a pathname socket in `$XDG_RUNTIME_DIR` (or alternatively, somewhere 
returned by `mkdtemp`).

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D9966

To: chinmoyr, #frameworks, thiago
Cc: ngraham, fvogt, lbeltrame, dfaure

D9966: [KIO] Fix issues with sharing of file descriptor

[Chinmoy Ranjan Pradhan]

chinmoyr created this revision.
chinmoyr added reviewers: Frameworks, thiago.
Restricted Application added a project: Frameworks.
chinmoyr requested review of this revision.

REVISION SUMMARY
  This patch,
  1.Fixes buffer overflow due to strcpy.
  2.Adds checks for socket credentials. Now a file descriptor will be received 
only if it was sent by a root owned process.
  
  These issues were mentioned in here : 
https://mail.kde.org/pipermail/kde-frameworks-devel/2018-January/055307.html

REPOSITORY
  R241 KIO

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D9966

AFFECTED FILES
  src/ioslaves/file/fdreceiver.cpp
  src/ioslaves/file/sharefd_p.h

To: chinmoyr, #frameworks, thiago
Cc: fvogt, lbeltrame, dfaure

D9958: Parseable output for balooctl status

[Michael Heidelbach]

michaelh added a comment.


  Just learned it's on the Qt-wishlist. I can live with that. Just wanted to 
get rid of the 2nd description line.

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D9958

To: michaelh, #frameworks, vhanda, smithjd, lbeltrame
Cc: broulik, ngraham

D9958: Parseable output for balooctl status

[Luca Beltrame]

lbeltrame added a comment.


  In https://phabricator.kde.org/D9958#192860, @michaelh wrote:
  
  >
  
  
  
  
  > The --format look like a global switch. I don't like that. Couldn't find 
a(n easy) way to avoid that. Do you know one?
  >  The subcommands are defined as posititional arguments after all.
  
  Apparently it's not possible in Qt (but I might be wrong).

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D9958

To: michaelh, #frameworks, vhanda, smithjd, lbeltrame
Cc: broulik, ngraham

D9959: [baloosearch] Send summary to stderr

[Michael Heidelbach]

michaelh added reviewers: broulik, lbeltrame.

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D9959

To: michaelh, #frameworks, vhanda, smithjd, broulik, lbeltrame

D9958: Parseable output for balooctl status

[Michael Heidelbach]

michaelh added a comment.


  Once I found an example (Qt doc) it was easy. Yesterday was struggling with 
this command line parsing to much :)
  BTW, regarding
  
balooctl status -h
  
  The --format look like a global switch. I don't like that. Couldn't find a(n 
easy) way to avoid that. Do you know one?
  The subcommands are defined as posititional arguments after all.

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D9958

To: michaelh, #frameworks, vhanda, smithjd, lbeltrame
Cc: broulik, ngraham

D9958: Parseable output for balooctl status

[Luca Beltrame]

lbeltrame added a comment.


  +1. @broulik How does it look on your side wrt the QJsonDocument usage?

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D9958

To: michaelh, #frameworks, vhanda, smithjd, lbeltrame
Cc: broulik, ngraham

D9958: Parseable output for balooctl status

[Michael Heidelbach]

michaelh marked 2 inline comments as done.

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D9958

To: michaelh, #frameworks, vhanda, smithjd, lbeltrame
Cc: broulik, ngraham

D9958: Parseable output for balooctl status

[Michael Heidelbach]

michaelh updated this revision to Diff 25591.
michaelh added a comment.


  utilized QJson*
  output:
   F5662110: jsonobject 

REPOSITORY
  R293 Baloo

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9958?vs=25579=25591

BRANCH
  formatting

REVISION DETAIL
  https://phabricator.kde.org/D9958

AFFECTED FILES
  src/tools/balooctl/main.cpp
  src/tools/balooctl/statuscommand.cpp

To: michaelh, #frameworks, vhanda, smithjd, lbeltrame
Cc: broulik, ngraham

D9958: Parseable output for balooctl status

[Michael Heidelbach]

michaelh added a comment.


  > Did you test this change also with filenames with Unicode characters or 
non-Latin characters?
  
  Yes. Example:
  F5662004: japanese 

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D9958

To: michaelh, #frameworks, vhanda, smithjd, lbeltrame
Cc: broulik, ngraham

A new tier1 for icontheme.rcc handling

[Hannah von Reth]

Hi everyone.

Only some few of you will be aware of KIconThemes ability to load binary
icon themes automagically.

https://cgit.kde.org/kiconthemes.git/tree/src/kicontheme.cpp#n48

The code looks for a icontheme.rcc and sets it as default theme.

On Windows and Mac we rely on that code as it is more feasible to
install that one
file with an single application installer. This code also ensures that
the theme path is set,
which on Linux is done by the qpa.

The problem with the current solution is that it only allows one single
theme and is in a tier3
framework.

I recently talked to David Faure and we agreed that it would be best to
put those few line of code into a new
created tier1 framework, with an explicit call instead of the magical
loading.

The explicit call would allow to specify the theme loaded and we  can
still maintain the current behaviour by putting a call to
that new framework into KIconThemes.

Now we need a name for that tier1 framework and ideally someone who
steps up for the once in a lifetime chance to become
maintainer of a glorious new tier1 framework.

Cheers,

Hannah






signature.asc
Description: OpenPGP digital signature

D9961: [Plasma Theme] Guard against invalid KPluginInfo object

[Kai Uwe Broulik]

broulik created this revision.
broulik added a reviewer: Plasma.
Restricted Application added projects: Plasma, Frameworks.
Restricted Application added subscribers: Frameworks, plasma-devel.
broulik requested review of this revision.

REVISION SUMMARY
  BUG: 389152

TEST PLAN
  Compiles

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D9961

AFFECTED FILES
  src/plasma/private/theme_p.cpp

To: broulik, #plasma
Cc: plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D9793: Fall back to language name for translations lookup if locale name fails

[Wolfgang Bauer]

This revision was automatically updated to reflect the committed changes.
Closed by commit R240:78443e0f0373: Fall back to language name for translations 
lookup if locale name fails (authored by wbauer).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9793?vs=25536=25566

REVISION DETAIL
  https://phabricator.kde.org/D9793

AFFECTED FILES
  modules/ECMQmLoader.cpp.in
  tests/ECMPoQmToolsTest/check.cmake.in

To: wbauer, #frameworks, aacid
Cc: aacid, safaalfulaij, #build_system

D9958: Parseable output for balooctl status

[Michael Heidelbach]

michaelh added a comment.


  @broulik: My reasons for not using it
  
  1. I was a little lazy: Using all the other Qt-Objects was enough work for me 
:).
  2. I thought not using QJsonDocument was accapteble because the overall 
structure of the formatters is similar.
  
  Should you insist on QJsonDocument I'll use it of course.

INLINE COMMENTS

> lbeltrame wrote in statuscommand.cpp:122
> Small nit: space after ":".

This way one can

  ...  | cut -d ':' -f2-

otherwise you have to get rid of leading space.

> lbeltrame wrote in statuscommand.cpp:149
> What do those replace operations do?

escape double quotes

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D9958

To: michaelh, #frameworks, vhanda, smithjd, lbeltrame
Cc: broulik, ngraham

D9958: Parseable output for balooctl status

[Kai Uwe Broulik]

broulik added a comment.


  > I'm not too fond of assembling JSON by hand, but I guess it was done to 
avoid dependencies for a tool that's supposed to be simple.
  
  Qt's JSON support is in QtCore since Qt 5, there's no additional dependency, 
so yes, please use `QJsonDocument` et at.

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D9958

To: michaelh, #frameworks, vhanda, smithjd, lbeltrame
Cc: broulik, ngraham

D9958: Parseable output for balooctl status

[Luca Beltrame]

lbeltrame added a comment.


  I'm not too fond of assembling JSON by hand, but I guess it was done to avoid 
dependencies for a tool that's supposed to be simple. I'll let others weigh in 
on this.
  Did you test this change also with filenames with Unicode characters or 
non-Latin characters?

INLINE COMMENTS

> statuscommand.cpp:122
> +
> +  out << ":" << filePath << endl;
> +  }

Small nit: space after ":".

> statuscommand.cpp:149
> +  out << separator << objectIn << endl;
> +  printItem(QStringLiteral("file"), 
> filePath.replace(QLatin1String("\""), QLatin1String("\\\"")));
> +  out << comma << endl;

What do those replace operations do?

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D9958

To: michaelh, #frameworks, vhanda, smithjd, lbeltrame
Cc: ngraham

D9958: Parseable output for balooctl status

[Michael Heidelbach]

michaelh added a comment.


  balooctl status outputs:
  F5661892: balooctl-status-output 

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D9958

To: michaelh, #frameworks, vhanda, smithjd, lbeltrame
Cc: ngraham

D9959: [baloosearch] Send summary to stderr

[Michael Heidelbach]

michaelh created this revision.
michaelh added reviewers: Frameworks, vhanda, smithjd.
michaelh added a project: Frameworks.
michaelh requested review of this revision.

REVISION SUMMARY
  - eliminate the need for '... | head -n -1' when piping output

TEST PLAN
  Obviously:
  $ baloosearch ... 2>/dev/null

REPOSITORY
  R293 Baloo

BRANCH
  search-summary

REVISION DETAIL
  https://phabricator.kde.org/D9959

AFFECTED FILES
  src/tools/baloosearch/main.cpp

To: michaelh, #frameworks, vhanda, smithjd

D9766: Use at least the requested width for the argument hint tree

[Kevin Funk]

kfunk added a comment.


  Whoops. Sorry for accidentally reopening it to begin with.

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D9766

To: mwolff, #kdevelop, #kate
Cc: dhaumann, kfunk, #frameworks, michaelh, kevinapavew, ngraham, demsking, 
cullmann, sars

D9824: Optimize inotify KDirWatch backend: map inotify wd to Entry

[René J . V . Bertin]

rjvbb added a comment.


  I don't see anything unreasonable to my request, which can also be satisfied 
by a argued demonstration why the same approach/fix doesn't apply to other 
backends. AFAIAC I'm just doing my reviewers' service like it's been shown to 
me how that's done.
  
  If the same approach can improve the 2 main backends (one of them being the 
cross-platform "default" that's not specific to a minority OS) that opportunity 
should be seized.
  
  Let me remind everyone that it's often been pointed out to me that I had been 
wasting more time arguing than it would have taken to do as asked (in addition 
to remarks about partial fixes and workarounds). Those don't apply just to me.
  
  I'm even going to add a request. Please describe a real-world example where 
this change actually has a noticeable impact, and please use time rather than 
CPU cycles as the measure. The observation that KDevelop `sometimes exhibits 
similar performance issues` is a little vague. I'm one of the few KDevelop 
users who have voiced concerns about KDirWatch performance but those are 
related to the adding of new watch items.
  
  If real-world impact is in the order of a highly significant but 
millisecond-order reduction of reaction time to file change there may be little 
reason to commit this improvement now (and then risk forgetting about the rest 
again). My hunch is that it could be more effective then to keep this change 
pending and use it as a motivation to work on a more complete overhaul of the 
class.
  
  A final suggestion: wouldn't it be better to reorganise the code first, 
splitting off the different backends into different files rather than keeping 
them all in a single file with all the resulting #ifdefs?

REPOSITORY
  R244 KCoreAddons

REVISION DETAIL
  https://phabricator.kde.org/D9824

To: mwolff, dfaure, rjvbb, #kdevelop
Cc: bcooksley, zimmerman, markg, #frameworks

D9766: Use at least the requested width for the argument hint tree

[Milian Wolff]

mwolff abandoned this revision.
mwolff added a comment.


  this was comitted already, closing it again

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D9766

To: mwolff, #kdevelop, #kate
Cc: dhaumann, kfunk, #frameworks, michaelh, kevinapavew, ngraham, demsking, 
cullmann, sars

KDE CI: Frameworks kcoreaddons kf5-qt5 SUSEQt5.7 - Build # 28 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kcoreaddons%20kf5-qt5%20SUSEQt5.7/28/
 Project:
Frameworks kcoreaddons kf5-qt5 SUSEQt5.7
 Date of build:
Thu, 18 Jan 2018 10:13:06 +
 Build duration:
9 min 22 sec and counting
   JUnit Tests
  Name: (root) Failed: 1 test(s), Passed: 23 test(s), Skipped: 0 test(s), Total: 24 test(s)Failed: TestSuite.kdirwatch_qfswatch_unittest

D9822: Add benchmarks for KDirWatch

[Milian Wolff]

This revision was automatically updated to reflect the committed changes.
Closed by commit R244:421e85344db7: Add benchmarks for KDirWatch (authored by 
mwolff).

REPOSITORY
  R244 KCoreAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9822?vs=25368=25583

REVISION DETAIL
  https://phabricator.kde.org/D9822

AFFECTED FILES
  autotests/kdirwatch_unittest.cpp

To: mwolff, dfaure
Cc: #frameworks

KDE CI: Frameworks kcoreaddons kf5-qt5 SUSEQt5.10 - Build # 33 - Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kcoreaddons%20kf5-qt5%20SUSEQt5.10/33/
 Project:
Frameworks kcoreaddons kf5-qt5 SUSEQt5.10
 Date of build:
Thu, 18 Jan 2018 10:13:06 +
 Build duration:
3 min 56 sec and counting
   JUnit Tests
  Name: (root) Failed: 2 test(s), Passed: 22 test(s), Skipped: 0 test(s), Total: 24 test(s)Failed: TestSuite.kdirwatch_inotify_unittestFailed: TestSuite.kdirwatch_qfswatch_unittest

D9820: Verify that the file was opened

[Milian Wolff]

This revision was automatically updated to reflect the committed changes.
Closed by commit R244:311a702fa070: Verify that the file was opened (authored 
by mwolff).

REPOSITORY
  R244 KCoreAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9820?vs=25167=25581

REVISION DETAIL
  https://phabricator.kde.org/D9820

AFFECTED FILES
  autotests/kdirwatch_unittest.cpp

To: mwolff, dfaure, apol
Cc: #frameworks

D9823: Optimize: use QMetaObject::invokeMethod with functor

[Milian Wolff]

This revision was automatically updated to reflect the committed changes.
Closed by commit R244:16e8cf1e6607: Optimize: use QMetaObject::invokeMethod 
with functor (authored by mwolff).

REPOSITORY
  R244 KCoreAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9823?vs=25366=25584

REVISION DETAIL
  https://phabricator.kde.org/D9823

AFFECTED FILES
  src/lib/io/kdirwatch.cpp

To: mwolff, dfaure, apol, mpyne
Cc: mpyne, #frameworks

D9958: Parseable output for balooctl status

[Luca Beltrame]

lbeltrame added a comment.


  Examples of each output would be nice.

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D9958

To: michaelh, #frameworks, vhanda, smithjd, lbeltrame
Cc: ngraham

D9821: Use QSignalSpy::wait instead of QTest::wait where possible

[Milian Wolff]

This revision was automatically updated to reflect the committed changes.
Closed by commit R244:5d91ecc2fb68: Use QSignalSpy::wait instead of QTest::wait 
where possible (authored by mwolff).

REPOSITORY
  R244 KCoreAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9821?vs=25168=25582

REVISION DETAIL
  https://phabricator.kde.org/D9821

AFFECTED FILES
  autotests/kdirwatch_unittest.cpp

To: mwolff, dfaure
Cc: #frameworks

D9819: Verify that the path is valid and writable

[Milian Wolff]

This revision was automatically updated to reflect the committed changes.
Closed by commit R244:5fa1aaa2a47b: Verify that the path is valid and writable 
(authored by mwolff).

REPOSITORY
  R244 KCoreAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9819?vs=25166=25580

REVISION DETAIL
  https://phabricator.kde.org/D9819

AFFECTED FILES
  autotests/kdirwatch_unittest.cpp

To: mwolff, dfaure, apol
Cc: #frameworks

KDE CI: Frameworks kcoreaddons kf5-qt5 FreeBSDQt5.9 - Build # 17 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kcoreaddons%20kf5-qt5%20FreeBSDQt5.9/17/
 Project:
Frameworks kcoreaddons kf5-qt5 FreeBSDQt5.9
 Date of build:
Thu, 18 Jan 2018 10:13:06 +
 Build duration:
3 min 41 sec and counting
   JUnit Tests
  Name: (root) Failed: 2 test(s), Passed: 21 test(s), Skipped: 0 test(s), Total: 23 test(s)Failed: TestSuite.kdirwatch_inotify_unittestFailed: TestSuite.kdirwatch_stat_unittest

D9958: Parseable output for balooctl status

[Michael Heidelbach]

michaelh created this revision.
michaelh added reviewers: Frameworks, vhanda, smithjd, lbeltrame.
michaelh added a project: Frameworks.
michaelh requested review of this revision.

REVISION SUMMARY
- added -f|--format option
  - implemented formatters 'simple', 'json', 'multiline' (=current output)

TEST PLAN
  $ balooctl status -h
  $ balooctl status /existing/path/* /not/existing/path [--format xxx]
  JSON well-formed check:
  $ balooctl status /existing/path/* /not/existing/path -f json | jq '.'

REPOSITORY
  R293 Baloo

BRANCH
  formatting

REVISION DETAIL
  https://phabricator.kde.org/D9958

AFFECTED FILES
  src/tools/balooctl/main.cpp
  src/tools/balooctl/statuscommand.cpp

To: michaelh, #frameworks, vhanda, smithjd, lbeltrame
Cc: ngraham

KDE CI: Frameworks baloo kf5-qt5 SUSEQt5.10 - Build # 22 - Fixed!

[CI System]

BUILD SUCCESS
 Build URL
https://build.kde.org/job/Frameworks%20baloo%20kf5-qt5%20SUSEQt5.10/22/
 Project:
Frameworks baloo kf5-qt5 SUSEQt5.10
 Date of build:
Thu, 18 Jan 2018 08:46:21 +
 Build duration:
13 min and counting
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 39 test(s), Skipped: 0 test(s), Total: 39 test(s)

KDE CI: Frameworks baloo kf5-qt5 SUSEQt5.7 - Build # 23 - Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20baloo%20kf5-qt5%20SUSEQt5.7/23/
 Project:
Frameworks baloo kf5-qt5 SUSEQt5.7
 Date of build:
Thu, 18 Jan 2018 08:46:21 +
 Build duration:
6 min 29 sec and counting
   JUnit Tests
  Name: (root) Failed: 1 test(s), Passed: 38 test(s), Skipped: 0 test(s), Total: 39 test(s)Failed: TestSuite.kinotifytest

D9712: balooctl status: translatable message

[Michael Heidelbach]

This revision was automatically updated to reflect the committed changes.
Closed by commit R293:e733c7f72695: balooctl status: translatable message 
(authored by michaelh).

REPOSITORY
  R293 Baloo

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9712?vs=25466=25576

REVISION DETAIL
  https://phabricator.kde.org/D9712

AFFECTED FILES
  src/tools/balooctl/statuscommand.cpp

To: michaelh, #frameworks, vhanda, smithjd, lueck, lbeltrame
Cc: ltoscano, lbeltrame, elvisangelaccio, lueck, dfaure, ngraham