Re: OSX/CI: ark fails to build on branch frameworks
On Tue, Sep 16, 2014 at 11:26 AM, Bhushan Shah bhus...@gmail.com wrote: is working fine, will correct it in little time.. Solved in http://commits.kde.org/ark/cf4c338216908f7b50fc1c36be753cb34b7daecc -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: OSX/CI: ark fails to build on branch frameworks
Thanks Bushan, On 16 Sep 2014, at 08:00 , Bhushan Shah bhus...@gmail.com wrote: Solved in http://commits.kde.org/ark/cf4c338216908f7b50fc1c36be753cb34b7daecc indeed, it did! :-) Another example how useful building on a different toolchain can be!!! Greets, Marko P.S.: I hope you could proceed with figuring out why plasma-mediacenter-qt5 is not locating taglib correctly at the moment. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : kwindowsystem_master_qt5 » All,LINBUILDER #98
See http://build.kde.org/job/kwindowsystem_master_qt5/Variation=All,label=LINBUILDER/98/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120213: Add support for protocols to NETWinInfo
On Sept. 15, 2014, 8:34 nachm., Thomas Lübking wrote: src/netwm.cpp, line 4630 https://git.reviewboard.kde.org/r/120213/diff/1/?file=312330#file312330line4630 Tarzan speech. Consider: - TakeFocusProtocol - Protocol::TakeFocus Martin Gräßlin wrote: we are (to my understanding) not allowed to use the enum class from C++11. As netwm_def.h is shared between the implementations I cannot even argument with but it's not compiled on Windows. So I'll switch to the TakeFocusProtocol approach. You could use a nested namespace, but i'm absolutely fine with TakeFocusProtocol. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120213/#review66605 --- On Sept. 16, 2014, 5:55 vorm., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120213/ --- (Updated Sept. 16, 2014, 5:55 vorm.) Review request for KDE Frameworks. Repository: kwindowsystem Description --- NETWinInfo is now able to read all known protocols set on WM_PROTOCOLS property and provides the set protocols as flags. So far the following protocols are supported: * WM_TAKE_FOCUS (ICCCM 4.1.2.7) * WM_DELETE_WINDOW (ICCCM 4.1.2.7) * _NET_WM_SYNC_REQUEST (EWMH) * _NET_WM_PING (EWMH) * _NET_WM_CONTEXT_HELP (KDE specific extension to EWMH) CHANGELOG: NETWinInfo provides convenient wrapper for WM_PROTOCOLS. Diffs - autotests/netwininfotestclient.cpp 7d941f4b32a546c8284ab81995f594cd9e69617e src/netwm.h 436ad2fd449b48a36d3bb15754f7c8c64f52c8dd src/netwm.cpp 1431cf6bae605050e2e86f7ca60357ddb7736d32 src/netwm_def.h 12abfff03af5b81a60ec03a5366b6ff0b95d35d0 src/netwm_p.h a586450211846af464c9014f586e14b0e808cd75 Diff: https://git.reviewboard.kde.org/r/120213/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 120213: Add support for protocols to NETWinInfo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120213/#review66633 --- Ship it! Ship It! - Thomas Lübking On Sept. 16, 2014, 5:55 vorm., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120213/ --- (Updated Sept. 16, 2014, 5:55 vorm.) Review request for KDE Frameworks. Repository: kwindowsystem Description --- NETWinInfo is now able to read all known protocols set on WM_PROTOCOLS property and provides the set protocols as flags. So far the following protocols are supported: * WM_TAKE_FOCUS (ICCCM 4.1.2.7) * WM_DELETE_WINDOW (ICCCM 4.1.2.7) * _NET_WM_SYNC_REQUEST (EWMH) * _NET_WM_PING (EWMH) * _NET_WM_CONTEXT_HELP (KDE specific extension to EWMH) CHANGELOG: NETWinInfo provides convenient wrapper for WM_PROTOCOLS. Diffs - autotests/netwininfotestclient.cpp 7d941f4b32a546c8284ab81995f594cd9e69617e src/netwm.h 436ad2fd449b48a36d3bb15754f7c8c64f52c8dd src/netwm.cpp 1431cf6bae605050e2e86f7ca60357ddb7736d32 src/netwm_def.h 12abfff03af5b81a60ec03a5366b6ff0b95d35d0 src/netwm_p.h a586450211846af464c9014f586e14b0e808cd75 Diff: https://git.reviewboard.kde.org/r/120213/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: Broken KWindowInfoX11Test::testActivities on CI system
Martin GräßlinOn Monday 15 September 2014 09:44:59 wrote: Hi Ivan, could you please have a look at KWindowInfoX11Test::testActivities. The unit test fails on the CI system and also locally with a setup similar to CI system (passes with KWin, though). To get a clean setup ensure to have an Xvfb running and an openbox on that Xvfb. The unit test looks somewhat wrong to me. E.g. there is an initial activity set which doesn't fit the NETWinInfo code. To me it looks like the test is dependent on behavior of KWin. I just pushed a change which skips the test if the WM doesn't announce support for Activities. This turned KWindowSystem green again. That's obviously not a proper fix and I still want to have it clarified how KWindowSystem and the tests are supposed to function if activities are not supported by the wm. As a side note: not even KWin announces that it supports activities (review request pending). This was overall quite a mess :-( Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120217: KWindowInfo::state can map urgency to NET::DemandsAttention
On Sept. 15, 2014, 10:28 nachm., Thomas Lübking wrote: If we merge, we should imo merge in NetWinInfo - having the same function return different values in NetWinInfo and KWindowInfo feels wrong. Martin Gräßlin wrote: I considered it, but decided against it as I consider NETWinInfo to be a level lower to X and exposing it directly. KWindowInfo on the other hand is a convenient wrapper. extra function ::demandsAttention()? - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120217/#review66618 --- On Sept. 15, 2014, 1:29 nachm., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120217/ --- (Updated Sept. 15, 2014, 1:29 nachm.) Review request for KDE Frameworks and kwin. Repository: kwindowsystem Description --- If WM2Urgency is passed to the ctor of KWindowInfo, ::state() checks the urgency state is set and adds NET::DemandsAttention. This allows to easily check whether the window demands attention either through EWMH or ICCCM. The change does not affect existing code as one has to explicitly pass WM2Urgency and this one is new in 5.3, too. This change only affects platform X11. CHANGELOG: KWindowInfo::state can map urgency to NET::DemandsAttention Diffs - autotests/kwindowinfox11test.cpp 3ff6a49447a99d9afdabe6c96361b276083de525 src/kwindowinfo.h b00e115f293231b661934d20e97be4d186f679de src/kwindowinfo_x11.cpp 2a32692a0f664d6a9884e6d1a1209e88e02944ec Diff: https://git.reviewboard.kde.org/r/120217/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 120217: KWindowInfo::state can map urgency to NET::DemandsAttention
On Sept. 16, 2014, 12:28 a.m., Thomas Lübking wrote:
If we merge, we should imo merge in NetWinInfo - having the same function
return different values in NetWinInfo and KWindowInfo feels wrong.
Martin Gräßlin wrote:
I considered it, but decided against it as I consider NETWinInfo to be a
level lower to X and exposing it directly. KWindowInfo on the other hand is a
convenient wrapper.
Thomas Lübking wrote:
extra function ::demandsAttention()?
as in
bool KWindoInfo::demandsAttention() const {
return hasState(NET::DemandsAttention) || info-urgency();
}
- Martin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120217/#review66618
---
On Sept. 15, 2014, 3:29 p.m., Martin Gräßlin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120217/
---
(Updated Sept. 15, 2014, 3:29 p.m.)
Review request for KDE Frameworks and kwin.
Repository: kwindowsystem
Description
---
If WM2Urgency is passed to the ctor of KWindowInfo, ::state() checks
the urgency state is set and adds NET::DemandsAttention. This allows
to easily check whether the window demands attention either through
EWMH or ICCCM.
The change does not affect existing code as one has to explicitly
pass WM2Urgency and this one is new in 5.3, too.
This change only affects platform X11.
CHANGELOG: KWindowInfo::state can map urgency to NET::DemandsAttention
Diffs
-
autotests/kwindowinfox11test.cpp 3ff6a49447a99d9afdabe6c96361b276083de525
src/kwindowinfo.h b00e115f293231b661934d20e97be4d186f679de
src/kwindowinfo_x11.cpp 2a32692a0f664d6a9884e6d1a1209e88e02944ec
Diff: https://git.reviewboard.kde.org/r/120217/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 120217: KWindowInfo::state can map urgency to NET::DemandsAttention
On Sept. 15, 2014, 10:28 nachm., Thomas Lübking wrote:
If we merge, we should imo merge in NetWinInfo - having the same function
return different values in NetWinInfo and KWindowInfo feels wrong.
Martin Gräßlin wrote:
I considered it, but decided against it as I consider NETWinInfo to be a
level lower to X and exposing it directly. KWindowInfo on the other hand is a
convenient wrapper.
Thomas Lübking wrote:
extra function ::demandsAttention()?
Martin Gräßlin wrote:
as in
bool KWindoInfo::demandsAttention() const {
return hasState(NET::DemandsAttention) || info-urgency();
}
Yes. I simply prospect confusion if the very same signature and return function
in NetWinInfo and KWindowInfo behave differently.
(It would probably be different if NetWinInfo would strictly only handle NETWM,
but there're various icccm related functions in it as well)
- Thomas
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120217/#review66618
---
On Sept. 15, 2014, 1:29 nachm., Martin Gräßlin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120217/
---
(Updated Sept. 15, 2014, 1:29 nachm.)
Review request for KDE Frameworks and kwin.
Repository: kwindowsystem
Description
---
If WM2Urgency is passed to the ctor of KWindowInfo, ::state() checks
the urgency state is set and adds NET::DemandsAttention. This allows
to easily check whether the window demands attention either through
EWMH or ICCCM.
The change does not affect existing code as one has to explicitly
pass WM2Urgency and this one is new in 5.3, too.
This change only affects platform X11.
CHANGELOG: KWindowInfo::state can map urgency to NET::DemandsAttention
Diffs
-
autotests/kwindowinfox11test.cpp 3ff6a49447a99d9afdabe6c96361b276083de525
src/kwindowinfo.h b00e115f293231b661934d20e97be4d186f679de
src/kwindowinfo_x11.cpp 2a32692a0f664d6a9884e6d1a1209e88e02944ec
Diff: https://git.reviewboard.kde.org/r/120217/diff/
Testing
---
Thanks,
Martin Gräßlin
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 120228: Support Gerrit in the fancy header style
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120228/ --- Review request for KDE Frameworks and KDEPIM. Repository: kdepim Description --- If the email is from Gerrit the following information is added to the header: * message type * url to change * change-id as link test for the url I'm not sure which is the right branch for such a change to go in. Diffs - messageviewer/header/fancyheaderstyle.cpp f58f07bda9b750aed30795644bdba5175f5edd56 messageviewer/header/headerstrategy_p.h 14951ea792ee13e468ff5a047c13dc94b78d6bc2 Diff: https://git.reviewboard.kde.org/r/120228/diff/ Testing --- File Attachments Example for a new change https://git.reviewboard.kde.org/media/uploaded/files/2014/09/16/60cdd1c0-d911-49a7-b184-cbb424d45ae1__gerrit-fancy-.png 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 120228: Support Gerrit in the fancy header style
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120228/#review66639 --- It adds a new string, please ask kde-i18n-doc about an exception if everyone else agreees 4.14 is the right branch to commit (i do think it makes sense there) - Albert Astals Cid On set. 16, 2014, 7:10 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120228/ --- (Updated set. 16, 2014, 7:10 a.m.) Review request for KDE Frameworks and KDEPIM. Repository: kdepim Description --- If the email is from Gerrit the following information is added to the header: * message type * url to change * change-id as link test for the url I'm not sure which is the right branch for such a change to go in. Diffs - messageviewer/header/fancyheaderstyle.cpp f58f07bda9b750aed30795644bdba5175f5edd56 messageviewer/header/headerstrategy_p.h 14951ea792ee13e468ff5a047c13dc94b78d6bc2 Diff: https://git.reviewboard.kde.org/r/120228/diff/ Testing --- File Attachments Example for a new change https://git.reviewboard.kde.org/media/uploaded/files/2014/09/16/60cdd1c0-d911-49a7-b184-cbb424d45ae1__gerrit-fancy-.png 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 120217: KWindowInfo::state can map urgency to NET::DemandsAttention
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120217/ --- (Updated Sept. 16, 2014, 9:48 a.m.) Status -- This change has been discarded. Review request for KDE Frameworks and kwin. Repository: kwindowsystem Description --- If WM2Urgency is passed to the ctor of KWindowInfo, ::state() checks the urgency state is set and adds NET::DemandsAttention. This allows to easily check whether the window demands attention either through EWMH or ICCCM. The change does not affect existing code as one has to explicitly pass WM2Urgency and this one is new in 5.3, too. This change only affects platform X11. CHANGELOG: KWindowInfo::state can map urgency to NET::DemandsAttention Diffs - autotests/kwindowinfox11test.cpp 3ff6a49447a99d9afdabe6c96361b276083de525 src/kwindowinfo.h b00e115f293231b661934d20e97be4d186f679de src/kwindowinfo_x11.cpp 2a32692a0f664d6a9884e6d1a1209e88e02944ec Diff: https://git.reviewboard.kde.org/r/120217/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 120040: Install kdesu under bin
On Sept. 2, 2014, 6:37 p.m., Marco Martin wrote: I'm a bit worried by the multitude of user and distro specific scripts that rely on kdesu being present :/ Marco Martin wrote: to me either way it gets fixed i'm ok. the other option is to keep it called kdesu, so it wouldn't be coinstallable so distributions would need to make kdesu a package of its own, alternative with the kde4 kdesu, but it may look even more problematic to me David Faure wrote: Scripts will just have to be updated, just like scripts calling kioclient4, kde4-config, kstart, kdecp, kbuildsycoca4 and so many other things. We can't have both source-compat-for-scripts and co-installability. It's one or the other. Any updates on that? is this the right approach or should i try something else? - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120040/#review65734 --- On Sept. 2, 2014, 6:27 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120040/ --- (Updated Sept. 2, 2014, 6:27 p.m.) Review request for KDE Frameworks and Plasma. Repository: kde-cli-tools Description --- this is a part of adressing the bug https://bugs.kde.org/show_bug.cgi?id=338755 https://bugs.kde.org/show_bug.cgi?id=338756 in kde4 kdesu was installed under bin, and should still, being something that should be invokable but renames it to kdesu5, for coinstallability reasons therefore, kio/src/core/desktopexecparser.cpp should be modified to search for kdesu5 instead of kdesu Diffs - kdesu/CMakeLists.txt 2a70831 Diff: https://git.reviewboard.kde.org/r/120040/diff/ Testing --- Thanks, Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kwindowsystem_master_qt5 » All,LINBUILDER #99
See http://build.kde.org/job/kwindowsystem_master_qt5/Variation=All,label=LINBUILDER/99/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120040: Install kdesu under bin
On Sept. 2, 2014, 6:54 p.m., Hrvoje Senjan wrote: in kde4 kdesu was installed under bin it was actually also in libexec. just that KStandardDirs::findExe() looked in libexec paths, QStandardPaths doesn't... right, it seems on both places here, but is probably a distro thing. Any idea of a way to find stuff under libexec on kf5? in other places the path is burned in in a define set by cmake, but that's probably not flexible enough - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120040/#review65738 --- On Sept. 2, 2014, 6:27 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120040/ --- (Updated Sept. 2, 2014, 6:27 p.m.) Review request for KDE Frameworks and Plasma. Repository: kde-cli-tools Description --- this is a part of adressing the bug https://bugs.kde.org/show_bug.cgi?id=338755 https://bugs.kde.org/show_bug.cgi?id=338756 in kde4 kdesu was installed under bin, and should still, being something that should be invokable but renames it to kdesu5, for coinstallability reasons therefore, kio/src/core/desktopexecparser.cpp should be modified to search for kdesu5 instead of kdesu Diffs - kdesu/CMakeLists.txt 2a70831 Diff: https://git.reviewboard.kde.org/r/120040/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: Review Request 120040: Install kdesu under bin
On Sept. 2, 2014, 6:54 p.m., Hrvoje Senjan wrote: in kde4 kdesu was installed under bin it was actually also in libexec. just that KStandardDirs::findExe() looked in libexec paths, QStandardPaths doesn't... Marco Martin wrote: right, it seems on both places here, but is probably a distro thing. Any idea of a way to find stuff under libexec on kf5? in other places the path is burned in in a define set by cmake, but that's probably not flexible enough Actually it appears to me that it wasn't in bin for kde4, some distros just worked around that because users where whining. That being said, I think at this point moving it bin would be counterproductive as users really should use pkexec as it is cross-desktop, cross-distro (mind kdesudo on kubuntu for example) and provides meaningful workspace integration through the relevant polkit-agent gui. In fact at the kubuntu/debian bof at akademy we were talking about proposing exactly that for all our usage of kdesu as to possibly retry the entire bugger in favor of pkexec with kf6. - Harald --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120040/#review65738 --- On Sept. 2, 2014, 6:27 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120040/ --- (Updated Sept. 2, 2014, 6:27 p.m.) Review request for KDE Frameworks and Plasma. Repository: kde-cli-tools Description --- this is a part of adressing the bug https://bugs.kde.org/show_bug.cgi?id=338755 https://bugs.kde.org/show_bug.cgi?id=338756 in kde4 kdesu was installed under bin, and should still, being something that should be invokable but renames it to kdesu5, for coinstallability reasons therefore, kio/src/core/desktopexecparser.cpp should be modified to search for kdesu5 instead of kdesu Diffs - kdesu/CMakeLists.txt 2a70831 Diff: https://git.reviewboard.kde.org/r/120040/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: Review Request 120213: Add support for protocols to NETWinInfo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120213/ --- (Updated Sept. 16, 2014, 8:20 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kwindowsystem Description --- NETWinInfo is now able to read all known protocols set on WM_PROTOCOLS property and provides the set protocols as flags. So far the following protocols are supported: * WM_TAKE_FOCUS (ICCCM 4.1.2.7) * WM_DELETE_WINDOW (ICCCM 4.1.2.7) * _NET_WM_SYNC_REQUEST (EWMH) * _NET_WM_PING (EWMH) * _NET_WM_CONTEXT_HELP (KDE specific extension to EWMH) CHANGELOG: NETWinInfo provides convenient wrapper for WM_PROTOCOLS. Diffs - autotests/netwininfotestclient.cpp 7d941f4b32a546c8284ab81995f594cd9e69617e src/netwm.h 436ad2fd449b48a36d3bb15754f7c8c64f52c8dd src/netwm.cpp 1431cf6bae605050e2e86f7ca60357ddb7736d32 src/netwm_def.h 12abfff03af5b81a60ec03a5366b6ff0b95d35d0 src/netwm_p.h a586450211846af464c9014f586e14b0e808cd75 Diff: https://git.reviewboard.kde.org/r/120213/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
Jenkins build is still unstable: kwindowsystem_master_qt5 » All,LINBUILDER #100
See http://build.kde.org/job/kwindowsystem_master_qt5/Variation=All,label=LINBUILDER/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is still unstable: kwindowsystem_master_qt5 » All,LINBUILDER #101
See http://build.kde.org/job/kwindowsystem_master_qt5/Variation=All,label=LINBUILDER/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : kwindowsystem_master_qt5 » All,LINBUILDER #102
See http://build.kde.org/job/kwindowsystem_master_qt5/Variation=All,label=LINBUILDER/102/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
What's qt5-stable on build.kde.org
Hi all, I just had a little problem with a new autotest for kwindowsystem which passed on my setup, but failed on build.kde.org. It turned out that it's missing an xcb_flush(QX11Info::connection()) before blocking in the event loop. I fixed this problem in Qt, so I'm wondering: which version is used on the CI system? I couldn't find any information on it by myself - neither in the build metadata nor in the jobs listed on build.kde.org. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: desktoptojson man page
On 2014-09-15, Alexander Richardson arichardson@gmail.com wrote: However, is this even possible? Building manpages seems to require KDocTools and kcoreaddons is a tier1 framework which would make this impossible. Do we really need a manpage for it? It seems to me that it is only used in cmake code Or rewrite the man page in troff directly. /Sune ___ 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
On Tue, Sep 16, 2014 at 9:12 PM, Martin Gräßlin mgraess...@kde.org wrote: Hi all, Hi Martin, I just had a little problem with a new autotest for kwindowsystem which passed on my setup, but failed on build.kde.org. It turned out that it's missing an xcb_flush(QX11Info::connection()) before blocking in the event loop. I fixed this problem in Qt, so I'm wondering: which version is used on the CI system? I couldn't find any information on it by myself - neither in the build metadata nor in the jobs listed on build.kde.org. Please see http://build.kde.org/job/qt5_stable_qt5/ This is shown on the External Deps view. You will have to review the actual build log to find out the revision we built though. Note that we use the combined qt/qt5.git repository so if the Qt CI system is broken again it may be behind again. Cheers Martin Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: What's qt5-stable on build.kde.org
On Tuesday 16 September 2014 21:17:37 Ben Cooksley wrote: On Tue, Sep 16, 2014 at 9:12 PM, Martin Gräßlin mgraess...@kde.org wrote: Hi all, Hi Martin, I just had a little problem with a new autotest for kwindowsystem which passed on my setup, but failed on build.kde.org. It turned out that it's missing an xcb_flush(QX11Info::connection()) before blocking in the event loop. I fixed this problem in Qt, so I'm wondering: which version is used on the CI system? I couldn't find any information on it by myself - neither in the build metadata nor in the jobs listed on build.kde.org. Please see http://build.kde.org/job/qt5_stable_qt5/ Error 404 This is shown on the External Deps view. it doesn't list such a job. There's a qt5_master_qt5 and a qt_stable which is documented as building Qt 4.8. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: What's qt5-stable on build.kde.org
On Tue, Sep 16, 2014 at 9:22 PM, Martin Gräßlin mgraess...@kde.org wrote: On Tuesday 16 September 2014 21:17:37 Ben Cooksley wrote: On Tue, Sep 16, 2014 at 9:12 PM, Martin Gräßlin mgraess...@kde.org wrote: Hi all, Hi Martin, I just had a little problem with a new autotest for kwindowsystem which passed on my setup, but failed on build.kde.org. It turned out that it's missing an xcb_flush(QX11Info::connection()) before blocking in the event loop. I fixed this problem in Qt, so I'm wondering: which version is used on the CI system? I couldn't find any information on it by myself - neither in the build metadata nor in the jobs listed on build.kde.org. Please see http://build.kde.org/job/qt5_stable_qt5/ Error 404 I wrote this a bit too quickly. The correct url is http://build.kde.org/view/External_Deps/job/qt5_master_qt5/ What the system means by stable in the output is that is the branch that it should theoretically be building against. This information is drawn from the build metadata available to it. It has no correspondence with the job name. In the case of Qt 5, this information is maintained in the CI scripts own files. This is shown on the External Deps view. it doesn't list such a job. There's a qt5_master_qt5 and a qt_stable which is documented as building Qt 4.8. Cheers Martin Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Re: What's qt5-stable on build.kde.org
On Tuesday 16 September 2014 21:23:54 Ben Cooksley wrote: I wrote this a bit too quickly. The correct url is http://build.kde.org/view/External_Deps/job/qt5_master_qt5/ What the system means by stable in the output is that is the branch that it should theoretically be building against. This information is drawn from the build metadata available to it. It has no correspondence with the job name. In the case of Qt 5, this information is maintained in the CI scripts own files. thanks, that explains it. From the latest build log: Branch jenkins set up to track remote branch stable from origin. and the stable branch seems to no longer being updated on upstream's side. qtbase is set to 8fa9121 according to build's output. This is older than the patch I got into Qt 5. Maybe it would be better to track the 5.3 branch instead? Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Re: What's qt5-stable on build.kde.org
On Tue, Sep 16, 2014 at 9:45 PM, Martin Gräßlin mgraess...@kde.org wrote: On Tuesday 16 September 2014 21:23:54 Ben Cooksley wrote: I wrote this a bit too quickly. The correct url is http://build.kde.org/view/External_Deps/job/qt5_master_qt5/ What the system means by stable in the output is that is the branch that it should theoretically be building against. This information is drawn from the build metadata available to it. It has no correspondence with the job name. In the case of Qt 5, this information is maintained in the CI scripts own files. thanks, that explains it. From the latest build log: Branch jenkins set up to track remote branch stable from origin. and the stable branch seems to no longer being updated on upstream's side. qtbase is set to 8fa9121 according to build's output. This is older than the patch I got into Qt 5. Maybe it would be better to track the 5.3 branch instead? That is a development decision. Once taken, the necessary file to adjust is the same as for all other KDE projects: logical-module-structure Cheers Martin Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120040: Install kdesu under bin
On Sept. 2, 2014, 6:54 p.m., Hrvoje Senjan wrote: in kde4 kdesu was installed under bin it was actually also in libexec. just that KStandardDirs::findExe() looked in libexec paths, QStandardPaths doesn't... Marco Martin wrote: right, it seems on both places here, but is probably a distro thing. Any idea of a way to find stuff under libexec on kf5? in other places the path is burned in in a define set by cmake, but that's probably not flexible enough Harald Sitter wrote: Actually it appears to me that it wasn't in bin for kde4, some distros just worked around that because users where whining. That being said, I think at this point moving it bin would be counterproductive as users really should use pkexec as it is cross-desktop, cross-distro (mind kdesudo on kubuntu for example) and provides meaningful workspace integration through the relevant polkit-agent gui. In fact at the kubuntu/debian bof at akademy we were talking about proposing exactly that for all our usage of kdesu as to possibly retry the entire bugger in favor of pkexec with kf6. Sorry, I did not see this review request sooner. See my attempt at fixing this bug (from KIO) here: https://git.reviewboard.kde.org/r/120185/ - Maarten --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120040/#review65738 --- On Sept. 2, 2014, 6:27 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120040/ --- (Updated Sept. 2, 2014, 6:27 p.m.) Review request for KDE Frameworks and Plasma. Repository: kde-cli-tools Description --- this is a part of adressing the bug https://bugs.kde.org/show_bug.cgi?id=338755 https://bugs.kde.org/show_bug.cgi?id=338756 in kde4 kdesu was installed under bin, and should still, being something that should be invokable but renames it to kdesu5, for coinstallability reasons therefore, kio/src/core/desktopexecparser.cpp should be modified to search for kdesu5 instead of kdesu Diffs - kdesu/CMakeLists.txt 2a70831 Diff: https://git.reviewboard.kde.org/r/120040/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: Review Request 120185: Look for kdesu in the correct location
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120185/#review66656 --- this approach is probably better than https://git.reviewboard.kde.org/r/120040/ - Marco Martin On Sept. 13, 2014, 3:59 p.m., Maarten De Meyer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120185/ --- (Updated Sept. 13, 2014, 3:59 p.m.) Review request for KDE Frameworks and David Faure. Bugs: 338755 https://bugs.kde.org/show_bug.cgi?id=338755 Repository: kio Description --- kdesu is installed in libexec/ look for it there first. I left the findExecutable search as a backup. Is looking in CMAKE_INSTALL_FULL_LIBEXECDIR correct? Or will kde-cli-tools be installed in libexec/kf5? Insert 'kdesu' at the end to show a nicer error. If we leave this part out the error is Could not launch 'root' which is somewhat correct but not as easy to figure out as Could not launch 'kdesu' Also added an unrelated QFile::decodeName() call. Diffs - src/core/config-kiocore.h.cmake 3c2e4a8 src/core/desktopexecparser.cpp 9510697 Diff: https://git.reviewboard.kde.org/r/120185/diff/ Testing --- Created .desktop file with X-KDE-SubstituteUID=true Now I can launch it as root and when I remove kdesu I got a normal error message. Thanks, Maarten De Meyer ___ 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
On Tuesday 16 September 2014 21:50:57 Ben Cooksley wrote: On Tue, Sep 16, 2014 at 9:45 PM, Martin Gräßlin mgraess...@kde.org wrote: On Tuesday 16 September 2014 21:23:54 Ben Cooksley wrote: I wrote this a bit too quickly. The correct url is http://build.kde.org/view/External_Deps/job/qt5_master_qt5/ What the system means by stable in the output is that is the branch that it should theoretically be building against. This information is drawn from the build metadata available to it. It has no correspondence with the job name. In the case of Qt 5, this information is maintained in the CI scripts own files. thanks, that explains it. From the latest build log: Branch jenkins set up to track remote branch stable from origin. and the stable branch seems to no longer being updated on upstream's side. qtbase is set to 8fa9121 according to build's output. This is older than the patch I got into Qt 5. Maybe it would be better to track the 5.3 branch instead? That is a development decision. Once taken, the necessary file to adjust is the same as for all other KDE projects: logical-module-structure Yes, there is no stable anymore upstream. 5.3 is probably a good choice for now, until 5.4 is released. Bye -- Milian Wolff m...@milianw.de http://milianw.de ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Initial standalone Plasma::Package repository
Hi all, first, brief introductionon what this is: during a Bof about scripting in applications at Akademy it occurred that some applications may be interested by the functionality provided by Plasma::Package, provided it was on a lower tier. Since I already had kindof the idea of making Package an independent framework, I started a scratch repo in which i isolated just Package (and a piece of PluginLoader, but not sure that will ultimately stay there) http://quickgit.kde.org/?p=scratch%2Fmart%2Fpackage-standalone.git the history right now would use the graft thing like other frameworks, if better, an attempt with filter-branch may be done as well. right now the dependencies are down to: * Qt5Core * Qt5 (required version = 5.2.0) * KF5Archive (required version = 5.2.0) * Gettext * PythonInterp * KF5I18n (required version = 5.2.0) * Qt5Xml (required version = 5.2.0) * KF5Config (required version = 5.2.0) * Qt5DBus (required version = 5.2.0) * KF5DBusAddons (required version = 5.2.0) * KF5Service (required version = 5.2.0) * ECM (required version = 0.0.9) * Qt5Test (required version = 5.2.0) * KF5CoreAddons some of those may even be removed still (dbus is used to trigger kbuildsycoca, but we want to eventually move this stuff out of sycoca) right now all the classes are still under the Plasma namespace, and should probably be renamed and cmakes to be cleaned up (especially because it would be used by plasma too to the two identically named classes, new and deprecated would clash) may be KPackage/KPackageStructure? (seems to clash only with an ancient KDE2 app) Another thing is the plugin loading, the sub part of PluginLoader should probably be kept, maybe in the form of KPackageTrader, that would support also api for trader queries Comments/things that should be done there? missing features? -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120185: Look for kdesu in the correct location
On Sept. 16, 2014, 10:33 a.m., Marco Martin wrote: this approach is probably better than https://git.reviewboard.kde.org/r/120040/ I think we'll need both. We still need to rename the kdesu binary, no? - Maarten --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120185/#review66656 --- On Sept. 13, 2014, 3:59 p.m., Maarten De Meyer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120185/ --- (Updated Sept. 13, 2014, 3:59 p.m.) Review request for KDE Frameworks and David Faure. Bugs: 338755 https://bugs.kde.org/show_bug.cgi?id=338755 Repository: kio Description --- kdesu is installed in libexec/ look for it there first. I left the findExecutable search as a backup. Is looking in CMAKE_INSTALL_FULL_LIBEXECDIR correct? Or will kde-cli-tools be installed in libexec/kf5? Insert 'kdesu' at the end to show a nicer error. If we leave this part out the error is Could not launch 'root' which is somewhat correct but not as easy to figure out as Could not launch 'kdesu' Also added an unrelated QFile::decodeName() call. Diffs - src/core/config-kiocore.h.cmake 3c2e4a8 src/core/desktopexecparser.cpp 9510697 Diff: https://git.reviewboard.kde.org/r/120185/diff/ Testing --- Created .desktop file with X-KDE-SubstituteUID=true Now I can launch it as root and when I remove kdesu I got a normal error message. Thanks, Maarten De Meyer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120185: Look for kdesu in the correct location
On Sept. 16, 2014, 10:33 a.m., Marco Martin wrote: this approach is probably better than https://git.reviewboard.kde.org/r/120040/ Maarten De Meyer wrote: I think we'll need both. We still need to rename the kdesu binary, no? if it goes in libexec yes, otherwise if it goes in libexec/kf5 shouldn't be necessary - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120185/#review66656 --- On Sept. 13, 2014, 3:59 p.m., Maarten De Meyer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120185/ --- (Updated Sept. 13, 2014, 3:59 p.m.) Review request for KDE Frameworks and David Faure. Bugs: 338755 https://bugs.kde.org/show_bug.cgi?id=338755 Repository: kio Description --- kdesu is installed in libexec/ look for it there first. I left the findExecutable search as a backup. Is looking in CMAKE_INSTALL_FULL_LIBEXECDIR correct? Or will kde-cli-tools be installed in libexec/kf5? Insert 'kdesu' at the end to show a nicer error. If we leave this part out the error is Could not launch 'root' which is somewhat correct but not as easy to figure out as Could not launch 'kdesu' Also added an unrelated QFile::decodeName() call. Diffs - src/core/config-kiocore.h.cmake 3c2e4a8 src/core/desktopexecparser.cpp 9510697 Diff: https://git.reviewboard.kde.org/r/120185/diff/ Testing --- Created .desktop file with X-KDE-SubstituteUID=true Now I can launch it as root and when I remove kdesu I got a normal error message. Thanks, Maarten De Meyer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: kdelibs_stable #1180
See http://build.kde.org/job/kdelibs_stable/1180/changes Changes: [faure] Fix test failure in chroot, reported by maxyz -- [...truncated 11001 lines...] [ 32%] Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/khelpmenu.o [ 32%] http://build.kde.org/job/kdelibs_stable/ws/kdeui/widgets/khelpmenu.cpp:392:2: warning: #warning how to enter whats this mode for a QX11EmbedWidget? [-Wcpp] #warning how to enter whats this mode for a QX11EmbedWidget? ^ Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/khistorycombobox.o [ 32%] [ 32%] Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/klanguagebutton.o Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/kkeysequencewidget.o [ 32%] Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/kled.o [ 32%] Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/klineedit.o [ 32%] [ 33%] Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/kmenu.o Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/kmainwindow.o [ 33%] Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/kmenubar.o [ 33%] Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/kmessagewidget.o [ 33%] Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/kmultitabbar.o [ 33%] Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/knuminput.o In file included from http://build.kde.org/job/kdelibs_stable/ws/kdeui/widgets/klineedit.cpp:1872:0: http://build.kde.org/job/kdelibs_stable/ws/build/kdeui/klineedit.moc: In member function ‘virtual int KLineEdit::qt_metacall(QMetaObject::Call, int, void**)’: http://build.kde.org/job/kdelibs_stable/ws/build/kdeui/klineedit.moc:189:70: warning: ‘bool KLineEdit::isContextMenuEnabled() const’ is deprecated (declared at http://build.kde.org/job/kdelibs_stable/ws/kdeui/widgets/klineedit.cpp:1830) [-Wdeprecated-declarations] case 0: *reinterpret_cast bool*(_v) = isContextMenuEnabled(); break; ^ http://build.kde.org/job/kdelibs_stable/ws/build/kdeui/klineedit.moc:201:68: warning: ‘virtual void KLineEdit::setContextMenuEnabled(bool)’ is deprecated (declared at http://build.kde.org/job/kdelibs_stable/ws/kdeui/widgets/klineedit.cpp:1823) [-Wdeprecated-declarations] case 0: setContextMenuEnabled(*reinterpret_cast bool*(_v)); break; ^ [ 33%] Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/kpixmapregionselectorwidget.o [ 33%] Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/kpushbutton.o [ 33%] Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/kratingpainter.o [ 33%] Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/kratingwidget.o http://build.kde.org/job/kdelibs_stable/ws/kdeui/widgets/knuminput.cpp: In constructor ‘KIntNumInput::KIntNumInput(KNumInput*, int, QWidget*, int)’: http://build.kde.org/job/kdelibs_stable/ws/kdeui/widgets/knuminput.cpp:341:43: warning: ‘KNumInput::KNumInput(QWidget*, KNumInput*)’ is deprecated (declared at http://build.kde.org/job/kdelibs_stable/ws/kdeui/widgets/knuminput.cpp:99) [-Wdeprecated-declarations] , d(new KIntNumInputPrivate(this, val)) ^ http://build.kde.org/job/kdelibs_stable/ws/kdeui/widgets/knuminput.cpp: In constructor ‘KDoubleNumInput::KDoubleNumInput(KNumInput*, double, double, double, QWidget*, double, int)’: http://build.kde.org/job/kdelibs_stable/ws/kdeui/widgets/knuminput.cpp:718:42: warning: ‘KNumInput::KNumInput(QWidget*, KNumInput*)’ is deprecated (declared at http://build.kde.org/job/kdelibs_stable/ws/kdeui/widgets/knuminput.cpp:99) [-Wdeprecated-declarations] , d(new KDoubleNumInputPrivate(value)) ^ [ 33%] Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/krestrictedline.o In file included from http://build.kde.org/job/kdelibs_stable/ws/kdeui/widgets/kratingwidget.cpp:299:0: http://build.kde.org/job/kdelibs_stable/ws/build/kdeui/kratingwidget.moc: In static member function ‘static void KRatingWidget::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)’: http://build.kde.org/job/kdelibs_stable/ws/build/kdeui/kratingwidget.moc:87:67: warning: ‘void KRatingWidget::setRating(unsigned int)’ is deprecated (declared at http://build.kde.org/job/kdelibs_stable/ws/kdeui/widgets/kratingwidget.cpp:155) [-Wdeprecated-declarations] case 3: _t-setRating((*reinterpret_cast uint(*)(_a[1]))); break; ^ http://build.kde.org/job/kdelibs_stable/ws/build/kdeui/kratingwidget.moc:89:70: warning: ‘void KRatingWidget::setMaxRating(unsigned int)’ is deprecated (declared at http://build.kde.org/job/kdelibs_stable/ws/kdeui/widgets/kratingwidget.cpp:175) [-Wdeprecated-declarations] case 5: _t-setMaxRating((*reinterpret_cast uint(*)(_a[1]))); break;
Re: What's qt5-stable on build.kde.org
El Dimarts, 16 de setembre de 2014, a les 12:37:31, Milian Wolff va escriure: On Tuesday 16 September 2014 21:50:57 Ben Cooksley wrote: On Tue, Sep 16, 2014 at 9:45 PM, Martin Gräßlin mgraess...@kde.org wrote: On Tuesday 16 September 2014 21:23:54 Ben Cooksley wrote: I wrote this a bit too quickly. The correct url is http://build.kde.org/view/External_Deps/job/qt5_master_qt5/ What the system means by stable in the output is that is the branch that it should theoretically be building against. This information is drawn from the build metadata available to it. It has no correspondence with the job name. In the case of Qt 5, this information is maintained in the CI scripts own files. thanks, that explains it. From the latest build log: Branch jenkins set up to track remote branch stable from origin. and the stable branch seems to no longer being updated on upstream's side. qtbase is set to 8fa9121 according to build's output. This is older than the patch I got into Qt 5. Maybe it would be better to track the 5.3 branch instead? That is a development decision. Once taken, the necessary file to adjust is the same as for all other KDE projects: logical-module-structure Yes, there is no stable anymore upstream. 5.3 is probably a good choice for now, until 5.4 is released. H, don't know, the thing is we're only requiring 5.2, maybe we want to require 5.3 if we know it won't work otherwise (i.e. Martin's test)? Or we prefer to keep the minimum at 5.2 while recommending 5.3? Cheers, Albert Bye ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to normal : kdelibs_stable #1181
See http://build.kde.org/job/kdelibs_stable/1181/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
