Re: Jenkins and XDG_DATA_DIRS

[Ben Cooksley]

On Mon, Mar 21, 2016 at 7:56 PM, Martin Graesslin  wrote:
> On Saturday, March 19, 2016 10:27:38 PM CET David Faure wrote:
>> It appears that something regressed in the jenkins setup.
>>
>> Almost all of the current failures in the "Frameworks kf5-qt5" group come
>> from XDG_DATA_DIRS not being set up correctly anymore, I think.
>> E.g. in
>> https://build.kde.org/view/Frameworks%20kf5-qt5/job/kio%20master%20kf5-qt5/
>> 269/PLATFORM=Linux,compiler=gcc/console * KUriFilterTest and others fail to
>> see the servicetype "KUriFilter/Plugin" which kio installs itself
>>
>> The kio job says
>>
>> export
>> XDG_DATA_DIRS="/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/frameworks/kw
>> idgetsaddons/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/f
>> rameworks/kauth/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt
>> 5/frameworks/sonnet/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf
>> 5-qt5/frameworks/knotifications/inst/usr/share:/srv/jenkins/install/ubuntu/x
>> 86_64/g++/kf5-qt5/kdesupport/extra-cmake-modules/inst/usr/share:/srv/jenkins
>> /install/ubuntu/x86_64/g++/kf5-qt5/frameworks/kdoctools/inst/usr/share:/srv/
>> jenkins/install/ubuntu/x86_64/g++/kf5-qt5/frameworks/ktextwidgets/inst/usr/s
>> hare:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/frameworks/kconfigwidget
>> s/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/frameworks/k
>> jobwidgets/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/fra
>> meworks/kcoreaddons/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf
>> 5-qt5/frameworks/breeze-icons/inst/usr/share:/srv/jenkins/install/ubuntu/x86
>> _64/g++/kf5-qt5/frameworks/kglobalaccel/inst/usr/share:/srv/jenkins/install/
>> ubuntu/x86_64/g++/kf5-qt5/frameworks/kservice/inst/usr/share:/srv/jenkins/in
>> stall/ubuntu/x86_64/g++/kf5-qt5/frameworks/kwallet/inst/usr/share:/srv/jenki
>> ns/install/ubuntu/x86_64/g++/kf5-qt5/kdesupport/phonon/phonon/inst/usr/share
>> :$XDG_DATA_DIRS:/usr/share:/usr/share"
>>
>> This is missing the dir for kio itself.
>>
>> Same kind of problem in kemoticonstest (which loads its own plugin),
>> frameworkintegration (same).
>>
>> Is this a voluntary change, as in, we should fix the tests to work without
>> the need to make install first?
>
> other frameworks affected by the CI-regression are:
> * kwindowsystem
> * kglobalaccel
>
> both cannot find their own plugin so I assume it's the same problem. I don't
> have the time to rework the tests to make them pass again, sorry :-(

From what i've been told, the necessary changes to the scripts should
now have been made to correct this.
A rebuild may be needed though.

>
> Cheers
> Martin

Regards,
Ben

> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127209: Fix some issues found by Coverity

[Aleix Pol Gonzalez]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127209/
---

(Updated March 22, 2016, 2:50 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 9ae6d765b37135bbfe3a8b936e5a88b8a435e424 by Aleix Pol to 
branch master.


Repository: kcoreaddons


Description
---

Mostly initializing values and using printf() correctly.


Diffs
-

  src/lib/io/kdirwatch.cpp f2fd3b8 
  src/lib/io/kprocess.cpp 07430f7 
  src/lib/io/kprocess_p.h 70fe91f 
  src/lib/kaboutdata.cpp a220977 
  src/lib/randomness/krandom.cpp bdbdec6 
  src/lib/util/kformatprivate.cpp 3d98007 

Diff: https://git.reviewboard.kde.org/r/127209/diff/


Testing
---


Thanks,

Aleix Pol Gonzalez

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127452: Handle left-button clicking on legacy systray icons

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127452/#review93849
---


Ship it!




Ship It!

- David Edmundson


On March 21, 2016, 7:23 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127452/
> ---
> 
> (Updated March 21, 2016, 7:23 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Bugs: 358589
> https://bugs.kde.org/show_bug.cgi?id=358589
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> As reported in https://bugs.kde.org/show_bug.cgi?id=358589 the left click
> is not handled when SNI host is not present and the legacy icon is used.
> 
> This adds handling of the left button.
> 
> 
> Diffs
> -
> 
>   src/kstatusnotifieritem.cpp f9bf460 
> 
> Diff: https://git.reviewboard.kde.org/r/127452/diff/
> 
> 
> Testing
> ---
> 
> According to David Jarvie in that bug report, it works.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127398: Add unit tests for KNotification and fix a whole bunch of issues uncovered thanks to them

[Martin Klapetek]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127398/
---

(Updated March 21, 2016, 10:59 p.m.)


Review request for KDE Frameworks.


Changes
---

Start assigning the ids at 0 rather than 1 with -1 still being invalid.

There's now a special test for the ids but it's limited as there's currently
no way to test the id changes other than those two. This would require a special
signal being useful only for the test, which I'm not sure is good to add?


Repository: knotifications


Description
---

Adds basic set of unit tests including fake notifications server.

This helped uncover and fix these issues:

* Calling close() on KNotification that was not "sent" would not emit closed() 
and would not delete it
* Closing a notification can delete the KNotification object prematurely
* Invoking an action leads to unnecessary dbus roundtrip
* Invoking an action would fail to properly close and delete the KNotification 
object


Diffs (updated)
-

  CMakeLists.txt 51f6c22 
  autotests/CMakeLists.txt PRE-CREATION 
  autotests/fake_notifications_server.h PRE-CREATION 
  autotests/fake_notifications_server.cpp PRE-CREATION 
  autotests/knotification_test.cpp PRE-CREATION 
  autotests/knotifications5/qttest.notifyrc PRE-CREATION 
  autotests/qtest_dbus.h PRE-CREATION 
  src/knotification.cpp 17b0be2 
  src/knotificationmanager.cpp e80d48c 
  src/knotificationplugin.cpp acf964c 
  src/notifybypopup.cpp c0050b2 

Diff: https://git.reviewboard.kde.org/r/127398/diff/


Testing
---

Unit tests all pass.


Thanks,

Martin Klapetek

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kdoctools master kf5-qt5 » Linux,gcc - Build # 1 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kdoctools%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/1/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 21 Mar 2016 19:44:48 +
Build duration: 1.3 sec

CHANGE SET
No changes
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: ki18n master stable-kf5-qt5 » Linux,gcc - Build # 1 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/ki18n%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/1/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 21 Mar 2016 19:44:40 +
Build duration: 1.6 sec

CHANGE SET
No changes
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kdoctools master stable-kf5-qt5 » Linux,gcc - Build # 1 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kdoctools%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/1/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 21 Mar 2016 19:44:49 +
Build duration: 1.4 sec

CHANGE SET
No changes
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: karchive master kf5-qt5 » Linux,gcc - Build # 1 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/karchive%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/1/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 21 Mar 2016 19:44:15 +
Build duration: 1.4 sec

CHANGE SET
No changes
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: karchive master stable-kf5-qt5 » Linux,gcc - Build # 1 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/karchive%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/1/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 21 Mar 2016 19:44:17 +
Build duration: 1.3 sec

CHANGE SET
No changes
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127424: KCompletionBox popup gets full window decoration on Windows

[Dominik Haumann]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127424/#review93837
---



ping

- Dominik Haumann


On March 20, 2016, 12:06 p.m., Dominik Haumann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127424/
> ---
> 
> (Updated March 20, 2016, 12:06 p.m.)
> 
> 
> Review request for KDE Frameworks, kdewin, kwin, and Marco Martin.
> 
> 
> Repository: kcompletion
> 
> 
> Description
> ---
> 
> In https://git.reviewboard.kde.org/r/127191/ the KCompletionBox WindowFlags 
> were change from Qt::ToolTip to Qt::Window.
> 
> As consequence, the completion popup of the Kate command line gets a full 
> window decoration, which is obviously wrong, see attached screenshot.
> 
> Changing the type to Qt::Popup shows the proper popup, but key presses are 
> not forwarded, so typing is not possible, and additionally, on losing focus 
> the popup keeps staying open.
> Therefore, this patch reverts the type back to Qt::ToolTip.
> 
> Better fixes are of course welcome ;) Any ideas?
> 
> 
> Diffs
> -
> 
>   src/kcompletionbox.cpp 005aff8 
> 
> Diff: https://git.reviewboard.kde.org/r/127424/diff/
> 
> 
> Testing
> ---
> 
> Works on Windows as expected.
> 
> 
> File Attachments
> 
> 
> Completion Popup
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/03/19/7be64cad-6d95-46b8-9caa-41b41a135ca1__kate2015.png
> 
> 
> Thanks,
> 
> Dominik Haumann
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 127452: Handle left-button clicking on legacy systray icons

[Martin Klapetek]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127452/
---

Review request for KDE Frameworks.


Bugs: 358589
https://bugs.kde.org/show_bug.cgi?id=358589


Repository: knotifications


Description
---

As reported in https://bugs.kde.org/show_bug.cgi?id=358589 the left click
is not handled when SNI host is not present and the legacy icon is used.

This adds handling of the left button.


Diffs
-

  src/kstatusnotifieritem.cpp f9bf460 

Diff: https://git.reviewboard.kde.org/r/127452/diff/


Testing
---

According to David Jarvie in that bug report, it works.


Thanks,

Martin Klapetek

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127398: Add unit tests for KNotification and fix a whole bunch of issues uncovered thanks to them

[Albert Astals Cid]

> On March 18, 2016, 5:20 a.m., Anthony Fieroni wrote:
> > src/knotification.cpp, line 63
> > 
> >
> > ref can't be UINT_MAX, but id can, no? Negative rage will brake all, 
> > it's this possible, maybe not. Counters it's not good idea to be signed.
> 
> Martin Klapetek wrote:
> Yes...if your application will emit more than 32767 notifications in its 
> lifetime. At which point the application is probalby broken.
> 
> Albert Astals Cid wrote:
> Is it? I don't use KTP, but assuming KTP sends Knotifications and 
> assuming you get like 1 chat notification per minute (not crazy imho) get say 
> around 500 notifications per day, so in 66 days you'd go over the limit. Sure 
> it's corner-case-y but i would not call it impossible nor the app being broken
> 
> Martin Klapetek wrote:
> This wouldn't actually break in the KTp case (in normal KNotification 
> usage, the id is not really needed), however this code (going back to 2009) 
> apparently chose real-life pragmatism over such corner cases.
> 
> To expand on that, the id uses values -1 and -2 to indicate "invalid" and 
> "about to be deleted" states. I can either introduce some bool/enum making 
> every "if (..)" twice as complicated, or start the counter from 2, reserving 
> 0 and 1. Tbh given this wasn't a problem for the past 7 years, I don't think 
> the code needs to be more complex making special assumptions for highly 
> unlikely corner cases.

ok, a bug to fix/discuss later in time :)


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127398/#review93676
---


On March 16, 2016, 8:23 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127398/
> ---
> 
> (Updated March 16, 2016, 8:23 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> Adds basic set of unit tests including fake notifications server.
> 
> This helped uncover and fix these issues:
> 
> * Calling close() on KNotification that was not "sent" would not emit 
> closed() and would not delete it
> * Closing a notification can delete the KNotification object prematurely
> * Invoking an action leads to unnecessary dbus roundtrip
> * Invoking an action would fail to properly close and delete the 
> KNotification object
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 6d09051 
>   autotests/CMakeLists.txt PRE-CREATION 
>   autotests/fake_notifications_server.h PRE-CREATION 
>   autotests/fake_notifications_server.cpp PRE-CREATION 
>   autotests/knotification_test.cpp PRE-CREATION 
>   autotests/knotifications5/qttest.notifyrc PRE-CREATION 
>   autotests/qtest_dbus.h PRE-CREATION 
>   src/knotification.cpp 17b0be2 
>   src/knotificationmanager.cpp e80d48c 
>   src/knotificationplugin.cpp acf964c 
>   src/notifybypopup.cpp b9489c1 
> 
> Diff: https://git.reviewboard.kde.org/r/127398/diff/
> 
> 
> Testing
> ---
> 
> Unit tests all pass.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127437: Fix many threading issues in KUrlCompletion

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127437/#review93829
---




src/widgets/kurlcompletion.cpp (line 1362)


this looks wrong, shouldn't it be insertItems (or ::addMatches which does 
the same thing)

we'll get this method called twice, once for each thread that takes longer 
than the initial timeout, setItems will discard matches from the first thread.


- David Edmundson


On March 20, 2016, 2:46 p.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127437/
> ---
> 
> (Updated March 20, 2016, 2:46 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> * Major race with other threads due to using QDir::setCurrent()
> * Race conditions on m_terminationRequested and m_matches
> * Race with previous completion thread when its posted event arrives after 
> cancelling
> * Cancellation code spread out in many methods and never done fully correctly
> * isRunning() was missing one of the two threads, making unit test fail in 
> valgrind
> * Fix the rarely-hit code path where the thread isn't finished after 200ms
>- the current search string was lost because finished() wasn't called
>- the matches were not used, in case of user-completion (AFAICS)
>- changing the search string while the thread was running could lead to 
> the old search
>  string still being used for completion
>  (the misnamed finished() wasn't called, so KCompletion didn't get the 
> new string)
>   => added a variant of the unittest which doesn't wait for the thread 
> initially
> 
> + Simplify code using signal/slots rather than a custom event
> + Simplify code using enum rather than casting to/from int
> 
> Most of these bugs are from 2004 (e.g. commit ec83c408619e3) ;)
> 
> REVIEW: 127437
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 4dff0a24d31897a9641a70017bd87e33415cef14 
>   autotests/kurlcompletiontest.cpp eef39ff17940fadcb9492e5e7092070c976310d4 
>   src/widgets/CMakeLists.txt 87dac50b377f6ea4c3cd39e9afa37a4680aecf31 
>   src/widgets/kurlcompletion.h 14fda22a0e08bcf2da30e19fed577c8bda64a4ca 
>   src/widgets/kurlcompletion.cpp 1dc8f4898fb78d6f49e687462446007a10305f98 
> 
> Diff: https://git.reviewboard.kde.org/r/127437/diff/
> 
> 
> Testing
> ---
> 
> Hit a crash in DirectoryListThread when playing with kopenwithtest.
> 
> kurlcompletiontest extended, kurlcompletion-nowait added, both pass, also in 
> valgrind (different timings).
> 
> 
> Thanks,
> 
> David Faure
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127398: Add unit tests for KNotification and fix a whole bunch of issues uncovered thanks to them

[Martin Klapetek]

> On March 18, 2016, 6:20 a.m., Anthony Fieroni wrote:
> > src/knotification.cpp, line 63
> > 
> >
> > ref can't be UINT_MAX, but id can, no? Negative rage will brake all, 
> > it's this possible, maybe not. Counters it's not good idea to be signed.
> 
> Martin Klapetek wrote:
> Yes...if your application will emit more than 32767 notifications in its 
> lifetime. At which point the application is probalby broken.
> 
> Albert Astals Cid wrote:
> Is it? I don't use KTP, but assuming KTP sends Knotifications and 
> assuming you get like 1 chat notification per minute (not crazy imho) get say 
> around 500 notifications per day, so in 66 days you'd go over the limit. Sure 
> it's corner-case-y but i would not call it impossible nor the app being broken

This wouldn't actually break in the KTp case (in normal KNotification usage, 
the id is not really needed), however this code (going back to 2009) apparently 
chose real-life pragmatism over such corner cases.

To expand on that, the id uses values -1 and -2 to indicate "invalid" and 
"about to be deleted" states. I can either introduce some bool/enum making 
every "if (..)" twice as complicated, or start the counter from 2, reserving 0 
and 1. Tbh given this wasn't a problem for the past 7 years, I don't think the 
code needs to be more complex making special assumptions for highly unlikely 
corner cases.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127398/#review93676
---


On March 16, 2016, 9:23 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127398/
> ---
> 
> (Updated March 16, 2016, 9:23 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> Adds basic set of unit tests including fake notifications server.
> 
> This helped uncover and fix these issues:
> 
> * Calling close() on KNotification that was not "sent" would not emit 
> closed() and would not delete it
> * Closing a notification can delete the KNotification object prematurely
> * Invoking an action leads to unnecessary dbus roundtrip
> * Invoking an action would fail to properly close and delete the 
> KNotification object
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 6d09051 
>   autotests/CMakeLists.txt PRE-CREATION 
>   autotests/fake_notifications_server.h PRE-CREATION 
>   autotests/fake_notifications_server.cpp PRE-CREATION 
>   autotests/knotification_test.cpp PRE-CREATION 
>   autotests/knotifications5/qttest.notifyrc PRE-CREATION 
>   autotests/qtest_dbus.h PRE-CREATION 
>   src/knotification.cpp 17b0be2 
>   src/knotificationmanager.cpp e80d48c 
>   src/knotificationplugin.cpp acf964c 
>   src/notifybypopup.cpp b9489c1 
> 
> Diff: https://git.reviewboard.kde.org/r/127398/diff/
> 
> 
> Testing
> ---
> 
> Unit tests all pass.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127398: Add unit tests for KNotification and fix a whole bunch of issues uncovered thanks to them

[Albert Astals Cid]

> On March 18, 2016, 5:20 a.m., Anthony Fieroni wrote:
> > src/knotification.cpp, line 63
> > 
> >
> > ref can't be UINT_MAX, but id can, no? Negative rage will brake all, 
> > it's this possible, maybe not. Counters it's not good idea to be signed.
> 
> Martin Klapetek wrote:
> Yes...if your application will emit more than 32767 notifications in its 
> lifetime. At which point the application is probalby broken.

Is it? I don't use KTP, but assuming KTP sends Knotifications and assuming you 
get like 1 chat notification per minute (not crazy imho) get say around 500 
notifications per day, so in 66 days you'd go over the limit. Sure it's 
corner-case-y but i would not call it impossible nor the app being broken


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127398/#review93676
---


On March 16, 2016, 8:23 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127398/
> ---
> 
> (Updated March 16, 2016, 8:23 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> Adds basic set of unit tests including fake notifications server.
> 
> This helped uncover and fix these issues:
> 
> * Calling close() on KNotification that was not "sent" would not emit 
> closed() and would not delete it
> * Closing a notification can delete the KNotification object prematurely
> * Invoking an action leads to unnecessary dbus roundtrip
> * Invoking an action would fail to properly close and delete the 
> KNotification object
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 6d09051 
>   autotests/CMakeLists.txt PRE-CREATION 
>   autotests/fake_notifications_server.h PRE-CREATION 
>   autotests/fake_notifications_server.cpp PRE-CREATION 
>   autotests/knotification_test.cpp PRE-CREATION 
>   autotests/knotifications5/qttest.notifyrc PRE-CREATION 
>   autotests/qtest_dbus.h PRE-CREATION 
>   src/knotification.cpp 17b0be2 
>   src/knotificationmanager.cpp e80d48c 
>   src/knotificationplugin.cpp acf964c 
>   src/notifybypopup.cpp b9489c1 
> 
> Diff: https://git.reviewboard.kde.org/r/127398/diff/
> 
> 
> Testing
> ---
> 
> Unit tests all pass.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127398: Add unit tests for KNotification and fix a whole bunch of issues uncovered thanks to them

[Martin Klapetek]

> On March 18, 2016, 6:20 a.m., Anthony Fieroni wrote:
> > src/knotification.cpp, line 63
> > 
> >
> > ref can't be UINT_MAX, but id can, no? Negative rage will brake all, 
> > it's this possible, maybe not. Counters it's not good idea to be signed.

Yes...if your application will emit more than 32767 notifications in its 
lifetime. At which point the application is probalby broken.


> On March 18, 2016, 6:20 a.m., Anthony Fieroni wrote:
> > src/knotificationmanager.cpp, line 168
> > 
> >
> > force = true, id not present how can take value? force is compromised

The force is actually unused and should go at some later point.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127398/#review93676
---


On March 16, 2016, 9:23 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127398/
> ---
> 
> (Updated March 16, 2016, 9:23 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> Adds basic set of unit tests including fake notifications server.
> 
> This helped uncover and fix these issues:
> 
> * Calling close() on KNotification that was not "sent" would not emit 
> closed() and would not delete it
> * Closing a notification can delete the KNotification object prematurely
> * Invoking an action leads to unnecessary dbus roundtrip
> * Invoking an action would fail to properly close and delete the 
> KNotification object
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 6d09051 
>   autotests/CMakeLists.txt PRE-CREATION 
>   autotests/fake_notifications_server.h PRE-CREATION 
>   autotests/fake_notifications_server.cpp PRE-CREATION 
>   autotests/knotification_test.cpp PRE-CREATION 
>   autotests/knotifications5/qttest.notifyrc PRE-CREATION 
>   autotests/qtest_dbus.h PRE-CREATION 
>   src/knotification.cpp 17b0be2 
>   src/knotificationmanager.cpp e80d48c 
>   src/knotificationplugin.cpp acf964c 
>   src/notifybypopup.cpp b9489c1 
> 
> Diff: https://git.reviewboard.kde.org/r/127398/diff/
> 
> 
> Testing
> ---
> 
> Unit tests all pass.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: ki18n master kf5-qt5 » Linux,gcc - Build # 1 - Successful!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/ki18n%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/1/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 21 Mar 2016 16:56:58 +
Build duration: 1 min 26 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 4 test(s), Skipped: 0 test(s), Total: 4 
test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 18/20 (90%)CLASSES 18/20 (90%)LINE 1840/3039 
(61%)CONDITIONAL 884/1404 (63%)

By packages
  
autotests
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 396/466 (85%)CONDITIONAL 
174/346 (50%)
src
FILES 10/12 (83%)CLASSES 10/12 (83%)LINE 1444/2573 
(56%)CONDITIONAL 710/1058 (67%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127448: After installing a package, load it

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127448/
---

(Updated March 21, 2016, 4:20 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Plasma.


Repository: kpackage


Description
---

right now, to install a package from a tarball, you create an invalid package 
instance and then use its install method.
we don't know for sure what will be its final installation path, and is not 
easy to know it (one can blindly connect to the private 
PackageJob::installPathChanged, but that's an hack)
With this patch, the invalid instance used as installer, will load the package 
itself when the install job is finished, so if you connect to its finished 
signal, you are guaranteed the package instance is directly usable after that 
(provided the job didn't have any fatal errors)


Diffs
-

  autotests/plasmoidpackagetest.cpp eeaa0a3 
  src/kpackage/package.h 4ff4c70 
  src/kpackage/packagestructure.cpp accc5d1 
  src/kpackage/private/packagejob.cpp 76614a0 
  src/kpackage/private/packagejob_p.h acafa5e 

Diff: https://git.reviewboard.kde.org/r/127448/diff/


Testing
---

autotest included


Thanks,

Marco Martin

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127448: After installing a package, load it

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127448/#review93825
---


Ship it!




Ship It!

- David Edmundson


On March 21, 2016, 3:50 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127448/
> ---
> 
> (Updated March 21, 2016, 3:50 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kpackage
> 
> 
> Description
> ---
> 
> right now, to install a package from a tarball, you create an invalid package 
> instance and then use its install method.
> we don't know for sure what will be its final installation path, and is not 
> easy to know it (one can blindly connect to the private 
> PackageJob::installPathChanged, but that's an hack)
> With this patch, the invalid instance used as installer, will load the 
> package itself when the install job is finished, so if you connect to its 
> finished signal, you are guaranteed the package instance is directly usable 
> after that (provided the job didn't have any fatal errors)
> 
> 
> Diffs
> -
> 
>   autotests/plasmoidpackagetest.cpp eeaa0a3 
>   src/kpackage/package.h 4ff4c70 
>   src/kpackage/packagestructure.cpp accc5d1 
>   src/kpackage/private/packagejob.cpp 76614a0 
>   src/kpackage/private/packagejob_p.h acafa5e 
> 
> Diff: https://git.reviewboard.kde.org/r/127448/diff/
> 
> 
> Testing
> ---
> 
> autotest included
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 127448: After installing a package, load it

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127448/
---

Review request for KDE Frameworks and Plasma.


Repository: kpackage


Description
---

right now, to install a package from a tarball, you create an invalid package 
instance and then use its install method.
we don't know for sure what will be its final installation path, and is not 
easy to know it (one can blindly connect to the private 
PackageJob::installPathChanged, but that's an hack)
With this patch, the invalid instance used as installer, will load the package 
itself when the install job is finished, so if you connect to its finished 
signal, you are guaranteed the package instance is directly usable after that 
(provided the job didn't have any fatal errors)


Diffs
-

  autotests/plasmoidpackagetest.cpp eeaa0a3 
  src/kpackage/package.h 4ff4c70 
  src/kpackage/packagestructure.cpp accc5d1 
  src/kpackage/private/packagejob.cpp 76614a0 
  src/kpackage/private/packagejob_p.h acafa5e 

Diff: https://git.reviewboard.kde.org/r/127448/diff/


Testing
---

autotest included


Thanks,

Marco Martin

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125965: Add declarative plugin to KHolidays

[Martin Klapetek]

> On Nov. 6, 2015, 3:29 p.m., Nick Shaforostoff wrote:
> > src/declarative/holidayregionsmodel.cpp, line 81
> > 
> >
> > i suggest enclosing strings into QByteArrayLiteral.
> > 
> > see http://woboq.com/blog/qstringliteral.html for explanation and 
> > https://gitlab.com/pteam/pteam-qtbase/commit/05663e29d047851adb9a1ef440fb78b38ff3cc9b
> >  for the case when QBAL are not suitable
> 
> Martin Klapetek wrote:
> Is QByteArrayLiteral available in Qt 5.4? I can't find any info about it 
> anywhere.
> 
> David Faure wrote:
> Anywhere? You know qtbase.git right? :-)
> Yes QByteArrayLiteral is available in 5.4, it is as old as QStringLiteral 
> (i.e. in 5.0.0 already, see qtbase ad35a41739c8e1fb6db62ed37b764448b2e59ece). 
> The difference is that it's not documented, however, not sure why.

I admit I don't have a Qt checkout on my disk since I stopped
building it myself but yeah, should have looked there :)

Will push a fix then.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125965/#review88099
---


On March 16, 2016, 10:24 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125965/
> ---
> 
> (Updated March 16, 2016, 10:24 p.m.)
> 
> 
> Review request for KDE Frameworks and John Layt.
> 
> 
> Repository: kholidays
> 
> 
> Description
> ---
> 
> For now it contains just the model of holiday regions
> which will be used in the Plasma calendar events
> configuration.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt e8b7970 
>   src/CMakeLists.txt c067b6c 
>   src/declarative/CMakeLists.txt PRE-CREATION 
>   src/declarative/holidayregionsmodel.h PRE-CREATION 
>   src/declarative/holidayregionsmodel.cpp PRE-CREATION 
>   src/declarative/kholidaysdeclarativeplugin.h PRE-CREATION 
>   src/declarative/kholidaysdeclarativeplugin.cpp PRE-CREATION 
>   src/declarative/qmldir PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125965/diff/
> 
> 
> Testing
> ---
> 
> Applet configuration contains proper list of available
> holiday regions.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Qt 5.6/QtWebkit (got it, now to build it)

[René J . V . Bertin]

Antonio Rojas wrote:


> Besides generating headers with syncqt.pl, you need to backport a patch to
> fix linking to pthread

Yeah, that's on Linux, though I got the impression not everyone had to apply 
the 
patch.

I'm homing in on whatever issue it is that causes my standalone build to fail 
when I do it via my build/packaging scripts and not manually from the shell. 
It's very weird really, because the build works fine through those scripts when 
I 
set up qtwebkit to build as part of the monolithic build as I always used to do.
The trick to that is to use the sources from git, not the "official" release 
tarball.

Oh, and if there's a .git directory in an in-tree build, qmake will invoke 
syncqt for you.

R.

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127031: Add function to get runtime frameworks version information

[Jarosław Staniek]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127031/#review93814
---



Just wanted to say: thanks for this addition! It is useful for collecting 
feedback/support information (Kexi does it per user demand as a part of its QA 
-- https://blogs.kde.org/2013/12/09/usage-stats).

- Jarosław Staniek


On Feb. 25, 2016, 2:02 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127031/
> ---
> 
> (Updated Feb. 25, 2016, 2:02 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> Adds a method similar to qVersion() that returns a string of the
> frameworks version being run. This differs from the header file which
> can only provide the version this app is compiled against.
> 
> The intended usage is in drkonqi system information.
> 
> 
> Diffs
> -
> 
>   src/lib/CMakeLists.txt a36eed26a281baf9ef1064dfb9aed3c394c52604 
>   src/lib/kcoreaddons.h PRE-CREATION 
>   src/lib/kcoreaddons.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/127031/diff/
> 
> 
> Testing
> ---
> 
> See https://git.reviewboard.kde.org/r/127032/
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Equivalent of KDE::version*()?

[Jaroslaw Staniek]

On 29 September 2015 at 09:32, David Faure  wrote:

> On Monday 15 June 2015 22:23:17 Jaroslaw Staniek wrote:
> > Hi,
> > One would need a need runtime version information of particular kf5
> > libraries -- in addition to version with which the software has been
> > built.
> >
> > It seems that mostly Plasma and KActivities have equivalent of runtime
> > version information.
> > I am not looking build-time *_version.h files generated (with
> > *_VERSION_* macros) but something like
> > plasma-framework/src/plasma/version.h.
> >
> > Attica is a good exception here, I cannot spot anything else.
> >
> > PS: Maybe the code can be generated?
>
> What would this be useful for? Working around bugs?
>

Sorry, late reply... ​As a last resort, yes.
But the original though is to know the version(s) when collecting
feedback/support information (Kexi does it per user demand as a part of its
QA).

My plan was rather not to have bugs in the first place :-)
> Yeah yeah, I know ;)
>
> If there's usefulness in this, we could generate some code indeed
> (ECM to the rescue once more...).
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>



-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126883: Add Package::cryptographicHash(QCryptographicHash::Algorithm)

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126883/
---

(Updated March 21, 2016, 10:10 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Plasma and Marco Martin.


Changes
---

Submitted with commit 30b189954387d4c17819e60dff0b4f31e3e11c38 by Martin 
Gräßlin to branch master.


Repository: kpackage


Description
---

This method is intended to replace contentsHash which operates only
on Sha1. In order to support more secure hashing algorithmns and also
to support future developments the new implementation does not hard
code the algorithm but allows to specify it. By that the existing
implementation can just delegate to the new one.

Another change in the implementation is that the new cryptographicHash
method returns a QByteArray instead of a QString. As only a hex
representation of the hash is returned the conversion to QString is
not necessary.

Package::contentsHash() is marked as deprecated.


Diffs
-

  autotests/plasmoidpackagetest.cpp 69f45f57bbec5c0f6d2268869249606c50338765 
  src/kpackage/package.h b97b70be42df7d9fd09e3fb4e7b82b00ef970be3 
  src/kpackage/package.cpp 4c0f671965d9ed33b9f52b06205bf6ffcda94c8a 

Diff: https://git.reviewboard.kde.org/r/126883/diff/


Testing
---


Thanks,

Martin Gräßlin

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: oxygen icon name clasheroo

[Harald Sitter]

On Sun, Mar 20, 2016 at 10:08 AM, David Faure  wrote:
> On Wednesday 16 March 2016 15:57:45 Harald Sitter wrote:
>> Hola!
>>
>> Our most awesome icon maintainers wanted to carry over icon symlinking
>> from breeze to oxygen, alas that turned up a whole slew of
>> compatibility problems.
>>
>> examples:
>> https://bugs.kde.org/show_bug.cgi?id=360605
>> https://bugs.kde.org/show_bug.cgi?id=360510
>>
>> # Problem
>> In kde4 software people used oxygen as the standard icon set and
>> installed their own icons there. Since breeze covers all icons ever,
>> replicating its coverage into oxygen means we have a million conflicts
>> with (older?) tarballs of existing software that also install icons
>> into oxygen under the same name.
>>
>> # Proposal
>> We could get rid of this and all future conflicts if we shift the
>> default oxygen icons into a subdirectory.
>>
>> So, we install the default icons to
>>
>> $prefix/share/icons/oxygen/base/22x22
>> $prefix/share/icons/oxygen/base/32x32
>> $prefix/share/icons/oxygen/base/...
>>
>> applications can thus continue to install to
>>
>> $prefix/share/icons/oxygen/22x22
>> $prefix/share/icons/oxygen/32x32
>> $prefix/share/icons/oxygen/...
>>
>> without conflicting with our base files what so ever.
>>
>> Downside of this is that the index.theme basically needs to list
>> everything twice (once for base and once for main directory), which
>> unfortunately incurs a bit of a runtime overhead. This is a bit of a
>> crap situation we are in and I can't think of another solution to
>> this.
>
> This doesn't sound like it matches the freedesktop.org icon theme spec.

How so?
https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html

Directories
list of subdirectories for this theme. For every subdirectory there
must be a section in the index.theme file describing that directory.

e.g. Directories=base/32x32/actions,32x32/actions

and then Table 2. Per-Directory Keys

[base/32x32/actions]
Size=32
Context=Actions

[32x32/actions]
Size=32
Context=Actions

> But if you rename oxygen/base/ to oxygen, and oxygen/ to hicolor, then it 
> does, AFAIK

We can't really change oxygen/ at all, that's kind of the problem.
Since existing apps install stuff into oxygen/ and expect it to be
used by default in a kdelibs4 context. What we could do is make
oxygen-base a standalone theme and link "oxygen" with "oxygen-base"
through inheritance.
That's not quite as good though because we want to override
application icons through the actual theme. So what we would need is
"oxygen-base" to be the selected theme and then inherit "oxygen"
(where apps install icons) to be the fallback. Since the uid of a
theme is its folder name and we can't feasibly change that without
breaking something that's not really useful either.

That said, we could go down the two theme route and simply accept that
applications that install to "oxygen" will be overriding consistent
theme icons from "oxygen-base". I'd rather deal with the directories
approach outlined above.

HS
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Jenkins and XDG_DATA_DIRS

[Martin Graesslin]

On Saturday, March 19, 2016 10:27:38 PM CET David Faure wrote:
> It appears that something regressed in the jenkins setup.
> 
> Almost all of the current failures in the "Frameworks kf5-qt5" group come
> from XDG_DATA_DIRS not being set up correctly anymore, I think.
> E.g. in
> https://build.kde.org/view/Frameworks%20kf5-qt5/job/kio%20master%20kf5-qt5/
> 269/PLATFORM=Linux,compiler=gcc/console * KUriFilterTest and others fail to
> see the servicetype "KUriFilter/Plugin" which kio installs itself
> 
> The kio job says
> 
> export
> XDG_DATA_DIRS="/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/frameworks/kw
> idgetsaddons/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/f
> rameworks/kauth/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt
> 5/frameworks/sonnet/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf
> 5-qt5/frameworks/knotifications/inst/usr/share:/srv/jenkins/install/ubuntu/x
> 86_64/g++/kf5-qt5/kdesupport/extra-cmake-modules/inst/usr/share:/srv/jenkins
> /install/ubuntu/x86_64/g++/kf5-qt5/frameworks/kdoctools/inst/usr/share:/srv/
> jenkins/install/ubuntu/x86_64/g++/kf5-qt5/frameworks/ktextwidgets/inst/usr/s
> hare:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/frameworks/kconfigwidget
> s/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/frameworks/k
> jobwidgets/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/fra
> meworks/kcoreaddons/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf
> 5-qt5/frameworks/breeze-icons/inst/usr/share:/srv/jenkins/install/ubuntu/x86
> _64/g++/kf5-qt5/frameworks/kglobalaccel/inst/usr/share:/srv/jenkins/install/
> ubuntu/x86_64/g++/kf5-qt5/frameworks/kservice/inst/usr/share:/srv/jenkins/in
> stall/ubuntu/x86_64/g++/kf5-qt5/frameworks/kwallet/inst/usr/share:/srv/jenki
> ns/install/ubuntu/x86_64/g++/kf5-qt5/kdesupport/phonon/phonon/inst/usr/share
> :$XDG_DATA_DIRS:/usr/share:/usr/share"
> 
> This is missing the dir for kio itself.
> 
> Same kind of problem in kemoticonstest (which loads its own plugin),
> frameworkintegration (same).
> 
> Is this a voluntary change, as in, we should fix the tests to work without
> the need to make install first?

other frameworks affected by the CI-regression are:
* kwindowsystem
* kglobalaccel

both cannot find their own plugin so I assume it's the same problem. I don't 
have the time to rework the tests to make them pass again, sorry :-(

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