Re: testing a plasma applet with plasmoid viewer despite PackageUrlInterceptor

[Marco Martin]

On Saturday 27 December 2014, Philipp A. wrote:
> Hi,
> 
> i’m developing a plasma wiget with C++ plugin.
> 
> consistent with how upstream packages do it, with my package being called
> `org.kde.plasma.steam`, the plugin is called
> `org.kde.plasma.private.steam`.
> 
> i try to load my plasmoid from its dev directory via
> 
> QML2_IMPORT_PATH="../build/:$QML2_IMPORT_PATH" plasmoidviewer "$@" .

does it load when installed?


-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121718: Allow to compile plasma-workspace without Qt5WebKit installed.

[Marco Martin]

> On Dic. 29, 2014, 4:40 a.m., Aleix Pol Gonzalez wrote:
> > Then Qt5Webkit should be marked as optional through the 
> > set_package_properties().
> > 
> > To be honest, I'm not thrilled about having many ways to configure these 
> > things, because sooner or later somebody will end up compiling Plasma 
> > without qtwebkit by mistake and then he'll miss drkonqi, but well, building 
> > qtwebkit sure is a PITA, so won't oppose.

anyways, this webkit dependency should be removed sooner than later no? so 
making it optional would be a good first step.


- Marco


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


On Dic. 28, 2014, 6:16 p.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121718/
> ---
> 
> (Updated Dic. 28, 2014, 6:16 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Only drkonqi and systemmonitor depend on it.
> 
> (systemmonitor uses libksysguard's processui lib, which is not installed
> by libksysguard if webkit is not found)
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 
>   drkonqi/CMakeLists.txt a362d7ec651c027d91d0912e84817cd3a2f94d67 
> 
> Diff: https://git.reviewboard.kde.org/r/121718/diff/
> 
> 
> Testing
> ---
> 
> Compiling without qt5 webkit.
> 
> 
> Thanks,
> 
> David Faure
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121718: Allow to compile plasma-workspace without Qt5WebKit installed.

[Marco Martin]

> On Dic. 29, 2014, 4:40 a.m., Aleix Pol Gonzalez wrote:
> > Then Qt5Webkit should be marked as optional through the 
> > set_package_properties().
> > 
> > To be honest, I'm not thrilled about having many ways to configure these 
> > things, because sooner or later somebody will end up compiling Plasma 
> > without qtwebkit by mistake and then he'll miss drkonqi, but well, building 
> > qtwebkit sure is a PITA, so won't oppose.
> 
> Marco Martin wrote:
> anyways, this webkit dependency should be removed sooner than later no? 
> so making it optional would be a good first step.

also, what exactly drkonqui uses qtwebkit for?


- Marco


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


On Dic. 28, 2014, 6:16 p.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121718/
> ---
> 
> (Updated Dic. 28, 2014, 6:16 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Only drkonqi and systemmonitor depend on it.
> 
> (systemmonitor uses libksysguard's processui lib, which is not installed
> by libksysguard if webkit is not found)
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 
>   drkonqi/CMakeLists.txt a362d7ec651c027d91d0912e84817cd3a2f94d67 
> 
> Diff: https://git.reviewboard.kde.org/r/121718/diff/
> 
> 
> Testing
> ---
> 
> Compiling without qt5 webkit.
> 
> 
> Thanks,
> 
> David Faure
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121728: Fix Label not picking up font changes at runtime

[Marco Martin]

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


ah, those should be on gerrit btw :p

- Marco Martin


On Dec. 28, 2014, 10:43 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121728/
> ---
> 
> (Updated Dec. 28, 2014, 10:43 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 334818
> http://bugs.kde.org/show_bug.cgi?id=334818
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> The event filter was installed but then removed when the color file path was 
> not empty (read: always). Keeping the event filter around ensures font 
> changes are picked up at runtime.
> 
> 
> Diffs
> -
> 
>   src/plasma/private/theme_p.cpp 1963f74 
> 
> Diff: https://git.reviewboard.kde.org/r/121728/diff/
> 
> 
> Testing
> ---
> 
> Changed my fonts to bold or changed the size, everything updated like magic 
> after hitting the Apply button.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121720: Load wallpaper immediately on startup

[Marco Martin]

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

Ship it!


Ship It!

- Marco Martin


On Dec. 28, 2014, 7:49 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121720/
> ---
> 
> (Updated Dec. 28, 2014, 7:49 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> When the shell starts we want the wallpaper to show up immediately to get a 
> seamless transition from ksplash.
> This patch also hides the background color rectangle while the image is not 
> ready yet to prevent it appearing for a split second.
> The add wallpaper stuff in Component.onCompleted has been removed since the 
> function got fired twice due to the onModelImageChanged which seems to be 
> executed anyway.
> 
> 
> Diffs
> -
> 
>   wallpapers/image/imagepackage/contents/ui/main.qml 0cb4812 
> 
> Diff: https://git.reviewboard.kde.org/r/121720/diff/
> 
> 
> Testing
> ---
> 
> Logged in, splash screen disappears and the wallpaper is already there. The 
> image seems to be loading fine too.
> 
> The slideshow also no longer initially loads the default wallpaper but just 
> black and then fade to the slideshow (but this is a bug in the image.cpp 
> where it falls back to the default wallpaper even initially when it's still 
> crawling for images (depending on the number of files it has to scan the 
> default wallpaper can stay there for a second or two))
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121710: Avoid risk of starting two kscreen_launchers at the same having race conditions

[David Edmundson]

> On Dec. 29, 2014, 1:55 a.m., Lukáš Tinkl wrote:
> > Unfortunataly it doesn't fix it here, plasmashell starts with a blank 
> > screen. kquitapp5 plasmashell && plasmashell brings it back
> 
> Bhushan Shah wrote:
> Works for me.. :S which XRandr version you have?

That's depressing to hear. I need some help on this; logs, traces, something as 
I can't reproduce here and this bug is super duper critical.

Do you agree this change still makes sense though? Even if there is another 
problem it will be easier if there's one potential bug less.


- David


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


On Dec. 28, 2014, 10:33 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121710/
> ---
> 
> (Updated Dec. 28, 2014, 10:33 a.m.)
> 
> 
> Review request for Plasma, Solid and Daniel Vrátil.
> 
> 
> Repository: libkscreen
> 
> 
> Description
> ---
> 
> Avoid risk of starting two kscreen_launchers at the same having a race 
> condition.
> 
> There were three possible bugs:
> CheckIsAlreadyRunning tried to register a service and check if it worked.
> This could clash with another process checking at the same time. Causing them 
> both to fail saying another is running
> Similarly, a daemon doing actual registering could clash with another daemon 
> just checking if the name is free, and then it would fail saying we can't 
> init()
>  
> There was also a risk that two launchers pass the check that nothing is 
> running, then both try to activate a session. DBus server handles this fine 
> and one will gracefully fail. Without this patch the second launcher would 
> just die without returning the path of the service that was activated causing 
> the relevant app to do nothing.
> 
> 
> --
> 
> IMHO, you'd be better off having a fixed service name and using DBus 
> activation for exactly these reasons.
> You could put the different backends at different object paths, and have a 
> method on the root object that says which object path to use rather than 
> using the stdout of a launcher. That's a discussion for another day though.
> 
> 
> Diffs
> -
> 
>   src/backendlauncher/backendloader.cpp e7da8cd 
>   src/backendlauncher/main.cpp f8bf323 
> 
> Diff: https://git.reviewboard.kde.org/r/121710/diff/
> 
> 
> Testing
> ---
> 
> Send it to bshah. Plasmashell started for him. Previously it didn't.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121581: Plotter in kdeclarative

[Marco Martin]

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

(Updated Dec. 29, 2014, 12:17 p.m.)


Review request for KDE Frameworks and Plasma.


Repository: kdeclarative


Description
---

This is an alternative, mutually exclusive to
https://gerrit.vesnicky.cesnet.cz/r/#/c/244
and dependent from
https://git.reviewboard.kde.org/r/121575/

since the plotter component doesn't depend from libplasma, it may be useful to 
have it outside of libplasma, so any applciation that wants it may use it.
Any opinion whether this should go here or in libplasma is welcome.


Diffs (updated)
-

  src/qmlcontrols/kquickcontrolsaddons/kquickcontrolsaddonsplugin.cpp 0e2eb2f 
  src/qmlcontrols/kquickcontrolsaddons/plotter.h PRE-CREATION 
  src/qmlcontrols/kquickcontrolsaddons/plotter.cpp PRE-CREATION 
  CMakeLists.txt 233ccce 
  cmake/Findepoxy.cmake PRE-CREATION 
  src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 786aaa5 

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


Testing
---


Thanks,

Marco Martin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: testing a plasma applet with plasmoid viewer despite PackageUrlInterceptor

[Philipp A.]

2014-12-29 10:23 GMT+01:00 Marco Martin :

> does it load when installed?
>

yes. i think it’s the way that plasmoidviewer loads it that breaks, see my
other mail, where i changed the interceptor to allow these requests and
still get errors:

2014-12-28 21:21 GMT+01:00 Philipp A. :

> aha, so the problem seems to be that when loaded via plasmoidviewer
>
> m_package.metadata().pluginName() == "org.kde.desktopcontainment"
>
> when using a custom interceptor to circumvent it, i still get strange
> errors. can someone help?
>
> QML debugging is enabled. Only use this in a safe environment.
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> file:///usr/lib/qt/qml/QtQuick/Controls/Styles/Plasma/FocusFrameStyle.qml:
> File not found
> file:///usr/lib/qt/qml/QtQuick/Controls/Styles/Base/ButtonStyle.qml:153:31:
> QML Item: Binding loop detected for property "implicitWidth"
> file:///usr/lib/qt/qml/QtQuick/Controls/Styles/Base/ButtonStyle.qml:153:31:
> QML Item: Binding loop detected for property "implicitWidth"
> file:///usr/lib/qt/qml/QtQuick/Controls/Styles/Base/ButtonStyle.qml:153:31:
> QML Item: Binding loop detected for property "implicitWidth"
> file:///usr/lib/qt/qml/QtQuick/Controls/Styles/Base/ButtonStyle.qml:153:31:
> QML Item: Binding loop detected for property "implicitWidth"
> file:///usr/lib/qt/qml/QtQuick/Controls/Styles/Base/ButtonStyle.qml:153:31:
> QML Item: Binding loop detected for property "implicitWidth"
> qml: View QML loaded
> kf5.kservice.sycoca: Trying to open ksycoca from
> "/home/phil/.cache/ksycoca5"
> Trying to use rootObject before initialization is completed, whilst using
> setInitializationDelayed. Forcing completion
> Plasmoidviewer detected: circumventing security  QUrl(
> "file:///home/phil/Dev/KDE/steam-plasmoid/build/org/kde/plasma/private/steam/qmldir"
> )
> Plasmoidviewer detected: circumventing security  QUrl(
> "file:///home/phil/Dev/KDE/steam-plasmoid/build/org/kde/plasma/private/steam/qmldir"
> )
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> qml: New Containment: ContainmentInterface(0x194b390)
> QQmlComponent: Component is not ready
> QCoreApplication::postEvent: Unexpected null receiver
> "file:///usr/share/plasma/shells/org.kde.plasma.plasmoidviewershell/contents/applet/AppletError.qml"
>
>  "Error loading QML file.
> File not found
> "
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() instead of kservice_desktop_to_json() in your
> CMake code.
> Constructing a KPluginInfo object from old style JSON. 

Re: Review Request 121732: Port kcm_kded away from kdelibs4support

[David Edmundson]

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

Ship it!


Thanks

- David Edmundson


On Dec. 29, 2014, 1:17 a.m., Alex Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121732/
> ---
> 
> (Updated Dec. 29, 2014, 1:17 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Port kcm_kded away from kdelibs4support
> 
> 
> Diffs
> -
> 
>   kcms/kded/CMakeLists.txt 07217e0cfe5490aab8099940de2ea26139fc52fe 
>   kcms/kded/kcmkded.h 272a6191a6c668dbc486673c724d5da02bbc5001 
>   kcms/kded/kcmkded.cpp 34a1acf6c6105d3ef7202663417603b47478e359 
> 
> Diff: https://git.reviewboard.kde.org/r/121732/diff/
> 
> 
> Testing
> ---
> 
> Compiles
> 
> 
> Thanks,
> 
> Alex Richardson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121718: Allow to compile plasma-workspace without Qt5WebKit installed.

[Aleix Pol Gonzalez]

> On Dec. 29, 2014, 4:40 a.m., Aleix Pol Gonzalez wrote:
> > Then Qt5Webkit should be marked as optional through the 
> > set_package_properties().
> > 
> > To be honest, I'm not thrilled about having many ways to configure these 
> > things, because sooner or later somebody will end up compiling Plasma 
> > without qtwebkit by mistake and then he'll miss drkonqi, but well, building 
> > qtwebkit sure is a PITA, so won't oppose.
> 
> Marco Martin wrote:
> anyways, this webkit dependency should be removed sooner than later no? 
> so making it optional would be a good first step.
> 
> Marco Martin wrote:
> also, what exactly drkonqui uses qtwebkit for?

/home/kde-devel/frameworks/plasma-workspace/drkonqi/bugzillaintegration/reportassistantpages_bugzilla.cpp
 uses KWebView for showing a report that the bug has been filled.

How would you remove the dependency? With QtWebEngine? Isn't it the same thing?


- Aleix


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


On Dec. 28, 2014, 6:16 p.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121718/
> ---
> 
> (Updated Dec. 28, 2014, 6:16 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Only drkonqi and systemmonitor depend on it.
> 
> (systemmonitor uses libksysguard's processui lib, which is not installed
> by libksysguard if webkit is not found)
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 
>   drkonqi/CMakeLists.txt a362d7ec651c027d91d0912e84817cd3a2f94d67 
> 
> Diff: https://git.reviewboard.kde.org/r/121718/diff/
> 
> 
> Testing
> ---
> 
> Compiling without qt5 webkit.
> 
> 
> Thanks,
> 
> David Faure
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Gerrit and GMail

[Aleix Pol]

Hi,
I've been struggling with getting some things that have gone through
gerrit lately. The reason wasn't (only) the baroque interface, but my
"plasma" filter wouldn't reach the gerrit e-mails.

Since I know I'm not the only one using such (hateful-privative)
service so far, I decided to look into what I was doing wrong. Filling
the "has the fields" field with [1] seemed to do.

I hope this helps.
Cheers!
Aleix

[1] replyto:plasma-devel@kde.org
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121732: Port kcm_kded away from kdelibs4support

[Alex Richardson]

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

(Updated Dec. 29, 2014, 2:41 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-desktop


Description
---

Port kcm_kded away from kdelibs4support


Diffs
-

  kcms/kded/CMakeLists.txt 07217e0cfe5490aab8099940de2ea26139fc52fe 
  kcms/kded/kcmkded.h 272a6191a6c668dbc486673c724d5da02bbc5001 
  kcms/kded/kcmkded.cpp 34a1acf6c6105d3ef7202663417603b47478e359 

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


Testing
---

Compiles


Thanks,

Alex Richardson

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Build failed in Jenkins: plasma-desktop_master_qt5 #887

[KDE CI System]

See 

Changes:

[arichardson.kde] Port kcm_kded away from kdelibs4support

--
Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit
Building remotely on LinuxSlave - 4 (PACKAGER LINBUILDER) in workspace 

Running Prebuild steps
[plasma-desktop_master_qt5] $ /bin/sh -xe /tmp/hudson519153656796517633.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

>From git://anongit.kde.org/plasma-desktop
   d9c396a..6faacfa  master -> origin/master
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at d9c396a Bring back computer-laptop icon in Kickoff
Removing build/
Removing local-inst/
Success build forhudson.tasks.Shell@77fda842
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://anongit.kde.org/plasma-desktop # 
 > timeout=10
Fetching upstream changes from git://anongit.kde.org/plasma-desktop
 > git --version # timeout=10
 > git fetch --tags --progress git://anongit.kde.org/plasma-desktop 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/jenkins^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/refs/heads/jenkins^{commit} # timeout=10
 > git rev-parse refs/heads/jenkins^{commit} # timeout=10
Checking out Revision 6faacfaa10c11e6ec0b2de73c7e89d78d710e508 
(refs/heads/jenkins)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 6faacfaa10c11e6ec0b2de73c7e89d78d710e508
 > git rev-list fb152686294ffc405eb3b38379398bed4c30872a # timeout=10
 > git tag -a -f -m Jenkins Build #887 jenkins-plasma-desktop_master_qt5-887 # 
 > timeout=10
[plasma-desktop_master_qt5] $ /bin/sh -xe /tmp/hudson6921137371427044548.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: plasma-desktop - Branch master
== Build Dependencies:
 kinit - Branch master
 khelpcenter - Branch master
 kiconthemes - Branch master
 threadweaver - Branch master
 kcodecs - Branch master
 kdesupport-svn - Branch master
 plasma-workspace - Branch master
 kde-cli-tools - Branch master
 plasma-framework - Branch master
 kio-extras - Branch master
 kpty - Branch master
 kdbusaddons - Branch master
 kpackage - Branch master
 kio - Branch master
 kservice - Branch master
 knewstuff - Branch master
 baloo - Branch master
 kitemviews - Branch master
 kdesu - Branch master
 kdnssd - Branch master
 kcmutils - Branch master
 kcoreaddons - Branch master
 breeze - Branch master
 polkit-qt-1 - Branch master
 extra-cmake-modules - Branch master
 ktexteditor - Branch master
 phonon - Branch master
 kjobwidgets - Branch master
 kemoticons - Branch master
 kwindowsystem - Branch master
 kconfig - Branch master
 kwidgetsaddons - Branch master
 krunner - Branch master
 milou - Branch master
 kauth - Branch master
 kfilemetadata - Branch master
 kglobalaccel - Branch master
 ksysguard - Branch master
 ktextwidgets - Branch master
 kcompletion - Branch master
 kplotting - Branch master
 kxmlgui - Branch master
 sonnet - Branch master
 kdesignerplugin - Branch master
 kdecoration - Branch master
 cmake - Branch master
 kcrash - Branch master
 libksysguard - Branch master
 knotifications - Branch master
 kjsembed - Branch master
 libgit2 - Branch master
 knotifyconfig - Branch master
 systemsettings - Branch master
 ki18n - Branch master
 kwayland - Branch master
 khtml - Branch master
 attica - Branch master
 kunitconversion - Branch master
 kwallet - Branch master
 libkscreen - Branch frameworks
 kdelibs4support - Branch master
 kded - Branch master
 kross - Branch master
 powerdevil - Branch master
 libssh - Branch master
 kwin - Branch master
 solid - Branch master
 kidletime - Branch master
 frameworkintegration - Branch master
 kdoctools - Branch master
 oxygen - Branch master
 kbookmarks - Branch master
 kdewebkit - Branch master
 kguiaddons - Branch master
 kparts - Branch master
 libdbusmenu-qt - Branch master
 kitemmodels - Branch master
 dogtail - Branch master
 karchive - Branch master
 kactivities - Branch master
 kdeclarative - Branch master
 kconfigwidgets - Branch master
 kjs - Branch master
 qt5 - Branch 5.3.2

== Applying Patches
=== No patches to apply

== Syncing Dependencies from Master Server


== Configuring Build

-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- 

Re: Review Request 121718: Allow to compile plasma-workspace without Qt5WebKit installed.

[David Faure]

> On Dec. 29, 2014, 4:40 a.m., Aleix Pol Gonzalez wrote:
> > Then Qt5Webkit should be marked as optional through the 
> > set_package_properties().
> > 
> > To be honest, I'm not thrilled about having many ways to configure these 
> > things, because sooner or later somebody will end up compiling Plasma 
> > without qtwebkit by mistake and then he'll miss drkonqi, but well, building 
> > qtwebkit sure is a PITA, so won't oppose.
> 
> Marco Martin wrote:
> anyways, this webkit dependency should be removed sooner than later no? 
> so making it optional would be a good first step.
> 
> Marco Martin wrote:
> also, what exactly drkonqui uses qtwebkit for?
> 
> Aleix Pol Gonzalez wrote:
> 
> /home/kde-devel/frameworks/plasma-workspace/drkonqi/bugzillaintegration/reportassistantpages_bugzilla.cpp
>  uses KWebView for showing a report that the bug has been filled.
> 
> How would you remove the dependency? With QtWebEngine? Isn't it the same 
> thing?

If it's just to open a URL at the end of process, why not just launch a web 
browser?


- David


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


On Dec. 28, 2014, 6:16 p.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121718/
> ---
> 
> (Updated Dec. 28, 2014, 6:16 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Only drkonqi and systemmonitor depend on it.
> 
> (systemmonitor uses libksysguard's processui lib, which is not installed
> by libksysguard if webkit is not found)
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 
>   drkonqi/CMakeLists.txt a362d7ec651c027d91d0912e84817cd3a2f94d67 
> 
> Diff: https://git.reviewboard.kde.org/r/121718/diff/
> 
> 
> Testing
> ---
> 
> Compiling without qt5 webkit.
> 
> 
> Thanks,
> 
> David Faure
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121710: Avoid risk of starting two kscreen_launchers at the same having race conditions

[Aleix Pol Gonzalez]

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


I like how the code ends up being simpler. I am still not convinced there's no 
space for race conditions here. Maybe we want to use something like QLockFile?
http://doc.qt.io/qt-5/qlockfile.html

- Aleix Pol Gonzalez


On Dec. 28, 2014, 10:33 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121710/
> ---
> 
> (Updated Dec. 28, 2014, 10:33 a.m.)
> 
> 
> Review request for Plasma, Solid and Daniel Vrátil.
> 
> 
> Repository: libkscreen
> 
> 
> Description
> ---
> 
> Avoid risk of starting two kscreen_launchers at the same having a race 
> condition.
> 
> There were three possible bugs:
> CheckIsAlreadyRunning tried to register a service and check if it worked.
> This could clash with another process checking at the same time. Causing them 
> both to fail saying another is running
> Similarly, a daemon doing actual registering could clash with another daemon 
> just checking if the name is free, and then it would fail saying we can't 
> init()
>  
> There was also a risk that two launchers pass the check that nothing is 
> running, then both try to activate a session. DBus server handles this fine 
> and one will gracefully fail. Without this patch the second launcher would 
> just die without returning the path of the service that was activated causing 
> the relevant app to do nothing.
> 
> 
> --
> 
> IMHO, you'd be better off having a fixed service name and using DBus 
> activation for exactly these reasons.
> You could put the different backends at different object paths, and have a 
> method on the root object that says which object path to use rather than 
> using the stdout of a launcher. That's a discussion for another day though.
> 
> 
> Diffs
> -
> 
>   src/backendlauncher/backendloader.cpp e7da8cd 
>   src/backendlauncher/main.cpp f8bf323 
> 
> Diff: https://git.reviewboard.kde.org/r/121710/diff/
> 
> 
> Testing
> ---
> 
> Send it to bshah. Plasmashell started for him. Previously it didn't.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121718: Allow to compile plasma-workspace without Qt5WebKit installed.

[Aleix Pol Gonzalez]

> On Dec. 29, 2014, 4:40 a.m., Aleix Pol Gonzalez wrote:
> > Then Qt5Webkit should be marked as optional through the 
> > set_package_properties().
> > 
> > To be honest, I'm not thrilled about having many ways to configure these 
> > things, because sooner or later somebody will end up compiling Plasma 
> > without qtwebkit by mistake and then he'll miss drkonqi, but well, building 
> > qtwebkit sure is a PITA, so won't oppose.
> 
> Marco Martin wrote:
> anyways, this webkit dependency should be removed sooner than later no? 
> so making it optional would be a good first step.
> 
> Marco Martin wrote:
> also, what exactly drkonqui uses qtwebkit for?
> 
> Aleix Pol Gonzalez wrote:
> 
> /home/kde-devel/frameworks/plasma-workspace/drkonqi/bugzillaintegration/reportassistantpages_bugzilla.cpp
>  uses KWebView for showing a report that the bug has been filled.
> 
> How would you remove the dependency? With QtWebEngine? Isn't it the same 
> thing?
> 
> David Faure wrote:
> If it's just to open a URL at the end of process, why not just launch a 
> web browser?

I didn't really think it through, maybe it's a good solution. It's derailing 
from the original patch anyway.


- Aleix


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


On Dec. 28, 2014, 6:16 p.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121718/
> ---
> 
> (Updated Dec. 28, 2014, 6:16 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Only drkonqi and systemmonitor depend on it.
> 
> (systemmonitor uses libksysguard's processui lib, which is not installed
> by libksysguard if webkit is not found)
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 
>   drkonqi/CMakeLists.txt a362d7ec651c027d91d0912e84817cd3a2f94d67 
> 
> Diff: https://git.reviewboard.kde.org/r/121718/diff/
> 
> 
> Testing
> ---
> 
> Compiling without qt5 webkit.
> 
> 
> Thanks,
> 
> David Faure
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121710: Avoid risk of starting two kscreen_launchers at the same having race conditions

[Raymond Wooninck]

> On Dec. 29, 2014, 1:55 a.m., Lukáš Tinkl wrote:
> > Unfortunataly it doesn't fix it here, plasmashell starts with a blank 
> > screen. kquitapp5 plasmashell && plasmashell brings it back
> 
> Bhushan Shah wrote:
> Works for me.. :S which XRandr version you have?
> 
> David Edmundson wrote:
> That's depressing to hear. I need some help on this; logs, traces, 
> something as I can't reproduce here and this bug is super duper critical.
> 
> Do you agree this change still makes sense though? Even if there is 
> another problem it will be easier if there's one potential bug less.

Unfortunately I seem to have hit a worse situation.  kquitapp5 plasmashell does 
not work in my case as it just fails. Killing plasmashell and then starting it 
just delivers the same situation, a black screen with plasmashell running in 
the background and that is it.  Starting plasmashell shows the following output:
kscreen: launcherDataAvailable: "org.kde.KScreen.Backend.XRandR"
kscreen: Launcher finished with exit code 1 , status 0
kscreen: Service for requested backend already running

And yes I have a kscreen_backend_launcher process running, which is started by 
kded5. When I try to kill this one, kded5 is automatically restarting it. 

To be honest this patch makes things worse as that plasmashell is not starting 
at all.


- Raymond


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


On Dec. 28, 2014, 10:33 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121710/
> ---
> 
> (Updated Dec. 28, 2014, 10:33 a.m.)
> 
> 
> Review request for Plasma, Solid and Daniel Vrátil.
> 
> 
> Repository: libkscreen
> 
> 
> Description
> ---
> 
> Avoid risk of starting two kscreen_launchers at the same having a race 
> condition.
> 
> There were three possible bugs:
> CheckIsAlreadyRunning tried to register a service and check if it worked.
> This could clash with another process checking at the same time. Causing them 
> both to fail saying another is running
> Similarly, a daemon doing actual registering could clash with another daemon 
> just checking if the name is free, and then it would fail saying we can't 
> init()
>  
> There was also a risk that two launchers pass the check that nothing is 
> running, then both try to activate a session. DBus server handles this fine 
> and one will gracefully fail. Without this patch the second launcher would 
> just die without returning the path of the service that was activated causing 
> the relevant app to do nothing.
> 
> 
> --
> 
> IMHO, you'd be better off having a fixed service name and using DBus 
> activation for exactly these reasons.
> You could put the different backends at different object paths, and have a 
> method on the root object that says which object path to use rather than 
> using the stdout of a launcher. That's a discussion for another day though.
> 
> 
> Diffs
> -
> 
>   src/backendlauncher/backendloader.cpp e7da8cd 
>   src/backendlauncher/main.cpp f8bf323 
> 
> Diff: https://git.reviewboard.kde.org/r/121710/diff/
> 
> 
> Testing
> ---
> 
> Send it to bshah. Plasmashell started for him. Previously it didn't.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121710: Avoid risk of starting two kscreen_launchers at the same having race conditions

[Raymond Wooninck]

> On Dec. 29, 2014, 1:55 a.m., Lukáš Tinkl wrote:
> > Unfortunataly it doesn't fix it here, plasmashell starts with a blank 
> > screen. kquitapp5 plasmashell && plasmashell brings it back
> 
> Bhushan Shah wrote:
> Works for me.. :S which XRandr version you have?
> 
> David Edmundson wrote:
> That's depressing to hear. I need some help on this; logs, traces, 
> something as I can't reproduce here and this bug is super duper critical.
> 
> Do you agree this change still makes sense though? Even if there is 
> another problem it will be easier if there's one potential bug less.
> 
> Raymond Wooninck wrote:
> Unfortunately I seem to have hit a worse situation.  kquitapp5 
> plasmashell does not work in my case as it just fails. Killing plasmashell 
> and then starting it just delivers the same situation, a black screen with 
> plasmashell running in the background and that is it.  Starting plasmashell 
> shows the following output:
> kscreen: launcherDataAvailable: "org.kde.KScreen.Backend.XRandR"
> kscreen: Launcher finished with exit code 1 , status 0
> kscreen: Service for requested backend already running
> 
> And yes I have a kscreen_backend_launcher process running, which is 
> started by kded5. When I try to kill this one, kded5 is automatically 
> restarting it. 
> 
> To be honest this patch makes things worse as that plasmashell is not 
> starting at all.

Just forgot:
raymond@HQVMT44011:~% xrandr --version
xrandr program version   1.4.3
Server reports RandR version 1.4


- Raymond


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


On Dec. 28, 2014, 10:33 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121710/
> ---
> 
> (Updated Dec. 28, 2014, 10:33 a.m.)
> 
> 
> Review request for Plasma, Solid and Daniel Vrátil.
> 
> 
> Repository: libkscreen
> 
> 
> Description
> ---
> 
> Avoid risk of starting two kscreen_launchers at the same having a race 
> condition.
> 
> There were three possible bugs:
> CheckIsAlreadyRunning tried to register a service and check if it worked.
> This could clash with another process checking at the same time. Causing them 
> both to fail saying another is running
> Similarly, a daemon doing actual registering could clash with another daemon 
> just checking if the name is free, and then it would fail saying we can't 
> init()
>  
> There was also a risk that two launchers pass the check that nothing is 
> running, then both try to activate a session. DBus server handles this fine 
> and one will gracefully fail. Without this patch the second launcher would 
> just die without returning the path of the service that was activated causing 
> the relevant app to do nothing.
> 
> 
> --
> 
> IMHO, you'd be better off having a fixed service name and using DBus 
> activation for exactly these reasons.
> You could put the different backends at different object paths, and have a 
> method on the root object that says which object path to use rather than 
> using the stdout of a launcher. That's a discussion for another day though.
> 
> 
> Diffs
> -
> 
>   src/backendlauncher/backendloader.cpp e7da8cd 
>   src/backendlauncher/main.cpp f8bf323 
> 
> Diff: https://git.reviewboard.kde.org/r/121710/diff/
> 
> 
> Testing
> ---
> 
> Send it to bshah. Plasmashell started for him. Previously it didn't.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121201: KRunner: Do not detect anything with a '.' as a NetworkLocation

[Vishesh Handa]

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

(Updated Dec. 29, 2014, 4:23 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


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


Repository: krunner


Description
---

One can also uses a decimal point in a calculator.


Diffs
-

  autotests/runnercontexttest.cpp ba5f6a1 
  src/runnercontext.cpp 2d6177d 

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


Testing
---


Thanks,

Vishesh Handa

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121710: Avoid risk of starting two kscreen_launchers at the same having race conditions

[Bhushan Shah]

> On Dec. 29, 2014, 7:25 a.m., Lukáš Tinkl wrote:
> > Unfortunataly it doesn't fix it here, plasmashell starts with a blank 
> > screen. kquitapp5 plasmashell && plasmashell brings it back
> 
> Bhushan Shah wrote:
> Works for me.. :S which XRandr version you have?
> 
> David Edmundson wrote:
> That's depressing to hear. I need some help on this; logs, traces, 
> something as I can't reproduce here and this bug is super duper critical.
> 
> Do you agree this change still makes sense though? Even if there is 
> another problem it will be easier if there's one potential bug less.
> 
> Raymond Wooninck wrote:
> Unfortunately I seem to have hit a worse situation.  kquitapp5 
> plasmashell does not work in my case as it just fails. Killing plasmashell 
> and then starting it just delivers the same situation, a black screen with 
> plasmashell running in the background and that is it.  Starting plasmashell 
> shows the following output:
> kscreen: launcherDataAvailable: "org.kde.KScreen.Backend.XRandR"
> kscreen: Launcher finished with exit code 1 , status 0
> kscreen: Service for requested backend already running
> 
> And yes I have a kscreen_backend_launcher process running, which is 
> started by kded5. When I try to kill this one, kded5 is automatically 
> restarting it. 
> 
> To be honest this patch makes things worse as that plasmashell is not 
> starting at all.
> 
> Raymond Wooninck wrote:
> Just forgot:
> raymond@HQVMT44011:~% xrandr --version
> xrandr program version   1.4.3
> Server reports RandR version 1.4

>kscreen: launcherDataAvailable: "org.kde.KScreen.Backend.XRandR"
>kscreen: Launcher finished with exit code 1 , status 0
>kscreen: Service for requested backend already running

I had same output but with this patch I am not getting that.. and plasmashell 
works for me fine.


- Bhushan


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


On Dec. 28, 2014, 4:03 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121710/
> ---
> 
> (Updated Dec. 28, 2014, 4:03 p.m.)
> 
> 
> Review request for Plasma, Solid and Daniel Vrátil.
> 
> 
> Repository: libkscreen
> 
> 
> Description
> ---
> 
> Avoid risk of starting two kscreen_launchers at the same having a race 
> condition.
> 
> There were three possible bugs:
> CheckIsAlreadyRunning tried to register a service and check if it worked.
> This could clash with another process checking at the same time. Causing them 
> both to fail saying another is running
> Similarly, a daemon doing actual registering could clash with another daemon 
> just checking if the name is free, and then it would fail saying we can't 
> init()
>  
> There was also a risk that two launchers pass the check that nothing is 
> running, then both try to activate a session. DBus server handles this fine 
> and one will gracefully fail. Without this patch the second launcher would 
> just die without returning the path of the service that was activated causing 
> the relevant app to do nothing.
> 
> 
> --
> 
> IMHO, you'd be better off having a fixed service name and using DBus 
> activation for exactly these reasons.
> You could put the different backends at different object paths, and have a 
> method on the root object that says which object path to use rather than 
> using the stdout of a launcher. That's a discussion for another day though.
> 
> 
> Diffs
> -
> 
>   src/backendlauncher/backendloader.cpp e7da8cd 
>   src/backendlauncher/main.cpp f8bf323 
> 
> Diff: https://git.reviewboard.kde.org/r/121710/diff/
> 
> 
> Testing
> ---
> 
> Send it to bshah. Plasmashell started for him. Previously it didn't.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[plasmashell] [Bug 340063] Please make KDE fade to black before turning screen off

[Andrew Lake]

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

Andrew Lake  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||jamboar...@gmail.com
 Status|UNCONFIRMED |CONFIRMED

--- Comment #5 from Andrew Lake  ---
I think the fade would be helpful in a utilitarian sense, and also add to the
overall visual polish. I'll confirm assuming there are no technical hurdles.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 121738: Let kcmkded also handle kded modules that use JSON metadata

[Alex Richardson]

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

Review request for Plasma.


Repository: plasma-desktop


Description
---

Let kcmkded also handle kded modules that use JSON metadata


Diffs
-

  kcms/kded/kcmkded.h 9afa1881f56d2f913b7e4f7eba5e556795ac5551 
  kcms/kded/kcmkded.cpp 6902f3a8c30af1ae43761c53b3b235e12f1fba9c 

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


Testing
---


Thanks,

Alex Richardson

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121720: Load wallpaper immediately on startup

[Kai Uwe Broulik]

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

(Updated Dec. 29, 2014, 7:03 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-workspace


Description
---

When the shell starts we want the wallpaper to show up immediately to get a 
seamless transition from ksplash.
This patch also hides the background color rectangle while the image is not 
ready yet to prevent it appearing for a split second.
The add wallpaper stuff in Component.onCompleted has been removed since the 
function got fired twice due to the onModelImageChanged which seems to be 
executed anyway.


Diffs
-

  wallpapers/image/imagepackage/contents/ui/main.qml 0cb4812 

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


Testing
---

Logged in, splash screen disappears and the wallpaper is already there. The 
image seems to be loading fine too.

The slideshow also no longer initially loads the default wallpaper but just 
black and then fade to the slideshow (but this is a bug in the image.cpp where 
it falls back to the default wallpaper even initially when it's still crawling 
for images (depending on the number of files it has to scan the default 
wallpaper can stay there for a second or two))


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [breeze] wallpapers/Next/contents/images: add new files

[šumski]

On Friday 19 of December 2014 11:56:26 Marco Martin wrote:
> Git commit 6a9897d2e0de65e30ea61f670a1d1716f02f1245 by Marco Martin.
> Committed on 19/12/2014 at 10:50.
> Pushed by mart into branch 'master'.
> 
> add new files

I don't know is it possible, but appears these should be png, as breeze plasma 
theme has png for defaultFileSuffix (and in order not to change that so that we 
can keep backwards compatibility).
As it is now, default plasma master has a black wallpaper for default (kscreen 
bug aside) ;-)


Cheers,
Hrvoje

> A  +---wallpapers/Next/contents/images/1280x1024.jpg
> A  +---wallpapers/Next/contents/images/1280x800.jpg
> A  +---wallpapers/Next/contents/images/1440x900.jpg
> A  +---wallpapers/Next/contents/images/1600x1200.jpg
> A  +---wallpapers/Next/contents/images/1638x1024.jpg
> A  +---wallpapers/Next/contents/images/1680x1050.jpg
> A  +---wallpapers/Next/contents/images/1920x1080.jpg
> A  +---wallpapers/Next/contents/images/1920x1200.jpg
> A  +---wallpapers/Next/contents/images/2560x1440.jpg
> A  +---wallpapers/Next/contents/images/2560x1600.jpg
> 
> http://commits.kde.org/breeze/6a9897d2e0de65e30ea61f670a1d1716f02f1245
> 
> diff --git a/wallpapers/Next/contents/images/1280x1024.jpg
> b/wallpapers/Next/contents/images/1280x1024.jpg new file mode 100644
> index 000..31d431c
> Binary files /dev/null and b/wallpapers/Next/contents/images/1280x1024.jpg
> differ diff --git a/wallpapers/Next/contents/images/1280x800.jpg
> b/wallpapers/Next/contents/images/1280x800.jpg new file mode 100644
> index 000..f951b8f
> Binary files /dev/null and b/wallpapers/Next/contents/images/1280x800.jpg
> differ diff --git a/wallpapers/Next/contents/images/1440x900.jpg
> b/wallpapers/Next/contents/images/1440x900.jpg new file mode 100644
> index 000..bc56297
> Binary files /dev/null and b/wallpapers/Next/contents/images/1440x900.jpg
> differ diff --git a/wallpapers/Next/contents/images/1600x1200.jpg
> b/wallpapers/Next/contents/images/1600x1200.jpg new file mode 100644
> index 000..42ffe54
> Binary files /dev/null and b/wallpapers/Next/contents/images/1600x1200.jpg
> differ diff --git a/wallpapers/Next/contents/images/1638x1024.jpg
> b/wallpapers/Next/contents/images/1638x1024.jpg new file mode 100644
> index 000..3b561ca
> Binary files /dev/null and b/wallpapers/Next/contents/images/1638x1024.jpg
> differ diff --git a/wallpapers/Next/contents/images/1680x1050.jpg
> b/wallpapers/Next/contents/images/1680x1050.jpg new file mode 100644
> index 000..6d6e91f
> Binary files /dev/null and b/wallpapers/Next/contents/images/1680x1050.jpg
> differ diff --git a/wallpapers/Next/contents/images/1920x1080.jpg
> b/wallpapers/Next/contents/images/1920x1080.jpg new file mode 100644
> index 000..260c87e
> Binary files /dev/null and b/wallpapers/Next/contents/images/1920x1080.jpg
> differ diff --git a/wallpapers/Next/contents/images/1920x1200.jpg
> b/wallpapers/Next/contents/images/1920x1200.jpg new file mode 100644
> index 000..5c7d342
> Binary files /dev/null and b/wallpapers/Next/contents/images/1920x1200.jpg
> differ diff --git a/wallpapers/Next/contents/images/2560x1440.jpg
> b/wallpapers/Next/contents/images/2560x1440.jpg new file mode 100644
> index 000..6613182
> Binary files /dev/null and b/wallpapers/Next/contents/images/2560x1440.jpg
> differ diff --git a/wallpapers/Next/contents/images/2560x1600.jpg
> b/wallpapers/Next/contents/images/2560x1600.jpg new file mode 100644
> index 000..f61f6f2
> Binary files /dev/null and b/wallpapers/Next/contents/images/2560x1600.jpg
> differ


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Build failed in Jenkins: plasma-workspace_master_qt5 #1161

[KDE CI System]

See 

Changes:

[kde] Load wallpaper immediately on startup

--
Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit
Building remotely on LinuxSlave - 3 (PACKAGER LINBUILDER) in workspace 

Running Prebuild steps
[plasma-workspace_master_qt5] $ /bin/sh -xe /tmp/hudson2529066719552226945.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

>From git://anongit.kde.org/plasma-workspace
   e9e0e01..a5243ef  mart/systemmonitor-net -> origin/mart/systemmonitor-net
   02a93e3..100bfbb  master -> origin/master
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at 02a93e3 Add "Is Lid Present" property to powermanagement engine
Removing build/
Removing local-inst/
Success build forhudson.tasks.Shell@24e48371
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://anongit.kde.org/plasma-workspace # 
 > timeout=10
Fetching upstream changes from git://anongit.kde.org/plasma-workspace
 > git --version # timeout=10
 > git fetch --tags --progress git://anongit.kde.org/plasma-workspace 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/jenkins^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/refs/heads/jenkins^{commit} # timeout=10
 > git rev-parse refs/heads/jenkins^{commit} # timeout=10
Checking out Revision 100bfbbfb5c9754d86d3996afe31d15ab6214c83 
(refs/heads/jenkins)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 100bfbbfb5c9754d86d3996afe31d15ab6214c83
 > git rev-list 02a93e3dfd1ccda416cbc1da0b5d6d814be41b6a # timeout=10
 > git tag -a -f -m Jenkins Build #1161 
 > jenkins-plasma-workspace_master_qt5-1161 # timeout=10
[plasma-workspace_master_qt5] $ /bin/sh -xe /tmp/hudson5753343918415913135.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: plasma-workspace - Branch master
== Build Dependencies:
 polkit-qt-1 - Branch master
 kiconthemes - Branch master
 kjobwidgets - Branch master
 kdbusaddons - Branch master
 kcodecs - Branch master
 kdeclarative - Branch master
 plasma-framework - Branch master
 kwayland - Branch master
 kpty - Branch master
 breeze - Branch master
 kconfig - Branch master
 kio - Branch master
 kdesignerplugin - Branch master
 kinit - Branch master
 knewstuff - Branch master
 kauth - Branch master
 kdesu - Branch master
 kcmutils - Branch master
 kcoreaddons - Branch master
 kdnssd - Branch master
 kitemviews - Branch master
 extra-cmake-modules - Branch master
 baloo - Branch master
 milou - Branch master
 cmake - Branch master
 kunitconversion - Branch master
 kjsembed - Branch master
 dogtail - Branch master
 krunner - Branch master
 kwidgetsaddons - Branch master
 kbookmarks - Branch master
 kdesupport-svn - Branch master
 kglobalaccel - Branch master
 kparts - Branch master
 kxmlgui - Branch master
 khelpcenter - Branch master
 solid - Branch master
 kplotting - Branch master
 karchive - Branch master
 kactivities - Branch master
 sonnet - Branch master
 ktexteditor - Branch master
 kfilemetadata - Branch master
 kwallet - Branch master
 kcrash - Branch master
 knotifications - Branch master
 ki18n - Branch master
 knotifyconfig - Branch master
 kio-extras - Branch master
 kdecoration - Branch master
 kwindowsystem - Branch master
 kdewebkit - Branch master
 libssh - Branch master
 qt5 - Branch 5.3.2
 khtml - Branch master
 frameworkintegration - Branch master
 libkscreen - Branch frameworks
 kdelibs4support - Branch master
 phonon - Branch master
 libdbusmenu-qt - Branch master
 kidletime - Branch master
 libgit2 - Branch master
 kservice - Branch master
 kded - Branch master
 libksysguard - Branch master
 kdoctools - Branch master
 kde-cli-tools - Branch master
 attica - Branch master
 kconfigwidgets - Branch master
 kemoticons - Branch master
 kitemmodels - Branch master
 threadweaver - Branch master
 kguiaddons - Branch master
 kpackage - Branch master
 ktextwidgets - Branch master
 kjs - Branch master
 kross - Branch master
 kcompletion - Branch master
 kwin - Branch master

== Applying Patches
=== No patches to apply

== Syncing Dependencies from Master Server


== Configuring Build

-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- De

Build failed in Jenkins: plasma-workspace_master_qt5 #1162

[KDE CI System]

See 

Changes:

[hrvoje.senjan] BUG: 337742 Go directly to passwords-only security on Bugzilla.

--
Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit
Building remotely on LinuxSlave - 1 (PACKAGER LINBUILDER) in workspace 

Running Prebuild steps
[plasma-workspace_master_qt5] $ /bin/sh -xe /tmp/hudson1392599072587492836.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

>From git://anongit.kde.org/plasma-workspace
   e9e0e01..a5243ef  mart/systemmonitor-net -> origin/mart/systemmonitor-net
   54006da..a764e9c  master -> origin/master
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at 54006da kdelibs4support--
Removing build/
Removing local-inst/
Success build forhudson.tasks.Shell@24e48371
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://anongit.kde.org/plasma-workspace # 
 > timeout=10
Fetching upstream changes from git://anongit.kde.org/plasma-workspace
 > git --version # timeout=10
 > git fetch --tags --progress git://anongit.kde.org/plasma-workspace 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/jenkins^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/refs/heads/jenkins^{commit} # timeout=10
 > git rev-parse refs/heads/jenkins^{commit} # timeout=10
Checking out Revision a764e9ce41b7fcf291d9b089e6327b07922e5a5f 
(refs/heads/jenkins)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f a764e9ce41b7fcf291d9b089e6327b07922e5a5f
 > git rev-list 100bfbbfb5c9754d86d3996afe31d15ab6214c83 # timeout=10
 > git tag -a -f -m Jenkins Build #1162 
 > jenkins-plasma-workspace_master_qt5-1162 # timeout=10
[plasma-workspace_master_qt5] $ /bin/sh -xe /tmp/hudson5648729460441219964.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: plasma-workspace - Branch master
== Build Dependencies:
 kxmlgui - Branch master
 kiconthemes - Branch master
 karchive - Branch master
 kunitconversion - Branch master
 kdesupport-svn - Branch master
 plasma-framework - Branch master
 kded - Branch master
 kpty - Branch master
 breeze - Branch master
 attica - Branch master
 kdnssd - Branch master
 milou - Branch master
 kemoticons - Branch master
 kservice - Branch master
 knewstuff - Branch master
 kpackage - Branch master
 kwindowsystem - Branch master
 kcmutils - Branch master
 kdesu - Branch master
 dogtail - Branch master
 extra-cmake-modules - Branch master
 kde-cli-tools - Branch master
 kjobwidgets - Branch master
 kactivities - Branch master
 polkit-qt-1 - Branch master
 kconfigwidgets - Branch master
 kjsembed - Branch master
 kcompletion - Branch master
 kwidgetsaddons - Branch master
 krunner - Branch master
 kauth - Branch master
 kparts - Branch master
 baloo - Branch master
 kcodecs - Branch master
 kcrash - Branch master
 knotifications - Branch master
 khelpcenter - Branch master
 kinit - Branch master
 kdesignerplugin - Branch master
 kplotting - Branch master
 kdbusaddons - Branch master
 solid - Branch master
 ktexteditor - Branch master
 khtml - Branch master
 kfilemetadata - Branch master
 kwallet - Branch master
 kitemmodels - Branch master
 libdbusmenu-qt - Branch master
 knotifyconfig - Branch master
 kio-extras - Branch master
 kbookmarks - Branch master
 kdewebkit - Branch master
 qt5 - Branch 5.3.2
 cmake - Branch master
 libkscreen - Branch frameworks
 kdelibs4support - Branch master
 frameworkintegration - Branch master
 ktextwidgets - Branch master
 kidletime - Branch master
 sonnet - Branch master
 kitemviews - Branch master
 libksysguard - Branch master
 kdoctools - Branch master
 phonon - Branch master
 kglobalaccel - Branch master
 kdeclarative - Branch master
 kio - Branch master
 threadweaver - Branch master
 kwayland - Branch master
 libssh - Branch master
 kguiaddons - Branch master
 ki18n - Branch master
 kjs - Branch master
 kdecoration - Branch master
 kcoreaddons - Branch master
 kross - Branch master
 kconfig - Branch master
 kwin - Branch master
 libgit2 - Branch master

== Applying Patches
=== No patches to apply

== Syncing Dependencies from Master Server


== Configuring Build

-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Dete

Re: Review Request 121710: Avoid risk of starting two kscreen_launchers at the same having race conditions

[Raymond Wooninck]

> On Dec. 29, 2014, 1:55 a.m., Lukáš Tinkl wrote:
> > Unfortunataly it doesn't fix it here, plasmashell starts with a blank 
> > screen. kquitapp5 plasmashell && plasmashell brings it back
> 
> Bhushan Shah wrote:
> Works for me.. :S which XRandr version you have?
> 
> David Edmundson wrote:
> That's depressing to hear. I need some help on this; logs, traces, 
> something as I can't reproduce here and this bug is super duper critical.
> 
> Do you agree this change still makes sense though? Even if there is 
> another problem it will be easier if there's one potential bug less.
> 
> Raymond Wooninck wrote:
> Unfortunately I seem to have hit a worse situation.  kquitapp5 
> plasmashell does not work in my case as it just fails. Killing plasmashell 
> and then starting it just delivers the same situation, a black screen with 
> plasmashell running in the background and that is it.  Starting plasmashell 
> shows the following output:
> kscreen: launcherDataAvailable: "org.kde.KScreen.Backend.XRandR"
> kscreen: Launcher finished with exit code 1 , status 0
> kscreen: Service for requested backend already running
> 
> And yes I have a kscreen_backend_launcher process running, which is 
> started by kded5. When I try to kill this one, kded5 is automatically 
> restarting it. 
> 
> To be honest this patch makes things worse as that plasmashell is not 
> starting at all.
> 
> Raymond Wooninck wrote:
> Just forgot:
> raymond@HQVMT44011:~% xrandr --version
> xrandr program version   1.4.3
> Server reports RandR version 1.4
> 
> Bhushan Shah wrote:
> >kscreen: launcherDataAvailable: "org.kde.KScreen.Backend.XRandR"
> >kscreen: Launcher finished with exit code 1 , status 0
> >kscreen: Service for requested backend already running
> 
> I had same output but with this patch I am not getting that.. and 
> plasmashell works for me fine.

Ok. I dived a little deeper into the issues that I got (as that reverting the 
patch didn't help) and it appeared that I had to clean my config files. I 
deleted all the "plasma*" files/directories from .config and after this I was 
able to start plasmashell again. A new problem arose with the kcache files for 
the plasma theme, which caused plasma freezes. Deleting those made my 
installation happy and now I can boot normally and plasmashell is starting.

Lukas, you might want to give this patch a try with a clean user, to see if it 
works. However it seems not to resolve the issue completely as that another 
person indicated that with a new user, he now gets the old issue despite that 
with his normal user everything works fine.


- Raymond


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


On Dec. 28, 2014, 10:33 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121710/
> ---
> 
> (Updated Dec. 28, 2014, 10:33 a.m.)
> 
> 
> Review request for Plasma, Solid and Daniel Vrátil.
> 
> 
> Repository: libkscreen
> 
> 
> Description
> ---
> 
> Avoid risk of starting two kscreen_launchers at the same having a race 
> condition.
> 
> There were three possible bugs:
> CheckIsAlreadyRunning tried to register a service and check if it worked.
> This could clash with another process checking at the same time. Causing them 
> both to fail saying another is running
> Similarly, a daemon doing actual registering could clash with another daemon 
> just checking if the name is free, and then it would fail saying we can't 
> init()
>  
> There was also a risk that two launchers pass the check that nothing is 
> running, then both try to activate a session. DBus server handles this fine 
> and one will gracefully fail. Without this patch the second launcher would 
> just die without returning the path of the service that was activated causing 
> the relevant app to do nothing.
> 
> 
> --
> 
> IMHO, you'd be better off having a fixed service name and using DBus 
> activation for exactly these reasons.
> You could put the different backends at different object paths, and have a 
> method on the root object that says which object path to use rather than 
> using the stdout of a launcher. That's a discussion for another day though.
> 
> 
> Diffs
> -
> 
>   src/backendlauncher/backendloader.cpp e7da8cd 
>   src/backendlauncher/main.cpp f8bf323 
> 
> Diff: https://git.reviewboard.kde.org/r/121710/diff/
> 
> 
> Testing
> ---
> 
> Send it to bshah. Plasmashell started for him. Previously it didn't.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
htt

Re: Review Request 121710: Avoid risk of starting two kscreen_launchers at the same having race conditions

[Lukáš Tinkl]

> On Pro. 29, 2014, 2:55 dop., Lukáš Tinkl wrote:
> > Unfortunataly it doesn't fix it here, plasmashell starts with a blank 
> > screen. kquitapp5 plasmashell && plasmashell brings it back
> 
> Bhushan Shah wrote:
> Works for me.. :S which XRandr version you have?
> 
> David Edmundson wrote:
> That's depressing to hear. I need some help on this; logs, traces, 
> something as I can't reproduce here and this bug is super duper critical.
> 
> Do you agree this change still makes sense though? Even if there is 
> another problem it will be easier if there's one potential bug less.
> 
> Raymond Wooninck wrote:
> Unfortunately I seem to have hit a worse situation.  kquitapp5 
> plasmashell does not work in my case as it just fails. Killing plasmashell 
> and then starting it just delivers the same situation, a black screen with 
> plasmashell running in the background and that is it.  Starting plasmashell 
> shows the following output:
> kscreen: launcherDataAvailable: "org.kde.KScreen.Backend.XRandR"
> kscreen: Launcher finished with exit code 1 , status 0
> kscreen: Service for requested backend already running
> 
> And yes I have a kscreen_backend_launcher process running, which is 
> started by kded5. When I try to kill this one, kded5 is automatically 
> restarting it. 
> 
> To be honest this patch makes things worse as that plasmashell is not 
> starting at all.
> 
> Raymond Wooninck wrote:
> Just forgot:
> raymond@HQVMT44011:~% xrandr --version
> xrandr program version   1.4.3
> Server reports RandR version 1.4
> 
> Bhushan Shah wrote:
> >kscreen: launcherDataAvailable: "org.kde.KScreen.Backend.XRandR"
> >kscreen: Launcher finished with exit code 1 , status 0
> >kscreen: Service for requested backend already running
> 
> I had same output but with this patch I am not getting that.. and 
> plasmashell works for me fine.
> 
> Raymond Wooninck wrote:
> Ok. I dived a little deeper into the issues that I got (as that reverting 
> the patch didn't help) and it appeared that I had to clean my config files. I 
> deleted all the "plasma*" files/directories from .config and after this I was 
> able to start plasmashell again. A new problem arose with the kcache files 
> for the plasma theme, which caused plasma freezes. Deleting those made my 
> installation happy and now I can boot normally and plasmashell is starting.
> 
> Lukas, you might want to give this patch a try with a clean user, to see 
> if it works. However it seems not to resolve the issue completely as that 
> another person indicated that with a new user, he now gets the old issue 
> despite that with his normal user everything works fine.

No change, even with a new user. KScreen also routinely forgets my settings and 
sets the external monitor as a clone (although my setup is an extension to the 
right side) and unsets the primary display to be empty.


- Lukáš


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


On Pro. 28, 2014, 11:33 dop., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121710/
> ---
> 
> (Updated Pro. 28, 2014, 11:33 dop.)
> 
> 
> Review request for Plasma, Solid and Daniel Vrátil.
> 
> 
> Repository: libkscreen
> 
> 
> Description
> ---
> 
> Avoid risk of starting two kscreen_launchers at the same having a race 
> condition.
> 
> There were three possible bugs:
> CheckIsAlreadyRunning tried to register a service and check if it worked.
> This could clash with another process checking at the same time. Causing them 
> both to fail saying another is running
> Similarly, a daemon doing actual registering could clash with another daemon 
> just checking if the name is free, and then it would fail saying we can't 
> init()
>  
> There was also a risk that two launchers pass the check that nothing is 
> running, then both try to activate a session. DBus server handles this fine 
> and one will gracefully fail. Without this patch the second launcher would 
> just die without returning the path of the service that was activated causing 
> the relevant app to do nothing.
> 
> 
> --
> 
> IMHO, you'd be better off having a fixed service name and using DBus 
> activation for exactly these reasons.
> You could put the different backends at different object paths, and have a 
> method on the root object that says which object path to use rather than 
> using the stdout of a launcher. That's a discussion for another day though.
> 
> 
> Diffs
> -
> 
>   src/backendlauncher/backendloader.cpp e7da8cd 
>   src/backendlauncher/main.cpp f8bf323 
> 
> Diff: https://gi