Will leave the content for @hindenburg to review.

The Gitlab migration is in planning and preparation stages, so should happen sometime in the next couple of months.

Okay. We'll need to make sure local-metadata/ignored-projects in sysadmin/ci-tooling is updated at the same time as i'm not sure if the CI tooling is as tolerant when ignoring projects (it certainly is when it comes to resolving the dependency graph)

This looks fine to me, subject to being okayed by @mpyne

In D20529#451561, @bruns wrote:

In D20529#451147, @bcooksley wrote:

can we get the full command it's running?

ctest -V -R externalextractortest

MSVC doesn't like this change i'm afraid - see https://build.kde.org/view/OS%20-%20Windows/job/Frameworks/job/kio/job/kf5-qt5%20WindowsMSVCQt5.11/259/console
Looks like you're making use of C++17 features?

The Python installation on the CI nodes is most definitely complete (the CI Tooling itself used to perform the builds is written entirely in Python)

@ngraham The people you will be finding will be those who hold developer accounts - because their information is available in kde-common/accounts, that information is also made accessible on Identity.
The people you're trying to find will likely be non-developers though, hence why you're not finding them.

In terms of getting this sorted, what sort of priority are we looking at here?

Thanks David, this looks good to me!

In D20279#444428, @ouwerkerk wrote:

In D20279#444164, @bcooksley wrote:

Would it be possible to have all the external items sitting in their own namespace?

Do you mean having a separate dependency data file for them (e.g. dependency-data-external-kf5-qt5) ? Or do you mean having a distinct path so a module like taglib becomes e.g. external/taglib ?

Would it be possible to have all the external items sitting in their own namespace?

This is because as far as Jenkins is aware the correct branch to be tracking is Applications/18.10.
The most likely reasons for this are either:

1. No build has been triggered since Applications/19.04 came into existence, probably because Applications/18.10 hasn't been committed to since March 17 and the Global Rebuild job hasn't been triggered.
2. The metadata hasn't been updated for some reason or another, and it still points at Applications/18.10

Can you please file a task on the build.kde.org board so I can get this worked through with the FreeBSD folks? (It will likely require the package being updated in FreeBSD itself)

The above files have been released as requested.

In D19740#442586, @staniek wrote:

Well I am not pushing for the cert, in fact it's hard to say how it would be seen by users: is KEXI widely certified and tested by KDE? No, no KDE app is, it's local work.
Maybe I'll have commercial certification or/and the app in app stores. Too early to say.
Thanks.

Krita is a highly special case yes. Even in their case we're still running the whole process on the Binary Factory - they don't have the certificate, nor do they have the ability to get arbitrary files signed.

In D20096#440451, @dfaure wrote:

In D20096#440440, @bruns wrote:

2. Tell the application where the slave library is located: QT_PLUGIN_PATH=... There must be a subdirectory kf5/kio/ containing the slave plugin file.so below the plugin path

ECM used to do this automatically btw, until 7d6d5b1e705f54a commented it out because it broke CI - should be investigated again, because re-reading the commit log, I fail to see how *appending* to the path would lead to things not being found....

Mirrorbrain itself doesn't support https so this will cause parts of it to fail. Running the mirror prober or scanner should make this show up.