I'll ask Hannah to take a look. Given the PDB code is Windows only and the code prior to this change works on Windows fine, I suspect that change is very much needed to make Windows work properly.

This change has broken builds on Windows
https://binary-factory.kde.org/job/Craft_Build_Cache_windows-msvc2017_64-cl-debug/lastFailedBuild/console

First jobs started - https://build.kde.org/job/Extragear/job/elisa/

The lack of stable builds for Elisa is due to a lack of stable branch definitions in logical-module-structure in the kde-build-metadata repository.
(See the existing Elisa section)

Looks fine to me.

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.