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

[David Faure]

On Friday 06 November 2015 08:47:34 Luiz Romário Santana Rios wrote:
> 2015-11-06 4:48 GMT-03:00 David Faure :
> > On Monday 02 November 2015 14:53:40 Luiz Romário Santana Rios wrote:
> >>
> >> 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
> >
> > I don't think this can work at all.
> > (and yes I've seen your review request, but while it fixes the file:/// 
> > case, are you sure
> > it fixes the network case as well?)
> 
> Since I wait for the QNAM::finished() signal before doing anything
> with the QNetworkReply, it probably does, but maybe not for, say, a
> QTcpSocket. That case would need the waitFor*() calls, indeed.

Ah, I see.

> > So the reason it breaks (apart from the issue of seeking) is that when KTar
> > (or KCompressionDevice) wants to read more data, it might not be available,
> > and the read fails. You could add waitFor* calls, but that would make the 
> > whole
> > thing blocking - very bad for the main thread of a GUI program.
> 
> It already blocks, even in the KTar archive("file.tar.gz") case.

Blocking while uncompressing is OK (fast CPU operation),
blocking while waiting for network packets is not (could take 30 minutes).
But now I see, you do an async download first, so no issue there.
 
> Then we could use a temp file in the KZip implementation and this
> approach for KTar?

I wouldn't want this for the case of random access devices, like
files on disk (it would be pointless to copy from a local file to a tempfile).
But yes I'm not opposed to code that would use a temp file for
cases of non-sequential devices being used as input.

Aleix suggested QBuffer, but archives can be *huge*, so this might
eat all available memory. This is the reason why KTar uses a temp file
for the compressed-tar case.

-- 
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

Re: 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/
---

(Updated Nov. 7, 2015, 10:07 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, David Faure and Laurent Montel.


Changes
---

Submitted with commit 5e00ad1f31a6cb436f3d17896de82e1691acfefa by Nick 
Shaforostoff to branch master.


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 
  src/karchive.cpp 0ece37c 

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: Build and test failures with Qt 5.6 and Qt 5.3

[Ivan Čukić]

>> - [5.3] kactivities: won't build due to QQuickWidget::setClearColor which
>> is 5.4+ only.
>
> Ivan, can this be worked around?

I'll have to check. (if nothing else, I'll disable that part - it is
for the settings module, not really a part of the framework)

For how long are we going to support 5.3?

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

Re: Review Request 125790: Recognize image/vnd.adobe.photoshop

[Kai Uwe Broulik]

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

(Updated Nov. 7, 2015, 12:19 nachm.)


Review request for KDE Frameworks.


Changes
---

Use only vnd.adobe.photoshop as suggested


Repository: kimageformats


Description
---

This is the mimetype I get for .psd files


Diffs (updated)
-

  src/imageformats/psd.desktop 494b746 
  src/imageformats/psd.json 859eede 

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


Testing
---

I still don't get any thumbnails for PSD files, though.


Thanks,

Kai Uwe Broulik

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

Re: Policy on order of include guards and license texts

[David Faure]

On Saturday 07 November 2015 00:23:31 Martin Walch wrote:
> Hi,
> 
> should include guards be put above or below the license text (for
> KDE in general)?

I have always always seen them below.
In Qt, in kdelibs, in KF5, in KDE apps code.

Someone might unearth an exception, of course, but I'm pretty sure
we always put the license text first.

> Should the answer also go into 
> https://techbase.kde.org/Policies/Kdelibs_Coding_Style
> ?

Feel free :)

-- 
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

Re: Updating techbase wiki page according to KF5 policies

[David Faure]

On Friday 06 November 2015 23:42:21 Martin Walch wrote:
> Hi,
> 
> the techbase wiki says
> 
> > If you add #includes for Qt classes, use both the module and class name.
> > This allows library code to be used by applications without excessive
> > compiler include paths.

Urgh, that's indeed outdated, it's the Qt4/kdelibs4 recommendation.

> * Is  really preferred over  since KF5?

Yes.

> * What is the reason for this?

So that code keeps compiling no matter where QClass is moved.
See  (Qt4) vs  (Qt5).
It's also faster (just copy/paste the classname).

The old idea of "keeping the buildsystem simple" has been deemed
no longer relevant. Nobody writes Makefiles by hand anymore.
qmake and cmake make it easy to have the right include paths.

> * Is that wiki page meant to apply to KF5?
> * If it shall apply to KF5 is it safe to update it accordingly?

Don't know. Technically the naming is wrong, there's no "kdelibs"
in KF5. Maybe you could make a new wiki page instead?

> * Should the coding style for kdelibs from KDE4 be kept around?

Can't hurt to keep it, there might references to it, and some people
still write Qt4/kdelibs4 based code (e.g. I do, in my company).

-- 
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

Jenkins-kde-ci: frameworkintegration master kf5-qt5 » Linux,gcc - Build # 33 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/frameworkintegration%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/33/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sat, 07 Nov 2015 12:30:59 +
Build duration: 1 min 59 sec

CHANGE SET
Revision 8691afcd8811b5e977495944db2d9e9b5e024f1e by nowrep: (Fix 
kdeplatformtheme_unittest after last commit)
  change: edit src/platformtheme/khintssettings.cpp
  change: edit autotests/kdeplatformtheme_unittest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 3/3 (100%)FILES 20/20 (100%)CLASSES 20/20 (100%)LINE 1178/1754 
(67%)CONDITIONAL 455/837 (54%)

By packages
  
autotests
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 427/435 (98%)CONDITIONAL 
220/407 (54%)
src.kstyle
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 45/178 (25%)CONDITIONAL 
28/103 (27%)
src.platformtheme
FILES 12/12 (100%)CLASSES 12/12 (100%)LINE 706/1141 
(62%)CONDITIONAL 207/327 (63%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: frameworkintegration master kf5-qt5 » Linux,gcc - Build # 33 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/frameworkintegration%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/33/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sat, 07 Nov 2015 12:30:59 +
Build duration: 1 min 59 sec

CHANGE SET
Revision 8691afcd8811b5e977495944db2d9e9b5e024f1e by nowrep: (Fix 
kdeplatformtheme_unittest after last commit)
  change: edit src/platformtheme/khintssettings.cpp
  change: edit autotests/kdeplatformtheme_unittest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 3/3 (100%)FILES 20/20 (100%)CLASSES 20/20 (100%)LINE 1178/1754 
(67%)CONDITIONAL 455/837 (54%)

By packages
  
autotests
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 427/435 (98%)CONDITIONAL 
220/407 (54%)
src.kstyle
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 45/178 (25%)CONDITIONAL 
28/103 (27%)
src.platformtheme
FILES 12/12 (100%)CLASSES 12/12 (100%)LINE 706/1141 
(62%)CONDITIONAL 207/327 (63%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Updating techbase wiki page according to KF5 policies

[Luigi Toscano]

David Faure ha scritto:
> On Friday 06 November 2015 23:42:21 Martin Walch wrote:
> 
>> * Is that wiki page meant to apply to KF5?
>> * If it shall apply to KF5 is it safe to update it accordingly?
> 
> Don't know. Technically the naming is wrong, there's no "kdelibs"
> in KF5. Maybe you could make a new wiki page instead?
> 
>> * Should the coding style for kdelibs from KDE4 be kept around?
> 
> Can't hurt to keep it, there might references to it, and some people
> still write Qt4/kdelibs4 based code (e.g. I do, in my company).

And also for people that wants to port program, in the foreseeable future. I
agree that a new page (Frameworks_Coding_Style?) should be created instead.

Ciao
-- 
Luigi

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

Re: Review Request 125976: add an update() method

[Sebastian Kügler]

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


In general, I like the idea. We have to be a bit careful to keep the code 
maintainable though.

Please also remove the extraneous debug output.


src/kpackage/package.h (line 329)


Capital If



src/kpackage/package.cpp (line 786)


QLatin1Char('/') ?



src/kpackage/packagestructure.h (line 80)


and an older version (what?)...?



src/kpackage/packagestructure.h (line 81)


If



src/kpackage/private/packagejobthread.cpp (line 321)


spaces around <<; why a qWarning without any explanation?



src/kpackage/private/packagejobthread.cpp (line 326)


Would probably be good to give the installed path here as well. Also, 
"Impossible *to* remove"...



src/kpackage/private/packagejobthread_p.h (line 58)


As you note yourself, perhaps just make it an enum? It's not private API, 
OK, but the code here is getting really convoluted that I think another boolean 
trap won't help...



src/kpackage/private/versionparser.cpp (line 25)


I think we can remove most of these includes?


- Sebastian Kügler


On Nov. 6, 2015, 5:57 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125976/
> ---
> 
> (Updated Nov. 6, 2015, 5:57 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Kai Uwe Broulik.
> 
> 
> Repository: kpackage
> 
> 
> Description
> ---
> 
> new job based update() function that compared to install()
> if a package with the same pluginId is already installed,
> removes the old one before installing the new one, if
> and only if the version of the new one is more recent
> 
> 
> Diffs
> -
> 
>   autotests/plasmoidpackagetest.h f730dce 
>   autotests/plasmoidpackagetest.cpp 567 
>   src/kpackage/CMakeLists.txt 3696f37 
>   src/kpackage/package.h 4ada8da 
>   src/kpackage/package.cpp 539b21a 
>   src/kpackage/packagestructure.h 9427b42 
>   src/kpackage/packagestructure.cpp 0070514 
>   src/kpackage/private/packagejob.cpp 0d2241b 
>   src/kpackage/private/packagejob_p.h 267429f 
>   src/kpackage/private/packagejobthread.cpp ca523b3 
>   src/kpackage/private/packagejobthread_p.h bf8a266 
>   src/kpackage/private/versionparser.cpp PRE-CREATION 
>   src/kpackagetool/CMakeLists.txt 78e0fb0 
> 
> Diff: https://git.reviewboard.kde.org/r/125976/diff/
> 
> 
> Testing
> ---
> 
> covered by autotests
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 125877: Fix kdeplatformtheme_unittest after last commit

[David Faure]

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

Ship it!


Thanks !!

- David Faure


On Nov. 7, 2015, 12:10 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125877/
> ---
> 
> (Updated Nov. 7, 2015, 12:10 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> Use Q_CONSTRUCTOR_FUNCTION for prepareEnvironment, so the QApplication's 
> platform theme is using the test paths.
> 
> This also fixes updating the WheelScrollLines when the settings change, 
> because QApplication is only using theme hint on startup. If the value 
> changes, we need to call QApplication::setWheelScrollLines instead of just 
> updating the theme hint.
> 
> 
> Diffs
> -
> 
>   autotests/kdeplatformtheme_unittest.cpp f660ffd 
>   src/platformtheme/khintssettings.cpp 14e1d43 
> 
> Diff: https://git.reviewboard.kde.org/r/125877/diff/
> 
> 
> Testing
> ---
> 
> Tests pass
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
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 Rosca]

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

(Updated Nov. 7, 2015, 12:10 p.m.)


Review request for KDE Frameworks.


Repository: frameworkintegration


Description (updated)
---

Use Q_CONSTRUCTOR_FUNCTION for prepareEnvironment, so the QApplication's 
platform theme is using the test paths.

This also fixes updating the WheelScrollLines when the settings change, because 
QApplication is only using theme hint on startup. If the value changes, we need 
to call QApplication::setWheelScrollLines instead of just updating the theme 
hint.


Diffs (updated)
-

  autotests/kdeplatformtheme_unittest.cpp f660ffd 
  src/platformtheme/khintssettings.cpp 14e1d43 

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


Testing (updated)
---

Tests pass


Thanks,

David Rosca

___
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 # 132 - 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/132/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Sat, 07 Nov 2015 12:17:29 +
Build duration: 6 min 44 sec

CHANGE SET
Revision af32d8b42fd9e24682aebf5ad26aa376821f84b0 by kde: 
([containmentinterface] Workaround self-destructing menu)
  change: edit src/scriptengines/qml/plasmoid/containmentinterface.cpp
Revision 606c7f651d668349da79313806d5ecefbc6ed221 by kde: ([TabBarLayout] 
Layout sooner)
  change: edit 
src/declarativeimports/plasmacomponents/qml/private/TabBarLayout.qml


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 3917/10053 
(39%)CONDITIONAL 1917/3034 (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/2010 
(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 945/1746 
(54%)CONDITIONAL 395/600 (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

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.
> 
> David Faure wrote:
> So why not test both, i.e. turn #else into #endif?
> 
> David Rosca wrote:
> Because the platform theme used by QTest QApplication is created before 
> prepareEnvironment() is called, thus it uses the user's kdeglobals and not 
> the one used by tests.
> 
> If we fix it, eg with:
> 
> ```
> int main(int argc, char *argv[])
> {
> prepareEnvironment();
> qputenv("QT_QPA_PLATFORMTHEME", QByteArrayLiteral("kde"));
> QApplication app(argc, argv);
> KdePlatformTheme_UnitTest t;
> return QTest::qExec(, argc, argv);
> }
> ```
> 
> instead of using Q_COREAPP_STARTUP_FUNCTION, then we can test the 
> QApplication directly (not only wheelScrollLines, but every other hints).
> 
> I can rewrite the test according to this, if it's fine.

You can use Q_CONSTRUCTOR_FUNCTION to run some code before main is called.
We have a few unittests that do this already, like 
kxmlgui/autotests/ktoolbar_unittest.cpp


- 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

Policy on order of include guards and license texts

[Martin Walch]

Hi,

should include guards be put above or below the license text (for
KDE in general)?

Should the answer also go into 
https://techbase.kde.org/Policies/Kdelibs_Coding_Style
?

Best regards,
Martin Walch
-- 

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

Updating techbase wiki page according to KF5 policies

[Martin Walch]

Hi,

the techbase wiki says

> If you add #includes for Qt classes, use both the module and class name.
> This allows library code to be used by applications without excessive
> compiler include paths.

Taken from:
https://techbase.kde.org/Policies/Kdelibs_Coding_Style

As far as I have understood so far, this is outdated for KF5 and should now
be made exactly the other way round. So, I have some questions:

* Is  really preferred over  since KF5?
* What is the reason for this?
* Is that wiki page meant to apply to KF5?
* If it shall apply to KF5 is it safe to update it accordingly?
* Should the coding style for kdelibs from KDE4 be kept around?

Best regards,
Martin Walch
-- 

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

Re: Fwd: KF5 plugins and PLUGIN_INSTALL_DIR vs QT_PLUGIN_INSTALL_DIR

[David Faure]

On Friday 06 November 2015 11:26:44 René J.V. Bertin wrote:
> 
> What is going wrong here, and why? 

What's going wrong is that your KF5 install prefix isn't known to Qt, evidently.
We solve this on Linux by
- setting the environment variable QT_PLUGIN_PATH, in the developer case
  (KF5 install prefix != Qt)
- using the same dir under /usr in distro packages.

> Should I be setting -DPLUGIN_INSTALL_DIR=${QT_PLUGIN_INSTALL_DIR}?

Yes, if you're making something more like a distro install than a developer 
install.

In a developer install, everything must be under the install prefix. This 
allows to
have multiple versions side by side, and it also avoids KF5 trying to install 
as a non-root user into a Qt directory owned by root.

In a distro install you can tune install dirs indeed.

-- 
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

Re: Review Request 125974: Make KTar KCompressionDevice-friendly

[David Faure]

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


BTW why create a KTar on top of a KCompressionDevice? KTar is able to handle 
compression automatically all by itself... and that's exactly the case where it 
will use a tempfile for the uncompressed data, making seeking work. This patch 
is unnecessary if you use KTar the intended way: if the filename doesn't end 
with .gz or .bz2, specify the mimetype explicitly in the KTar constructor.

- David Faure


On Nov. 6, 2015, 2:52 a.m., Romário Rios wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125974/
> ---
> 
> (Updated Nov. 6, 2015, 2:52 a.m.)
> 
> 
> 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

Jenkins-kde-ci: kio master kf5-qt5 » Linux,gcc - Build # 161 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/161/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sat, 07 Nov 2015 09:31:41 +
Build duration: 5 min 7 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 46 test(s), Skipped: 0 test(s), Total: 
47 test(s)Failed: TestSuite.kiocore-threadtest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 20/20 (100%)FILES 253/331 (76%)CLASSES 253/331 (76%)LINE 24771/50007 
(50%)CONDITIONAL 13378/20681 (65%)

By packages
  
autotests
FILES 61/61 (100%)CLASSES 61/61 (100%)LINE 7018/7236 
(97%)CONDITIONAL 3830/7041 (54%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 
(100%)CONDITIONAL 166/272 (61%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 
60/90 (67%)
src.core
FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7395/14021 
(53%)CONDITIONAL 3868/5381 (72%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2283/7589 
(30%)CONDITIONAL 911/1407 (65%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 432/843 (51%)CONDITIONAL 
314/459 (68%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3800 
(20%)CONDITIONAL 547/678 (81%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 
602/758 (79%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 684/1182 (58%)CONDITIONAL 
358/495 (72%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 
433/820 (53%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 302/388 (78%)CONDITIONAL 
86/108 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 384/600 (64%)CONDITIONAL 
280/408 (69%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 280/285 (98%)CONDITIONAL 
144/254 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 32/35 (91%)CONDITIONAL 
42/52 (81%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 248/743 (33%)CONDITIONAL 
147/194 (76%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 20/27 (74%)CONDITIONAL 
14/18 (78%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 226/256 (88%)CONDITIONAL 
292/358 (82%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2679/10636 
(25%)CONDITIONAL 1276/1872 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [CRITICAL] KIO Test "threadtest" can enter into infinite loop

[David Faure]

On Saturday 07 November 2015 11:17:31 Ben Cooksley wrote:
> Hi all,
> 
> It appears the test running with the binary name of "threadtest" in
> kio has a grave bug which can lead to it entering into an infinite
> loop.
> 
> This was consuming virtually the entire resources of one builder with
> old hung processes, and the whole core of another builder -
> drastically limiting the capabilities of the CI system (even though
> KIO was not being built at the time).
> 
> Can someone please investigate? Manual intervention (with kill -9) is
> needed to remove these hung processes.

It of course works fine on my own machine.

And I just tried running it on LinuxNode2, in 
~/builds/kio/stable-kf5-qt5/build/autotests
(after sourcing ~/kio.env which I just generated), and it ran fine (multiple 
times).

Any suggestion on how / where to hit the issue?

-- 
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

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

[Nick Shaforostoff]

 > Aleix suggested QBuffer, but archives can be *huge*, so this might
> eat all available memory. This is the reason why KTar uses a temp file
> for the compressed-tar case.

qbuffer may be used for decompressing archives that are e.g. less than 50% of 
free ram
if an archive is larger then tmpfile-based branch would be executed.
 
 
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125788: [kio thumbnailer] Recognize image/webp

[David Faure]

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


In fact image/webp is the only mimetype that is defined in (shared mime info + 
kcoreaddons). image/x-webp doesn't exist and should be removed (or if it's 
actually used by webservers, then an alias should be added in shared-mime-info).

- David Faure


On Oct. 25, 2015, 12:02 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125788/
> ---
> 
> (Updated Oct. 25, 2015, 12:02 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> When I download a .webp file the system claims it to be image/webp, not 
> image/x-webp which we already support.
> 
> 
> Diffs
> -
> 
>   thumbnail/imagethumbnail.desktop e64341b 
> 
> Diff: https://git.reviewboard.kde.org/r/125788/diff/
> 
> 
> Testing
> ---
> 
> I now get thumbnails for .webp files
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

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

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/160/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sat, 07 Nov 2015 09:18:54 +
Build duration: 1 min 5 sec

CHANGE SET
Revision 11ec27748cf6562daaf1ee6f15fe4b332affdb65 by David Faure: (Fix race 
detected by helgrind, s_storage must be file-static so it gets)
  change: edit src/core/scheduler.cpp
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125974: Make KTar KCompressionDevice-friendly

[David Faure]

> On Nov. 6, 2015, 7:52 a.m., David Faure wrote:
> > src/karchive.cpp, line 652
> > 
> >
> > This is not equivalent to seek(d->pos).
> > seek(d->pos) goes to the absolute position d->pos, counting from the 
> > beginning of the device.
> > 
> > read(d->pos) goes to the absolute position (current position + d->pos).
> > 
> > If this is seeking forward, you could emulate it with a dummy read, but 
> > what if this is seeking backward? That's not possible on a sequential 
> > device, so my advice is, forget using a sequential device here, download to 
> > a temp file.
> 
> Romário Rios wrote:
> Actually, this is irrelevant to the issue. I reverted this code back to 
> the original and the fix still works.
> 
> You're right about the situation in this case, but, inside 
> KTar::openArchive, it works because it originally only seeks the device 
> forward.

Maybe but if you call KArchiveFile::data() on the last file in the archive, and 
then on the first file in the archive, seeking back is obviously needed.


- David


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


On Nov. 6, 2015, 2:52 a.m., Romário Rios wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125974/
> ---
> 
> (Updated Nov. 6, 2015, 2:52 a.m.)
> 
> 
> 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: [CRITICAL] KIO Test "threadtest" can enter into infinite loop

[Ben Cooksley]

On Sat, Nov 7, 2015 at 11:23 PM, David Faure  wrote:
> On Saturday 07 November 2015 10:36:18 David Faure wrote:
>> On Saturday 07 November 2015 11:17:31 Ben Cooksley wrote:
>> > Hi all,
>> >
>> > It appears the test running with the binary name of "threadtest" in
>> > kio has a grave bug which can lead to it entering into an infinite
>> > loop.
>> >
>> > This was consuming virtually the entire resources of one builder with
>> > old hung processes, and the whole core of another builder -
>> > drastically limiting the capabilities of the CI system (even though
>> > KIO was not being built at the time).
>> >
>> > Can someone please investigate? Manual intervention (with kill -9) is
>> > needed to remove these hung processes.
>>
>> It of course works fine on my own machine.
>>
>> And I just tried running it on LinuxNode2, in 
>> ~/builds/kio/stable-kf5-qt5/build/autotests
>> (after sourcing ~/kio.env which I just generated), and it ran fine (multiple 
>> times).
>>
>> Any suggestion on how / where to hit the issue?
>
> OK, it happens in kf5-qt5 rather than in stable-kf5-qt5
>
> One of the KIO-using threads seems stuck in QProcess smells like a Qt bug?
> Or is there a reason why starting a new process or creating a new pipe would
> sometimes fail (some ulimit?)

It working in stable-kf5-qt5 but failing in kf5-qt5 would support the
theory of a Qt bug - the only difference is the version of Qt...

>
> Context: this test starts 20 threads at once, each of which starts a QProcess
> (using startDetached) (for the kioslave binary). It works most of the time, 
> but sometimes
> hangs with the bt below.
>
> (gdb) bt
> #0  0x74bdd49d in read () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x76f27637 in read () from /usr/lib/x86_64-linux-gnu/libasan.so.1
> #2  0x7565a2ed in qt_safe_read (fd=43, data=0x7fffddf14cc0, maxlen=1) 
> at 
> ../../include/QtCore/5.5.1/QtCore/private/../../../../../src/corelib/kernel/qcore_unix_p.h:265
> #3  0x7565e2b4 in QProcessPrivate::startDetached (program=..., 
> arguments=..., workingDirectory=..., pid=0x0) at io/qprocess_unix.cpp:1246
> #4  0x7560142d in QProcess::startDetached (program=..., 
> arguments=...) at io/qprocess.cpp:2461
> #5  0x7652f1f5 in KIO::Slave::createSlave (protocol=..., url=..., 
> error=@0x7fffddf15260: 214848, error_text=...) at 
> /home/jenkins/builds/kio/kf5-qt5/src/core/slave.cpp:499
> #6  0x7658ec6d in KIO::ProtoQueue::createSlave (this=0x611db8c0, 
> protocol=..., job=0x6032e330, url=...) at 
> /home/jenkins/builds/kio/kf5-qt5/src/core/scheduler.cpp:529
> #7  0x7658fc60 in KIO::ProtoQueue::startAJob (this=0x611db8c0) at 
> /home/jenkins/builds/kio/kf5-qt5/src/core/scheduler.cpp:616
> #8  0x76599711 in KIO::ProtoQueue::qt_static_metacall 
> (_o=0x611db8c0, _c=QMetaObject::InvokeMetaMethod, _id=0, 
> _a=0x7fffddf154b0)
> at /home/jenkins/builds/kio/kf5-qt5/build/src/core/moc_scheduler_p.cpp:250
> #9  0x7571273e in QMetaObject::activate (sender=0x611db918, 
> signalOffset=3, local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3713
> #10 0x75711f2a in QMetaObject::activate (sender=0x611db918, 
> m=0x75a45420 , local_signal_index=0, argv=0x0) 
> at kernel/qobject.cpp:3578
> #11 0x757b6b49 in QTimer::timeout (this=0x611db918) at 
> .moc/moc_qtimer.cpp:197
> #12 0x7571e420 in QTimer::timerEvent (this=0x611db918, 
> e=0x7fffddf158c0) at kernel/qtimer.cpp:247
> #13 0x7570b77b in QObject::event (this=0x611db918, 
> e=0x7fffddf158c0) at kernel/qobject.cpp:1220
> #14 0x756d0782 in QCoreApplicationPrivate::notify_helper 
> (this=0x60f0ef50, receiver=0x611db918, event=0x7fffddf158c0) at 
> kernel/qcoreapplication.cpp:1093
> #15 0x756d0409 in QCoreApplication::notify (this=0x7fff7570, 
> receiver=0x611db918, event=0x7fffddf158c0) at 
> kernel/qcoreapplication.cpp:1038
> #16 0x756d02f1 in QCoreApplication::notifyInternal 
> (this=0x7fff7570, receiver=0x611db918, event=0x7fffddf158c0) at 
> kernel/qcoreapplication.cpp:965
> #17 0x756d42a5 in QCoreApplication::sendEvent 
> (receiver=0x611db918, event=0x7fffddf158c0) at 
> ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:224
> #18 0x7574cac1 in QTimerInfoList::activateTimers 
> (this=0x60f8e6c0) at kernel/qtimerinfo_unix.cpp:637
> #19 0x7574dfc0 in timerSourceDispatch (source=0x60f8e660) at 
> kernel/qeventdispatcher_glib.cpp:177
>
> Config: Using QtTest library 5.5.1, Qt 5.5.1 (x86_64-little_endian-lp64 
> shared (dynamic) debug build; by GCC 4.9.2)
>
> After many tries I got it to hang under strace -f as well.
> Here's the log: http://www.davidfaure.fr/2015/strace.output.bz2
> pipe2() succeeds 40 times, so that's not the problem...
>
> Process 7389 (which works) does set_robust_list, close(43), execve(kioslave).
> Process 7391 (which hangs) does 

Re: Build and test failures with Qt 5.6 and Qt 5.3

[David Faure]

On Friday 06 November 2015 17:21:33 Jan Kundrát wrote:
> Hi folks,
> please take a look at the CI status matrix at [1]. TL;DR: There are build 
> failures with Qt 5.3, plenty of test failures, and some test failures 
> specific to the still unreleased Qt 5.6.
> 
> Oh, and a cmake 3.4-git regression that I'm not going to bother you with. 
> Reported, known, downgraded for now.
> 
> This testing is more or less a side effect of kio's and plasma-workspace 
> presence in Gerrit. If you like this CI coverage, if you appreciate the 
> range of covered compilers and Qt5 versions, or if you would like it to 
> extend the coverage to all of KF5 and/or plasma or some other apps, please 
> let me know.

Having this for all of KF5 would definitely be useful.

Clearly it spots additional issues compared to jenkins, the more CIs we have
the better for quality ;)

However I admit that I keep forgetting to take a look at 
http://ci-logs.kde.flaska.net/matrix.html
in addition to jenkins, so your email is very useful.

> A quick summary (please click the "console" link in the matrix overview to 
> see full log):
> 
> - [5.3] kactivities: won't build due to QQuickWidget::setClearColor which 
> is 5.4+ only.

Ivan, can this be worked around?

> - [5.3] kcoreaddons: QDebug::noquote

Fixed.

> - [5.3] kwidgetsaddons: QTimer::singleShot and the new slot syntax

Fixed.

> - [5.3] plasma-workspace: QString::splitRef

You mean plasma-framework.
Nick, can you ifdef this depending on the Qt version?

> - [5.6] karchive: wrong number of items in the archive

I just committed more debug output in case of failure, to find out more.
The result is staggering, null bytes everywhere.

> - [5.6] kconfig: error which I don't understand

Possibly also related to null bytes, let's dig more after fixing karchive.

> - [5.6] kcoreaddons: different number formatting

This test sets a C locale. Could it be that on your system, the C locale
doesn't include having the comma as thousands-separator?
Or maybe the system's locale still interfers, i.e. KFormat format(QLocale::c());
isn't enough to -really- use the C locale?

> - kio, in all versions: test failures in KNewFileMenuTest::test(text file 
> with jpeg extension)

Also a mimetype problem. kcoreaddons' kde5.xml adds "*.doc" as a pattern
for text/plain, but surely it doesn't mean for it to become the main extension.
Can you the value of 
QMimeDatabase().mimeTypeForName("text/plain").preferredSuffix()
on your system? Here's it's "txt", I suspect it's "doc" on your system. Not 
sure why yet
though, but let's first check that.

> - kservice, in all versions: test failure

It appears that your system doesn't know that opendocument inherits 
application/zip.
Do you have this line in /usr/share/mime/subclasses ?
application/vnd.oasis.opendocument.text application/zip

> - [5.6] kwindowsystem: KWindowInfoX11Test fails tests

Martin, can you take a look at
http://ci-logs.kde.flaska.net/0c/0c4039dc8d4c3fa9eed18a4f5604a90648fe3e84/rebuilddep/rebuilddep-kf5-qt56-gcc-el7/d8b3c13/shell_output.log
?

> - plasma-framework, all versions: wrong dialog dimensions/offsets

Same as what we can currently see in Jenkins, so that one is more expected
than all of the others...

> [1] http://ci-logs.kde.flaska.net/matrix.html 

-- 
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

Re: icon frameworks

[David Faure]

On Friday 06 November 2015 11:27:36 Harald Sitter wrote:
> Quick update with
> 
> On Thu, Nov 5, 2015 at 10:07 AM, Harald Sitter  wrote:
> > - breeze-icons is a new repo going to be split from breeze and moving
> > to frameworks (tier1)
> 
> This is now in frameworks and open to push to.
> 
> > - 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.
> 
> Ticket ZUG-6194 requests a move *and* rename (as requested by
> Riddell). Final destination being frameworks and name oxygen-icons5.
> The name change is to make sure the oxygen-icons in frameworks are
> distinctly set apart from the version released in applications up to
> 15.04, since frameworks has a lower version number and to aid
> distributions in dealing with this.
> 
> > Until we are confident everything is lovely these should be marked release: 
> > false.
> 
> This is done for both repos. Both repositories should comply with
> frameworks documentation/metadata requirements.
> David, please have a look and if it seems alright feel free to toggle
> the release value.

Did you check the list from
https://community.kde.org/Frameworks/CreationGuidelines
?

At first sight I see already one thing missing: no CI job under
https://build.kde.org/view/Frameworks%20kf5-qt5/

-- 
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

Re: Review Request 125974: Make KTar KCompressionDevice-friendly

[David Faure]

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



src/ktar.cpp (line 480)


Variable-size C-arrays are non-standard in C++ (at least before C++11, 
dunno about C++11). You have to use malloc or new or QVarLengthArray.


- David Faure


On Nov. 6, 2015, 2:52 a.m., Romário Rios wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125974/
> ---
> 
> (Updated Nov. 6, 2015, 2:52 a.m.)
> 
> 
> 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: Re[2]: Failure while executing KTar::open while using KCompressionDevice as the device

[David Faure]

On Saturday 07 November 2015 12:18:56 Nick Shaforostoff wrote:
>  > Aleix suggested QBuffer, but archives can be *huge*, so this might
> > eat all available memory. This is the reason why KTar uses a temp file
> > for the compressed-tar case.
> 
> qbuffer may be used for decompressing archives that are e.g. less than 50% of 
> free ram
> if an archive is larger then tmpfile-based branch would be executed.

How many code paths do we want to maintain? ;)

-- 
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

Re: [CRITICAL] KIO Test "threadtest" can enter into infinite loop

[David Faure]

On Saturday 07 November 2015 10:36:18 David Faure wrote:
> On Saturday 07 November 2015 11:17:31 Ben Cooksley wrote:
> > Hi all,
> > 
> > It appears the test running with the binary name of "threadtest" in
> > kio has a grave bug which can lead to it entering into an infinite
> > loop.
> > 
> > This was consuming virtually the entire resources of one builder with
> > old hung processes, and the whole core of another builder -
> > drastically limiting the capabilities of the CI system (even though
> > KIO was not being built at the time).
> > 
> > Can someone please investigate? Manual intervention (with kill -9) is
> > needed to remove these hung processes.
> 
> It of course works fine on my own machine.
> 
> And I just tried running it on LinuxNode2, in 
> ~/builds/kio/stable-kf5-qt5/build/autotests
> (after sourcing ~/kio.env which I just generated), and it ran fine (multiple 
> times).
> 
> Any suggestion on how / where to hit the issue?

OK, it happens in kf5-qt5 rather than in stable-kf5-qt5

One of the KIO-using threads seems stuck in QProcess smells like a Qt bug?
Or is there a reason why starting a new process or creating a new pipe would
sometimes fail (some ulimit?)

Context: this test starts 20 threads at once, each of which starts a QProcess 
(using startDetached) (for the kioslave binary). It works most of the time, but 
sometimes
hangs with the bt below.

(gdb) bt   
#0  0x74bdd49d in read () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x76f27637 in read () from /usr/lib/x86_64-linux-gnu/libasan.so.1
#2  0x7565a2ed in qt_safe_read (fd=43, data=0x7fffddf14cc0, maxlen=1) 
at 
../../include/QtCore/5.5.1/QtCore/private/../../../../../src/corelib/kernel/qcore_unix_p.h:265
#3  0x7565e2b4 in QProcessPrivate::startDetached (program=..., 
arguments=..., workingDirectory=..., pid=0x0) at io/qprocess_unix.cpp:1246
#4  0x7560142d in QProcess::startDetached (program=..., arguments=...) 
at io/qprocess.cpp:2461
#5  0x7652f1f5 in KIO::Slave::createSlave (protocol=..., url=..., 
error=@0x7fffddf15260: 214848, error_text=...) at 
/home/jenkins/builds/kio/kf5-qt5/src/core/slave.cpp:499
#6  0x7658ec6d in KIO::ProtoQueue::createSlave (this=0x611db8c0, 
protocol=..., job=0x6032e330, url=...) at 
/home/jenkins/builds/kio/kf5-qt5/src/core/scheduler.cpp:529
#7  0x7658fc60 in KIO::ProtoQueue::startAJob (this=0x611db8c0) at 
/home/jenkins/builds/kio/kf5-qt5/src/core/scheduler.cpp:616
#8  0x76599711 in KIO::ProtoQueue::qt_static_metacall 
(_o=0x611db8c0, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x7fffddf154b0)
at /home/jenkins/builds/kio/kf5-qt5/build/src/core/moc_scheduler_p.cpp:250
#9  0x7571273e in QMetaObject::activate (sender=0x611db918, 
signalOffset=3, local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3713
#10 0x75711f2a in QMetaObject::activate (sender=0x611db918, 
m=0x75a45420 , local_signal_index=0, argv=0x0) at 
kernel/qobject.cpp:3578
#11 0x757b6b49 in QTimer::timeout (this=0x611db918) at 
.moc/moc_qtimer.cpp:197
#12 0x7571e420 in QTimer::timerEvent (this=0x611db918, 
e=0x7fffddf158c0) at kernel/qtimer.cpp:247
#13 0x7570b77b in QObject::event (this=0x611db918, 
e=0x7fffddf158c0) at kernel/qobject.cpp:1220
#14 0x756d0782 in QCoreApplicationPrivate::notify_helper 
(this=0x60f0ef50, receiver=0x611db918, event=0x7fffddf158c0) at 
kernel/qcoreapplication.cpp:1093
#15 0x756d0409 in QCoreApplication::notify (this=0x7fff7570, 
receiver=0x611db918, event=0x7fffddf158c0) at 
kernel/qcoreapplication.cpp:1038
#16 0x756d02f1 in QCoreApplication::notifyInternal 
(this=0x7fff7570, receiver=0x611db918, event=0x7fffddf158c0) at 
kernel/qcoreapplication.cpp:965
#17 0x756d42a5 in QCoreApplication::sendEvent (receiver=0x611db918, 
event=0x7fffddf158c0) at 
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:224
#18 0x7574cac1 in QTimerInfoList::activateTimers (this=0x60f8e6c0) 
at kernel/qtimerinfo_unix.cpp:637
#19 0x7574dfc0 in timerSourceDispatch (source=0x60f8e660) at 
kernel/qeventdispatcher_glib.cpp:177

Config: Using QtTest library 5.5.1, Qt 5.5.1 (x86_64-little_endian-lp64 shared 
(dynamic) debug build; by GCC 4.9.2)

After many tries I got it to hang under strace -f as well.
Here's the log: http://www.davidfaure.fr/2015/strace.output.bz2
pipe2() succeeds 40 times, so that's not the problem...

Process 7389 (which works) does set_robust_list, close(43), execve(kioslave).
Process 7391 (which hangs) does set_robust_list, close(43) ... and nothing else.
Overall I see 60 calls to clone(), 40 calls to pipe2(), but only 16 calls to 
execve(kioslave).
Help?

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

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org

plasma-frameworks unittest still broken

[David Faure]

Good morning from the unit test police...

https://build.kde.org/job/plasma-framework%20master%20kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/122/console

03:08:59 FAIL!  : DialogNativeTest::size() Compared values are not the same
03:08:59Actual   (m_dialog->width()): 112
03:08:59Expected (108)  : 108
03:08:59Loc: 
[/home/jenkins/builds/plasma-framework/kf5-qt5/autotests/dialognativetest.cpp(68)]
03:08:59 FAIL!  : DialogNativeTest::position() Compared values are not the same
03:08:59Actual   (m_dialog->x()): 69
03:08:59Expected (71)   : 71
03:08:59Loc: 
[/home/jenkins/builds/plasma-framework/kf5-qt5/autotests/dialognativetest.cpp(86)]
03:08:59 PASS   : DialogNativeTest::cleanupTestCase()
03:08:59 Totals: 2 passed, 2 failed, 0 skipped, 0 blacklisted
03:08:59 * Finished testing of DialogNativeTest *

Please guys keep an eye on CI so I don't have to hunt for broken unittests when 
making a release.

-- 
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

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

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kxmlgui%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/34/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sat, 07 Nov 2015 09:13:09 +
Build duration: 39 sec

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

Re: Review Request 125790: Recognize image/vnd.adobe.photoshop

[David Faure]

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


/usr/share/mime/aliases says image/x-psd image/vnd.adobe.photoshop

=> just remove image/x-psd, and use image/vnd.adobe.photoshop everywhere.

- David Faure


On Nov. 3, 2015, 7:51 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125790/
> ---
> 
> (Updated Nov. 3, 2015, 7:51 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kimageformats
> 
> 
> Description
> ---
> 
> This is the mimetype I get for .psd files
> 
> 
> Diffs
> -
> 
>   src/imageformats/psd.json 859eede 
>   src/imageformats/psd.desktop 494b746 
> 
> Diff: https://git.reviewboard.kde.org/r/125790/diff/
> 
> 
> Testing
> ---
> 
> I still don't get any thumbnails for PSD files, though.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Review Request 125987: KFontSettingsData autotest: dbus connect happens with QueuedConnection, wait for it.

[David Faure]

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

Review request for KDE Frameworks and Àlex Fiestas.


Repository: frameworkintegration


Description
---

KFontSettingsData autotest: dbus connect happens with QueuedConnection, wait 
for it.


Diffs
-

  autotests/kfontsettingsdata_unittest.cpp 
56ba9458625e2f39622251467ee39b388fc6508d 

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


Testing
---

This fixes ./kfontsettingsdata_unittest on my machine. I'm not sure how it 
passes on CI at all...


Thanks,

David Faure

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

Re: icon frameworks

[David Faure]

On Saturday 07 November 2015 10:04:52 David Faure wrote:
> 
> Did you check the list from
> https://community.kde.org/Frameworks/CreationGuidelines
> ?
> 
> At first sight I see already one thing missing: no CI job under
> https://build.kde.org/view/Frameworks%20kf5-qt5/

To get this moving (since it's blocking the release) I looked into
adding it myself but I don't have permissions or maybe I forgot
how to go about doing that.

So I filed https://phabricator.kde.org/T1032 for it to be done by the sysadmins.

Still, please go through the rest of the checklist ;)

-- 
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 125988: [KUrlCompletion] Add autocompletion for '.' input which offers all hidden files/folders

[Emmanuel Pescosta]

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

Review request for KDE Frameworks.


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


Repository: kio


Description
---

Currently KUrlCompletion only offers autocompletion for hidden folders when you 
input at least one additional character after the dot. 
With this patch all hidden folders will be offered when only a dot is present.

This behaviour is test covered.


Diffs
-

  autotests/kurlcompletiontest.cpp ca8563c 
  src/widgets/kurlcompletion.cpp c6764e4 

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


Testing
---

All test cases for KUrlCompletion pass


Thanks,

Emmanuel Pescosta

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

Re: Build and test failures with Qt 5.6 and Qt 5.3

[Jan Kundrát]

Hi David,
thanks for looking into this. I'm happy that you find the additional 
coverage useful. At this time, the infrastructure cannot easily send out 
automated e-mails only upon a change in the state of a build job -- if 
someone has some time and is willing to improve this, I'll be happy to walk 
them through.



Having this for all of KF5 would definitely be useful.


I'll see into doing this.


- [5.6] kcoreaddons: different number formatting


This test sets a C locale. Could it be that on your system, the C locale
doesn't include having the comma as thousands-separator?


The build jobs appear to be running with LANG=en_US.UTF-8. My ssh setup 
apparently forwards these LANG and LC_* variables, so I cannot guarantee 
100% correctness, but here's how the number formatting works in root's 
bash:


[root@ci-el7-a-4 ~]# LC_ALL=C printf "%'.3f\n" 12345678.901
12345678.901
[root@ci-el7-a-4 ~]# LC_ALL=en_US.utf8 printf "%'.3f\n" 12345678.901
12,345,678.901

Is that a correct behavior?

Or maybe the system's locale still interfers, i.e. KFormat 
format(QLocale::c());

isn't enough to -really- use the C locale?


Note that the failure is specific to Qt 5.6, which IMHO suggests that 
there's some behavior change in Qt.


- kio, in all versions: test failures in KNewFileMenuTest::test(text file 
with jpeg extension)


Also a mimetype problem. kcoreaddons' kde5.xml adds "*.doc" as a pattern
for text/plain, but surely it doesn't mean for it to become the 
main extension.
Can you the value of 
QMimeDatabase().mimeTypeForName("text/plain").preferredSuffix()
on your system? Here's it's "txt", I suspect it's "doc" on your 
system. Not sure why yet

though, but let's first check that.


It prints out "txt".


- kservice, in all versions: test failure


It appears that your system doesn't know that opendocument 
inherits application/zip.

Do you have this line in /usr/share/mime/subclasses ?
application/vnd.oasis.opendocument.text application/zip


That line is missing:

[root@ci-el7-a-4 ~]# grep -c opendocument /usr/share/mime/subclasses 
0

[root@ci-el7-a-4 ~]# rpm -qf /usr/share/mime/subclasses
shared-mime-info-1.1-7.el7.x86_64

Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Build and test failures with Qt 5.6 and Qt 5.3

[Jan Kundrát]

On Saturday, 7 November 2015 22:38:16 CET, Ivan Čukić wrote:
- [5.3] kactivities: won't build due to 
QQuickWidget::setClearColor which is

5.4+ only.


It should be ok now. I've added a work-around (essentially how the
method is implemented in 5.4 and 5.5).


kactivities/src/workspace/settings/imports/dialog.cpp:77:15: error: no 
member named 'quickWindow' in 'QQuickWidget'


--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Build and test failures with Qt 5.6 and Qt 5.3

[Ivan Čukić]

> - [5.3] kactivities: won't build due to QQuickWidget::setClearColor which is
> 5.4+ only.

It should be ok now. I've added a work-around (essentially how the
method is implemented in 5.4 and 5.5).

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

Jenkins-kde-ci: kio master kf5-qt5 » Linux,gcc - Build # 162 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/162/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sat, 07 Nov 2015 21:14:45 +
Build duration: 12 min

CHANGE SET
Revision 2b211d1db809df2e01362e8dbfda3dffab8c6e3d by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit src/kssld/kssld.json
  change: edit src/kpac/proxyscout.json
  change: edit src/new_file_templates/Directory.desktop
  change: edit src/kpasswdserver/kpasswdserver.json
  change: edit src/new_file_templates/HTMLFile.desktop
  change: edit src/new_file_templates/linkProgram.desktop
  change: edit src/new_file_templates/TextFile.desktop
  change: edit src/urifilters/ikws/searchproviders/qt.desktop
  change: edit src/new_file_templates/linkPath.desktop
  change: edit src/new_file_templates/linkURL.desktop
  change: edit src/widgets/konqpopupmenuplugin.desktop
  change: edit src/ioslaves/http/kcookiejar/kcookiejar.json
  change: edit src/urifilters/ikws/searchproviders/qt4.desktop


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 20/20 (100%)FILES 253/331 (76%)CLASSES 253/331 (76%)LINE 24858/50007 
(50%)CONDITIONAL 13433/20731 (65%)

By packages
  
autotests
FILES 61/61 (100%)CLASSES 61/61 (100%)LINE 7019/7236 
(97%)CONDITIONAL 3832/7041 (54%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 
(100%)CONDITIONAL 166/272 (61%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 
60/90 (67%)
src.core
FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7436/14021 
(53%)CONDITIONAL 3897/5401 (72%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2283/7589 
(30%)CONDITIONAL 911/1407 (65%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 435/843 (52%)CONDITIONAL 
317/461 (69%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3800 
(20%)CONDITIONAL 547/678 (81%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 
602/758 (79%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 718/1182 (61%)CONDITIONAL 
373/515 (72%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 
434/822 (53%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 302/388 (78%)CONDITIONAL 
86/108 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 384/600 (64%)CONDITIONAL 
280/408 (69%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 280/285 (98%)CONDITIONAL 
144/254 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 32/35 (91%)CONDITIONAL 
42/52 (81%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 248/743 (33%)CONDITIONAL 
147/194 (76%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 20/27 (74%)CONDITIONAL 
14/18 (78%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 226/256 (88%)CONDITIONAL 
292/358 (82%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2687/10636 
(25%)CONDITIONAL 1281/1878 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kio master kf5-qt5 » Linux,gcc - Build # 162 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/162/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sat, 07 Nov 2015 21:14:45 +
Build duration: 12 min

CHANGE SET
Revision 2b211d1db809df2e01362e8dbfda3dffab8c6e3d by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit src/kssld/kssld.json
  change: edit src/kpac/proxyscout.json
  change: edit src/new_file_templates/Directory.desktop
  change: edit src/kpasswdserver/kpasswdserver.json
  change: edit src/new_file_templates/HTMLFile.desktop
  change: edit src/new_file_templates/linkProgram.desktop
  change: edit src/new_file_templates/TextFile.desktop
  change: edit src/urifilters/ikws/searchproviders/qt.desktop
  change: edit src/new_file_templates/linkPath.desktop
  change: edit src/new_file_templates/linkURL.desktop
  change: edit src/widgets/konqpopupmenuplugin.desktop
  change: edit src/ioslaves/http/kcookiejar/kcookiejar.json
  change: edit src/urifilters/ikws/searchproviders/qt4.desktop


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 20/20 (100%)FILES 253/331 (76%)CLASSES 253/331 (76%)LINE 24858/50007 
(50%)CONDITIONAL 13433/20731 (65%)

By packages
  
autotests
FILES 61/61 (100%)CLASSES 61/61 (100%)LINE 7019/7236 
(97%)CONDITIONAL 3832/7041 (54%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 
(100%)CONDITIONAL 166/272 (61%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 
60/90 (67%)
src.core
FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7436/14021 
(53%)CONDITIONAL 3897/5401 (72%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2283/7589 
(30%)CONDITIONAL 911/1407 (65%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 435/843 (52%)CONDITIONAL 
317/461 (69%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3800 
(20%)CONDITIONAL 547/678 (81%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 
602/758 (79%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 718/1182 (61%)CONDITIONAL 
373/515 (72%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 
434/822 (53%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 302/388 (78%)CONDITIONAL 
86/108 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 384/600 (64%)CONDITIONAL 
280/408 (69%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 280/285 (98%)CONDITIONAL 
144/254 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 32/35 (91%)CONDITIONAL 
42/52 (81%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 248/743 (33%)CONDITIONAL 
147/194 (76%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 20/27 (74%)CONDITIONAL 
14/18 (78%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 226/256 (88%)CONDITIONAL 
292/358 (82%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2687/10636 
(25%)CONDITIONAL 1281/1878 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Qt 5.6 behavior change with QByteArray(str, size) and QFile::encodeName()

[David Faure]

KTar's unittests detected a behavior change in Qt.
Thiago, is it intentional, or should it be fixed in Qt ?

KTar does

QString name = QFile::decodeName(QByteArray(buffer, 100));

where buffer is e.g. "filename\0\0\0\0\0\0[...]"

With Qt < 5.6 this would lead to name being equal to "filename".

With Qt 5.6 from git, it leads to name being equal to "filename\0\0\0\0\0etc.".

It appears that QUtfCodec doesn't stop at the first null byte anymore.

This appears to fix it:
-name = QFile::decodeName(QByteArray(buffer, 100));
+name = QFile::decodeName(QByteArray(buffer, qstrnlen(buffer, 100)));

but I have to find the other places in there, some more unittests still fail.

-- 
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

Re: Build and test failures with Qt 5.6 and Qt 5.3

[Ivan Čukić]

Ah, for the *** sake. My fault, I expected that the 'since' tag is
missing from that one like it is for setClearColor and didn't check.

I've removed the call in question when compiling against Qt 5.3.

It will manifest as an issue for people that use dark colour scheme,
but since the activities KCM is used only by plasma which requires Qt
5.4, we should be ok.

Thanks for the reporting.

Cheerio,
Ivan

--
KDE, ivan.cu...@kde.org, http://cukic.co/
gpg key id: 850B6F76
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 124714: Add support to qmake's options to api.kde.org

[Lamarque Souza]

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

(Updated Nov. 8, 2015, 1:21 a.m.)


Review request for KDE Frameworks and Alex Merry.


Changes
---

This version allows adding all lines from qmakepro section to the output html 
file.


Repository: kapidox


Description
---

NetworkManagerQt requires some options to be added to .pro file to compile:

QT += NetworkManagerQt dbus network
CONFIG += link_pkgconfig
PKGCONFIG += libnm # from NetworkManager package
DEFINES += QT_NO_KEYWORDS # libnm declares a variable named signals

kapidox already supports the first option (QT), but not the others. This patch 
adds support to adding the other three options.


Diffs (updated)
-

  src/kapidox/data/templates/fwinfo.html a20c1d1 

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


Testing (updated)
---

I added the lines below to networkmanager-qt/metainfo.html and kapidox created 
the correct output:

qmakepro:
 - CONFIG += link_pkgconfig
 - DEFINES += QT_NO_KEYWORDS
 - PKGCONFIG += libnm


Thanks,

Lamarque Souza

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

Re: Review Request 124714: Add support to qmake's options to api.kde.org

[Lamarque Souza]

> On Nov. 3, 2015, 7:42 p.m., Alex Merry wrote:
> > Sorry I've let this sit for so long - Real Life(TM) got in the way.
> > 
> > Rather than adding variables for each of these, I'd rather have some way to 
> > add free text to this field. Also, have you checked that an extra line 
> > break doesn't get added when the fields are not set?
> > 
> > Finally, have you explored ways to make these *not* be required? I don't 
> > know QMake's build system very well, but it seems to me that at least some 
> > of these might be able to go in the .pri file (and it might be possible to 
> > protect client projects from the need to set QT_NO_KEYWORDS).

I have changed the patch to allow adding (almost) free text to the field. The 
dash at each line start is still needed to mark linebreaks in the output html 
file.

I am not able to compile networkmanager-qt using qmake from Qt 5.4.2 anymore, 
so I cannot test your suggestion to move some of the configurations to .pri 
file. Anyway, the current patch seems to work and does not add unnecessary 
fields like the first version.


- Lamarque


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


On Nov. 8, 2015, 1:21 a.m., Lamarque Souza wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124714/
> ---
> 
> (Updated Nov. 8, 2015, 1:21 a.m.)
> 
> 
> Review request for KDE Frameworks and Alex Merry.
> 
> 
> Repository: kapidox
> 
> 
> Description
> ---
> 
> NetworkManagerQt requires some options to be added to .pro file to compile:
> 
> QT += NetworkManagerQt dbus network
> CONFIG += link_pkgconfig
> PKGCONFIG += libnm # from NetworkManager package
> DEFINES += QT_NO_KEYWORDS # libnm declares a variable named signals
> 
> kapidox already supports the first option (QT), but not the others. This 
> patch adds support to adding the other three options.
> 
> 
> Diffs
> -
> 
>   src/kapidox/data/templates/fwinfo.html a20c1d1 
> 
> Diff: https://git.reviewboard.kde.org/r/124714/diff/
> 
> 
> Testing
> ---
> 
> I added the lines below to networkmanager-qt/metainfo.html and kapidox 
> created the correct output:
> 
> qmakepro:
>  - CONFIG += link_pkgconfig
>  - DEFINES += QT_NO_KEYWORDS
>  - PKGCONFIG += libnm
> 
> 
> Thanks,
> 
> Lamarque Souza
> 
>

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

Re: Review Request 125815: Provide an alternative when khelpcenter is not available

[Luigi Toscano]

> On Nov. 4, 2015, 1:43 a.m., Aleix Pol Gonzalez wrote:
> > Bump? Anyone with docs.kde.org knowledge around?
> 
> Ben Cooksley wrote:
> As long as the application name is being submitted in lower case, it 
> should work fine.
> 
> Examples: 
> https://docs.kde.org/index.php?branch=stable5=gwenview
> https://docs.kde.org/index.php?branch=stable5=konversation
> https://docs.kde.org/index.php?branch=stable5=dolphin
> 
> Luigi Toscano wrote:
> There are few exceptions for kioslaves and kcm modules:
> application=kioslave5/ftp for kioslaves (or kioslave/ftp for the kdelibs4 
> based version)
> application=kcontrol/powerdevil
> Not sure if they need to be handled there or those values are already 
> specified as applicationName()
> 
> For the record, all the source code is here:
> https://quickgit.kde.org/?p=websites%2Fdocs-kde-org.git=tree
> 
> Ralf Habacker wrote:
> What about language selection ? khelpcenter also covers to select the 
> language currently used in the KDE environment.
> 
> Aleix Pol Gonzalez wrote:
> I introduced it in the committed version. It will need some love in the 
> server-side though, since it needs to understand that "fr_FR" is "fr".
> We can do the cutting before the _ because there's some exceptions, for 
> example zh_CN.
> 
> Help there is welcome.

Server side for xy_XY: 
https://quickgit.kde.org/?p=websites%2Fdocs-kde-org.git=commit=60ef1e16faf3328362b17e1048d8bad01f168fef


- Luigi


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


On Nov. 6, 2015, 5:48 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125815/
> ---
> 
> (Updated Nov. 6, 2015, 5:48 p.m.)
> 
> 
> Review request for KDE Frameworks, Christoph Cullmann and Luigi Toscano.
> 
> 
> Repository: kguiaddons
> 
> 
> Description
> ---
> 
> Tries to reach out to docs.kde.org when khelpcenter is not available.
> 
> 
> Diffs
> -
> 
>   src/util/urlhandler.cpp 5b46be2 
> 
> Diff: https://git.reviewboard.kde.org/r/125815/diff/
> 
> 
> Testing
> ---
> 
> I tried it with a couple of applications. For the main documentation just 
> works.
> 
> Needs figuring out for more complex cases, I'm unsure if applications are 
> opening the documentation in specific pages. In fact, I couldn't find the 
> documentation for docs.kde.org url scheme, and I just made up the `path` 
> part, although it seems to work.
> 
> 
> 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 125904: Save proxy url with correct scheme.

[Xuetian Weng]

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

(Updated Nov. 8, 2015, 3:26 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Eike Hein.


Changes
---

Submitted with commit 4e2a52c67167507b62553ca595bb561b925dc440 by Weng Xuetian 
to branch master.


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 125885: Support socks5 proxy in KTcpSocket

[Xuetian Weng]

> On Nov. 2, 2015, 8:08 a.m., David Faure wrote:
> > Ah I see, forget what I said about HTTP proxy.
> > 
> > About the missing argument, it would indeed be useful for this code:
> > http://lxr.kde.org/source/extragear/network/konversation/src/irc/server.cpp
> > Add a separate method, for BC reasons.

After you mentioned it, I actually test the http proxy (proxy server I used is 
polipo) and pure tcp, and it does support tcp connection over http proxy.

I'd like to be more careful for other users of ktcpsocket in ioslaves.

KTcpSocket does not know the protocol that this TcpSocket will use. But http 
ioslave uses setApplicationProxy to set the proxy. Use connectionHost with 
policy = AutoProxy may make http uses socks instead http proxy by default. Same 
applies to ftp ioslave and maybe others ioslave use TCPSlaveBase.

I wonder if there should also be some protocol hint argument of connectHost, or 
http and ftp ioslave should use policy = ManualProxy.


- Xuetian


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


On Oct. 30, 2015, 11:26 p.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125885/
> ---
> 
> (Updated Oct. 30, 2015, 11:26 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Bugs: 342402
> https://bugs.kde.org/show_bug.cgi?id=342402
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Automatically set socks5 proxy in KTcpSocket.
> 
> 
> Diffs
> -
> 
>   src/core/ktcpsocket.h ffa3f0b 
>   src/core/ktcpsocket.cpp fde35a7 
> 
> Diff: https://git.reviewboard.kde.org/r/125885/diff/
> 
> 
> Testing
> ---
> 
> Test with akonadi imap agent, connect through socks5 proxy.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

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