https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: app-portage/kuroo-1.2.1 fails to compile. Discovered on: amd64 (internal ref: ci) NOTE: This machine uses GCC-11: https://gcc.gnu.org/gcc-11/porting_to.html If you think this is a GCC-11 related issue, please block bug 732706.
Created attachment 737548 [details] build.log build log and emerge --info
Created attachment 737551 [details] 1-CMakeOutput.log 1-CMakeOutput.log
Possible context of error(s): -- Could NOT find KF5ItemModels: found neither KF5ItemModelsConfig.cmake nor kf5itemmodels-config.cmake -- Could NOT find KF5ItemModels (missing: KF5ItemModels_DIR) Could NOT find KF5 (missing: ItemModels Su) (found suitable version -- Could NOT find KF5Su: found neither KF5SuConfig.cmake nor kf5su-config.cmake -- Could NOT find KF5Su (missing: KF5Su_DIR)
(In reply to Agostino Sarubbo from comment #0) > https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ > > Issue: app-portage/kuroo-1.2.1 fails to compile. > Discovered on: amd64 (internal ref: ci) > > NOTE: > This machine uses GCC-11: https://gcc.gnu.org/gcc-11/porting_to.html > If you think this is a GCC-11 related issue, please block bug 732706. The local machine development happens on is using GCC-11 so that seems unlikely to be the trigger. There's probably something deeper underlying. Anyways, thanks for the report, we'll look into it right away.
(In reply to A Schenck from comment #4) > The local machine development happens on is using GCC-11 so that seems > unlikely to be the trigger. There's probably something deeper underlying. > Anyways, thanks for the report, we'll look into it right away. This is rather simple, ebuild does not reflect the dependencies listed by upstream CMakeLists.txt file. KF5ItemModels -> kde-frameworks/kitemmodels KF5Su -> kde-frameworks/kdesu Packaging oversight or bogus deps upstream?
Created attachment 738934 [details] Ebuild including kitemmodels Finally finished testing trying to install in a clean VM after many delays. It is possible for the dependency tree to miss kitemmodels in default{,/desktop{,/gnome,/plasma}} profiles so long as plasma-{desktop,workspace} are not emerged, so it is pretty important to require it for anybody running an alternate DE.
Created attachment 738937 [details, diff] Don't depend on KDESu in CMakeFiles.txt Kuroo never actually linked to KDESu, it was just used in the desktop file to launch as super-user which is no longer necessary now. It will always be provided by something else in the dependency tree to satisfy find_package, but it's more correct to remove the call.
(In reply to A Schenck from comment #6) > It is possible for the dependency tree to miss kitemmodels in > default{,/desktop{,/gnome,/plasma}} profiles so long as > plasma-{desktop,workspace} are not emerged, so it is pretty important to > require it for anybody running an alternate DE. Not quite; ebuild must depend on everything required for it to build, as listed by the build system. It must not rely on deps of its deps, and most certainly not on the assumption of availability of an unrelated 3rd package, even if it is a toolkit adjacent DE.
(In reply to A Schenck from comment #7) > It will always be provided by something else in the dependency tree to satisfy > find_package, but it's more correct to remove the call. Ebuild must not rely on such assumptions. Please also be aware of the distinction: kde-frameworks/kdesu - "Framework to handle super user actions" kde-plasma/kde-cli-tools[kdesu] - "Build graphical frontend for kde-frameworks/kdesu" So if it depends on the kdesu binary to work, as the previous version did, it must have kde-plasma/kde-cli-tools:5[kdesu] in RDEPEND.
Created attachment 739063 [details, diff] Try to specify everything in CMakeLists Went through CMakeLists step by step and: 1. Delete each line of find_package( KF5 <modules> ) a. clean, reconfigure, and make b. if it fails add the line back 2. Delete each line of target_link_libraries a. clean, reconfigure, and make b. if it fails add the line back 3. execute less on the executables and add each library listed in the dynamic section to find_package and target_link_libraries a. except libstdc++, libm, libgcc_s, and libc 4. Sort these by which obviously make sense and which don't The result is this patch. Notably KItemModels and KDESu aren't needed, models are actually just Q(Abstract)ItemModel not K. Su was probably accidental thinking that it meant kde_cli_tools[kdesu] which was required previously in the desktop file, but not since 1.1. Sorry for causing so much trouble for you. Read most if not all of the pages about CMake in techbase, and documentation of the other KDE* and ECM* CMake modules to try to do everything correctly once and for all, hence all the other various changes. If this is right, it'll also require changing the ebuild of course.
At least these are bogus - your method seems to pick up deps of deps that are irrelevant to kuroo: > 64 # Shown in less but why? > 65 Sonnet > 66 Service > 67 Codecs Coming from some find_package dep(s), just ignore them: > 68 # feature_summary also reports these as OPTIONAL > 69 #Bookmarks > 70 #Completion > 71 #JobWidgets > 72 #Solid > 73 #WindowSystem Please use tools like e.g. lddtree which clearly indicates first-level dependencies as opposed to deps of deps.
Created attachment 739338 [details, diff] Full CMakeLists cleanup Thanks to asturm's guidance, these CMakeLists now find_package and target_link_libraries everything that is directly used by kuroo. The current ebuild in tree is already correct for these deps (except for skipping QtCore). KItemModels were never used, it uses Q(Abstract)ItemModels directly, KDESu was never used.
(In reply to A Schenck from comment #12) > The current ebuild in tree is already correct for these deps (except for > skipping QtCore). ecm.eclass provides dev-qt/qtcore to all ebuilds that inherit it. I notice that you bump your upstream minimum version requirements to align with up to date Gentoo stable versions. I'm not stopping you, but this is by no means necessary (and other projects are much more conservative and only update those versions as necessary by the code). I've stripped the attached patch from all unrelated noise to only contain the dependency fixes. Changes are queued up.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e4de64c9978b82a66c7d07913a32058f3d54c07d commit e4de64c9978b82a66c7d07913a32058f3d54c07d Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-09-22 21:20:20 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-09-22 21:59:09 +0000 app-portage/kuroo: Drop bogus dependencies Closes: https://bugs.gentoo.org/811693 Package-Manager: Portage-3.0.23, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> app-portage/kuroo/files/kuroo-1.2.1-cmake.patch | 108 ++++++++++++++++++++++++ app-portage/kuroo/kuroo-1.2.1.ebuild | 2 + 2 files changed, 110 insertions(+)
