Jenkins-kde-ci: plasma-framework master kf5-qt5 » Linux,All,gcc - Build # 119 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/119/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Wed, 04 Nov 2015 17:22:17 +
Build duration: 6 min 42 sec

CHANGE SET
Revision 01f4cf59eaf2e97c4bae60eeb88e4f373b189982 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit src/plasma/data/servicetypes/plasma-shell.desktop
  change: edit src/desktoptheme/breeze-dark/metadata.desktop
  change: edit examples/applets/widgetgallery/metadata.desktop
  change: edit 
src/scriptengines/ruby/plasma-scriptengine-ruby-dataengine.desktop
  change: edit 
src/scriptengines/python/plasma-scriptengine-runner-python.desktop
  change: edit src/desktoptheme/air/metadata.desktop
  change: edit examples/kpart/plasma-example-kpart-shell.desktop
  change: edit examples/applets/helloworld/metadata.desktop
  change: edit examples/applets/testshaders/metadata.desktop
  change: edit examples/applets/qmltasks/metadata.desktop
  change: edit examples/applets/windowthumbnails/metadata.desktop
  change: edit 
examples/dataengines/sourcesOnRequest/plasma-dataengine-example-sourcesOnRequest.desktop
  change: edit autotests/data/testpackage/metadata.desktop
  change: edit examples/applets/compactrepresentation/metadata.desktop
  change: edit src/plasma/data/servicetypes/plasma-generic.desktop
  change: edit src/desktoptheme/breeze/metadata.desktop
  change: edit 
examples/dataengines/simpleEngine/plasma-dataengine-example-simpleEngine.desktop
  change: edit examples/wallpapers/autumn/metadata.desktop
  change: edit examples/applets/bugreport/metadata.desktop
  change: edit examples/applets/conditionalloader/metadata.desktop
  change: edit examples/applets/testtheme/metadata.desktop
  change: edit src/plasma/data/servicetypes/plasma-scriptengine.desktop
  change: edit src/plasma/data/servicetypes/plasma-containmentactions.desktop
  change: edit src/scriptengines/qml/data/plasma-wallpaper.desktop
  change: edit src/platformstatus/platformstatus.desktop
  change: edit src/kpart/plasma-kpart.desktop
  change: edit src/plasma/data/servicetypes/plasma-applet.desktop
  change: edit examples/applets/samegame/metadata.desktop
  change: edit examples/applets/notes/metadata.desktop
  change: edit 
src/scriptengines/python/plasma-scriptengine-dataengine-python.desktop
  change: edit autotests/packagemetadatatest.desktop
  change: edit examples/applets/dataenginemodel/metadata.desktop
  change: edit src/desktoptheme/oxygen/metadata.desktop
  change: edit tests/testengine/plasma-dataengine-testengine.desktop
  change: edit examples/applets/testcomponents/metadata.desktop
  change: edit src/plasma/data/servicetypes/plasma-service.desktop
  change: edit src/plasma/data/servicetypes/plasma-containment.desktop
  change: edit autotests/data/signedPackage/metadata.desktop
  change: edit 
examples/testcontainmentactionsplugin/plasma-containmentactions-test.desktop
  change: edit autotests/data/testfallbackpackage/metadata.desktop
  change: edit src/plasma/data/servicetypes/plasma-packagestructure.desktop
  change: edit src/plasma/data/servicetypes/plasma-dataengine.desktop
  change: edit 
examples/dataengines/customDataContainers/plasma-dataengine-example-customDataContainers.desktop
  change: edit examples/applets/nowplaying/metadata.desktop
  change: edit examples/applets/config/metadata.desktop
  change: edit src/plasma/data/servicetypes/plasma-lookandfeel.desktop
  change: edit 
src/scriptengines/qml/data/plasma-scriptengine-applet-declarative.desktop
  change: edit examples/containments/testcontainment/metadata.desktop


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
11 test(s)Failed: TestSuite.dialognativetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 5/7 (71%)FILES 63/104 (61%)CLASSES 63/104 (61%)LINE 3912/10009 
(39%)CONDITIONAL 1919/3036 (63%)

By packages
  
autotests
FILES 20/20 (100%)CLASSES 20/20 (100%)LINE 543/564 
(96%)CONDITIONAL 338/606 (56%)
src.declarativeimports.core
FILES 7/20 (35%)CLASSES 7/20 (35%)LINE 355/2003 
(18%)CONDITIONAL 148/228 (65%)
src.plasma
FILES 14/21 (67%)CLASSES 14/21 (67%)LINE 1588/3635 
(44%)CONDITIONAL 776/1192 (65%)
src.plasma.private
FILES 18/26 (69%)CLASSES 18/26 (69%)LINE 946/1739 
(54%)CONDITIONAL 397/602 (66%)
src.plasma.scripting
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/184 (0%)CONDITIONAL 0/0 
(100%)
src.plasmaquick
FILES 4/11 (36%)CLASSES 4/11 (36%)LINE 480/1771 
(27%)CONDITIONAL 260/408 (64%)
src.plasmaquick.private
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/113 (0%)CONDITIONAL 0/0 
(100%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org

Moving KWayland to frameworks

[Martin Graesslin]

Hi,

after the Plasma 5.5 release I would like to move KWayland to frameworks. The 
main reason is that it is oddly placed in plasma-workspace as it's also a 
library useful for applications (example kde-connect uses it already).

KWayland is designed to be a tier1/integration framework. The current 
dependencies are:
* QtGui 
* Wayland Client (1.7)
* Wayland Server (1.7)
* EGL

License is  LGPL version 2.1, or version 3 or later versions approved by the 
membership of KDE e.V.

There are two things which make the move to frameworks difficult and I don't 
see a solution to it at the moment:

1. We require C++11 without exceptions: reason, it's designed for Linux and it 
didn't come to my mind to restrict us on the compiler due to lack of support 
in Visual Studio.

2. We use Qt 5.4.

For item 1 I only see the possibility of adding an exception [1]. For 2 it 
might be possible to get it down to 5.3 again. The biggest usage of Qt 5.4 
code is the new QSignalSpy syntax in autotests. I don't want to remove that, 
but it's of course possible to make autotests to only build with Qt 5.4. Of 
course I would also accept an exception ;-)

Given the release schedule I would target either the January or February 
frameworks release for inclusion.

Opinions?

Best Regards
Martin Gräßlin


[1] It might make sense to formalize the exception that integration frameworks 
which are not buildable on some platforms are not bound to restrictions of 
that framework.

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

icon frameworks

[Harald Sitter]

Salut,

I am presently preparing to move icons into frameworks scope.

So we are all on the same page:

- breeze-icons is a new repo going to be split from breeze and moving
to frameworks (tier1)
- oxygen-icons is a new repo of an old tarball (previously part of
apps) that ought to be released alongside breeze-icons since we want
to support both. so that also ought to move to frameworks (tier1).
currently this is still in plasma's scope and needs a ticket filed for
moving the repo.

From what I understand both need a metainfo.yaml and a README.md to
comply with requriements. Until we are confident everything is lovely
these should be marked release: false.
Since Plasma has a defacto runtime dependency on breeze-icons I
suspect some release coordination or gap-closing releases will be
needed to make plasma 5.5 beta have icons?

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

Maintenance of api.kde.org

[Ben Cooksley]

Hi all,

For some time it has been apparent that api.kde.org is experiencing
some issues with maintenance. It doesn't really fall into sysadmin's
domain, but developers often lack the knowledge on how to get Doxygen
working as needed to build projects API documentation. This isn't
helped by the setup not being simple for easy local testing.

Any volunteers to look into it, fix some issues and generally make it
easier to work with for the future?

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

Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » Linux,All,gcc - Build # 128 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/128/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Wed, 04 Nov 2015 17:37:05 +
Build duration: 7 min 34 sec

CHANGE SET
Revision 01f4cf59eaf2e97c4bae60eeb88e4f373b189982 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit src/desktoptheme/oxygen/metadata.desktop
  change: edit examples/applets/nowplaying/metadata.desktop
  change: edit examples/applets/samegame/metadata.desktop
  change: edit src/plasma/data/servicetypes/plasma-lookandfeel.desktop
  change: edit 
src/scriptengines/python/plasma-scriptengine-runner-python.desktop
  change: edit examples/applets/bugreport/metadata.desktop
  change: edit src/desktoptheme/breeze-dark/metadata.desktop
  change: edit examples/applets/helloworld/metadata.desktop
  change: edit src/plasma/data/servicetypes/plasma-packagestructure.desktop
  change: edit 
examples/dataengines/sourcesOnRequest/plasma-dataengine-example-sourcesOnRequest.desktop
  change: edit src/platformstatus/platformstatus.desktop
  change: edit src/plasma/data/servicetypes/plasma-applet.desktop
  change: edit src/desktoptheme/breeze/metadata.desktop
  change: edit examples/wallpapers/autumn/metadata.desktop
  change: edit examples/applets/compactrepresentation/metadata.desktop
  change: edit src/plasma/data/servicetypes/plasma-shell.desktop
  change: edit autotests/data/testpackage/metadata.desktop
  change: edit examples/applets/testshaders/metadata.desktop
  change: edit autotests/data/testfallbackpackage/metadata.desktop
  change: edit autotests/data/signedPackage/metadata.desktop
  change: edit src/plasma/data/servicetypes/plasma-containmentactions.desktop
  change: edit src/plasma/data/servicetypes/plasma-scriptengine.desktop
  change: edit examples/applets/windowthumbnails/metadata.desktop
  change: edit 
examples/dataengines/simpleEngine/plasma-dataengine-example-simpleEngine.desktop
  change: edit examples/applets/testtheme/metadata.desktop
  change: edit src/scriptengines/qml/data/plasma-wallpaper.desktop
  change: edit examples/applets/qmltasks/metadata.desktop
  change: edit src/kpart/plasma-kpart.desktop
  change: edit src/plasma/data/servicetypes/plasma-service.desktop
  change: edit examples/applets/widgetgallery/metadata.desktop
  change: edit examples/containments/testcontainment/metadata.desktop
  change: edit examples/applets/conditionalloader/metadata.desktop
  change: edit examples/applets/dataenginemodel/metadata.desktop
  change: edit examples/applets/testcomponents/metadata.desktop
  change: edit src/plasma/data/servicetypes/plasma-generic.desktop
  change: edit examples/applets/config/metadata.desktop
  change: edit 
examples/dataengines/customDataContainers/plasma-dataengine-example-customDataContainers.desktop
  change: edit tests/testengine/plasma-dataengine-testengine.desktop
  change: edit src/plasma/data/servicetypes/plasma-containment.desktop
  change: edit examples/kpart/plasma-example-kpart-shell.desktop
  change: edit autotests/packagemetadatatest.desktop
  change: edit src/plasma/data/servicetypes/plasma-dataengine.desktop
  change: edit examples/applets/notes/metadata.desktop
  change: edit 
src/scriptengines/qml/data/plasma-scriptengine-applet-declarative.desktop
  change: edit 
src/scriptengines/python/plasma-scriptengine-dataengine-python.desktop
  change: edit 
src/scriptengines/ruby/plasma-scriptengine-ruby-dataengine.desktop
  change: edit src/desktoptheme/air/metadata.desktop
  change: edit 
examples/testcontainmentactionsplugin/plasma-containmentactions-test.desktop


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
11 test(s)Failed: TestSuite.dialognativetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 5/7 (71%)FILES 63/104 (61%)CLASSES 63/104 (61%)LINE 3919/10047 
(39%)CONDITIONAL 1918/3036 (63%)

By packages
  
autotests
FILES 20/20 (100%)CLASSES 20/20 (100%)LINE 542/565 
(96%)CONDITIONAL 338/606 (56%)
src.declarativeimports.core
FILES 7/20 (35%)CLASSES 7/20 (35%)LINE 356/2004 
(18%)CONDITIONAL 148/228 (65%)
src.plasma
FILES 14/21 (67%)CLASSES 14/21 (67%)LINE 1591/3640 
(44%)CONDITIONAL 776/1192 (65%)
src.plasma.private
FILES 18/26 (69%)CLASSES 18/26 (69%)LINE 949/1746 
(54%)CONDITIONAL 396/602 (66%)
src.plasma.scripting
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/194 (0%)CONDITIONAL 0/0 
(100%)
src.plasmaquick
FILES 4/11 (36%)CLASSES 4/11 (36%)LINE 481/1785 
(27%)CONDITIONAL 260/408 (64%)
src.plasmaquick.private
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/113 (0%)CONDITIONAL 0/0 
(100%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org

Re: [OS X] avoiding kdelibs4 headers? ("unknown type name 'KARCHIVE_DEPRECATED'" building kdoctools)

[René J . V . Bertin]

Alex Merry wrote:

> Well, if we'd done it for kdelibs4 as well, you wouldn't have this issue
> - if you had to add -I/opt/local/include/kdelibs in order to find any
> kdelibs headers, none would be found by mistake.

Before I find myself patching who knows how many KF5 files: is there a 
provision 
in KDELibs4 to install its headers in a place where they shouldn't clash with 
KF5's headers?

Thanks
René

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

Re: Moving KWayland to frameworks

[Kevin Ottens]

Hello,

On Thursday 05 November 2015 10:50:06 Martin Graesslin wrote:
> There are two things which make the move to frameworks difficult and I don't
> see a solution to it at the moment:
> 
> 1. We require C++11 without exceptions: reason, it's designed for Linux and
> it didn't come to my mind to restrict us on the compiler due to lack of
> support in Visual Studio.
> 
> 2. We use Qt 5.4.
> 
> For item 1 I only see the possibility of adding an exception [1].

I personally don't like exceptions, it gets complex fast.

Now are you sure it is really problematic? To me it looks like you're using 
almost exclusively features from the white list. It is probably just a matter 
of s/nullptr/Q_NULLPTR/ and s/override/Q_DECL_OVERRIDE/ in your case.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



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

Re: [OS X] avoiding kdelibs4 headers? ("unknown type name 'KARCHIVE_DEPRECATED'" building kdoctools)

[René J . V . Bertin]

René J. V. Bertin wrote:

> Before I find myself patching who knows how many KF5 files: is there a
> provision in KDELibs4 to install its headers in a place where they shouldn't
> clash with KF5's headers?

(apologies for asking a bit too quickly):

It seems that configuring KDELibs4 with -DINCLUDE_INSTALL_DIR=foo should have 
the desired effect, but will that also cause all other KDE4 headerfiles to be 
installed under that same prefix?
In other words, am I going to have to rebuild all dependencies of KDE4 
applications I'll continue to use? Surely something has been foreseen to allow 
developers to bootstrap gradually from KDE4 to KF5?
(This is not on Linux, so I'm not running a KDE desktop, just a number of KDE-
based applications installed, to be exhaustive, through MacPorts.)

R.

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

Re: Review Request 125961: [declarative/core] Use BypassWindowManagerHint only on platform X11

[Marco Martin]

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

Ship it!


good as short term, but would love apps not suiciding when that flag is set. 
would need a fix in qtwayland i guess

- Marco Martin


On Nov. 5, 2015, 3:38 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125961/
> ---
> 
> (Updated Nov. 5, 2015, 3:38 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> BypassWindowManagerHint is a flag which is X11 specific. Because of
> that for example QtWayland doesn't create a real window for QWindows
> with this flag.
> 
> Using such a window will eventually result in a freeze of the whole
> application. If one renders with QtQuick to such a window, mesa will
> request a frame callback from the compositor. Just the compositor
> will never deliver the frame rendered callback as it doesn't know the
> window exists in the first place and by that doesn't render it and
> will never ever deliver the frame rendered callback.
> 
> If now one tries to render another frame, mesa notices that it hasn't
> got the frame callback and will block the thread till that happens.
> With the setup described: that's until eternity.
> 
> Change-Id: I352ff788f90799ce0e0a5de53d5d34c02c8468c3
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/CMakeLists.txt 
> 4e0fe8bf95d51c282060a0a05914c976cd4e5783 
>   src/declarativeimports/core/config-x11.h.cmake PRE-CREATION 
>   src/declarativeimports/core/tooltipdialog.cpp 
> 121ccf91bb17c5dd17e0742831830186e9e44a1e 
> 
> Diff: https://git.reviewboard.kde.org/r/125961/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

Review Request 125965: Add declarative plugin to KHolidays

[Martin Klapetek]

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

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: Review Request 125969: kinit: fix Coverity issues + small optimization

[Nick Shaforostoff]

> On Nov. 5, 2015, 11:37 p.m., Alex Merry wrote:
> > src/kdeinit/kinit.cpp, line 370
> > 
> >
> > Why call fromRawData with an explicit strlen()? 
> > QByteArray(displayEnvVarName()) will have the same effect.

fromRawData doesn't copy the data provided. the deep copy will be made later by 
operator+ into a properly sized qbytearray to store "="-ending string


- Nick


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


On Nov. 5, 2015, 10:16 p.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125969/
> ---
> 
> (Updated Nov. 5, 2015, 10:16 p.m.)
> 
> 
> Review request for KDE Frameworks and Alex Merry.
> 
> 
> Repository: kinit
> 
> 
> Description
> ---
> 
> this patch fixes two coverity issues ranked 'outstanding':
> https://scan5.coverity.com/reports.htm#v39099/p10103/fileInstanceId=82663767=24554334=258481
> https://scan5.coverity.com/reports.htm#v39099/p10103/fileInstanceId=82663767=24557588=258474
> 
> and also does small string-related optimization by eliminating redundant 
> mallocs done by QByteArray ctor
> 
> 
> Diffs
> -
> 
>   src/kdeinit/kinit.cpp 9e775b6 
> 
> Diff: https://git.reviewboard.kde.org/r/125969/diff/
> 
> 
> Testing
> ---
> 
> compiles fine
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

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

Re: Maintenance of api.kde.org

[Alex Merry]

On 2015-11-05 09:22, Ben Cooksley wrote:

Hi all,

For some time it has been apparent that api.kde.org is experiencing
some issues with maintenance. It doesn't really fall into sysadmin's
domain, but developers often lack the knowledge on how to get Doxygen
working as needed to build projects API documentation. This isn't
helped by the setup not being simple for easy local testing.

Any volunteers to look into it, fix some issues and generally make it
easier to work with for the future?


This is my domain really, as maintainer of kapidox - kapidox was 
intended to make this simpler and easier, but currently it's only run on 
frameworks. I don't really know much about the automation on api.kde.org 
itself, though, and we need to figure out how to choose whether to run 
kapidox, kdelibs4's apidox generation scripts, or no apidox generation 
at all for a given project.


I'm willing to put some time into this, but I'd need to be able to at 
least mirror api.kde.org's setup locally to try tweaking and testing 
things - going through Allen Winter every time I want to test something 
out (and then waiting for the cron jobs or whatever to run) is just too 
slow of a feedback cycle.


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

Re: Review Request 125969: kinit: fix Coverity issues + small optimization

[Alex Merry]

> On Nov. 5, 2015, 11:37 p.m., Alex Merry wrote:
> > src/kdeinit/kinit.cpp, line 370
> > 
> >
> > Why call fromRawData with an explicit strlen()? 
> > QByteArray(displayEnvVarName()) will have the same effect.
> 
> Nick Shaforostoff wrote:
> fromRawData doesn't copy the data provided. the deep copy will be made 
> later by operator+ into a properly sized qbytearray to store "="-ending string

Ah, ok, makes sense. It would be a bit nicer to wrap up getting 
displayEnvVarName() as a QByteArray in a function that was next to the 
definition of displayEnvVarName() in the file - given the lifetime constraints 
of fromRawData, it's nice to be able to see easily from where it is used that 
those constraints will be satisfied.


- Alex


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


On Nov. 5, 2015, 10:16 p.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125969/
> ---
> 
> (Updated Nov. 5, 2015, 10:16 p.m.)
> 
> 
> Review request for KDE Frameworks and Alex Merry.
> 
> 
> Repository: kinit
> 
> 
> Description
> ---
> 
> this patch fixes two coverity issues ranked 'outstanding':
> https://scan5.coverity.com/reports.htm#v39099/p10103/fileInstanceId=82663767=24554334=258481
> https://scan5.coverity.com/reports.htm#v39099/p10103/fileInstanceId=82663767=24557588=258474
> 
> and also does small string-related optimization by eliminating redundant 
> mallocs done by QByteArray ctor
> 
> 
> Diffs
> -
> 
>   src/kdeinit/kinit.cpp 9e775b6 
> 
> Diff: https://git.reviewboard.kde.org/r/125969/diff/
> 
> 
> Testing
> ---
> 
> compiles fine
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

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

Re: Failure while executing KTar::open while using KCompressionDevice as the device

[Luiz Romário Santana Rios]

2015-11-03 21:29 GMT-03:00 Aleix Pol :
> On Tue, Nov 3, 2015 at 3:58 AM, Luiz Romário Santana Rios
>  wrote:
>> 2015-11-02 23:03 GMT-03:00 Aleix Pol :
>>> On Tue, Nov 3, 2015 at 3:00 AM, Luiz Romário Santana Rios
>>>  wrote:
 2015-11-02 22:41 GMT-03:00 Aleix Pol :
> On Mon, Nov 2, 2015 at 6:53 PM, Luiz Romário Santana Rios
>  wrote:
>> Hello,
>>
>> I'm trying to decompress a XZ archive downloaded using
>> QNetworkAccessManager, so, according to the documents, I have to pass
>> the QNetworkReply pointer to a KCompressionDevice and, then, use it as
>> Ktar's device like this:
>>
>> https://gist.github.com/anonymous/b8fb686367f518a7dbb5
>>
>> The problem is that KTar::open() fails and returns false. The file I'm
>> trying to extract has the following structure more or less:
>> /root
>> /root/dir
>> /root/dir/file1
>> /root/dir/file2
>> ...
>>
>> So, as far as I've seen, the code runs normally when entering /root
>> and /root/dir, but, pretty high in the stack, at
>> KXzFilter::uncompress(), the call to lzma_code returns
>> LZMA_FORMAT_ERROR while trying to uncompress file1 (or file2, I'm not
>> sure). Here's the call stack:
>>
>> https://gist.github.com/anonymous/9ea380cfe48daadb5971
>>
>> Is this a bug? If it's a bug, how can I proceed to fix it?
>>
>> Thanks for the attention.
>
> Hi,
> A good first step would be coming up with a unit test like the ones
> you can find in karchive/autotests. If we have a reproducible test
> case it will be much faster to fix (for you and for us).
>
> Regards,
> Aleix

 I'll do that, but how do I host a local file so that it can be
 "downloaded" from QNAM?

 --
 Luiz Romário Santana Rios
>>>
>>> Using file:/// url scheme you can asynchronously read local files.
>>>
>>> Aleix
>>
>> I created a pretty simple archive:
>> /root
>> /root/dir
>> /root/dir/file1: contents of file1
>> /root/dir/file2: contents of file2
>> /root/dir/file3: contents of file3
>>
>> And then set up a simple test case:
>> Header: https://paste.kde.org/p8jkzlcgg/u5oiqj
>> Implementation: https://paste.kde.org/pt1yeawj1/t8sg8j
>>
>> Then this happens:
>> [...]
>> QWARN : KCompressionDeviceTest::testXzNetworkReplyDevice()
>> QIODevice::seek: Cannot call seek on a sequential device
>> QWARN : KCompressionDeviceTest::testXzNetworkReplyDevice()
>> QIODevice::seek: Cannot call seek on a sequential device
>> QWARN : KCompressionDeviceTest::testXzNetworkReplyDevice()
>> QIODevice::seek: Cannot call seek on a sequential device
>> QWARN : KCompressionDeviceTest::testXzNetworkReplyDevice()
>> QIODevice::seek: Cannot call seek on a sequential device
>> QWARN : KCompressionDeviceTest::testXzNetworkReplyDevice()
>> QIODevice::seek: Cannot call seek on a sequential device
>> QSYSTEM: KCompressionDeviceTest::testXzNetworkReplyDevice() Maximum
>> amount of warnings exceeded. Use -maxwarnings to override.
>>
>> Then the test freezes. I have to interrupt it so that it finishes. What's 
>> wrong?
>>
>> --
>> Luiz Romário Santana Rios
>
> If non-sequential is not supposed to work (which I don't know, I've
> never used KArchive like that), maybe you can consider doing a
> if(!device->isSequential()) download, then open.

I tried downloading the contents to a QBuffer and then passing it to
KCompressionDevice but it didn't work either.

>
> Also, can you provide the test in the shape of a patch to KArchive? :)

There you go: https://git.reviewboard.kde.org/r/125941/

>
> Aleix

P.S.: Resending because my previous message didn't reach the list.

-- 
Luiz Romário Santana Rios
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 125971: k7zip: fix memleaks, lower memory usage

[Nick Shaforostoff]

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

Review request for KDE Frameworks and Laurent Montel.


Repository: karchive


Description
---

i couldn't find the place where the pointers contained in the member arrays are 
deleted so i have added their releasing. for this i have used qDeleteAll (you 
can search for qDeleteAll in the diff)

also i have reordered members of FileInfo to reduce its 'sizeof'
also using qvector for storing pointers is as fast as using qlist (or even 
faster) and needs less memory
also i have switched qvector acces from operator[] to .at() because it is const 
(doesn't call detach() method internally)
also i have disabled the code that was filling 'method' string because it was 
not used anywhere after


Diffs
-

  src/k7zip.cpp 321620a 

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


Testing
---

compiles fine


Thanks,

Nick Shaforostoff

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

Re: Review Request 125969: kinit: fix Coverity issues + small optimization

[Alex Merry]

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


Generally makes sense to me, other than my first note below:


src/kdeinit/kinit.cpp (line 370)


Why call fromRawData with an explicit strlen()? 
QByteArray(displayEnvVarName()) will have the same effect.



src/kdeinit/kinit.cpp (lines 1076 - 1077)


This whole thing is unpleasantly C-ish, and a QByteArray or QVector 
would have been altogether nicer, but that would be a much bigger refactoring 
of the code.


- Alex Merry


On Nov. 5, 2015, 10:16 p.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125969/
> ---
> 
> (Updated Nov. 5, 2015, 10:16 p.m.)
> 
> 
> Review request for KDE Frameworks and Alex Merry.
> 
> 
> Repository: kinit
> 
> 
> Description
> ---
> 
> this patch fixes two coverity issues ranked 'outstanding':
> https://scan5.coverity.com/reports.htm#v39099/p10103/fileInstanceId=82663767=24554334=258481
> https://scan5.coverity.com/reports.htm#v39099/p10103/fileInstanceId=82663767=24557588=258474
> 
> and also does small string-related optimization by eliminating redundant 
> mallocs done by QByteArray ctor
> 
> 
> Diffs
> -
> 
>   src/kdeinit/kinit.cpp 9e775b6 
> 
> Diff: https://git.reviewboard.kde.org/r/125969/diff/
> 
> 
> Testing
> ---
> 
> compiles fine
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

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

Re: Review Request 125960: Fix build of some projects using ecm_create_qm_loader()

[Alex Merry]

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


I'm confused about what you're trying to acheive with this. What you've 
actually done, as far as I can tell, is *stop* the files being set in the 
parent scope. That will make the project build, yes, but it will make 
ecm_create_qm_loader() essentially useless, because the file we generated won't 
be added to the target, and so won't be built.

Did you try running the unit tests? Because I'd be very surprised if they 
passed.

I suspect the issue analitza is having is similar to what I fixed in 
http://commits.kde.org/kconfig/19513e1910f19375a4c17a61f048c7f8c2f9e840 - using 
the file generation macro in a different CMakeLists.txt to the target the files 
are added to. Although I haven't looked at analitza's source code to be sure.

- Alex Merry


On Nov. 5, 2015, 2:36 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125960/
> ---
> 
> (Updated Nov. 5, 2015, 2:36 p.m.)
> 
> 
> Review request for Extra Cmake Modules and KDE Frameworks.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Makes sure the variable is properly initialized.
> 
> 
> Diffs
> -
> 
>   modules/ECMPoQmTools.cmake 22258dc 
> 
> Diff: https://git.reviewboard.kde.org/r/125960/diff/
> 
> 
> Testing
> ---
> 
> This error won't happen anymore:
> https://build.kde.org/job/analitza%20master%20kf5-qt5/12/PLATFORM=Linux,compiler=gcc/console
> 
> 
> 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 125965: Add declarative plugin to KHolidays

[Aleix Pol Gonzalez]

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


I don't know enough about the module, so I don't know about the exact case, but 
usually it's good to develop such API outside then when it stabilizes merge to 
the framework, I'd say. Otherwise changes in the API will be very hard.

- Aleix Pol Gonzalez


On Nov. 5, 2015, 8:57 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125965/
> ---
> 
> (Updated Nov. 5, 2015, 8:57 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: Review Request 125869: Convert all io slave .protocol data to json and embed it.

[Albert Astals Cid]

> On nov. 3, 2015, 9:47 p.m., Albert Astals Cid wrote:
> > How does this work without modifying 
> > KProtocolInfoPrivate::KProtocolInfoPrivate?
> 
> Christoph Cullmann wrote:
> You mean the JSON stuff? That was implemented in 
> https://git.reviewboard.kde.org/r/125830/
> For the http slave, that already works nicely, but we missed that 
> "ExtraNames" as used by other slaves need i18n care.
> 
> Albert Astals Cid wrote:
> i see, i did not see that there's two almost copied 
> KProtocolInfoPrivate::KProtocolInfoPrivate implementations
> 
> So the json magic stuff (you can see 
> ./src/ioslaves/http/kcookiejar/kcookiejar.json in kio) only works for 
> Description and Name inside KPlugin, someone would need to update 
> createjsoncontext.py and filljsonfrompo.py so they also take into account 
> ExtraNames inside childs of "KDE-KIO-Protocols" and then make that new code 
> from 125830 extract the correct translation from the json.
> 
> Alex Richardson wrote:
> Reading the translated string can be done using 
> `KPluginMetaData::readTranslatedString()`
> 
> Christoph Cullmann wrote:
> Hmm, Ok, can take a look at that scripts. Will it be a problem that the 
> ExtraNames are a stringlist or is that fine?

You'll have to take care of serializing and unserializing the list, ideally 
using a well known marker like ; or similar. The scripts are at 
https://websvn.kde.org/trunk/l10n-kf5/scripts/


- Albert


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


On nov. 1, 2015, 6:13 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125869/
> ---
> 
> (Updated nov. 1, 2015, 6:13 p.m.)
> 
> 
> Review request for KDE Frameworks, Albert Astals Cid, Alex Richardson, David 
> Faure, and Luigi Toscano.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Convert all io slave .protocol data to json and embed it.
> Allows easier deployment of the slaves.
> 
> 
> Diffs
> -
> 
>   src/ioslaves/http/CMakeLists.txt 76a8e28 
>   src/ioslaves/help/main_ghelp.cpp 59c8558 
>   src/ioslaves/help/main.cpp 9939196 
>   src/ioslaves/help/help.protocol 1deefe5 
>   src/ioslaves/help/help.json PRE-CREATION 
>   src/ioslaves/help/ghelp.protocol d2a642a 
>   src/ioslaves/help/ghelp.json PRE-CREATION 
>   src/ioslaves/help/CMakeLists.txt 867b59d 
>   src/ioslaves/ftp/ftp.protocol 4c5f80c 
>   src/ioslaves/ftp/ftp.json PRE-CREATION 
>   src/ioslaves/ftp/ftp.cpp 382723a 
>   src/ioslaves/ftp/CMakeLists.txt 04f5600 
>   src/ioslaves/file/file.protocol 523c0f5 
>   src/ioslaves/file/file.json PRE-CREATION 
>   src/ioslaves/file/file.cpp 5ef1587 
>   src/ioslaves/file/CMakeLists.txt cb85cfb 
>   autotests/kprotocolinfotest.cpp fa3ad38 
>   src/ioslaves/http/http.protocol 49e5dc5 
>   src/ioslaves/http/https.protocol c15d06f 
>   src/ioslaves/http/webdav.protocol 05c977a 
>   src/ioslaves/http/webdavs.protocol d5e4b2f 
>   src/ioslaves/trash/CMakeLists.txt 05161cd 
>   src/ioslaves/trash/kio_trash.cpp cb23169 
>   src/ioslaves/trash/trash.json PRE-CREATION 
>   src/ioslaves/trash/trash.protocol 7430575 
> 
> Diff: https://git.reviewboard.kde.org/r/125869/diff/
> 
> 
> Testing
> ---
> 
> Tests still work (one needed patching, as the exec line contains now the full 
> path).
> 
> Correction: Somehow the ./autotests/jobtest test is unstable for me here, 
> sometimes it works, sometimes not :/ but even without this change.
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

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

Review Request 125969: kinit: fix Coverity issues + small optimization

[Nick Shaforostoff]

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

Review request for KDE Frameworks and Alex Merry.


Repository: kinit


Description
---

this patch fixes two coverity issues ranked 'outstanding':
https://scan5.coverity.com/reports.htm#v39099/p10103/fileInstanceId=82663767=24554334=258481
https://scan5.coverity.com/reports.htm#v39099/p10103/fileInstanceId=82663767=24557588=258474

and also does small string-related optimization by eliminating redundant 
mallocs done by QByteArray ctor


Diffs
-

  src/kdeinit/kinit.cpp 9e775b6 

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


Testing
---

compiles fine


Thanks,

Nick Shaforostoff

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

Jenkins-kde-ci: plasma-framework master kf5-qt5 » Linux,All,gcc - Build # 120 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/120/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Thu, 05 Nov 2015 09:15:37 +
Build duration: 8 min 21 sec

CHANGE SET
Revision 8286c7445257c7a66739cfdfe486e2dd447daf64 by David Edmundson: (Update 
version number of breeze dark too)
  change: edit src/desktoptheme/breeze-dark/metadata.desktop


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
11 test(s)Failed: TestSuite.dialognativetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 5/7 (71%)FILES 63/104 (61%)CLASSES 63/104 (61%)LINE 3906/10009 
(39%)CONDITIONAL 1916/3034 (63%)

By packages
  
autotests
FILES 20/20 (100%)CLASSES 20/20 (100%)LINE 541/564 
(96%)CONDITIONAL 338/606 (56%)
src.declarativeimports.core
FILES 7/20 (35%)CLASSES 7/20 (35%)LINE 355/2003 
(18%)CONDITIONAL 148/228 (65%)
src.plasma
FILES 14/21 (67%)CLASSES 14/21 (67%)LINE 1588/3635 
(44%)CONDITIONAL 776/1192 (65%)
src.plasma.private
FILES 18/26 (69%)CLASSES 18/26 (69%)LINE 942/1739 
(54%)CONDITIONAL 394/600 (66%)
src.plasma.scripting
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/184 (0%)CONDITIONAL 0/0 
(100%)
src.plasmaquick
FILES 4/11 (36%)CLASSES 4/11 (36%)LINE 480/1771 
(27%)CONDITIONAL 260/408 (64%)
src.plasmaquick.private
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/113 (0%)CONDITIONAL 0/0 
(100%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » Linux,All,gcc - Build # 129 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/129/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Thu, 05 Nov 2015 10:36:27 +
Build duration: 7 min 3 sec

CHANGE SET
Revision 8286c7445257c7a66739cfdfe486e2dd447daf64 by David Edmundson: (Update 
version number of breeze dark too)
  change: edit src/desktoptheme/breeze-dark/metadata.desktop
Revision 0233a7d5718774781d2b2a814742df1f09c353f6 by Marco Martin: (delete old 
panel background)
  change: delete 
src/desktoptheme/breeze-dark/translucent/widgets/panel-background.svgz
  change: edit src/desktoptheme/breeze-dark/CMakeLists.txt


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
11 test(s)Failed: TestSuite.dialognativetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 5/7 (71%)FILES 63/104 (61%)CLASSES 63/104 (61%)LINE 3921/10047 
(39%)CONDITIONAL 1919/3036 (63%)

By packages
  
autotests
FILES 20/20 (100%)CLASSES 20/20 (100%)LINE 544/565 
(96%)CONDITIONAL 338/606 (56%)
src.declarativeimports.core
FILES 7/20 (35%)CLASSES 7/20 (35%)LINE 356/2004 
(18%)CONDITIONAL 148/228 (65%)
src.plasma
FILES 14/21 (67%)CLASSES 14/21 (67%)LINE 1591/3640 
(44%)CONDITIONAL 776/1192 (65%)
src.plasma.private
FILES 18/26 (69%)CLASSES 18/26 (69%)LINE 949/1746 
(54%)CONDITIONAL 397/602 (66%)
src.plasma.scripting
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/194 (0%)CONDITIONAL 0/0 
(100%)
src.plasmaquick
FILES 4/11 (36%)CLASSES 4/11 (36%)LINE 481/1785 
(27%)CONDITIONAL 260/408 (64%)
src.plasmaquick.private
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/113 (0%)CONDITIONAL 0/0 
(100%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 125974: Make KTar KCompressionDevice-friendly

[Romário Rios]

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

Review request for KDE Frameworks and Aleix Pol Gonzalez.


Repository: karchive


Description
---

Up until now, since at least 5.12, decompressing some data coming directly from 
a QIODevice by using KCompressionDevice because this is a sequential device, 
and KTar and KArchive used to use QIODevice::seek and pos and some places, 
which made the decompression fail. This patch makes KTar sequential-friendly by 
replacing the calls to seek and pos with read and a simple counter, 
respectively.


Diffs
-

  src/karchive.cpp 0ece37c 
  src/ktar.cpp 824395e 

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


Testing
---

Makes the tests from review #125941 pass


Thanks,

Romário Rios

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

Re: Maintenance of api.kde.org

[Jeremy Whiting]

Alex,

Last time I checked api.kde.org was generated by scripts in the
websites/quality-kde-org git repository. It includes instructions for
installing it locally, though the instructions are a bit outdated. I
think perl's setup scripts have changed since it was written since I
needed to tweak the install script to get it to install here (when I
was looking into it about 8 months ago or so). Poke me if you hit the
same issues and I can put a patch up on reviewboard if it's still
around my hard drive here somewhere...

thanks,
Jeremy

On Thu, Nov 5, 2015 at 4:58 PM, Alex Merry  wrote:
> On 2015-11-05 09:22, Ben Cooksley wrote:
>>
>> Hi all,
>>
>> For some time it has been apparent that api.kde.org is experiencing
>> some issues with maintenance. It doesn't really fall into sysadmin's
>> domain, but developers often lack the knowledge on how to get Doxygen
>> working as needed to build projects API documentation. This isn't
>> helped by the setup not being simple for easy local testing.
>>
>> Any volunteers to look into it, fix some issues and generally make it
>> easier to work with for the future?
>
>
> This is my domain really, as maintainer of kapidox - kapidox was intended to
> make this simpler and easier, but currently it's only run on frameworks. I
> don't really know much about the automation on api.kde.org itself, though,
> and we need to figure out how to choose whether to run kapidox, kdelibs4's
> apidox generation scripts, or no apidox generation at all for a given
> project.
>
> I'm willing to put some time into this, but I'd need to be able to at least
> mirror api.kde.org's setup locally to try tweaking and testing things -
> going through Allen Winter every time I want to test something out (and then
> waiting for the cron jobs or whatever to run) is just too slow of a feedback
> cycle.
>
> Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125904: Save proxy url with correct scheme.

[David Faure]

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

Ship it!


If it worked in KDE SC 4, then the fix is probably much simpler than this (URLs 
without scheme usually sound like KUrl->QUrl porting bugs).
But otherwise, this fix looks good.

- David Faure


On Nov. 3, 2015, 3:48 p.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125904/
> ---
> 
> (Updated Nov. 3, 2015, 3:48 p.m.)
> 
> 
> Review request for KDE Frameworks and Eike Hein.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Currently, if user type a ip address/domain name in socks 5 proxy field, the 
> saved proxy url in configuration file will start with http:// instead of 
> socks:// . Same applies to ftp proxy.
> 
> The reason is that KUrlFilter append http scheme to url without scheme. This 
> patch uses setDefaultUrlScheme to make sure the correct scheme is used.
> 
> Also make necessary change to make sure that loading url configuration will 
> hide url scheme correctly.
> 
> 
> Diffs
> -
> 
>   src/kcms/kio/kproxydlg.cpp c8fd0cd 
> 
> Diff: https://git.reviewboard.kde.org/r/125904/diff/
> 
> 
> Testing
> ---
> 
> Save socks proxy and ftp proxy will result in "ftp://; and "socks://".
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

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

Re: Review Request 125961: [declarative/core] Use BypassWindowManagerHint only on platform X11

[Martin Gräßlin]

> On Nov. 5, 2015, 6:04 p.m., Marco Martin wrote:
> > good as short term, but would love apps not suiciding when that flag is 
> > set. would need a fix in qtwayland i guess

Bug report with a minimal example created: 
https://bugreports.qt.io/browse/QTBUG-49272


- Martin


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


On Nov. 5, 2015, 4:38 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125961/
> ---
> 
> (Updated Nov. 5, 2015, 4:38 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> BypassWindowManagerHint is a flag which is X11 specific. Because of
> that for example QtWayland doesn't create a real window for QWindows
> with this flag.
> 
> Using such a window will eventually result in a freeze of the whole
> application. If one renders with QtQuick to such a window, mesa will
> request a frame callback from the compositor. Just the compositor
> will never deliver the frame rendered callback as it doesn't know the
> window exists in the first place and by that doesn't render it and
> will never ever deliver the frame rendered callback.
> 
> If now one tries to render another frame, mesa notices that it hasn't
> got the frame callback and will block the thread till that happens.
> With the setup described: that's until eternity.
> 
> Change-Id: I352ff788f90799ce0e0a5de53d5d34c02c8468c3
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/CMakeLists.txt 
> 4e0fe8bf95d51c282060a0a05914c976cd4e5783 
>   src/declarativeimports/core/config-x11.h.cmake PRE-CREATION 
>   src/declarativeimports/core/tooltipdialog.cpp 
> 121ccf91bb17c5dd17e0742831830186e9e44a1e 
> 
> Diff: https://git.reviewboard.kde.org/r/125961/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: Review Request 125877: Fix kdeplatformtheme_unittest after last commit

[David Faure]

> On Oct. 29, 2015, 8:26 p.m., Aleix Pol Gonzalez wrote:
> > autotests/kdeplatformtheme_unittest.cpp, line 237
> > 
> >
> > What does `qApp->wheelScrollLines()` return now?
> 
> David Rosca wrote:
> It returned the value I have set in mouse kcm, because the test 
> KdePlatformTheme is not installed to qApp (and WheelScrollLines is now set as 
> themeHint instead of directly calling qApp->setWheelScrollLines)
> 
> Aleix Pol Gonzalez wrote:
> So the behavior on all applications that used qApp->wheelScrollLines() 
> changed now?
> 
> David Rosca wrote:
> No, it just can't be set with QApplication::setWheelScrollLines (from 
> KdePlatformTheme constructor) because QApplication is querying QPlatformTheme 
> for the value. 
> 
> That is with Qt 5.5, older version didn't have the WheelScrollLines hint.
> 
> Marco Martin wrote:
> if QApplication is querying QPlatformTheme for wheelScrollLines(), why do 
> you have to use themeHint directly?
> 
> David Rosca wrote:
> Because that's what this autotest is doing (see how the other themeHints 
> are tested above). It just tests if the KdePlatformTheme correctly gets the 
> value from config.

So why not test both, i.e. turn #else into #endif?


- David


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


On Oct. 29, 2015, 8:22 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125877/
> ---
> 
> (Updated Oct. 29, 2015, 8:22 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> see summary
> 
> 
> Diffs
> -
> 
>   autotests/kdeplatformtheme_unittest.cpp f660ffd 
> 
> Diff: https://git.reviewboard.kde.org/r/125877/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Rosca
> 
>

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

Re: KPixmapCache in kdelibs4support uses QDateTime in mmap'ed struct

[David Faure]

On Tuesday 03 November 2015 11:06:00 Alex Merry wrote:
> On 2015-11-03 00:56, Michael Pyne wrote:
> > On Tue, November 3, 2015 00:40:58 Albert Astals Cid wrote:
> >> Someone went a bit too far in the "port away from time_t to QDateTime" 
> >> and
> >> changed the timestamp member of the KPixmapCacheIndexHeader struct.
> >> 
> >> According to mpyne and thiago this is a big no-no.
> > 
> > The reason it's a big no-no is because KPixmapCacheIndexHeader is meant 
> > to be
> > held and used from mmap()'d shared memory, which generally requires the 
> > use of
> > plain old data (POD) types only, to avoid inadvertent constructor or
> > destructor calls once the memory is freed.
> > 
> > QDateTime will (and is) leak applications to crash so I'd +1 the
> > recommendation to change back to time_t (or at least some kind of 
> > integral
> > type), and the type is internal-only so there's no API concern. Just 
> > don't
> > forget to bump the defined KPIXMAPCACHE_VERSION so that old caches are 
> > flushed
> > ;).
> 
> Also, in practice, I believe time_t is everywhere we care about - we 
> just have to take a little care about what API calls we use.

Right. On the other hand, it will break in 2039 on 32 bit machines,
so nowadays I use "qint64 msecs" and QDateTime::fromMsecsSinceEpoch
instead.

But anyway, we can hope kdelibs4support won't exist anymore in 2039 ;)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

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

Review Request 125961: [declarative/core] Use BypassWindowManagerHint only on platform X11

[Martin Gräßlin]

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

Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

BypassWindowManagerHint is a flag which is X11 specific. Because of
that for example QtWayland doesn't create a real window for QWindows
with this flag.

Using such a window will eventually result in a freeze of the whole
application. If one renders with QtQuick to such a window, mesa will
request a frame callback from the compositor. Just the compositor
will never deliver the frame rendered callback as it doesn't know the
window exists in the first place and by that doesn't render it and
will never ever deliver the frame rendered callback.

If now one tries to render another frame, mesa notices that it hasn't
got the frame callback and will block the thread till that happens.
With the setup described: that's until eternity.

Change-Id: I352ff788f90799ce0e0a5de53d5d34c02c8468c3


Diffs
-

  src/declarativeimports/core/CMakeLists.txt 
4e0fe8bf95d51c282060a0a05914c976cd4e5783 
  src/declarativeimports/core/config-x11.h.cmake PRE-CREATION 
  src/declarativeimports/core/tooltipdialog.cpp 
121ccf91bb17c5dd17e0742831830186e9e44a1e 

Diff: https://git.reviewboard.kde.org/r/125961/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

Install UdevQt headers in Solid

[David Rosca]

Hi,

I was working on udev device notifier in kcm_keyboard [1] and ended up
with using libudev directly.

We are using libudev in various places, either directly or through
Solid's UdevQt. But in the case of UdevQt, all projects using it have
its own copy [2]. I think it would be better if Solid installs the
udevqt headers instead.

The headers are:

src/solid/devices/backends/shared/udevqt.h
src/solid/devices/backends/shared/udevqtclient.h
src/solid/devices/backends/shared/udevqtdevice.h

Would it be a problem that the headers only gets installed on Linux?
That means the project using it would need to use it only in
Linux-specific code.

Thanks,
David

[1] https://git.reviewboard.kde.org/r/125465/
[2] http://lxr.kde.org/ident?_i=udev
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

AW: Install UdevQt headers in Solid

[Kai Uwe Broulik]

+1

but I guess we should review and cleanup that stuff whilst at it, however I 
don't really have time to make this stuff Frameworks ready

Gesendet von meinem BlackBerry 10-Smartphone.
  Originalnachricht  
Von: David Rosca
Gesendet: Donnerstag, 5. November 2015 14:27
An: kde-frameworks-devel@kde.org; kde-hardware-de...@kde.org
Antwort an: kde-frameworks-devel@kde.org
Betreff: Install UdevQt headers in Solid

Hi,

I was working on udev device notifier in kcm_keyboard [1] and ended up
with using libudev directly.

We are using libudev in various places, either directly or through
Solid's UdevQt. But in the case of UdevQt, all projects using it have
its own copy [2]. I think it would be better if Solid installs the
udevqt headers instead.

The headers are:

src/solid/devices/backends/shared/udevqt.h
src/solid/devices/backends/shared/udevqtclient.h
src/solid/devices/backends/shared/udevqtdevice.h

Would it be a problem that the headers only gets installed on Linux?
That means the project using it would need to use it only in
Linux-specific code.

Thanks,
David

[1] https://git.reviewboard.kde.org/r/125465/
[2] http://lxr.kde.org/ident?_i=udev
___
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