I like the change! We'll need to watch for things to add to ignored-projects as @bcooksley points out.

Looks good, thank you!

+1 to @aacid's comment about relicensing.

Right then, sounds good.

I have a question, and also it would be good to know if there's a standardized convention for this kind of detection between Debian, BSD, Fedora, etc. etc.

Looks good. The way these compat changes normally impact working code against glibc / FreeBSD is to accidentally enable stricter symbol definitions, that shouldn't be an issue here and I've confirmed the header is also present on FreeBSD.

Good to go! If you have commit access you'll need to commit to the Gitlab instance rather than git.kde.org directly. In my case I'd just run git remote add gitlab git@invent.kde.org:kde/kdesrc-build.git first, git fetch gitlab to ensure it's fully downloaded, and then run something like git push gitlab master to push to the proper remote.

The existing Qt5 mention is meant to be special-cased by kdesrc-build and other users of this file (like the build.kde.org infrastructure) so I would not bother changing it just because kdesrc-build now supports Qt 5.

Aside from the absPathToExecutable2 new function the updated logic is sound. You'll want to keep the check you added to call absPathToExecutable without the preferred paths if the program couldn't be found even after that change as well, so don't get rid of that extra call you added to account for when the preferred paths don't find the program being sought.

This is good to commit. Note that JuK's repository is in testing for a trial KDE is running of GitLab, so you'll need to commit to the JuK repository at https://invent.kde.org/kde/juk

This bug should be fixed (at its precise source) in commit b01505bec941f06be52ca3ac88d9b6937e1f4c88.

I'll take a look and fix but if further review is needed may I invite you to the trial GitLab instance at https://invent.kde.org/kde/kdesrc-build/merge_requests ? (kdesrc-build is a participant in the trial).

The KSharedDataCache change is definitely correct. I've not done much with the kdelibs migrator but I agree with the logic and the implementation. Have you tried building some of the other frameworks or Plasma after implementing this patch? That's the only real risk I can think of.

Probably because we're using kdesrc-build as a testcase for the Gitlab instance at invent.kde.org. I'll go ahead and push.

This is perfect, you've already put more testing than I have been able to put for Arch. If you have future such fixes you can feel free to push, especially if already tested (I've only been able to test OpenSUSE up to this point).

Thanks for the patch! Since the m_networkAccessManager is now sure to be constructed once the Scrobbler constructor runs, I decided instead to just initialize that variable directly without making it conditional, and remove its creation in getAuthToken.

Yes, good point. I've applied in Applications/18.12 as well.