SUMMARY When building Qt 5 from source using kdesrc-build the generated tools end up in ${qtdir}/bin This is unlikely to be on the PATH, which makes it hard to compile KF5 & apps with tools you just built from source. STEPS TO REPRODUCE 1. On a fresh system without Qt set up kdesrc-build (so there won't be a qmake) 2. Make sure to include kf5-qt5-build-include and qt5-build-include 3. Build Qt 5 locally with kdesrc-build qt5 4. Run kdesrc-build with for example the following options: --include-dependencies kate OBSERVED RESULT ``` Unable to find qmake. This program is absolutely essential for building the modules: kded kcmutils kate kemoticons kactivities kiconthemes ktextwidgets kpackage phonon kplotting kdesignerplugin attica frameworkintegration modemmanager-qt khtml kauth knotifyconfig kitemmodels kdeclarative kxmlrpcclient kconfigwidgets oxygen-icons5 kpty karchive threadweaver kservice kdesu plasma-framework kwayland kbookmarks krunner knewstuff baloo kjobwidgets kjs kwallet kcompletion knotifications kconfig kjsembed bluez-qt kdnssd solid kpeople kglobalaccel sonnet kdbusaddons kdoctools kwidgetsaddons kmediaplayer kdelibs4support ktexteditor kdewebkit kross kidletime kcoreaddons polkit-qt-1 kfilemetadata prison kunitconversion networkmanager-qt qqc2-desktop-style kinit kactivities-stats kirigami kcodecs kitemviews kimageformats kparts syntax-highlighting kio kguiaddons kcrash ki18n kxmlgui breeze-icons kwindowsystem extra-cmake-modules. Please ensure the development packages for Qt are installed by using your distribution's package manager. ``` EXPECTED RESULT kdesrc-build picks up locally built Qt tools from qtdir and does not bail.
Tracking partial fix(es) through: https://phabricator.kde.org/D19127 PS: what is the correct way to tag a bug in your commit message?
Can confirm, I had to work through this myself when I added Qt5 build support, and noted it as something that would need to be fixed. See https://invent.kde.org/kde/kdesrc-build/issues/18 I would rather we track this bug up there... maybe resolve as "UPSTREAM" here to make it clear the bug remains valid? To answer your question about closing bugs, though, you can use the BUG:nnnnn keyword in your commit message for most KDE repositories to indicate the Bugzilla bug can be closed as fixed. For the repositories participating in the Gitlab pilot at invent.kde.org (like kdesrc-build), you can close their Gitlab issues by just mentioning "Fixes #n" in the commit message somewhere. Last I tried the Gitlab instance can't actually close Bugzilla bugs because the hooks aren't setup for that.
Generally we can do RESOLVED MOVED for that. I think if you use the standard BUG: keyword, it hits the appropriate hookscripts when the commit gets mirrored to cgit, right?
I am getting a bit confused about how to track issues here. To me it looks like we have 3 separate places: - bugs.kde.org - phabricator.kde.org (the kdesrc-build workboard) - invent.kde.org (the kdesrc-build Gitlab repo/project) How are these systems related? Am I still supposed to file bugs on bugs.kde.org at all, anymore? Also looking at the git remotes, I don't see invent.kde.org there at all so I also don't see how I am supposed to tag my commit message properly for Gitlab.
(In reply to jm.ouwerkerk from comment #4) > I am getting a bit confused about how to track issues here. To me it looks > like we have 3 separate places: > > - bugs.kde.org > - phabricator.kde.org (the kdesrc-build workboard) > - invent.kde.org (the kdesrc-build Gitlab repo/project) > > How are these systems related? Am I still supposed to file bugs on > bugs.kde.org at all, anymore? For kdesrc-build, prefer https://invent.kde.org/ for now. b.k.o will remain and if the gitlab experiment doesn't work out then we'll fall back to b.k.o. I can close down the phab board (or just point it to https://invent.kde.org/). > Also looking at the git remotes, I don't see invent.kde.org there at all so > I also don't see how I am supposed to tag my commit message properly for > Gitlab. You don't have to do anything special to write your commit message for invent.kde.org in most situations, except to say something like "Fixes #4" (where '4' is the issue number that is impacted on the Gitlab instance). If/when the Git commit fixing the bug gets pulled into the gitlab-hosted repository, gitlab will close the matching issue itself. For an example please see https://invent.kde.org/kde/kdesrc-build/commit/0ceb50e9fefbc43c037e7303fa66b0e793987b3c You don't actually need to add gitlab as a remote to develop against it, the gitlab-hosted repo syncs back to anongit like normal. It can be more convenient to do so, however. The gitlab instance should be able to point out which commands to run if you want to add gitlab as a remote to submit a Merge Request, or you can always just add the diff to the issue. And if it's all too annoying, feel free to continue to work here or in phab.
Git commit 69ca1a31fcd294e0f02196716124718849f2b780 by Johan Ouwerkerk. Committed on 20/02/2019 at 19:16. Pushed by ouwerkerk into branch 'master'. Consider and prefer using tools from qtdir/bin and kdedir/bin if available. Fixes: #18 Differential Revision: https://phabricator.kde.org/D19127 M +5 -1 modules/ksb/Application.pm M +7 -4 modules/ksb/Util.pm https://invent.kde.org/kde/kdesrc-build/commit/69ca1a31fcd294e0f02196716124718849f2b780