- User Since
- Mar 23 2016, 2:38 AM (165 w, 5 d)
Sat, May 25
I was under the impression that LD_LIBRARY_PATH shouldn't be required if the paths to Qt are setup properly, but as long as you've tested that it's necessary I've no objection.
Sat, May 18
Sat, May 4
Wed, May 1
The patch works in my testing and looks reasonable. Are you able to commit or should I?
Sat, Apr 27
I have committed the doc fix (and maintained your authorship). I expect that we will be able to automatically migrate git modules to the new location if it is decided to use Gitlab for all KDE git repositories, but in the meantime it does require manually running some git commands.
Apr 23 2019
Apr 20 2019
I like the change! We'll need to watch for things to add to ignored-projects as @bcooksley points out.
Apr 13 2019
Looks good, thank you!
Mar 30 2019
+1 to @aacid's comment about relicensing.
Mar 26 2019
Right then, sounds good.
Mar 24 2019
Mar 23 2019
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.
Mar 14 2019
Mar 9 2019
Mar 3 2019
Feb 20 2019
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 firstname.lastname@example.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.
Feb 19 2019
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.
Feb 18 2019
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
Feb 9 2019
Feb 8 2019
Jan 14 2019
Jan 13 2019
Jan 12 2019
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).
Jan 10 2019
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.
Jan 7 2019
Jan 6 2019
Dec 29 2018
Dec 28 2018
Dec 27 2018
Dec 26 2018
Probably because we're using kdesrc-build as a testcase for the Gitlab instance at invent.kde.org. I'll go ahead and push.
Dec 25 2018
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).