D18630: Fix warning

2019-01-31 Thread Kai Uwe Broulik
broulik accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

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

To: apol, #plasma, broulik
Cc: kde-frameworks-devel, michaelh, ngraham, bruns


D18638: Avoid using trimmed method

2019-01-31 Thread Laurent Montel
mlaurent added a reviewer: dfaure.

REPOSITORY
  R246 Sonnet

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

To: mlaurent, dfaure
Cc: kde-frameworks-devel, michaelh, ngraham, bruns


D18638: Avoid using trimmed method

2019-01-31 Thread Laurent Montel
mlaurent created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
mlaurent requested review of this revision.

REVISION SUMMARY
  We don't want to use trimmed() but we want to avoid to call sonnet code for 
empty text

REPOSITORY
  R246 Sonnet

BRANCH
  remove_using_trimmed (branched from master)

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

AFFECTED FILES
  src/ui/highlighter.cpp

To: mlaurent
Cc: kde-frameworks-devel, michaelh, ngraham, bruns


D18545: [breeze desktop theme/dialogs] Add rounded corners to dialogs

2019-01-31 Thread Vlad Zagorodniy
zzag added a comment.


  ... though I'm not sure whether that's a bug.

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

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

To: rooty, #vdg, ngraham
Cc: zzag, davidedmundson, Codezela, filipf, kde-frameworks-devel, michaelh, 
ngraham, bruns


D18545: [breeze desktop theme/dialogs] Add rounded corners to dialogs

2019-01-31 Thread Vlad Zagorodniy
zzag added a comment.


  Well, there are still issues with corners
  
  F6580225: Screenshot_20190131_151157.png 

  
  (both the blur and the background contrast effect are disabled)

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

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

To: rooty, #vdg, ngraham
Cc: zzag, davidedmundson, Codezela, filipf, kde-frameworks-devel, michaelh, 
ngraham, bruns


D18545: [breeze desktop theme/dialogs] Add rounded corners to dialogs

2019-01-31 Thread Nathaniel Graham
ngraham accepted this revision.
ngraham added a comment.
This revision is now accepted and ready to land.


  This works as intended for me on both Breeze and Breeze Dark and looks 
fantastic. Sooo... is there anything left to do here, or shall we land it?

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

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

To: rooty, #vdg, ngraham
Cc: zzag, davidedmundson, Codezela, filipf, kde-frameworks-devel, michaelh, 
ngraham, bruns


D18450: Add extractor for AppImage files

2019-01-31 Thread Alexander Stippich
astippich accepted this revision.
astippich added a comment.
This revision is now accepted and ready to land.


  Just noticed, you never use the AppDataParser.name(). Is that intentional?
  Otherwise looks good, but you may want to wait for someone more experienced 
than me.

REPOSITORY
  R286 KFileMetaData

BRANCH
  addappimageextractor

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

To: kossebau, #baloo, astippich
Cc: TheAssassin, astippich, broulik, kde-frameworks-devel, ashaposhnikov, 
michaelh, spoorun, ngraham, bruns, abrahams


D15189: [KRun] Don’t follow redirection to speed up and avoid incorrect behavior

2019-01-31 Thread Nathaniel Graham
ngraham added a comment.


  Can you provide your email address so we can land this patch for you with 
proper authorship information? Thanks!

REPOSITORY
  R126 KDE CLI Utilities

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

To: achauvel, #frameworks, dfaure, cfeck
Cc: plasma-devel, anthonyfieroni, ngraham, kde-frameworks-devel, jraleigh, 
GB_2, ragreen, Pitel, michaelh, ZrenBot, bruns, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D18533: Improve the Notfication Bell Icon by using the KAlarm design

2019-01-31 Thread Nathaniel Graham
ngraham added a comment.


  Any update/progress on this?

REPOSITORY
  R266 Breeze Icons

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

To: trickyricky26, #vdg
Cc: ngraham, ndavis, djarvie, kde-frameworks-devel, michaelh, bruns


D18610: Introduce KF5AuthCore

2019-01-31 Thread Albert Astals Cid
aacid updated this revision to Diff 50622.
aacid added a comment.


  Only have one debug category for now

REPOSITORY
  R283 KAuth

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18610?vs=50563=50622

BRANCH
  arcpatch-D18610

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

AFFECTED FILES
  src/CMakeLists.txt

To: aacid
Cc: apol, kde-frameworks-devel, michaelh, ngraham, bruns


D18450: Add extractor for AppImage files

2019-01-31 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  In D18450#402952 , @astippich 
wrote:
  
  > got it up and running!
  
  
  Yay :) Thanks for keeping trying.
  
  > One question: Why is the extra desktop file parser necessary? Shouldn't all 
required information be available from the app data parser?
  
  Reasons are that for one, the appdata file is optional by the appimage spec, 
so one needs a fallback. Then other appimage handling tools also give the data 
from the desktop file a priority over the data from the appdata file (the 
desktop file being the older metadata container in the history of the spec, so 
also sometimes completely ignored), so for consistency I followed that priority 
handling for data from the desktop file.

REPOSITORY
  R286 KFileMetaData

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

To: kossebau, #baloo
Cc: TheAssassin, astippich, broulik, kde-frameworks-devel, ashaposhnikov, 
michaelh, spoorun, ngraham, bruns, abrahams


D18237: Fix ResultIterator

2019-01-31 Thread Albert Astals Cid
aacid added a comment.


  In D18237#402918 , @bruns wrote:
  
  > Oh, and you forgot to undelete the operator=, so this is still BIC ...
  
  
  No, that is not BIC

REPOSITORY
  R293 Baloo

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

To: aacid, #baloo, bruns, poboiko, apol
Cc: apol, kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, 
spoorun, ngraham, bruns, abrahams


D18450: Add extractor for AppImage files

2019-01-31 Thread Alexander Stippich
astippich added a comment.


  got it up and running!
  One question: Why is the extra desktop file parser necessary? Shouldn't all 
required information be available from the app data parser?

REPOSITORY
  R286 KFileMetaData

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

To: kossebau, #baloo
Cc: TheAssassin, astippich, broulik, kde-frameworks-devel, ashaposhnikov, 
michaelh, spoorun, ngraham, bruns, abrahams


D16643: Correct the accept flag of the event object on DragMove

2019-01-31 Thread Fabian Vogt
fvogt added a comment.


  I tried to understand what this change does both by trying to reproduce the 
issue and reading Qt code.
  Here the symptom was more drags not getting accepted at all than flipping 
back and forth, but this patch fixes that as well.
  
  What might cause confusion is that the `DeclarativeDropArea::enabled` 
property is unrelated to `QQuickItem::enabled`.
  If the latter is set to disabled, events don't get delivered at all (== 
rejected) and this should work directly (so I wonder why
  this has a custom property at all).
  
  From what I can tell this patch actually does two independent changes:
  
  - Not actively ignoring an event if the move didn't change position (this is 
enough to fix my case, but apparently not for @trmdi, can you clarify?)
  - Actively rejecting an event if the area is "disabled" or "temporarily 
inhibited" to prevent stealing of the event by any parent areas
  
  IMO the first change is absolutely correct - actively reejecting a move 
breaks the drag.
  
  The second change seems to be necessary because DragMove events are 
considered to be accepted by the current drag target item by default.
  So it needs to be rejected actively if "disabled" or "inhibited". This is 
normally done by Qt itself for disabled items, but as this reimplements a custom
  enabled property it needs to be done manually.
  
  I suggest to wait until Monday whether @bruns has something to add, but if 
there's no objection this can IMO be landed.

REPOSITORY
  R296 KDeclarative

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

To: trmdi, mart, broulik, #plasma, hein, bruns
Cc: fvogt, aacid, bruns, dkorth, ngraham, kde-frameworks-devel, michaelh


D18237: Fix ResultIterator

2019-01-31 Thread Stefan Brüns
bruns added a comment.


  Oh, and you forgot to undelete the operator=, so this is still BIC ...

REPOSITORY
  R293 Baloo

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

To: aacid, #baloo, bruns, poboiko, apol
Cc: apol, kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, 
spoorun, ngraham, bruns, abrahams


D16894: [ECM] use a macro to add compiler flags conditionally

2019-01-31 Thread René J . V . Bertin
rjvbb added a comment.


  >   So according to you, this line is useful ? from my point of view, it's 
needless and just looks like a syntax error.
  
  Yes, it shows which compiler is being queried and for what. The line is going 
to be there anyway because CMake's Check*CompilerFlag macros don't have a QUIET 
option.
  
  We can discuss the exact dynamic variable name but since Cmake will not query 
the compiler twice for the same return variable the template should contain 
both the compiler ID and the flag being tested in order to cover all possible 
uses.
  I've considered trying to reset the cached result variable but we probably 
don't want to lose the benefits of that caching.

REPOSITORY
  R240 Extra CMake Modules

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

To: rjvbb, #build_system, kfunk
Cc: cgiboudeaux, dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, 
#build_system, michaelh, ngraham, bruns


D18237: Fix ResultIterator

2019-01-31 Thread Stefan Brüns
bruns added a comment.


  The correct way to **fix** this is by allocating a new ResultIteratorPrivate 
and "copying" the QStringList.

REPOSITORY
  R293 Baloo

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

To: aacid, #baloo, bruns, poboiko, apol
Cc: apol, kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, 
spoorun, ngraham, bruns, abrahams


D16894: [ECM] use a macro to add compiler flags conditionally

2019-01-31 Thread Christophe Giboudeaux
cgiboudeaux added a comment.


  In D16894#402901 , @rjvbb wrote:
  
  > > Forget that. The syntax is confusing, please remove this HASFLAG
  >
  > That I'm not going to do. The goal is to both to have useful feedback like 
below, and to avoid caching issues that would cause on the first query to be 
performed (if you were to use a single result variable):
  >
  >   -- Performing Test Clang++_ACCEPTS-Wvla
  >   ``
  
  
  So according to you, this line is useful ? from my point of view, it's 
needless and just looks like a syntax error.

REPOSITORY
  R240 Extra CMake Modules

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

To: rjvbb, #build_system, kfunk
Cc: cgiboudeaux, dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, 
#build_system, michaelh, ngraham, bruns


D18601: Rewrite taglib writer to use property interface

2019-01-31 Thread Stefan Brüns
bruns added a comment.


  I think this becomes better structured when you:
  
  1. Create one function per file type, with parameters (Taglib::Filestream, 
KFM::PropertyMap)
  2. From this function, call a generic `updateProperties(oldProperties, 
newProperties) -> mergedProperties`
  3. Call the type specific function from TaglibWriter::write(...)
  
  Especially when taking the changes for writing the rating into account, this 
would make the code easier to read - handling of different types just once (not 
once for reading and once for writing), and no upcasting/dynamic_cast of 
Taglib::File*.  It also saves the heap allocation of the concrete TagLib::File 
implementation.

REPOSITORY
  R286 KFileMetaData

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

To: astippich, bruns, mgallien, broulik, cfeck
Cc: kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, spoorun, 
ngraham, bruns, abrahams


D18604: Implement support for writing rating information for taglib writer

2019-01-31 Thread Stefan Brüns
bruns added inline comments.

INLINE COMMENTS

> taglibwritertest.cpp:409
> +QTest::addRow("mp3_0")
> +<< QStringLiteral("mp3")
> +<< QStringLiteral("audio/mpeg3")

What are the differences between the various mp3 test cases?

> taglibwriter.cpp:153
> +//map the rating values of WMP to Baloo rating
> +//0->0, 1->2, 25->4, 50->6, 75->8, 99->10
> +int rating = properties.value(Property::Rating).toInt();

This should probably go into a separate file, togheter with the inverse 
transform.

This can then be tested independently, i.e.

  for rating in {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10} {
r = wmpRating(rating);
Q_ASSERT(rating = balooRating(r)); }

REPOSITORY
  R286 KFileMetaData

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

To: astippich, bruns, mgallien
Cc: kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, spoorun, 
ngraham, bruns, abrahams


D16894: [ECM] use a macro to add compiler flags conditionally

2019-01-31 Thread René J . V . Bertin
rjvbb added a comment.


  > Forget that. The syntax is confusing, please remove this HASFLAG
  
  That I'm not going to do. The goal is to both to have useful feedback like 
below, and to avoid caching issues that would cause on the first query to be 
performed (if you were to use a single result variable):
  
-- Performing Test Clang++_ACCEPTS-Wvla
``

I decided against the idea of using a single macro name with a language 
parameter very early during development. It adds a parameter to each call or 
extra code to the macro to implement a default value, it can lead to errors 
that can remain undetected, and it deviates from the usual CMake syntax.

REPOSITORY
  R240 Extra CMake Modules

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

To: rjvbb, #build_system, kfunk
Cc: cgiboudeaux, dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, 
#build_system, michaelh, ngraham, bruns


D18601: Rewrite taglib writer to use property interface

2019-01-31 Thread Stefan Brüns
bruns added inline comments.

INLINE COMMENTS

> taglibwriter.cpp:123
>  
> -TagLib::Tag* tags = file.tag();
> +TagLib::File *file = openFile(, mimeType);
> +if (!file) {

use a smart pointer (unique_ptr, QScopedPtr) here, and get rid of the delete 
below.

REPOSITORY
  R286 KFileMetaData

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

To: astippich, bruns, mgallien, broulik, cfeck
Cc: kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, spoorun, 
ngraham, bruns, abrahams


D18163: Set the color scheme to Printing for Print Preview

2019-01-31 Thread Dominik Haumann
dhaumann accepted this revision.
dhaumann added a comment.


  Now this looks good to me.
  
  @mwolff: you also agree?

REPOSITORY
  R39 KTextEditor

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

To: ahmadsamir, cullmann, #ktexteditor, dhaumann, mwolff
Cc: kwrite-devel, kde-frameworks-devel, hase, michaelh, ngraham, bruns, 
demsking, cullmann, sars, dhaumann


D14467: Auth Support: Drop privileges if target is not owned by root

2019-01-31 Thread Matthias Gerstner
mgerstner added a comment.


  chinmoyr asked me to review this patch since I was involved with A CVE in 
similar code in kate / ktexteditor a while ago.
  
  Back then the logic was special purpose to replace a file in the file system 
with content provided via D-Bus. This here is a way more generic interface with 
a lot of file operations that complicates the security review quite a bit. I 
don't know whether this is well thought out in all cases ... for example: The 
OPEN action allows to specify arbitrary open flags and mode. So it can also be 
used to create new files. The calling application receives the resulting file 
descriptor ... this is a lot of power and each application that employs this 
interface would need to be checked in turn for safe usage of that file 
descriptor.
  
  Also the `mkdir()` with mode `0777` is a bit optimistic, shouldn't the caller 
specify the exact permissions? Maybe it should become a private directory.
  
  Regarding the `dropPrivileges()` I first have some coding related comments. 
It takes an `int action` where it should rather take an `enum ActionType` 
parameter. This adds a bit of type safety and makes more clear what kind of 
parameter is expected. Then I think the function wants to do to many things at 
once:
  
  - it checks whether a privilege drop is required at all
  - if so then it performs the privilege drop
  - the return value signals some kind of "should we continue" flag but not 
whether privileges have been dropped or not
  - it handles single-file operations as well as dual-file operations (rename)
  
  Better separating the logic might be a good idea. One function that 
determines whether a privilege drop is necessary and to which uid/gid 
privileges should be dropped to. Then another function that unconditionally 
performs the privilege drop. The case of a single file operation should be 
better separated from the dual-file operation which can become quite more 
complex to check.
  
  Now for a couple of security issues with this proposal:
  
  - in line 70 we have a case where no privileges are dropped but operation is 
still continued. When a rename of two paths is requested and both are owned by 
different users then there is no safe way to perform the rename as root user 
(actually the permissions of the parent directories are more important here but 
that is another issue). Such a case is fishy and I would maybe rather not 
perform the action than performing it in an unsafe way.
  - the `stat()` call is used to determine ownership. This follows symlinks.
  - you are operating on the path names all the time. This involves race 
conditions. I.e. the file object `stat()` is called for can be a different one 
than the one that `chown()` etc. is called upon.
  
  So you should open the files to operate on one time at the start of the call 
and then only operate on the file descriptors to be on the safe side. The 
`open()` should use `O_NOFOLLOW`. There is `fstat()` to get the ownership info 
of an open file descriptor. Then we have `fchmod()`, `fchown()`, `mkdirat()`, 
`unlinkat()`, `symlinkat()`, `futimes()` and so on. Only this way you can make 
sure that you're always operating on the same file system object.
  
  An example case for MKDIR. You get the request to MKDIR 
"/var/www/localhost/app/CGI". Following ownership situation:
  
-rw-r--r-- 1 apache apache 2.2K  3. Jan 10:53 /var/www/localhost/app
-rw-r--r-- 1 apache apache 2.4K  3. Jan 10:51 /var/www/localhost
  
  So your `dropPrivileges()` will look at /var/www/localhost/app to determine 
which user to drop privileges to. Suppose the `apache` user is compromised and 
simply replaces /var/www/localhost/app by a symlink to /root or so. Now your 
function thinks it needs to drop to root i.e. drop nothing at all. Before the 
actual `mkdir()` happens the evil apace user replaces the symlink by another 
one pointing to `/etc`. As a result the MKDIR operation will create a directory 
`/etc/CGI`.
  
  To prevent such a situation one safe approach is the following:
  
int pardir_fd = open("/var/www/localhost/app", O_DIRECTORY | O_PATH | 
O_NOFOLLOW);
struct stat info;
if( fstat(pardir_fd, ) != 0 )
// error handling

// drop privileges to info.st_uid and info.st_gid

// finally create the directory using just the basename
mkdirat(pardir_fd, "CGI", mode);

REPOSITORY
  R241 KIO

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

To: chinmoyr, dfaure, ngraham, elvisangelaccio, #frameworks, #dolphin
Cc: mgerstner, fvogt, kde-frameworks-devel, michaelh, ngraham, bruns


D18603: Implement more tags for taglib writer

2019-01-31 Thread Stefan Brüns
bruns added inline comments.

INLINE COMMENTS

> taglibwritertest.cpp:276
> +QFAIL("This mime type is not supported by the extractor. Likely a 
> newer KDE Frameworks version is required.");
> +KFileMetaData::Extractor* ex = extractorList.first();
> +KFileMetaData::SimpleExtractionResult 
> result(testFilePath(temporaryFileName), mimeType,

You should probably add a warning when `extractorList.size() > 1`, as in this 
case the extractor you run would be arbitrary.

Though, I am currently not aware of cases where one mimetype is supported by 
several extractors.

REPOSITORY
  R286 KFileMetaData

BRANCH
  enhance_taglibwriter

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

To: astippich, bruns, mgallien, ngraham
Cc: kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, spoorun, 
ngraham, bruns, abrahams


KDE CI: Frameworks » kwayland » kf5-qt5 FreeBSDQt5.12 - Build # 11 - Still Unstable!

2019-01-31 Thread CI System
BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kwayland/job/kf5-qt5%20FreeBSDQt5.12/11/
 Project:
kf5-qt5 FreeBSDQt5.12
 Date of build:
Thu, 31 Jan 2019 16:06:05 +
 Build duration:
19 min and counting
   JUnit Tests
  Name: projectroot.autotests Failed: 12 test(s), Passed: 30 test(s), Skipped: 0 test(s), Total: 42 test(s)Failed: projectroot.autotests.client.kwayland_testCompositorFailed: projectroot.autotests.client.kwayland_testDataDeviceFailed: projectroot.autotests.client.kwayland_testDataSourceFailed: projectroot.autotests.client.kwayland_testRegionFailed: projectroot.autotests.client.kwayland_testShmPoolFailed: projectroot.autotests.client.kwayland_testSubCompositorFailed: projectroot.autotests.client.kwayland_testSubSurfaceFailed: projectroot.autotests.client.kwayland_testWaylandConnectionThreadFailed: projectroot.autotests.client.kwayland_testWaylandRegistryFailed: projectroot.autotests.client.kwayland_testWaylandShellFailed: projectroot.autotests.client.kwayland_testWaylandSurfaceFailed: projectroot.autotests.server.kwayland_testWaylandServerDisplay

KDE CI: Frameworks » kwayland » kf5-qt5 FreeBSDQt5.12 - Build # 10 - Still Unstable!

2019-01-31 Thread CI System
BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kwayland/job/kf5-qt5%20FreeBSDQt5.12/10/
 Project:
kf5-qt5 FreeBSDQt5.12
 Date of build:
Thu, 31 Jan 2019 15:45:42 +
 Build duration:
20 min and counting
   JUnit Tests
  Name: projectroot.autotests Failed: 13 test(s), Passed: 29 test(s), Skipped: 0 test(s), Total: 42 test(s)Failed: projectroot.autotests.client.kwayland_testCompositorFailed: projectroot.autotests.client.kwayland_testDataDeviceFailed: projectroot.autotests.client.kwayland_testDataSourceFailed: projectroot.autotests.client.kwayland_testRegionFailed: projectroot.autotests.client.kwayland_testShmPoolFailed: projectroot.autotests.client.kwayland_testSubCompositorFailed: projectroot.autotests.client.kwayland_testSubSurfaceFailed: projectroot.autotests.client.kwayland_testWaylandConnectionThreadFailed: projectroot.autotests.client.kwayland_testWaylandRegistryFailed: projectroot.autotests.client.kwayland_testWaylandShellFailed: projectroot.autotests.client.kwayland_testWaylandSurfaceFailed: projectroot.autotests.client.kwayland_testXdgShellV5Failed: projectroot.autotests.server.kwayland_testWaylandServerDisplay

KDE CI: Frameworks » kwayland » kf5-qt5 SUSEQt5.10 - Build # 10 - Fixed!

2019-01-31 Thread CI System
BUILD SUCCESS
 Build URL
https://build.kde.org/job/Frameworks/job/kwayland/job/kf5-qt5%20SUSEQt5.10/10/
 Project:
kf5-qt5 SUSEQt5.10
 Date of build:
Thu, 31 Jan 2019 15:54:45 +
 Build duration:
9 min 25 sec and counting
   BUILD ARTIFACTS
  abi-compatibility-results.yamlcompat_reports/KF5Wayland_compat_report.htmllogs/KF5Wayland/5.54.0/log.txt
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.autotests Failed: 0 test(s), Passed: 46 test(s), Skipped: 0 test(s), Total: 46 test(s)
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report63%
(5/8)92%
(240/260)92%
(240/260)85%
(26817/31390)53%
(10748/20113)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests.client100%
(43/43)100%
(43/43)99%
(12301/12375)50%
(6469/12859)autotests.server100%
(5/5)100%
(5/5)99%
(373/376)49%
(177/360)src.client99%
(73/74)99%
(73/74)85%
(6280/7384)65%
(1808/2795)src.compat100%
(2/2)100%
(2/2)100%
(81/81)100%
(0/0)src.server100%
(117/117)100%
(117/117)87%
(7782/8978)66%
(2294/3470)src.tools0%
(0/2)0%
(0/2)0%
(0/785)0%
(0/302)src.tools.testserver0%
(0/3)0%
(0/3)0%
(0/120)0%
(0/14)tests0%
(0/14)0%
(0/14)0%
(0/1291)0%
(0/313)

KDE CI: Frameworks » kwayland » kf5-qt5 SUSEQt5.12 - Build # 3 - Fixed!

2019-01-31 Thread CI System
BUILD SUCCESS
 Build URL
https://build.kde.org/job/Frameworks/job/kwayland/job/kf5-qt5%20SUSEQt5.12/3/
 Project:
kf5-qt5 SUSEQt5.12
 Date of build:
Thu, 31 Jan 2019 15:45:42 +
 Build duration:
10 min and counting
   BUILD ARTIFACTS
  abi-compatibility-results.yamlcompat_reports/KF5Wayland_compat_report.htmllogs/KF5Wayland/5.54.0/log.txt
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.autotests Failed: 0 test(s), Passed: 46 test(s), Skipped: 0 test(s), Total: 46 test(s)
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report63%
(5/8)92%
(240/260)92%
(240/260)85%
(26815/31389)53%
(10748/20113)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests.client100%
(43/43)100%
(43/43)99%
(12299/12374)50%
(6469/12859)autotests.server100%
(5/5)100%
(5/5)99%
(373/376)49%
(177/360)src.client99%
(73/74)99%
(73/74)85%
(6280/7384)65%
(1808/2795)src.compat100%
(2/2)100%
(2/2)100%
(81/81)100%
(0/0)src.server100%
(117/117)100%
(117/117)87%
(7782/8978)66%
(2294/3470)src.tools0%
(0/2)0%
(0/2)0%
(0/785)0%
(0/302)src.tools.testserver0%
(0/3)0%
(0/3)0%
(0/120)0%
(0/14)tests0%
(0/14)0%
(0/14)0%
(0/1291)0%
(0/313)

KDE CI: Frameworks » kwayland » kf5-qt5 SUSEQt5.10 - Build # 9 - Still Unstable!

2019-01-31 Thread CI System
BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kwayland/job/kf5-qt5%20SUSEQt5.10/9/
 Project:
kf5-qt5 SUSEQt5.10
 Date of build:
Thu, 31 Jan 2019 15:45:42 +
 Build duration:
9 min 2 sec and counting
   BUILD ARTIFACTS
  abi-compatibility-results.yamlcompat_reports/KF5Wayland_compat_report.htmllogs/KF5Wayland/5.54.0/log.txt
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.autotests Failed: 1 test(s), Passed: 45 test(s), Skipped: 0 test(s), Total: 46 test(s)Failed: projectroot.autotests.client.kwayland_testRemoteAccess
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report63%
(5/8)92%
(240/260)92%
(240/260)85%
(26816/31391)53%
(10745/20113)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests.client100%
(43/43)100%
(43/43)99%
(12289/12374)50%
(6460/12859)autotests.server100%
(5/5)100%
(5/5)99%
(373/376)49%
(177/360)src.client99%
(73/74)99%
(73/74)85%
(6290/7386)65%
(1813/2795)src.compat100%
(2/2)100%
(2/2)100%
(81/81)100%
(0/0)src.server100%
(117/117)100%
(117/117)87%
(7783/8978)66%
(2295/3470)src.tools0%
(0/2)0%
(0/2)0%
(0/785)0%
(0/302)src.tools.testserver0%
(0/3)0%
(0/3)0%
(0/120)0%
(0/14)tests0%
(0/14)0%
(0/14)0%
(0/1291)0%
(0/313)

D18628: [server] Generate correct touch ids

2019-01-31 Thread Vlad Zagorodniy
This revision was automatically updated to reflect the committed changes.
Closed by commit R127:e167526d0bdb: [server] Generate correct touch ids 
(authored by zzag).

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18628?vs=50599=50606

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

AFFECTED FILES
  src/server/seat_interface.cpp

To: zzag, #kwin, davidedmundson
Cc: kde-frameworks-devel, michaelh, ngraham, bruns


D18421: [autotests] Stabilize testWindowmanagement

2019-01-31 Thread Vlad Zagorodniy
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R127:e6aa2c847df5: [autotests] Stabilize testWindowmanagement 
(authored by zzag).

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18421?vs=49970=50605

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

AFFECTED FILES
  autotests/client/test_wayland_windowmanagement.cpp

To: zzag, #kwin
Cc: kde-frameworks-devel, michaelh, ngraham, bruns


D18630: Fix warning

2019-01-31 Thread Aleix Pol Gonzalez
apol created this revision.
apol added a reviewer: Plasma.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
apol requested review of this revision.

REVISION SUMMARY
  org/kde/plasma/components.3/TextArea.qml:54:5: Unable to assign [undefined] 
to QQmlComponent*

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

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

AFFECTED FILES
  src/declarativeimports/plasmacomponents3/TextArea.qml

To: apol, #plasma
Cc: kde-frameworks-devel, michaelh, ngraham, bruns


D18628: [server] Generate correct touch ids

2019-01-31 Thread David Edmundson
davidedmundson accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R127 KWayland

BRANCH
  fix-test-wayland-set

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

To: zzag, #kwin, davidedmundson
Cc: kde-frameworks-devel, michaelh, ngraham, bruns


D16894: [ECM] use a macro to add compiler flags conditionally

2019-01-31 Thread Christophe Giboudeaux
cgiboudeaux added inline comments.

INLINE COMMENTS

> ECMAddCompilerFlag.cmake:108
> +check_cxx_compiler_flag(${flag} ${HASFLAG})
> +if({${HASFLAG}})
> +set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${flag}" 
> PARENT_SCOPE)

Forget that. The syntax is confusing, please remove this HASFLAG

REPOSITORY
  R240 Extra CMake Modules

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

To: rjvbb, #build_system, kfunk
Cc: cgiboudeaux, dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, 
#build_system, michaelh, ngraham, bruns


D18421: [autotests] Stabilize testWindowmanagement

2019-01-31 Thread Vlad Zagorodniy
zzag added a comment.


  If there are no objections, I'm going to land this revision.

REPOSITORY
  R127 KWayland

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

To: zzag, #kwin
Cc: kde-frameworks-devel, michaelh, ngraham, bruns


D16894: [ECM] use a macro to add compiler flags conditionally

2019-01-31 Thread Christophe Giboudeaux
cgiboudeaux added inline comments.

INLINE COMMENTS

> ECMAddCompilerFlag.cmake:108
> +check_cxx_compiler_flag(${flag} ${HASFLAG})
> +if({${HASFLAG}})
> +set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${flag}" 
> PARENT_SCOPE)

if(HASFLAG)

you're testing the result, not the string

REPOSITORY
  R240 Extra CMake Modules

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

To: rjvbb, #build_system, kfunk
Cc: cgiboudeaux, dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, 
#build_system, michaelh, ngraham, bruns


D18628: [server] Generate correct touch ids

2019-01-31 Thread Vlad Zagorodniy
zzag added a comment.


  I don't own any device with touchscreen. Could someone please test this patch?

REPOSITORY
  R127 KWayland

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

To: zzag, #kwin
Cc: kde-frameworks-devel, michaelh, ngraham, bruns


D18628: [server] Generate correct touch ids

2019-01-31 Thread Vlad Zagorodniy
zzag created this revision.
zzag added a reviewer: KWin.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
zzag requested review of this revision.

REVISION SUMMARY
  testWaylandSeat fails because the seat interface generates incorrect id
  for the second touch.

TEST PLAN
  testWaylandSeat passes.

REPOSITORY
  R127 KWayland

BRANCH
  fix-test-wayland-set

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

AFFECTED FILES
  src/server/seat_interface.cpp

To: zzag, #kwin
Cc: kde-frameworks-devel, michaelh, ngraham, bruns


D16894: [ECM] use a macro to add compiler flags conditionally

2019-01-31 Thread Christophe Giboudeaux
cgiboudeaux added a comment.


  In D16894#402701 , @rjvbb wrote:
  
  > >   There are tests for other ECM modules in the **tests** subdir.
  >
  > That's not the expected answer, so let me rephrase: which existing test can 
I clone and adapt (which is about the only thing I know how to do in this 
domain)?
  
  
  And the answer is the same, there are examples in the tests/ folder.
  
  > I'm going to need a hand here if not only because the only kind of testing 
that makes sense to me is checking manually with a selection of the compilers 
you happen to have installed. Anything automatic I can think of would not be 
able to do much more than taking the resulting CMAKE_??_FLAGS variable and 
check if the compiler indeed accepts all the arguments. That's basically just 
repeating the same tests already performed in the macro you're supposed to be 
testing and thus as much (if not more) a test of the input logic (the 
conditional expression(s)) as of the macro.
  
  The macro has different parameters.
  
  Things you can test:
  
  - Compiler flags accepted by all compilers (-Wall, -Wextra...)
  - flags only accepted by a given compiler. You can then check that it's not 
added by mistake to unsupported platforms
  
  About the code itself:
  The two functions are clones, this can be avoided by only having one 
ECM_ADD_COMPILER_FLAG function and a LANGUAGE argument.
  This has 2 benefits:
  
  - The module name matches the function name
  - it's shorter than ecm_add_cxx_compiler_flag_if_supported and easier to 
remember.

INLINE COMMENTS

> ECMAddCompilerFlag.cmake:94
> +# if the user provided conditions, evaluate them now to simplify things 
> later
> +if(EASCXXFLAGS_IF_SUPPORTED AND (${EASCXXFLAGS_IF_SUPPORTED}))
> +set(EASCXXFLAGS_is_supported ON)

EASCXXFLAGS_SUPPORTED_IF

> ECMAddCompilerFlag.cmake:98
> +if((EASCXXFLAGS_QUERY_IF AND (${EASCXXFLAGS_QUERY_IF}))
> +OR (NOT EASCXXFLAGS_IF_SUPPORTED AND NOT EASCXXFLAGS_QUERY_IF))
> +set(EASCXXFLAGS_needs_query ON)

EASCXXFLAGS_SUPPORTED_IF

> ECMAddCompilerFlag.cmake:129
> +# if the user provided conditions, evaluate them now to simplify things 
> later
> +if(EASCFLAGS_IF_SUPPORTED AND (${EASCFLAGS_IF_SUPPORTED}))
> +set(EASCFLAGS_is_supported ON)

EASCFLAGS_SUPPORTED_IF

> ECMAddCompilerFlag.cmake:133
> +if((EASCFLAGS_QUERY_IF AND (${EASCFLAGS_QUERY_IF}))
> +OR (NOT EASCFLAGS_IF_SUPPORTED AND NOT EASCFLAGS_QUERY_IF))
> +set(EASCFLAGS_needs_query ON)

EASCFLAGS_SUPPORTED_IF

REPOSITORY
  R240 Extra CMake Modules

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

To: rjvbb, #build_system, kfunk
Cc: cgiboudeaux, dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, 
#build_system, michaelh, ngraham, bruns


D18545: [breeze desktop theme/dialogs] Add rounded corners to dialogs

2019-01-31 Thread Krešimir Čohar
rooty added a comment.


  In D18545#402668 , @zzag wrote:
  
  > Shot in the dark: maybe purge cache?
  
  
  No change unfortunately.

REPOSITORY
  R242 Plasma Framework (Library)

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

To: rooty, #vdg, ngraham
Cc: zzag, davidedmundson, Codezela, filipf, kde-frameworks-devel, michaelh, 
ngraham, bruns


D16894: [ECM] use a macro to add compiler flags conditionally

2019-01-31 Thread René J . V . Bertin
rjvbb added a comment.


  >   There are tests for other ECM modules in the **tests** subdir.
  
  That's not the expected answer, so let me rephrase: which existing test can I 
clone and adapt (which is about the only thing I know how to do in this domain)?
  
  I'm going to need a hand here if not only because the only kind of testing 
that makes sense to me is checking manually with a selection of the compilers 
you happen to have installed. Anything automatic I can think of would not be 
able to do much more than taking the resulting CMAKE_??_FLAGS variable and 
check if the compiler indeed accepts all the arguments. That's basically just 
repeating the same tests already performed in the macro you're supposed to be 
testing and thus as much (if not more) a test of the input logic (the 
conditional expression(s)) as of the macro.

REPOSITORY
  R240 Extra CMake Modules

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

To: rjvbb, #build_system, kfunk
Cc: cgiboudeaux, dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, 
#build_system, michaelh, ngraham, bruns


D16894: [ECM] use a macro to add compiler flags conditionally

2019-01-31 Thread Christophe Giboudeaux
cgiboudeaux added a comment.


  In D16894#402364 , @rjvbb wrote:
  
  >
  
  
  
  
  > Christophe: can you please be more specific why sphinx fails? Also, is 
there an existing unittest I can clone and adapt?
  
  There are tests for other ECM modules in the **tests** subdir.

INLINE COMMENTS

> rjvbb wrote in ECMAddCompilerFlag.cmake:1-25
> I'm guessing you meant "Please move [...]" and not that this would somehow 
> happen automagically(?)

Indeed.

REPOSITORY
  R240 Extra CMake Modules

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

To: rjvbb, #build_system, kfunk
Cc: cgiboudeaux, dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, 
#build_system, michaelh, ngraham, bruns


D16894: [ECM] use a macro to add compiler flags conditionally

2019-01-31 Thread René J . V . Bertin
rjvbb set the repository for this revision to R240 Extra CMake Modules.

REPOSITORY
  R240 Extra CMake Modules

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

To: rjvbb, #build_system, kfunk
Cc: cgiboudeaux, dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, 
#build_system, michaelh, ngraham, bruns


D16894: [ECM] use a macro to add compiler flags conditionally

2019-01-31 Thread René J . V . Bertin
rjvbb updated this revision to Diff 50589.
rjvbb marked an inline comment as done.
rjvbb added a comment.


  Updated as requested.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D16894?vs=50451=50589

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

AFFECTED FILES
  docs/module/ECMAddCompilerFlag.rst
  kde-modules/KDECompilerSettings.cmake
  kde-modules/KDEFrameworkCompilerSettings.cmake
  modules/ECMAddCompilerFlag.cmake

To: rjvbb, #build_system, kfunk
Cc: cgiboudeaux, dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, 
#build_system, michaelh, ngraham, bruns


D16894: [ECM] use a macro to add compiler flags conditionally

2019-01-31 Thread René J . V . Bertin
rjvbb marked 9 inline comments as done.
rjvbb added inline comments.

INLINE COMMENTS

> cgiboudeaux wrote in ECMAddCompilerFlag.cmake:1-25
> Shall be moved after the module documentation

I'm guessing you meant "Please move [...]" and not that this would somehow 
happen automagically(?)

REPOSITORY
  R240 Extra CMake Modules

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

To: rjvbb, #build_system, kfunk
Cc: cgiboudeaux, dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, 
#build_system, michaelh, ngraham, bruns


T3689: Add abi compliance checker to CI

2019-01-31 Thread Dag Andersen
danders added a comment.


  I get ABI error on use of QPair and QSet in kdiagram:
  
https://build.kde.org/job/Calligra/job/kdiagram/job/kf5-qt5%20SUSEQt5.10/8/artifact/compat_reports/KGantt_compat_report.html#Type_Binary_Problems_Medium
  Afaics these lines have not been changed since last release.
  I have added a public getter to the class, but it does not complain about 
that, so...
  Also it does not complain about similar use in calligra (although not 
*exactly* the same, calligra uses other datatypes)
  Can anybody shed any light on this?

TASK DETAIL
  https://phabricator.kde.org/T3689

To: knauss, danders
Cc: danders, davidedmundson, dfaure, kde-frameworks-devel, bcooksley, sysadmin, 
scarlettclark, aacid, knauss, alexeymin, kaning, blazquez


D18163: Set the color scheme to Printing for Print Preview

2019-01-31 Thread Ahmad Samir
ahmadsamir marked 2 inline comments as done.

REPOSITORY
  R39 KTextEditor

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

To: ahmadsamir, cullmann, #ktexteditor, dhaumann, mwolff
Cc: kwrite-devel, kde-frameworks-devel, hase, michaelh, ngraham, bruns, 
demsking, cullmann, sars, dhaumann


D18163: Set the color scheme to Printing for Print Preview

2019-01-31 Thread Ahmad Samir
ahmadsamir updated this revision to Diff 50588.
ahmadsamir retitled this revision from "Set the color scheme to Printing when 
print preview'ing" to "Set the color scheme to Printing for Print Preview".
ahmadsamir added a comment.


  Use a setter

REPOSITORY
  R39 KTextEditor

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18163?vs=50503=50588

BRANCH
  print-preview-text-color (branched from master)

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

AFFECTED FILES
  src/printing/kateprinter.cpp

To: ahmadsamir, cullmann, #ktexteditor, dhaumann, mwolff
Cc: kwrite-devel, kde-frameworks-devel, hase, michaelh, ngraham, bruns, 
demsking, cullmann, sars, dhaumann


D18545: [breeze desktop theme/dialogs] Add rounded corners to dialogs

2019-01-31 Thread Vlad Zagorodniy
zzag added a comment.


  In D18545#402636 , @ngraham wrote:
  
  > It there indeed a bug in the KWin effect somewhere?
  
  
  I don't think so. Both the blur and the background contrast effect operate on 
regions. Rounded corners are approximated by a bunch of smaller rectangles.
  
  Shot in the dark: maybe purge cache?

REPOSITORY
  R242 Plasma Framework (Library)

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

To: rooty, #vdg, ngraham
Cc: zzag, davidedmundson, Codezela, filipf, kde-frameworks-devel, michaelh, 
ngraham, bruns


D15189: [KRun] Don’t follow redirection to speed up and avoid incorrect behavior

2019-01-31 Thread David Faure
dfaure accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R126 KDE CLI Utilities

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

To: achauvel, #frameworks, dfaure, cfeck
Cc: plasma-devel, anthonyfieroni, ngraham, kde-frameworks-devel, jraleigh, 
GB_2, ragreen, Pitel, michaelh, ZrenBot, bruns, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart