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.