Live-git kde-frameworks via the gentoo/kde project overlay live-git packages. HEAD at 5a1445bd0. (The build first failed during normal update, but I tried again after everything else finished and ultimately bisected to the below commit, so it's not a dependency-order issue.) Commit 5732a12a9 "Add pre-commit hook for clang-format" fails configure with the following warning and error: CMake Warning at /usr/share/ECM/kde-modules/KDEGitCommitHooks.cmake:63 (message): No clang-format executable was found, skipping the formatting pre-commit hook Call Stack (most recent call first): CMakeLists.txt:137 (kde_configure_git_pre_commit_hook) CMake Error: File /usr/share/ECM/kde-modules/kde-git-commit-hooks/pre-commit.in does not exist. CMake Error at /usr/share/ECM/kde-modules/KDEGitCommitHooks.cmake:66 (configure_file): configure_file Problem configuring file Call Stack (most recent call first): CMakeLists.txt:137 (kde_configure_git_pre_commit_hook)
This is weird, it works for me with my kdesrc-build setup and when updating the ECM package with apt (Neon Unstable) the file exists. And when I uninstall clang-format and make a clean build I just get a warning.
PS: The build passes on the CI: https://build.kde.org/job/Frameworks/job/ktexteditor/. And there the dependencies were rebuild yesterday, so most likely this is a packaging issue :)
(In reply to Alexander Lohnau from comment #2) > so most likely this is a packaging issue :) Filed downstream as https://bugs.gentoo.org/765889 This may well be the first of several bugs given the recent ecm git-hooks commit (which I understood why but wondered about the bugs it might generate when I saw it), so however this ultimately gets resolved will let me see where I file those bugs. =;^|
(In reply to Duncan from comment #3) > (In reply to Alexander Lohnau from comment #2) > > so most likely this is a packaging issue :) > > Filed downstream as https://bugs.gentoo.org/765889 Thanks! > This may well be the first of several bugs given the recent ecm git-hooks > commit (which I understood why but wondered about the bugs it might generate > when I saw it), so however this ultimately gets resolved will let me see > where I file those bugs. =;^| I honestly do not understand what you mean. The error that the file does not exist should definitely get fixed. After that you will just get a warning that there is no clang-format executable found, but that is not a critical error.
(In reply to Alexander Lohnau from comment #4) > (In reply to Duncan from comment #3) > > This may well be the first of several bugs given the recent ecm git-hooks > > commit (which I understood why but wondered about the bugs it might generate > > when I saw it), so however this ultimately gets resolved will let me see > > where I file those bugs. =;^| > > I honestly do not understand what you mean. The error that the file does not > exist should definitely get fixed. After that you will just get a warning > that there is no clang-format executable found, but that is not a critical > error. Apologies in advance as this ends up being a bit of a wall of text... [Just to make the context explicit in case someone hasn't seen the logs or comes back to this in a few months, it's extra-cmake-modules 45edd1b17 and followups. And explicit thanks to you the author as well; it's surely going to improve things in general! That said...] Perhaps an existing example will make things clearer. Tests. I'm sure everyone agrees integration testing is critical. I believe devs normally run with them enabled (as they should) as does the testing machinery (the point, for it!). But users building from source, gentooers, linux-from-scratchers, perhaps archers, others, may turn off testing at configure time (it's an available package-manager-config togglable feature on gentoo), because for them tests are actually building and running the software, and testing at build-time can both take much more time and pull in all sorts of additional deps. The problem is that because devs and their testing machinery always have testing enabled, the non-testing option tends to bit-rot and tends to be broken on enough packages enough of the time that gentoo/kde at least has an entire set of machinery dedicated to allow testing to be forced off where upstream overlooked it and automate the easiest breakage fixes, so the only no-testing breakage they have to spend per-package time on is breakage that's not so easily automated away. It eventually gets fixed upstream, but by then there's other no-test breakage elsewhere, so it tends to be an unending battle. [After writing the above I wonder: Would an integration tests setup that included build-testing for failures with testing turned off help catch this sort of no-testing bugs? Would it be worth it? Come to think of it, it has been awhile since I needed to report such a bug. I know gentoo/kde upgraded their automation for it a few months ago. That probably helped, but maybe upstream kde setup a no-tests test too? Anyway...] This git-hooks feature looks, at least initially, like it could be similar. It's another feature like testing that devs might overlook where their configuration is likely to be different from that of some of the direct users, thus triggering another opportunity for new code designed to take advantage of the feature to break for users who don't have that feature enabled, due to inadvertently hard-coded assumptions that don't hold for those users and their build environment. So overall it's good, even GREAT!, but like many good/GREAT! things, I'm afraid there are likely to be some relatively smaller negatives that partially offset the goodness. And due to my personal position in the ecosystem running live-git so catching and bug-reporting these things before they can affect others, I'm likely to be particularly heavily affected by any such negatives. So pardon my grumpiness, even if I know it's part of what I deliberately undertook by choosing to run live-git! =:^) Maybe I'm wrong and this isn't going to trigger an entire new genre of bugs akin to those I've seen and reported for testing, or sometimes seen the aftermath of in the git logs at both the gentoo and upstream levels, and like testing it's surely worth it even if it does, but that possibility is what I was alluding to and am afraid of. But if this /is/ the first of such an entire new genre of bugs hatched by this thing, how this one gets resolved will help me know where to file and what details I need to include on the others, when they come.
The last comment on the linked gentoo report suggests that it is a file permissions problem. Can you confirm?
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/77
(In reply to David Edmundson from comment #6) > The last comment on the linked gentoo report suggests that it is a file > permissions problem. > > Can you confirm? Looks like you're ahead of me, but confirming. root:root 0700 perms initially for both pre-commit.in and clang-format.sh, while the build is done using non-root system (package-manager) user portage:portage, so obviously it can't read/execute them. But the MR suggests read/execute (0755 I think) and read (without execute), 0744 or even 0644 (I tested both), seems to be all that's actually needed. They need to be readable, but executable, not so much.
Git commit 7b835ca4d837f22c49f88dabc256569a80692c6d by Alexander Lohnau. Committed on 18/01/2021 at 14:23. Pushed by alex into branch 'master'. Fix permissions for scripts On Gentoo the permissions are differently set, which causes problems when running cmake. FIXED-IN: 5.79 M +1 -2 CMakeLists.txt https://invent.kde.org/frameworks/extra-cmake-modules/commit/7b835ca4d837f22c49f88dabc256569a80692c6d