D5788: Add syntax highlighting for YANG data modeling language

[Jan Kundrát]

jkt added a comment.


  Re "extracting bits from the RFC", RFC 6020 says (among other things) that 
//"Code Components extracted from this document must include Simplified BSD 
License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Simplified BSD License."// That 
sounds like a reasonable license, doesn't it?

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  master

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

To: nalvarez, #kate, jkt, dhaumann
Cc: dhaumann, jkt, #frameworks

D5788: Add syntax highlighting for YANG data modeling language

[Jan Kundrát]

jkt accepted this revision.
jkt added a comment.


  Oops, sorry, I forgot to comment here. I appreciate your conversion, it works 
really nicely!
  
  Compared to the vim version, my QtCreator theme is not highlighting the 
`true` and `false` keywords in statements such as `mandatory true;`. That's 
because the `dsVariable` appears to be mapped to "Local" in QtC, and that thing 
is not being decorated in any manner in my theme. Perhaps mapping it to 
"something else" ,ight be a good idea? I have to admit that I have no clue 
about a best fit here; it's probably not a keyword.
  
  Thanks again for implementing this!

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  master

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

To: nalvarez, #kate, jkt, dhaumann
Cc: dhaumann, jkt, #frameworks

Re: Differential e-mail subject re-arrangement

[Jan Kundrát]

On čtvrtek 2. března 2017 9:08:25 CET, Ben Cooksley wrote:

In regards to the way email subjects are treated, I've now customised
the metamta.differential.subject-prefix preference on our installation
to be blank, to the "[Differential]" part should no longer be present.


Roughly at the time you flipped this, the outoging e-mails ceased to be 
multipart/alternative with HTML and plaintext. They are now HTML-only.


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Review Request 129426: refactor gpg finding

[Jan Kundrát]

> On Nov. 18, 2016, 8:05 p.m., Andreas Sturmlechner wrote:
> > CMakeLists.txt, line 37
> > 
> >
> > that looks to me as if it does the opposite as in $description; prefer 
> > the old one to the new one.
> 
> Harald Sitter wrote:
> You take offense with an if checking whether we can build with gpg 
> support?
> 
> Andreas Sturmlechner wrote:
> It does the opposite of what you say you want in the description. 
> Preferring the new lib is the status quo.
> 
> Andreas Sturmlechner wrote:
> And while I agree that the current approach can be much improved, 
> KF5Gpgmepp is not here to stay anyway. 16.08.3 is its final release and with 
> KF-5.30 it may as well be kicked out by simply reverting 
> 60ebcad53c95ecfbe822647075f79578c3420851 (which leaves the unnecessary 
> duplication in test dir).
> 
> Harald Sitter wrote:
> I don't understand.

Harald, I believe that Andreas is telling you that the review description says 
"the new bindings from gpgme upstream are preferred over the legacy 
kf5-gpgmepp", but the actual cmake code will select kf5-gpgmepp when both of 
them are installed on the build machine.


- Jan


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


On Nov. 18, 2016, 2 p.m., Harald Sitter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129426/
> ---
> 
> (Updated Nov. 18, 2016, 2 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kwallet
> 
> 
> Description
> ---
> 
> refactor gpg finding code to be correctly taking all FOUND vars into account, 
> indicate itself as feature to cmake, prefer the new lib over the old one, not 
> be duplicated in runtime and test dir, not require excessively shitty if's to 
> be used.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 6145fda8ebd8470024396b9029d1f23298d1a333 
>   src/runtime/kwalletd/CMakeLists.txt 
> 5092a7e77a1ca7203827e444c11310566b2cc8b5 
>   src/runtime/kwalletd/backend/CMakeLists.txt 
> 2f99bc3cca89dd7a194f46cb314d2f7f90f931f3 
>   tests/kwalletd/CMakeLists.txt 1e7c4b77ba478147fae964f61c28a736e32b9ea9 
> 
> Diff: https://git.reviewboard.kde.org/r/129426/diff/
> 
> 
> Testing
> ---
> 
> builds and continues to link to gpg
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

Re: kdewebkit?

[Jan Kundrát]

On Thursday, 21 April 2016 18:33:51 CEST, David Edmundson wrote:

-postCheckoutCommand=./init-repository -f
+postCheckoutCommand=./init-repository -f --module-subest=default,qtwebkit


That parameter is called --module-subset, not --module-subest (on both 
places).


--
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: QString -> QStringLiteral conversions might make applications crash on exit

[Jan Kundrát]

On Monday, 29 February 2016 23:16:22 CET, Frank Reininghaus wrote:

If something like "do not use QStringLiteral in plugins" will be the
conclusion from this issue, then I'm all for continuing to use
QStringLiteral everywhere else in order to avoid heap allocations.


The conclusion is "do not unload Qt plugins". Unfortunately, a fix for this 
depends on the Qt projet merging that patch which forbids this plugin 
unloading.


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: QString -> QStringLiteral conversions might make applications crash on exit

[Jan Kundrát]

On Friday, 26 February 2016 01:37:57 CET, Frank Reininghaus wrote:

This becomes a problem if the read-only data that the QString refers
to are not there any more, which can happen if the QString was stored
in a global static object from one library, and the QStringLiteral is
from another library, which might have been unloaded before the global
static object was destroyed.


Are you 100% sure that this is not "just" due to icon loaders which are 
implemented as plugins [1]?


Upstream says [2] that they do not want to support unloading of plugins 
which "leak" Qt data. There's a patch [3] which implements this for all 
plugins (including the icon loaders). Apparently, it's been so ever since 
Qt 5.0.


For an example on how an application can workaround this thing, see my 
patch to Trojitá [4].


Cheers,
Jan

[1] https://bugreports.qt.io/browse/QTBUG-50829
[2] 
https://bugreports.qt.io/browse/QTBUG-49061?focusedCommentId=297937=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-297937

[3] https://codereview.qt-project.org/140750
[4] 
https://gerrit.vesnicky.cesnet.cz/r/#/c/595/5/src/UiUtils/IconLoader.cpp


--
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: test failures on http://ci-logs.kde.flaska.net

[Jan Kundrát]

And indeed the value of XDG_DATA_DIRS in
http://ci-logs.kde.flaska.net/7f/7f50569d59eabc20897f54fb97483bd7f8b89d63/rebuilddep/rebuilddep-kf5-qt55-clang-el7/3cef5be/shell_output.log
is long and messy and has /usr/share in front (so it's viewed 
as being "on top of" the kde mimetype file, while it's supposed 
to be the other way around).


Good catch, thanks for debugging this. This was caused by my change to the 
KDE CI scripts, and unfortunately these systemwide locations were being 
pushed for each project in the current project's dependencies rather than 
just once at the very end.


Fixed now, and KIO's tests are once again all green.

Cheers from a rainy Lesvos,
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: Scope of framework integration plugin?

[Jan Kundrát]

On Monday, 30 November 2015 14:45:41 CET, René J.  V. Bertin wrote:
Would you really expect Qt to accept a patch 
that allows generic applications to use font role specifications from KF5?


Yes, I think that such a goal is fully in line with Qt's attempt at being 
reasonably cross-platform.


They'd rightfully reject such a patch because it'd be up to KF5 
to provide the glue required to make that work.


Well, whether it's done through a plugin which is provided by the DE and 
injected into Qt's plugin paths or whether it's "just" a DE-specific logic 
that is however maintained within Qt's own git tree, that's a technical 
decision which I think should be answered by Qt developers.


In my experience, the Qt developers usually respond very well to patches in 
Gerrit.


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 Monday, 9 November 2015 08:21:21 CET, Martin Graesslin wrote:
I'm sorry, but I'm not able to reproduce the failure on my 
local Qt 5.6 setup. 
The failures look like there is no WM running on the CI system, 
maybe openbox 
crashed? (We had that before that our tests were able to trigger crashes in 
openbox).


All Qt versions are hitting the same pool of VMs, and the failure only 
happens on Qt 5.6. Unless there's something in Qt 5.6 which makes openbox 
crash, I don't think that it's a plausible explanation.


Anyway, if you look at the test log, you can see that the remaining tests 
all passed. Would they still pass even if there was no running WM at that 
point?


I can add some extra diagnostics to the build scripts if it's really 
needed, but let's figure out other possibilities first, please.


With kind regards,
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 Sunday, 8 November 2015 12:17:19 CET, David Faure wrote:

Any chance you could do some debugging around there?


I'm afraid I don't have time and motivation to fix this, sorry. I'll be 
happy to spin a VM with an identical setup for you, though, if you're OK 
with IPv6-only access. If so, please send me your SSH pubkey and I'll get 
it running.


[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


That is really broken. The inheritance of opendocument.text 
from application/zip

has always been there in s-m-i (since 0.18).

Do you actually have /usr/share/mime/packages/freedesktop.org.xml at all ?


Yup, that file is present.

If yes, then I don't know what could have gone wrong; could you 
maybe send me

a .zip of all of your /usr/share/mime ?


http://jkt.flaska.net/tmp/centos7-usr-share-mime.tar

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 11:59:48 CET, David Faure wrote:

Having this for all of KF5 would definitely be useful.


And it's done now: http://ci-logs.kde.flaska.net/matrix.html

- [5.3] ballo, missing QList::join

- [5.3] knewstuff, QTimer::singleShot and new slots

- [5.3] modemmanager-qt, checks for Qt>=5.4

- bluez-qt fails to install because it ignores the install prefix when 
installing the udev rules, and tries to modify a live system


- [5.6] frameworkintegration, test failure through some font stuff

- kwidgetsaddons, unstable tests [1] [2]. They tend to fail, but the 
failures appear to be perhaps timing-related?


- The karchive, kconfig, kcoreaddons, kio, plasma-frgamework have the same 
issue as previously reported -- just for the completeness.


Cheers,
Jan

[1] 
http://ci-logs.kde.flaska.net/89/8956b5338b3daf9e2e53f7fc44b23e879f3844a8/rebuilddep/rebuilddep-kf5-qt54-gcc-el7/e1103bb/shell_output.log
[2] 
http://ci-logs.kde.flaska.net/89/8956b5338b3daf9e2e53f7fc44b23e879f3844a8/rebuilddep/rebuilddep-kf5-qt56-gcc-el7/4c4af2c/shell_output.log


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

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

Build and test failures with Qt 5.6 and Qt 5.3

[Jan Kundrát]

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.


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.


- [5.3] kcoreaddons: QDebug::noquote

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

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

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

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

- [5.6] kcoreaddons: different number formatting

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


- kservice, in all versions: test failure

- [5.6] kwindowsystem: KWindowInfoX11Test fails tests

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

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

--
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: marble builds when it shouldn't

[Jan Kundrát]

On Tuesday, 22 September 2015 13:00:38 CEST, Harald Sitter wrote:

Also on a more general note: I think it would be handy if all builds
used CMAKE_VERBOSE_MAKEFILE=TRUE to get verbose make output which
would make it easier to notice when things such as -DNDEBUG are passed
to gcc.


Absolutely -- the last time I raised this, though, someone disagreed on 
basis of increased volume of logs, IIRC.


With kind regards,
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: Review Request 124386: Fix build with Qt 5.4

[Jan Kundrát]

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

(Updated July 19, 2015, 10:30 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit b54a1b2dab13569d73ec5ba55358689e8849cc01 by Jan Kundrát 
to branch master.


Repository: kidletime


Description
---

The QJsonArray::operator-() got added in qtbase's commit 7dce9622 which
is only present in Qt 5.4.


Diffs
-

  src/kidletime.cpp 675cd2bc1642906c0fe21fa2f674549f85cf0aac 

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


Testing
---


Thanks,

Jan Kundrát

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

Re: Review Request 124384: Fix build with Qt 5.4

[Jan Kundrát]

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

(Updated July 19, 2015, 10:30 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit bc0848882cea3943c69a1dfb6ca427fa11d07ef9 by Jan Kundrát 
to branch master.


Repository: kwindowsystem


Description
---

The QJsonArray::operator-() got added in qtbase's commit 7dce9622 which
is only present in Qt 5.4.


Diffs
-

  src/pluginwrapper.cpp c3eed03d559308ad4d158a5de112febb50e6c93e 

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


Testing
---


Thanks,

Jan Kundrát

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

Review Request 124385: Fix build failure with clang 3.4.2

[Jan Kundrát]

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

Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

autotests/kextracolumnsproxymodeltest.cpp:68:9: error: control may reach end of 
non-void function [-Werror,-Wreturn-type]


Diffs
-

  autotests/kextracolumnsproxymodeltest.cpp 
b4064ad07da169aeaaeb0adc9207aa4395857c70 

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


Testing
---


Thanks,

Jan Kundrát

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

Re: Review Request 124385: Fix build failure with clang 3.4.2

[Jan Kundrát]

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

(Updated July 18, 2015, 9:09 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 4316ecb1b96a758afda79a0108d008f001171734 by Jan Kundrát 
to branch master.


Repository: kitemmodels


Description
---

autotests/kextracolumnsproxymodeltest.cpp:68:9: error: control may reach end of 
non-void function [-Werror,-Wreturn-type]


Diffs
-

  autotests/kextracolumnsproxymodeltest.cpp 
b4064ad07da169aeaaeb0adc9207aa4395857c70 

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


Testing
---


Thanks,

Jan Kundrát

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

Review Request 124384: Fix build with Qt 5.4

[Jan Kundrát]

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

Review request for KDE Frameworks.


Repository: kwindowsystem


Description
---

The QJsonArray::operator-() got added in qtbase's commit 7dce9622 which
is only present in Qt 5.4.


Diffs
-

  src/pluginwrapper.cpp c3eed03d559308ad4d158a5de112febb50e6c93e 

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


Testing
---


Thanks,

Jan Kundrát

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

Review Request 124386: Fix build with Qt 5.4

[Jan Kundrát]

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

Review request for KDE Frameworks.


Repository: kidletime


Description
---

The QJsonArray::operator-() got added in qtbase's commit 7dce9622 which
is only present in Qt 5.4.


Diffs
-

  src/kidletime.cpp 675cd2bc1642906c0fe21fa2f674549f85cf0aac 

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


Testing
---


Thanks,

Jan Kundrát

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

A CI dashboard with multiple versions of Qt5 on Linux

[Jan Kundrát]

Hi,
if you would like to check how well the KF5 builds cope with multiple Qt5 
versions, take a look at this page generated from the Zuul/Gerrit CI 
system:


http://ci-logs.kde.flaska.net/matrix.html

I am open for suggestions for service improvements, so if you have an idea 
on how to make this more useful, I'm all ears.


The tests failures look like real stuff, not some occasional 
non-deterministic occasional breakage, btw.


With kind regards,
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: A CI dashboard with multiple versions of Qt5 on Linux

[Jan Kundrát]

On Friday, 12 June 2015 01:29:59 CEST, Scarlett Clark wrote:

Question, is your Qt5.2 patched?


I'm pretty sure that it was a vanilla build straight from git on CentOS 7 
back in December 2014.


I have no idea what failure you saw and I agree that no patches is a good 
general approach, but I think that obvious compile time fixes required by, 
say, a too-new underlying distro are a well-qualifying exception.


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: Review Request 123743: Fix missing category to silence `desktop-file-validate`

[Jan Kundrát]

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

(Updated May 13, 2015, 12:50 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit aa3c4e7797940e53433dfbd38a1bdc4b0a5727a6 by Jan Kundrát 
to branch master.


Repository: ksshaskpass


Description
---

src/org.kde.ksshaskpass.desktop: error: (will be fatal in the future):
value Security in key Categories in group Desktop Entry requires
another category to be present among the following categories: Settings,
or System

...and System sounds closer to the actual purpose of this application.
Either this one, or let's remove the Security bit altogether.


Diffs
-

  src/org.kde.ksshaskpass.desktop a5fa682b7e6195be2474f2547714d71d68dd7284 

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


Testing
---


Thanks,

Jan Kundrát

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

Re: Review Request 123731: Cleanup handling of notifications closing

[Jan Kundrát]

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


Is it OK to have a non-null main object whose d-ptr is nullptr already? If not, 
can you fix the cause of that?


src/notifybypopup.cpp (line 491)
https://git.reviewboard.kde.org/r/123731/#comment55062

Is there an enum for this? Using that instead of a comment which explains 
what a magic value is about sounds much better.


- Jan Kundrát


On May 12, 2015, 11:59 a.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123731/
 ---
 
 (Updated May 12, 2015, 11:59 a.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Repository: knotifications
 
 
 Description
 ---
 
 While investigating the cause of crash of 
 https://bugs.kde.org/show_bug.cgi?id=342752 I've come across some loose ends 
 in how KNotifications is handling closing of notifications.
 
 As for the crash itself, I never managed to reproduce even with special 
 written test cases, but what happens (or seem to) is this:
  * KNotification object gets deleted
  * The destructor calls close() on all plugins
  * The NotifyByPopup plugin does async dbus call to close the notification 
 and returns
  * KNotification's dpointer is deleted
  * The DBus reply returns, calling NotifyByPopup::finished()
  * Now for some reason the KNotification object is still not null but its 
 dpointer is gone, so the check if (!notification || 
 d-notifications.contains(notification-id())) crashes on the 
 notification-id() call
 
 So I've made it simply return -1 when dpointer is null, which should ideally 
 prevent the crashes
 
 
 Diffs
 -
 
   src/knotification.cpp 01962b3 
   src/knotificationmanager.cpp 0d9b3b0 
   src/knotificationmanager_p.h f8e7df8 
   src/notifybypopup.cpp 2f84ab0 
 
 Diff: https://git.reviewboard.kde.org/r/123731/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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

Review Request 123743: Fix missing category to silence `desktop-file-validate`

[Jan Kundrát]

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

Review request for KDE Frameworks.


Repository: ksshaskpass


Description
---

src/org.kde.ksshaskpass.desktop: error: (will be fatal in the future):
value Security in key Categories in group Desktop Entry requires
another category to be present among the following categories: Settings,
or System

...and System sounds closer to the actual purpose of this application.
Either this one, or let's remove the Security bit altogether.


Diffs
-

  src/org.kde.ksshaskpass.desktop a5fa682b7e6195be2474f2547714d71d68dd7284 

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


Testing
---


Thanks,

Jan Kundrát

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

Re: Review Request 123724: Use QTemporaryFile instead of hardcoding /tmp.

[Jan Kundrát]

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


Was the old code a part of some release? If yes, this should get a CVE security 
announcement because it allows a local attacker to e.g. force you to overwirte 
some of your user's files.

- Jan Kundrát


On May 12, 2015, 12:49 p.m., Michael Palimaka wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123724/
 ---
 
 (Updated May 12, 2015, 12:49 p.m.)
 
 
 Review request for KDE Frameworks and KDEPIM.
 
 
 Repository: kpeople
 
 
 Description
 ---
 
 Hardcoding files like this seems like a bad idea.
 
 
 Diffs
 -
 
   autotests/persondatatests.h 30eeeb5cd647c713f1b438543a54516ced9f3ede 
   autotests/persondatatests.cpp 73098d3717509ad80761bbd02000b4ce5060bbb2 
   autotests/personsmodeltest.h 5b8879521f334459c4f73c2708b3368c543e40a3 
   autotests/personsmodeltest.cpp b19d1baf8a2c2e617d4b6128df29fbab3b8e61a7 
 
 Diff: https://git.reviewboard.kde.org/r/123724/diff/
 
 
 Testing
 ---
 
 Tests still pass.
 
 
 Thanks,
 
 Michael Palimaka
 


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

Re: Versioning of Frameworks

[Jan Kundrát]

On Sunday, 10 May 2015 15:39:02 CEST, David Faure wrote:

Qt *is* splitted. It's just that the splitted libs are released together.


The splitting of Qt is not full and complete, however. Modules tend to 
use each other's internal APIs, and that's the biggest reason for not 
supporting random mixing of different versions of Qt modules. Reducing the 
supported space of all possible combinations is another reason for sure, so 
I understand your point about doing the same in KF -- just explaining that 
in case of Qt5, there are other reasons as well.


Making it possible for people to work on frameworks and then 
use the result in 
their applications quickly is exactly the reason why we have a 
monthly release 
cycle (unlike Qt). You can implement stuff in KF5 and use it the month that 
follows in the layers above. This is orthogonal to the 
discussion on version 
numbering, i.e. I definitely don't see this as an argument in favour of 
version hell.


I think that Christian is saying that he can't really just use a new 
version of a particular framework because that new version brings along a 
lot of unrelated changes as well. For some reason (extra testing is 
required, we want stability) he doesn't want to follow that path. I think 
that it's a useful feedback from a user's point of view. I don't have an 
answer on how to fix this without introducing extra work to KF5 
maintainers, though.


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

Review Request 123700: Fix build with cmake 2.8.12.2

[Jan Kundrát]

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

Review request for KDE Frameworks, KDEPIM and Albert Astals Cid.


Bugs: 347399
http://bugs.kde.org/show_bug.cgi?id=347399


Repository: kpeople


Description
---

Fix build with cmake 2.8.12.2

Prior to 3.0, CMake didn't know how to handle the Q_GADGET macro, which
means that its presence was not enough to trigger automoc run on these
files. See [1] for a summary of the situation.

[1] 
https://mail.kde.org/pipermail/kde-frameworks-devel/2014-December/020713.html
BUG: 347399
REVIEW: 123700


Diffs
-

  src/match.cpp f84a824 

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


Testing
---


Thanks,

Jan Kundrát

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

Re: Review Request 123679: Fix build with Qt 5.5

[Jan Kundrát]

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

(Updated May 8, 2015, 11:48 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Stephen Kelly.


Changes
---

Submitted with commit d598382536d8c9982bba3ee210869e50d1313dff by Jan Kundrát 
to branch master.


Repository: kitemmodels


Description
---

Turns out that there's apparently no overload accepting a QPointer as
the first argument.

This is on Gentoo with qtbase e374ffc29c67493a51527117b55a53dfa5dd4267
and GCC 4.8.3.

Also make sure to tie the lifetime of the connection with `this` because
the lambda accesses our D-pointer, which means that it has to be
disconnected on destruction of `this`. Thanks to Milian Wolff for
catching this.

REVIEW: 123679


Diffs
-

  src/kselectionproxymodel.cpp 0755fb1ca527dde8287ba2607d915a4e18c20134 

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


Testing
---


Thanks,

Jan Kundrát

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

Review Request 123679: Fix build with Qt 5.5

[Jan Kundrát]

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

Review request for KDE Frameworks and Stephen Kelly.


Repository: kitemmodels


Description
---

Turns out that there's apparently no overload accepting a QPointer as
the first argument.

This is on Gentoo with qtbase e374ffc29c67493a51527117b55a53dfa5dd4267
and GCC 4.8.3.


Diffs
-

  src/kselectionproxymodel.cpp 0755fb1ca527dde8287ba2607d915a4e18c20134 

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


Testing
---


Thanks,

Jan Kundrát

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

Re: Versioning of Frameworks

[Jan Kundrát]

Hi Christian,
I think that the stuff you're looking for (reducing version churn) can also 
be provided by having stable branches for selected parts of KF5.


IMHO this can be quite an elegant solution given the usual cat-herding 
problem of FLOSS where people just do what they want to do. Those who value 
the benefits of having bugfix-only releases and those willing to put their 
time into this could well branch from a random KF5 release and keep 
backporting bugfixes. I can give you CI coverage pretty easily for this.


Would this solve this problem for you, and would you volunteer to become a 
maintainer for this? Has this been discussed before, or is there some 
reason against doing this?


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: stable-KF5-QT5 QT version...

[Jan Kundrát]

On Saturday, 18 April 2015 17:17:16 CEST, Scarlett Clark wrote:

qt5: {
kf5-qt5: 5.4.1,
stable-kf5-qt5: 5.3.2
},


The impression which I got in my earlier inquiries about this topic was 
that there's no KDE-wide consensus on which Qt5 version is the oldest 
supported one. That makes sense; if an application wants to support, e.g., 
Qt 5.2, having CI coverage for that target is important.


Given that you're rewriting the CI wrappers, my suggestion would be to get 
rid of the concept of one fixed Qt version for stable branch, whatever it 
is, and another Qt version for master. In the Zuul-based CI setup which we 
use with Gerrit, we've got all three Qt version (presently 5.2, 5.3 and 
5.4) as separate build configurations (using the traditional 
build.kde.org's scripts with no problem).


Hope this helps,
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: Review Request 122978: Add unit test for crash of bug 343976

[Jan Kundrát]

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

Ship it!


+2 from me -- it fixes a crash for me.

+I don't know the code and API asumptions to know whether it's better to just 
Q_ASSERT in the other methods (`setText` etc.), but even if it was better to 
assert crash, this patch does provide a big improvement :).

- Jan Kundrát


On March 16, 2015, 12:04 p.m., Martin Gräßlin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/122978/
 ---
 
 (Updated March 16, 2015, 12:04 p.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Bugs: 343976
 https://bugs.kde.org/show_bug.cgi?id=343976
 
 
 Repository: frameworkintegration
 
 
 Description
 ---
 
 Use a QPointer for QMenu of SystemTrayMenu
 
 We need better memory management as the QMenu the SystemTrayMenu creates
 might be deleted externally causing a double delete if the so-far
 QScopedPoiter cleans up.
 
 Switch to QPointer and call deleteLater if the pointer is still valid
 during destroying the SystemTrayMenu.
 
 BUG: 343976
 CHANGELOG: Fix possible crash when destroying a QSystemTrayIcon (triggered by 
 Trojita)
 
 
 Diffs
 -
 
   autotests/CMakeLists.txt e8ed6a99bb45969231ba21b8c5588e093bbbe3ee 
   autotests/ksni_unittest.cpp PRE-CREATION 
   src/platformtheme/kdeplatformsystemtrayicon.h 
 8f13a36ae7cebed7499ce8a160f3533665b909ac 
   src/platformtheme/kdeplatformsystemtrayicon.cpp 
 ce3d3de9f9cf479a5fe3af65ef7fb8ec2b9e0d29 
 
 Diff: https://git.reviewboard.kde.org/r/122978/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 122908: Fix segfaults due to missing screens

[Jan Kundrát]

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

(Updated March 16, 2015, 11:28 a.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks.


Repository: kwindowsystem


Description
---

Fix segfaults due to missing screens

Qt 5.5 has some changes which allow returning of null QScreen*. This
file was OK with such a situation throughout a lot of other places, but
these two were missing.


Diffs
-

  src/kwindoweffects_x11.cpp 661a0af95a7a1757c5ae863270434b0c2d5c0a26 

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


Testing
---


Thanks,

Jan Kundrát

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

Re: Review Request 122978: Add unit test for crash of bug 343976

[Jan Kundrát]

/platformsupport/eventdispatchers/qeventdispatcher_glib.cpp:70
#42 0x7fffef5d19c4 in g_main_dispatch (context=0x7fffe0001e00) at 
/var/tmp/portage/dev-libs/glib-2.40.0-r1/work/glib-2.40.0/glib/gmain.c:3064
#43 g_main_context_dispatch (context=context@entry=0x7fffe0001e00) at 
/var/tmp/portage/dev-libs/glib-2.40.0-r1/work/glib-2.40.0/glib/gmain.c:3663
#44 0x7fffef5d1c18 in g_main_context_iterate 
(context=context@entry=0x7fffe0001e00, block=block@entry=1, 
dispatch=dispatch@entry=1, self=optimized out)
at 
/var/tmp/portage/dev-libs/glib-2.40.0-r1/work/glib-2.40.0/glib/gmain.c:3734
#45 0x7fffef5d1d0c in g_main_context_iteration (context=0x7fffe0001e00, 
may_block=1) at 
/var/tmp/portage/dev-libs/glib-2.40.0-r1/work/glib-2.40.0/glib/gmain.c:3795
#46 0x74472991 in QEventDispatcherGlib::processEvents 
(this=0x55ab9a80, flags=...)
at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qeventdispatcher_glib.cpp:418
#47 0x74408e4b in QEventLoop::exec (this=this@entry=0x7fffd140, 
flags=..., flags@entry=...)
at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qeventloop.cpp:204
#48 0x7441221e in QCoreApplication::exec () at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qcoreapplication.cpp:1216
#49 0x555b9c08 in main (argc=3, argv=optimized out) at 
/home/jkt/work/prog/trojita/src/Gui/main.cpp:217
```


src/platformtheme/kdeplatformsystemtrayicon.cpp
https://git.reviewboard.kde.org/r/122978/#comment53282

What about just:
 
if (m_menu)


- Jan Kundrát


On March 16, 2015, 10:58 a.m., Martin Gräßlin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/122978/
 ---
 
 (Updated March 16, 2015, 10:58 a.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Bugs: 343976
 https://bugs.kde.org/show_bug.cgi?id=343976
 
 
 Repository: frameworkintegration
 
 
 Description
 ---
 
 Use a QPointer for QMenu of SystemTrayMenu
 
 We need better memory management as the QMenu the SystemTrayMenu creates
 might be deleted externally causing a double delete if the so-far
 QScopedPoiter cleans up.
 
 Switch to QPointer and call deleteLater if the pointer is still valid
 during destroying the SystemTrayMenu.
 
 BUG: 343976
 CHANGELOG: Fix possible crash when destroying a QSystemTrayIcon (triggered by 
 Trojita)
 
 
 Diffs
 -
 
   autotests/CMakeLists.txt e8ed6a99bb45969231ba21b8c5588e093bbbe3ee 
   autotests/ksni_unittest.cpp PRE-CREATION 
   src/platformtheme/kdeplatformsystemtrayicon.h 
 8f13a36ae7cebed7499ce8a160f3533665b909ac 
   src/platformtheme/kdeplatformsystemtrayicon.cpp 
 ce3d3de9f9cf479a5fe3af65ef7fb8ec2b9e0d29 
 
 Diff: https://git.reviewboard.kde.org/r/122978/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

KDeclarative doesn't build with Qt 5.2 due to QOpenGLContext::isOpenGLES() from plotter

[Jan Kundrát]

Hi,
kdeclarative doesn't build on Qt 5.2 since commit 
25c37a8a599f66e65be44ef99fd1fc8ca55dd477 [1] which introduced a hard dep on 
QOpenGLContext::isOpenGLES(), which is 5.3+ only. That commit was merged 
almost two months ago. Seems that I should configure some breakage 
notifications from the Zuul CI.


Is KDeclarative supposed to support Qt 5.2?

Cheers,
Jan

[1] 
http://quickgit.kde.org/?p=kdeclarative.gita=commitdiffh=25c37a8a599f66e65be44ef99fd1fc8ca55dd477

[2] http://doc.qt.io/qt-5/qopenglcontext.html#isOpenGLES

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

Review Request 122908: Fix segfaults due to missing screens

[Jan Kundrát]

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

Review request for KDE Frameworks.


Repository: kwindowsystem


Description
---

Fix segfaults due to missing screens

Qt 5.5 has some changes which allow returning of null QScreen*. This
file was OK with such a situation throughout a lot of other places, but
these two were missing.


Diffs
-

  src/kwindoweffects_x11.cpp 661a0af95a7a1757c5ae863270434b0c2d5c0a26 

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


Testing
---


Thanks,

Jan Kundrát

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

Re: Review Request 122843: Mark QuickAddons as its own project.

[Jan Kundrát]

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


To expland a bit, the reason for -I/.. being wrong is that it messes up include 
paths in a harmful way on some systems. C++ stdlib from GCC 4.8 ships with 
stuff such as #include debug/foo, and if there's an empty mountpoint /debug 
with too-strict permissions, the build fails (see e.g. 
https://bugs.gentoo.org/show_bug.cgi?id=542298).

Thanks for debugging this!

- Jan Kundrát


On March 6, 2015, 4:07 p.m., Michael Palimaka wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/122843/
 ---
 
 (Updated March 6, 2015, 4:07 p.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Repository: kdeclarative
 
 
 Description
 ---
 
 Otherwise, QuickAddons_BINARY_DIR is undefined causing -I/.. to be passed to 
 the
 compiler, which can cause a build failure.
 
 
 Diffs
 -
 
   src/quickaddons/CMakeLists.txt 3c7a34b89a77e09221e2b44688a6bd9123f8aec5 
 
 Diff: https://git.reviewboard.kde.org/r/122843/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Michael Palimaka
 


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

Re: Required and supported Qt versions

[Jan Kundrát]

On Tuesday, 30 December 2014 09:32:08 CEST, David Faure wrote:

Ideally every released minor version since 5.2 :-)
i.e. 5.2, 5.3, 5.4. Possibly even dev.


Hi,
the CI which is plugged into Gerrit now checks the following combinations:

- Qt 5.2.1, GCC 4.8.2 (RHEL7), release mode
- Qt 5.3.2, clang 3.4.2 (RHEL7), release mode
- Qt 5.4.0, GCC 4.8.2 (RHEL7), debug build

The plasma-framework also has an extra profile similar to the 5.3.2 above, 
but with disabled X11 on top of that.


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: Qt 5 buildability

[Jan Kundrát]

On Thursday, 8 January 2015 22:59:53 CEST, Ben Cooksley wrote:

QtWebEngine won't build unless you have nss-devel installed (which it
complains about) but it also won't build unless libcap-devel is
installed (which it doesn't complain about - you only find out when
the compiler bails out on you).


It's documented at their wiki page [1]. I agree that configure checking 
these deps is an obviously good thing and that nobody reads wiki pages.



The real big issue here though is none of this is integrated with
./configure, and the failure in QtWebEngine is fatal. Can someone
please raise this with the Qt developers and get them to fix their
build system please?


Nobody but you have full knowledge of the build environment that you use. 
Even if I forwarded your report, the Qt developers are likely to ask 
further questions which only you can answer. That's why it's important to 
eliminate as many middlemens from the bug reporting process as possible, 
IMHO.


You should file a bug at their issue tracker.

Cheers,
Jan

[1] http://qt-project.org/wiki/Building_Qt_5_from_Git

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

Required and supported Qt versions

[Jan Kundrát]

Hi,
is there a minimal required Qt version which applies to all of KF5? I see 
that most of the modules I currently have checked out say that they need 
5.2.0 while polkit-qt-1 declares itself compatible with 5.1.0.


- Is that information correct? Is 5.2.0 universally supported?
- Is there any value in having CI checks for this oldest supported version?
- Should the CI check other versions of Qt as well? Which ones?
- Would there be any value in testing e.g. libdep1 built against Qt 5.3.2 
with a project that uses libdep1 but is itself built with Qt 5.4?


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: Review Request 121575: FindEpoxy.cmake

[Jan Kundrát]

 On Dec. 18, 2014, 8:47 a.m., Martin Gräßlin wrote:
  find-modules/Findepoxy.cmake, line 14
  https://git.reviewboard.kde.org/r/121575/diff/1/?file=333638#file333638line14
 
  I just need to point out that I consider epoxy as a bad dependency for 
  usage in a cross platform library (like now proposed in kdeclarative) if it 
  has a huge if not win32 block.
 
 Marco Martin wrote:
 ah, doesn't support windows at all? even for libplasma isn't that good 
 then.
 how much boilerplate would be needed to not use it for the graph thing?

There are some remarks about win32 at https://github.com/anholt/libepoxy and 
their release page contains a win32 version, so I think there's at least some 
upstream support. The if not block Martin mentioned exists in the 
CMakeLists.txt.


- Jan


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


On Dec. 17, 2014, 10:35 a.m., Marco Martin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121575/
 ---
 
 (Updated Dec. 17, 2014, 10:35 a.m.)
 
 
 Review request for KDE Frameworks, kwin and Martin Gräßlin.
 
 
 Repository: extra-cmake-modules
 
 
 Description
 ---
 
 Both Plasma and KWin now depend from the epoxy opengl library.
 So would be better to have the necessary cmake stuff in ecm instead of having 
 it copied in the two repos.
 This is the file coming from KWin
 
 
 Diffs
 -
 
   find-modules/Findepoxy.cmake PRE-CREATION 
 
 Diff: https://git.reviewboard.kde.org/r/121575/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Marco Martin
 


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

Re: OSX/CI: kio fails to build on branch master

[Jan Kundrát]

On Saturday, 13 December 2014 13:55:25 CEST, Marko Käning wrote:

Any idea what’g going on with this XML file?


One option is to run make with VERBOSE=1 (either asn an env var, or as an 
argument to make). That way, the output will contain information on what 
commands are executed, and you should be able to run that single failing 
command by hand and/or with extra options to see where the problem is.


Hope this helps,
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: plasma-framework now getting early CI feedback on changes within Gerrit

[Jan Kundrát]

On Tuesday, 9 December 2014 19:44:19 CEST, Jan Kundrát wrote:
I've activated CI checking for changes proposed to 
plasma-framework (kio is waiting for a review of two patches 
which improve test stability).


KIO is now getting this, too. Sorry for the mail noise associated with 
re-checks.


With kind regards,
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: KIO's KDirListerTest::testRefreshRootItem on RHEL7 and XFS

[Jan Kundrát]

After applying [1] and [2], I don't see any more test failures -- reviews 
are appreciated.


With kind regards,
Jan

[1] https://gerrit.vesnicky.cesnet.cz/r/#/c/204/3
[2] https://gerrit.vesnicky.cesnet.cz/r/#/c/208/6

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

plasma-framework now getting early CI feedback on changes within Gerrit

[Jan Kundrát]

Hi,
I've activated CI checking for changes proposed to plasma-framework (kio is 
waiting for a review of two patches which improve test stability).


The build environment is different from the one at build.k.o, but the 
scripts are more or less the same. Both the default build/test variant and 
the one without X11 are performed. The important differences from Jenkins 
are that the jobs run within Centos5 VMs, and that it uses EPEL's Qt 5.3.2 
built in release mode and system packages of non-KDE software in general. 
We're using a git snapshot of cmake, though.


If a build succeeds, the change under review will get a Verified +1 vote 
from the CI system. If it fails, you'll get a -1, and at that point you 
should look at the result of the job to see what failed. If it's a CI 
fluke, please let me know. If it looks like a temporary problem, add a 
comment which starts with a word recheck through Gerrit, and the tests 
will be re-run.


If the problem is more serious or cannot be fixed by doing a recheck or 
two, any KDE developer can remove the KDE Zuul CI from the list of 
reviewers (it gets added back automatically on each change of the patch). 
It is then up to you to give a Verified+1 score, similar to how you would 
do a Code-Review+2. A change cannot be submitted until it gets at least one 
Verified+1 and exactly zero Verified-1 votes. Of course you still have that 
option of pushing directly into git.k.o, Gerrit will get what you mean.


With kind regards,
Jan

[1] https://gerrit.vesnicky.cesnet.cz/r/209

--
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: KIO's KDirListerTest::testRefreshRootItem on RHEL7 and XFS

[Jan Kundrát]

It looks like there are more failing tests, and in a non-deterministic 
manner. An example of a failing one is [1] while I've also seen all of them 
succeeding, [2].


Are you guys sure that these tests are really doing the right thing and 
that there are no failures when you run them a thousand times in a while 
loop?


With kind regards,
Jan

[1] 
http://ci-logs.kde.flaska.net/06/206/3/check/check-kf5qt5-generic-test-el7/297d450/shell_output.log
[2] 
http://ci-logs.kde.flaska.net/04/204/2/check/check-kf5qt5-generic-test-el7/ed72480/shell_output.log


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

KIO's KDirListerTest::testRefreshRootItem on RHEL7 and XFS

[Jan Kundrát]

Hi,
there's one test in KIO which keeps failing when I run it inside my CI 
environment (a RHEL7 VM with XFS).


Take a look at [1], the /tmp/kdirlistertest-dIp2zR/subdir's mtime and atime 
are getting bumped by one second. The patch which introduces this debug 
output is at [2].


I will admit that I'm not sure what that test is actually testing -- I 
would have expected some sort of file watcher in the background, but I'm 
not sure with the manual calls to org::kde::KDirNotify::emitXYZ. Anyway, 
the comments on lines 401-402 seems to indicate that the sort of behavior 
I'm seeing is semi-expected.


What can I do to fix the test failure I'm seeing? Why is the change of 
/tmp/kdirlistertest-dIp2zR/subdir encountered too early in this test?


With kind regards,
Jan

[1] 
http://ci-logs.kde.flaska.net/06/206/2/check/check-kf5qt5-generic-test-el7/95ea34f/shell_output.log
[2] 
http://quickgit.kde.org/?p=kio.gita=commith=55f949798a99158d06d030186204fc0f19365b4a


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

Debugging failures in KIO when using custom CI environment

[Jan Kundrát]

Hi,
I'm working on a testing setup which plugs into Gerrit to add info whether 
a proposed change still builds and tests continue to pass. This is using a 
modified version of KDE's own Jenkins' CI scripts, but the environment is 
very likely much different. It runs within a sanitized environment on a 
CentOS7 VM using Qt 5.3.2 from EPEL.


I'm seeing quite a few timeouts during the execution of these tests. A full 
build log is at [1], the failures start at 2014-12-06 14:48:57,448.


This is how a backtrace from a debugger attached to one of the stuck tests 
looked like:


(gdb) bt
#0  0x7f2c668eba4d in poll () from /lib64/libc.so.6
#1  0x7f2c629c8dd4 in g_main_context_iterate.isra.22 () from 
/lib64/libglib-2.0.so.0
#2  0x7f2c629c8efc in g_main_context_iteration () from 
/lib64/libglib-2.0.so.0
#3  0x7f2c676d333b in 
QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) 
() from /lib64/libQt5Core.so.5
#4  0x7f2c676776fb in 
QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from 
/lib64/libQt5Core.so.5
#5  0x7f2c67d7611c in KJob::exec (this=0x1aa30f0) at 
/home/turbo-hipster/git/3d0386f34adf/kcoreaddons/src/lib/jobs/kjob.cpp:188
#6  0x00407e36 in MkpathJobTest::shouldCreateOneDirectory 
(this=0x7fffc9943e80) at 
/home/turbo-hipster/git/0c50b62535fe/kio/autotests/mkpathjobtest.cpp:68
#7  0x00406888 in MkpathJobTest::qt_static_metacall 
(_o=0x7fffc9943e80, _c=QMetaObject::InvokeMetaMethod, _id=3, 
_a=0x7fffc9943440) at 
/home/turbo-hipster/jobs/0c50b62535fe/01/201/1/check/check-kf5qt5-generic-test-el7/b840c48/build/autotests/mkpathjobtest.moc:100
#8  0x7f2c676840fc in QMetaMethod::invoke(QObject*, Qt::ConnectionType, 
QGenericReturnArgument, QGenericArgument, QGenericArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument) 
const ()

  from /lib64/libQt5Core.so.5
#9  0x7f2c676885cc in QMetaObject::invokeMethod(QObject*, char const*, 
Qt::ConnectionType, QGenericReturnArgument, QGenericArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, 
QGenericArgument) ()

  from /lib64/libQt5Core.so.5
#10 0x7f2c6881eff2 in QTest::qInvokeTestMethod(char const*, char 
const*) () from /lib64/libQt5Test.so.5
#11 0x7f2c6881fa48 in QTest::qExec(QObject*, int, char**) () from 
/lib64/libQt5Test.so.5
#12 0x004067d9 in main (argc=1, argv=0x7fffc9943fa8) at 
/home/turbo-hipster/git/0c50b62535fe/kio/autotests/mkpathjobtest.cpp:145


For comparison, the tests went much further when I simply used a `su -` 
environment to run them, see [2]. (That was also against a different 
commit, but I don't see any relevant changes in there.)


- Do you see some obvious problem in what I'm doing?

With kind regards,
Jan

[1] 
http://ci-logs.kde.flaska.net/01/201/1/check/check-kf5qt5-generic-test-el7/b840c48/shell_output.log

[2] http://ci-logs.kde.flaska.net/manual/rebuilddep/0022/shell_output.log

--
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: Debugging failures in KIO when using custom CI environment

[Jan Kundrát]

It seems that the problem is related to how a kioslave is launched along 
with using different installation dirs. Here's what got me to the right 
path:


13032 
execve(/home/turbo-hipster/target/el7-x86_64-gcc/kf5-qt5/frameworks/kio/inst/lib64/libexec/kf5/kioslave, 
[/home/turbo-hipster/target/el7-x..., 
/home/turbo-hipster/jobs/7f0e670..., file, , 
local:/tmp/runtime-turbo-hipster...], [/* 41 vars */]) = -1 ENOENT (No 
such file or directory)


There was a bug in error checking within kioslave, see [1] for a fixes.

The real problem with CI is that the CI environment configures the build 
with an expected install prefix being 
/home/turbo-hipster/target/el7-x86_64-gcc/kf5-qt5/frameworks/kio/inst, but 
the actual installation goes somewhere else, into a temporary directory. 
This problem is masked by Jenkins on build.kde.org because it will always 
attempt to deploy the build to that directory and rsync to some shared 
depot afterwards. The checks of _proposed_ changes within Gerrit/Zuul, 
however, do not perform the rsync step, and that means that the kioslave 
executable was there.


- I have stuff to fix in the CI environment.

With kind regards,
Jan

[1] https://gerrit.vesnicky.cesnet.cz/r/202

--
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: Gerrit available for trial

[Jan Kundrát]

On Saturday, 11 October 2014 11:57:20 CEST, Kevin Krammer wrote:

I am not opposed but I think just the new ones would be sufficient.
If one is interested in the proceedings of a specific request it is easy 
enough to add oneselves as a reviewer.


It also makes the new notification stand out since it is the one being 
delivered to the list while the following ones are delivered to 
each reviewer directly.


I've set up Gerrit so that the mailing list will receive exactly one mail 
when a new change is uploaded (and not for new versions).


The other settings which uses `git blame` and Cc-es authors of the changed 
lines directly is still active.


With kind regards,
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: Gerrit available for trial

[Jan Kundrát]

On Friday, 10 October 2014 22:57:26 CEST, David Faure wrote:

However I can't add the KDE contributors that I want, to the request.
They all have a KDE identity account, but obviously didn't create a gerrit 
account yet.


Hi David, all KDE developers are now available in Gerrit, so you can start 
adding them to review requests now.


They will still have to upload their SSH keys once they want to start 
pushing stuff through Gerrit.


With kind regards,
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: Gerrit available for trial

[Jan Kundrát]

On Friday, 10 October 2014 22:57:26 CEST, David Faure wrote:

Is there any chance we could import all of KDE identity into gerrit?
Otherwise that doesn't really make it usable, until everyone has created an
account there - which won't happen. I think with reviewboard we can add
anyone with a KDE identity account, right?


I see a slightly hackish way of doing this. What I'm unsure about is 
whether it is going to break some stuff that I don't know about yet. I've 
asked on the Gerrit ML. If it's possible, I'll be happy to bulk-create 
accounts for all developers.


With kind regards,
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: Gerrit available for trial

[Jan Kundrát]

On Friday, 10 October 2014 23:38:37 CEST, David Faure wrote:
Another issue: could all incoming review requests for kio (and all other 
frameworks in the future, except plasma-framework which has a 
dedicated list) 
be sent to kde-frameworks-devel? I don't see a mail with my request there.


Sure, that can be done, too.

How noisy would you like Gerrit to be? Just new changes? New revisions, 
too? What about comments/reviews? See [1] for possible options. I'll also 
have to chat with Ben to make sure that the e-mails do not end up in the 
moderation queue.


Cheers,
Jan

[1] 
https://gerrit-review.googlesource.com/Documentation/user-notify.html#project


--
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: What's qt5-stable on build.kde.org

[Jan Kundrát]

On Thursday, 18 September 2014 10:10:41 CEST, Ben Cooksley wrote:

This would still apply even after the implementation of new scheme for
dependencies and other build metadata.


Where do I learn about these new features?

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: Gerrit available for trial

[Jan Kundrát]

Hi folks,
we're trying to document how to work with Gerrit within KDE at [1]. If you 
can make that page better, please go ahead.


With kind regards,
Jan

[1] https://techbase.kde.org/Development/Gerrit

--
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: Review Request 109551: port KPtyProcess to QProcess

[Jan Kundrát]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109551/#review29432
---



kpty/tests/kptyprocesstest.h
http://git.reviewboard.kde.org/r/109551/#comment21974

Why are these commented out instead of being removed?


- Jan Kundrát


On March 17, 2013, 4:44 p.m., Martin Tobias Holmedahl Sandsmark wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/109551/
 ---
 
 (Updated March 17, 2013, 4:44 p.m.)
 
 
 Review request for KDE Frameworks, kdelibs and David Faure.
 
 
 Description
 ---
 
 Just a simple port of KPtyProcess away from using KProcess.
 
 
 Diffs
 -
 
   kpty/kptyprocess.h 5e0df96 
   kpty/kptyprocess.cpp 015a58c 
   kpty/tests/kptyprocesstest.h 64bded0 
   kpty/tests/kptyprocesstest.cpp 04990a0 
 
 Diff: http://git.reviewboard.kde.org/r/109551/diff/
 
 
 Testing
 ---
 
 builds and tests pass.
 
 
 Thanks,
 
 Martin Tobias Holmedahl Sandsmark
 


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