KDE CI: Frameworks » kio » kf5-qt5 FreeBSDQt5.15 - Build # 1631 - Fixed!
BUILD SUCCESS Build URL https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20FreeBSDQt5.15/1631/ Project: kf5-qt5 FreeBSDQt5.15 Date of build: Sun, 19 Jun 2022 05:35:27 + Build duration: 5 min 13 sec and counting JUnit Tests Name: projectroot Failed: 0 test(s), Passed: 61 test(s), Skipped: 0 test(s), Total: 61 test(s)Name: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)
The KDE Patchset Collection has been rebased on top of Qt 5.15.5
The KDE Patchset Collection has been rebased on top of Qt 5.15.5 Cheers, Albert
Re: Debugging CI test failures
On Sat, Jun 18, 2022 at 11:07 PM Thomas Friedrichsmeier <
thomas.friedrichsme...@kdemail.net> wrote:
> On Sat, 18 Jun 2022 21:50:33 +1200
> Ben Cooksley wrote:
>
> > On Fri, Jun 17, 2022 at 8:04 AM Thomas Friedrichsmeier <
> > thomas.friedrichsme...@kdemail.net> wrote:
> >
> > > On Thu, 16 Jun 2022 17:31:16 +0200
> > > Thomas Friedrichsmeier wrote:
> > >
> > > > On Thu, 16 Jun 2022 22:26:31 +1200
> > > > Ben Cooksley wrote:
> > > >
> > > > > On Thu, Jun 16, 2022 at 8:08 AM Thomas Friedrichsmeier <
> > > > > thomas.friedrichsme...@kdemail.net> wrote:
> > > > >
> > > > > > On Wed, 15 Jun 2022 17:51:52 +0200
> > > > > > Thomas Friedrichsmeier
> > > > > > wrote: [...]
> > > > > > > I suppose, I could try seting up some dummy test binaries,
> > > > > > > linking against the various libraries, hoping to narrow down
> > > > > > > the problem that way?
> > > > > >
> > > > > > Ok, that finally led to something. I have no idea, why this is
> > > > > > happening, or how to fix it, but I have isolated QWebEngine
> > > > > > as the troublemaker.
> > > > > >
> > > > > > relevant portion of CMakeLists.txt:
> > > > > >
> > > > > > add_executable(linktest linktest.cpp)
> > > > > > target_link_libraries(linktest PRIVATE Qt5::Test
> > > > > > Qt5::WebEngineWidgets) add_test(NAME rkward-linktest COMMAND
> > > > > > linktest) ecm_mark_as_test(linktest)
> > > > > >
> > > > > > relevant code:
> > > > > >
> > > > > >
> > >
> https://invent.kde.org/education/rkward/-/blob/work/diagnose_testfailure/rkward/autotests/linktest.cpp
> > >
> > > > > >
> > > > > > result:
> > > > > > https://invent.kde.org/education/rkward/-/jobs/359945
> > > > > >
> > > > > > (2/2 Test #2: rkward-linktest ..Exit code
> > > > > > 0xc135)
> > > > > >
> > > > > > Note that "new QWebEngineView();" does not even have to be
> > > > > > called. It's enough that the line of code is present,
> > > > > > directly or indirectly. In contrast - for instance - creating
> > > > > > a KTextEditor::Document/View does not cause any trouble.
> > > > > >
> > > > >
> > > > > Interesting. When you build RKward on your local system do you
> > > > > use the Craft cache or does your system build everything itself?
> > > > > I wonder if the Craft binaries for WebEngineWidgets are broken
> > > > > - and MSVC doesn't check down the full chain when it does it's
> > > > > linking.
> > > >
> > > > Well, my local craft builds are MinGW-based, and so are using
> > > > QWebKit, instead. So that does not really compare. No problem,
> > > > there, however, despite using the cache.
> > > >
> > > > I did just check that the latest MSVC build from binary-factory is
> > > > working. Of course that doesn't contain the test, but rkward
> > > > itself works fine.
> > > >
> > > > I'm currently trying to get my MSVC craft root back to life, but
> > > > that seems to take another while...
> > >
> > > Ok, so no problem (well not _that_ problem, anyway) on craft MSVC
> > > 2019 with Craft cache. That's a Windows 8.1 VM by the way.
> > >
> >
> > Strange. Just curious - do we see any additional library dependencies
> > in WebEngineWidgets that aren't present in the other Qt libraries?
>
> There may be more elegant ways to find this info (I'm definitely not up
> to speed on Windows tools), but: I started rkward, listed the loaded
> dlls using "tasklist /m", then did the same for kate, and compared the
> lists. Most, but not all, differences should be related to QWebEngine
> ("+" means only in rkward.exe, "-" is only in kate.exe). Surprisingly,
> this also includes some differences in filename case, for whatever
> reason.
>
> + AVRT.dll
> + cfgmgr32.dll
> - CFGMGR32.dll
> + d3d10warp.dll
> + d3dcompiler_47.dll
> + dbghelp.dll
> + DCIMAN32.dll
> + dcomp.dll
> + DDRAW.dll
> + dhcpcsvc6.DLL
> + dhcpcsvc.DLL
> + DWrite.dll
> - dwrite.dll
> + dxva2.dll
> - externaltoolsplugin.dll
> + GLU32.dll
> + HID.DLL
> + iertutil.dll
> - katefiletreeplugin.dll
> + katesnippetsplugin.dll
> + KF5Bookmarks.dll
> + KF5KIOFileWidgets.dll
> - KUserFeedbackCore.dll
> - KUserFeedbackWidgets.dll
> + libEGL.DLL
> + libGLESv2.dll
> + MFCaptureEngine.dll
> + mf.dll
> + mfh264enc.dll
> + mfplat.dll
> + mfreadwrite.dll
> + MMDevApi.dll
> + mscms.dll
> + msmpeg2vdec.dll
> + msvproc.dll
> + ncrypt.dll
> + NLAapi.dll
> + NTASN1.dll
> + ntmarta.dll
> + opengl32.dll
> + Qt5Positioning.dll
> + Qt5QuickWidgets.dll
> + Qt5WebChannel.dll
> + Qt5WebEngineCore.dll
> + Qt5WebEngineWidgets.dll
> + RTWorkQ.DLL
> - tabswitcherplugin.dll
> + urlmon.dll
> + USP10.dll
> + WINHTTP.dll
> + WININET.dll
> + WINSTA.dll
>
Ah bingo! (said like https://youtu.be/QMiubC6LdTA?t=1574)
Looks like DirectX and it's corresponding components are missing:
PS C:\> Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue
-Force -Filter ddraw.dll
PS C:\> Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue
-Force -Filter glu32.dll
PS C:\> Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue
-Force -Filter
[QML] Having different imports depending on Qt version
Hi, for GCompris (compiled in Qt5 only), we have activities using the Calendar qml object. Previously, we imported the one from QtQuick.Controls 1 but this module has been deprecated and we switched to QtQuick.Controls 2. This component hasn't been implemented in QtQuick.Controls 2 before Qt6.3 (via "import QtQuick.Controls"). This one is available in Qt Marketplace ( https://code.qt.io/cgit/qt-extensions/qtquickcalendar.git) and supports Qt5 and Qt 6.0-> 6.2 (via "import QtQuick.Calendar 1.0") but requires QtControls private headers to be installed and they are not present on some distributions (Ubuntu < 21.04...), which we would like to still support for the next version. There is the one in Qt.labs which is available in Qt5 but not Qt6 (via "import Qt.labs.calendar 1.0"). GCompris' code works fine with any of the import ( https://invent.kde.org/education/gcompris/-/blob/master/src/activities/calendar/Calendar.qml#L14) but I didn't find any "if(Qt_version < ...) use one, else the other" except doing a Calendar.qml.cmake with a @GOOD_IMPORT@ that would be set by cmake and a configure_file. Is there a better way? For now, we only target Qt5, so we could use Qt.labs without having to handle the other two but once we switch to Qt6, we will face the issue with distributions using Qt6.2 so I'd rather prepare this transition sooner than later. Cheers, Johnny
Re: Debugging CI test failures
On Sat, 18 Jun 2022 21:50:33 +1200
Ben Cooksley wrote:
> On Fri, Jun 17, 2022 at 8:04 AM Thomas Friedrichsmeier <
> thomas.friedrichsme...@kdemail.net> wrote:
>
> > On Thu, 16 Jun 2022 17:31:16 +0200
> > Thomas Friedrichsmeier wrote:
> >
> > > On Thu, 16 Jun 2022 22:26:31 +1200
> > > Ben Cooksley wrote:
> > >
> > > > On Thu, Jun 16, 2022 at 8:08 AM Thomas Friedrichsmeier <
> > > > thomas.friedrichsme...@kdemail.net> wrote:
> > > >
> > > > > On Wed, 15 Jun 2022 17:51:52 +0200
> > > > > Thomas Friedrichsmeier
> > > > > wrote: [...]
> > > > > > I suppose, I could try seting up some dummy test binaries,
> > > > > > linking against the various libraries, hoping to narrow down
> > > > > > the problem that way?
> > > > >
> > > > > Ok, that finally led to something. I have no idea, why this is
> > > > > happening, or how to fix it, but I have isolated QWebEngine
> > > > > as the troublemaker.
> > > > >
> > > > > relevant portion of CMakeLists.txt:
> > > > >
> > > > > add_executable(linktest linktest.cpp)
> > > > > target_link_libraries(linktest PRIVATE Qt5::Test
> > > > > Qt5::WebEngineWidgets) add_test(NAME rkward-linktest COMMAND
> > > > > linktest) ecm_mark_as_test(linktest)
> > > > >
> > > > > relevant code:
> > > > >
> > > > >
> > https://invent.kde.org/education/rkward/-/blob/work/diagnose_testfailure/rkward/autotests/linktest.cpp
> >
> > > > >
> > > > > result:
> > > > > https://invent.kde.org/education/rkward/-/jobs/359945
> > > > >
> > > > > (2/2 Test #2: rkward-linktest ..Exit code
> > > > > 0xc135)
> > > > >
> > > > > Note that "new QWebEngineView();" does not even have to be
> > > > > called. It's enough that the line of code is present,
> > > > > directly or indirectly. In contrast - for instance - creating
> > > > > a KTextEditor::Document/View does not cause any trouble.
> > > > >
> > > >
> > > > Interesting. When you build RKward on your local system do you
> > > > use the Craft cache or does your system build everything itself?
> > > > I wonder if the Craft binaries for WebEngineWidgets are broken
> > > > - and MSVC doesn't check down the full chain when it does it's
> > > > linking.
> > >
> > > Well, my local craft builds are MinGW-based, and so are using
> > > QWebKit, instead. So that does not really compare. No problem,
> > > there, however, despite using the cache.
> > >
> > > I did just check that the latest MSVC build from binary-factory is
> > > working. Of course that doesn't contain the test, but rkward
> > > itself works fine.
> > >
> > > I'm currently trying to get my MSVC craft root back to life, but
> > > that seems to take another while...
> >
> > Ok, so no problem (well not _that_ problem, anyway) on craft MSVC
> > 2019 with Craft cache. That's a Windows 8.1 VM by the way.
> >
>
> Strange. Just curious - do we see any additional library dependencies
> in WebEngineWidgets that aren't present in the other Qt libraries?
There may be more elegant ways to find this info (I'm definitely not up
to speed on Windows tools), but: I started rkward, listed the loaded
dlls using "tasklist /m", then did the same for kate, and compared the
lists. Most, but not all, differences should be related to QWebEngine
("+" means only in rkward.exe, "-" is only in kate.exe). Surprisingly,
this also includes some differences in filename case, for whatever
reason.
+ AVRT.dll
+ cfgmgr32.dll
- CFGMGR32.dll
+ d3d10warp.dll
+ d3dcompiler_47.dll
+ dbghelp.dll
+ DCIMAN32.dll
+ dcomp.dll
+ DDRAW.dll
+ dhcpcsvc6.DLL
+ dhcpcsvc.DLL
+ DWrite.dll
- dwrite.dll
+ dxva2.dll
- externaltoolsplugin.dll
+ GLU32.dll
+ HID.DLL
+ iertutil.dll
- katefiletreeplugin.dll
+ katesnippetsplugin.dll
+ KF5Bookmarks.dll
+ KF5KIOFileWidgets.dll
- KUserFeedbackCore.dll
- KUserFeedbackWidgets.dll
+ libEGL.DLL
+ libGLESv2.dll
+ MFCaptureEngine.dll
+ mf.dll
+ mfh264enc.dll
+ mfplat.dll
+ mfreadwrite.dll
+ MMDevApi.dll
+ mscms.dll
+ msmpeg2vdec.dll
+ msvproc.dll
+ ncrypt.dll
+ NLAapi.dll
+ NTASN1.dll
+ ntmarta.dll
+ opengl32.dll
+ Qt5Positioning.dll
+ Qt5QuickWidgets.dll
+ Qt5WebChannel.dll
+ Qt5WebEngineCore.dll
+ Qt5WebEngineWidgets.dll
+ RTWorkQ.DLL
- tabswitcherplugin.dll
+ urlmon.dll
+ USP10.dll
+ WINHTTP.dll
+ WININET.dll
+ WINSTA.dll
> Reason I ask is because the Gitlab CI builds are using Windows Server
> Core 2022 (LTSC) which is both stripped down compared to a normal
> Windows desktop system (Server Core is missing most of the UI stuff),
> and is based on the same foundations as Windows 11. The Jenkins
> based Binary Factory however uses full traditional Windows 10 Desktop
> for its builds.
>
> Our Server Core 2022 (LTSC) images do contain .Net 4.8 (including
> it's SDK) though which I thought would have given us sufficient
> coverage but perhaps there is some part of Windows missing that
> WebEngine relies on that is missing here.
Just a thought: Many of the internet search hits on 0xc135 are about
an _older_ version of .NET no longer being enabled, after an update.
Re: Debugging CI test failures
On Fri, Jun 17, 2022 at 8:04 AM Thomas Friedrichsmeier < thomas.friedrichsme...@kdemail.net> wrote: > On Thu, 16 Jun 2022 17:31:16 +0200 > Thomas Friedrichsmeier wrote: > > > On Thu, 16 Jun 2022 22:26:31 +1200 > > Ben Cooksley wrote: > > > > > On Thu, Jun 16, 2022 at 8:08 AM Thomas Friedrichsmeier < > > > thomas.friedrichsme...@kdemail.net> wrote: > > > > > > > On Wed, 15 Jun 2022 17:51:52 +0200 > > > > Thomas Friedrichsmeier wrote: > > > > [...] > > > > > I suppose, I could try seting up some dummy test binaries, > > > > > linking against the various libraries, hoping to narrow down > > > > > the problem that way? > > > > > > > > Ok, that finally led to something. I have no idea, why this is > > > > happening, or how to fix it, but I have isolated QWebEngine as the > > > > troublemaker. > > > > > > > > relevant portion of CMakeLists.txt: > > > > > > > > add_executable(linktest linktest.cpp) > > > > target_link_libraries(linktest PRIVATE Qt5::Test > > > > Qt5::WebEngineWidgets) add_test(NAME rkward-linktest COMMAND > > > > linktest) ecm_mark_as_test(linktest) > > > > > > > > relevant code: > > > > > > > > > https://invent.kde.org/education/rkward/-/blob/work/diagnose_testfailure/rkward/autotests/linktest.cpp > > > > > > > > result: > > > > https://invent.kde.org/education/rkward/-/jobs/359945 > > > > > > > > (2/2 Test #2: rkward-linktest ..Exit code > > > > 0xc135) > > > > > > > > Note that "new QWebEngineView();" does not even have to be called. > > > > It's enough that the line of code is present, directly or > > > > indirectly. In contrast - for instance - creating a > > > > KTextEditor::Document/View does not cause any trouble. > > > > > > > > > > Interesting. When you build RKward on your local system do you use > > > the Craft cache or does your system build everything itself? > > > I wonder if the Craft binaries for WebEngineWidgets are broken - and > > > MSVC doesn't check down the full chain when it does it's linking. > > > > Well, my local craft builds are MinGW-based, and so are using QWebKit, > > instead. So that does not really compare. No problem, there, however, > > despite using the cache. > > > > I did just check that the latest MSVC build from binary-factory is > > working. Of course that doesn't contain the test, but rkward itself > > works fine. > > > > I'm currently trying to get my MSVC craft root back to life, but that > > seems to take another while... > > Ok, so no problem (well not _that_ problem, anyway) on craft MSVC 2019 > with Craft cache. That's a Windows 8.1 VM by the way. > Strange. Just curious - do we see any additional library dependencies in WebEngineWidgets that aren't present in the other Qt libraries? Reason I ask is because the Gitlab CI builds are using Windows Server Core 2022 (LTSC) which is both stripped down compared to a normal Windows desktop system (Server Core is missing most of the UI stuff), and is based on the same foundations as Windows 11. The Jenkins based Binary Factory however uses full traditional Windows 10 Desktop for its builds. Our Server Core 2022 (LTSC) images do contain .Net 4.8 (including it's SDK) though which I thought would have given us sufficient coverage but perhaps there is some part of Windows missing that WebEngine relies on that is missing here. > > Thomas > Cheers, Ben
[sdk/ikona] data: Remove direct link to invent.kde.org.
Git commit ebb24a7118581ff27dbf66c3dc32da3bd6645d30 by Ben Cooksley. Committed on 18/06/2022 at 09:11. Pushed by bcooksley into branch 'master'. Remove direct link to invent.kde.org. Linking to raw files on invent.kde.org is *strictly* and *absolutely* prohibited in the strongest possible terms and is something that Sysadmin does not permit in any form. This is particularly the case when those files will be fetched by end user systems, as it creates the risk of an unintentional Distributed Denial of Service attack on invent.kde.org. CCMAIL: sysad...@kde.org CCMAIL: kde-core-devel@kde.org CCMAIL: community...@kde.org M +0-1data/org.kde.Ikona.appdata.xml https://invent.kde.org/sdk/ikona/commit/ebb24a7118581ff27dbf66c3dc32da3bd6645d30 diff --git a/data/org.kde.Ikona.appdata.xml b/data/org.kde.Ikona.appdata.xml index c214f59..fe98e6c 100644 --- a/data/org.kde.Ikona.appdata.xml +++ b/data/org.kde.Ikona.appdata.xml @@ -2,7 +2,6 @@ org.kde.Ikona - https://invent.kde.org/sdk/ikona/raw/master/data/org.kde.Ikona.svg Ikona أيقونة Ikona
