Yes, we have Appimages via Craft now and they seem to work quite well :)

I suppose this task can be closed.

This should now be fixed.

The build.kde.org system will be going away very soon now that Windows is for all intents and purposes available on Invent.
Just need to put together some dashboards, for which a server move was conducted this weekend to prepare for that.

Bit sad to see that, but yes you can disable that.

Seems such insight is nothing people have active interest in it, thus discarding again, makes no sense to setup and maintain something only 1-2 persons would ever use. And fits the lack of other insight overview reports like development of compiler warnings, test results etc., guess the lack of MBAs has not helped to establish a cult around metrics ;)

Oha, I just gave doing a build of KF with EXCLUDE_DEPRECATED_BEFORE_AND_AT a try, and seems there are now lots of places in non-deprecated parts of KF modules which use/rely on deprecated API...

Thinking about it some more, seeing the state of EXCLUDE_DEPRECATED_BEFORE_AND_AT might be also slightly orthogonal to which Qt version is used.

Another option might be to go directly for Qt6 builds (which imply EXCLUDE_DEPRECATED_BEFORE_AND_AT=CURRENT). The upside of this is that it is something we need long-term anyway, the downside is that we so far have only one module ready for this (I expect this to change shortly though, but possibly not to full KF coverage before branching).

With the arrival of gitlab CI, there might be a new chance to revive this idea (please see task description) here to keep some automated track where we are with KF itself depending on own deprecated API in the non-deprecated parts.

I've now enabled KIO on Android CI.

Given Android Deps build faild again in KIO, and given that there seems no interest/resources to invest into making KIO a proper optional dependency for the apps build for Android, I propose to just add KIO to the Android CI instead, even more as KIO is large and there are lots of changes and thus changes to break the Android build.

So to confirm what we are doing here - add KIO to Android CI?

I don't mind this being changed, my point is that touching that part of the CI tends to have unforeseen side-effects, so better be prepared for that :)

So you propose to just leave the status quo or to add also all the others? My intention here was to help the KDE-Android project by not having their Deps build fail now and then (and then those who care to keep CI in green/blue sate), but the passive reaction so far on principle changes makes me feel there is no interest? Just say, todo has me lots of other things to do :)

https://invent.kde.org/frameworks/kio/-/merge_requests/505 should fix this

Okay, sounds like "not really, but then somehow" ;)

I couldn't find a reason for KIO being newly pulled into the dependency build, and it turns out it has always been there, there's just a build breakage due to recent KIO changes. Might be easier to fix that than dealing with the hard to calculate fallout of pulling KIO out of the middle of the dependency chain.

There certainly is interest in having KIO functional on Android, but currently that's not the case and won't be for the foreseeable future.

Yes, thanks to Kai Knoblich we were able to update to a more recent webengine quite some time ago -- so should be all good :)

Based on what we can see in the logs of other projects that use webengine it should be safe to revert that so i've now done so.

I've done some testing this morning and have been unable to reproduce the common failures I could see online (with CMake being unable to find a usable C/C++ compiler, with elfscan dumping core, etc) related to this.

Fun. In theory we should be okay, as our version of Docker should be new enough:

Docker version 20.10.3, build 48d30b5

This is a known item and is part of our overall plan regarding Gitlab CI

We'll do that when we switch to GitLab CI. Some projects already use it.

I've enabled Linux and FreeBSD builds for now - once we've gotten those 100% working we can then proceed with Windows & Android.

Right, the Build Now action is present on https://build.kde.org/job/Administration/job/Dependency%20Build%20KDevelop%20kf5-qt5%20SUSEQt5.14/ when I'm logged in. Thank you.

You've now been granted those permissions as requested.

This has now been executed in https://invent.kde.org/sysadmin/ci-tooling/commit/5bee2e0b13669608710cd0349fb50b8f05961c5a

Apologies for that - it is indeed non-trivial with the current system architecture in Jenkins.

Seems this has not been simple to implement, most KF contributors are already challenged to track KDE CI for normal builds, no-one has added to this task, and KF6 splitting is just around the corner anyway (at least I assume people will do that somewhere between Akademy 2020 and targetted Qt 6.0.0 release in December), I drop this request. The occasional local builds done by the few suspected and their follow-up fixes have substituted things good enough.

These jobs have now been provisioned as requested - https://build.kde.org/job/Extragear/job/markdownpart/

Thanks for confirming it's now fixed!

Compilation fixed: https://invent.kde.org/education/marble/-/commit/de5cef9149ea5bda96437670b9a6bb420347f74c

Thank you. I'm taking a look asap. It seems protobuf is detected but has link issues

This has now been provisioned.

I've merged on both master and stable version after checking it works fine on my computer.

In T13428#236074, @bcooksley wrote:

As a number of applications depend on Marble, we'll need the master and stable branches to both be buildable before we can enable this i'm afraid, as Marble is currently ignored as a project on Windows.

As a number of applications depend on Marble, we'll need the master and stable branches to both be buildable before we can enable this i'm afraid, as Marble is currently ignored as a project on Windows.

This has now been setup as requested. We don't have MacOS CI at this stage i'm afraid though.

Yes i understand the scripts are shared between gitlab and jenkins and that lots of projects are not "very good" in keeping their tests clean, that's why i asked this to be opt-in for those projects that try to actually have passing tests :)

I already have plans to significantly revamp how CI works with Gitlab so it shouldn't be too much of an issue to delegate control over this as part of the changes.

This is now sorted out.

Windows CI is separate to the Binary Factory and does not make available any artifacts for users to download (in particular because they'd be useless without all the associated dependencies, and the result of each job would be many gigabytes in size due to everything involved being full debug binaries)

We have it fixed like so in the tree:
https://github.com/freebsd/freebsd-ports-kde/blob/master/graphics/digikam/files/patch-core_CMakeLists.txt

03:32:36 [ 42%] Linking CXX shared library libdigikamcore.so
03:32:36 ld: error: unable to find library -llqr-1
03:32:36 ld: error: unable to find library -lglib-2.0
03:32:36 ld: error: unable to find library -lintl
03:32:36 ld: error: unable to find library -llqr-1
03:32:36 ld: error: unable to find library -lglib-2.0
03:32:36 ld: error: unable to find library -lintl
03:32:36 c++: error: linker command failed with exit code 1 (use -v to see invocation)
03:32:36 gmake[2]: * [core/app/CMakeFiles/digikamcore.dir/build.make:1279: core/app/libdigikamcore.so.7.0.0] Error 1
03:32:36 gmake[1]: * [CMakeFiles/Makefile2:6377: core/app/CMakeFiles/digikamcore.dir/all] Error 2
03:32:36 gmake[1]: *** Waiting for unfinished jobs....

@cgilles https://build.kde.org/job/Extragear/job/digikam/job/kf5-qt5%20FreeBSDQt5.13/8/console opencv has been installed -- failures are now the missing link directories (basically -L/usr/local/lib)

Sure, I'll do that later today.

Tobias and Adriaan, could we get OpenCV added to the FreeBSD images please?

Tests are run again now, thanks to 811c7544490031e1faeb4a1597c4d11afbf68eb9

Lol (windows)

`49% tests passed, 42 tests failed out of 82

Unfortunately this is likely the result of continued bitrot of the old Warnings module which we're using.

This is intentional, please see https://cgit.kde.org/sysadmin/ci-tooling.git/commit/build-specs/Frameworks/extra-cmake-modules.yaml?id=45ff1bc4ecb18ad71ad0570f7e838d1ae7cab2e2

Thanks for your work, log now as wanted, thus closing as resolved

See build 160

00:26:54  ==654==ERROR: AddressSanitizer: heap-use-after-free on address 0x60700075d3c8 at pc 0x00080264d0fb bp 0x7fffdddec670 sp 0x7fffdddec668
00:26:54  READ of size 4 at 0x60700075d3c8 thread T18
00:26:54      #0 0x80264d0fa in std::__1::__atomic_base<int, false>::load(std::__1::memory_order) const /usr/include/c++/v1/atomic:926:17
00:26:54      #1 0x80264d0fa in int QAtomicOps<int>::loadAcquire<int>(std::__1::atomic<QAtomicOps<int>::loadAcquire<int>> const&) /usr/local/include/qt5/QtCore/qatomic_cxx11.h:239
00:26:54      #2 0x80264c504 in QBasicAtomicInteger<int>::loadAcquire(void) const /usr/local/include/qt5/QtCore/qbasicatomic.h:106:51
00:26:54      #3 0x8026f3b44 in QBasicAtomicInteger<int>::operator(cast)(int, void) const /usr/local/include/qt5/QtCore/qbasicatomic.h:108:48
00:26:54      #4 0x8026f24dc in KDevelop::FileManagerListJob::startNextJob(void)::$_0::operator()(KDevelop::Path const&) const /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 FreeBSDQt5.12/kdevplatform/project/filemanagerlistjob.cpp:122:17
00:26:54      #5 0x8026f1daa in QtConcurrent::StoredFunctorCall1<void, KDevelop::FileManagerListJob::startNextJob(void)::$_0, KDevelop::Path>::runFunctor(void) /usr/local/include/qt5/QtConcurrent/qtconcurrentstoredfunctioncall.h:432:34
00:26:54      #6 0x80269c364 in QtConcurrent::RunFunctionTask<void>::run(void) /usr/local/include/qt5/QtConcurrent/qtconcurrentrunbase.h:136:19
00:26:54      #7 0x80269c528 in virtual function non-virtual override offset : -16 QtConcurrent::RunFunctionTask<void>::run(void) /usr/local/include/qt5/QtConcurrent/qtconcurrentrunbase.h
00:26:54      #8 0x807716d6f in QThreadPoolThread::run(void) /wrkdirs/usr/ports/devel/qt5-core/work/qtbase-everywhere-src-5.12.2/src/corelib/thread/qthreadpool.cpp:99:24
00:26:54      #9 0x80770d8d4 in QThreadPrivate::start(void*) /wrkdirs/usr/ports/devel/qt5-core/work/qtbase-everywhere-src-5.12.2/src/corelib/thread/qthread_unix.cpp:361:14
00:26:54      #10 0x807379775  (/lib/libthr.so.3+0xd775)

I think the issue was that there was no llvm-symbolizer binary found on the system, as in FreeBSD 12.0 it seems none is provided by the base system, so we only had the versioned ones llvm-symbolizer50 and llvm-symbolizer60 available in $PATH.

Closing due to lack of response.

I'll leave this for Tobias to perform his initial investigation - should anything need to change in terms of how the CI system executes tests, please let me know.

Is any further action needed from the CI system side on this?

Any update on this @knauss?