nit: Could use the STR_INTERNAL_BUG helper, while touching this?

(same)

forgot to remove the include?

[12:05:51.093] /ci_container_base/src/util/check.cpp should remove these lines:
[12:05:51.093] - #include <clientversion.h>  // lines 9-9
[12:05:51.093] 

However, the CLIENT_NAME symbol is still used in the kernel, so I am not sure removing the link dependency is meaningful. I'd say it should either be removed fully, or it can be kept. If you just want to turn the link-time dependency into a compile-time dependency, this is also possible, because everything can be done at compile-time. Proof:

diff --git a/src/clientversion.cpp b/src/clientversion.cpp
index 10e9472b84..acf01ff1bb 100644
--- a/src/clientversion.cpp
+++ b/src/clientversion.cpp
@@ -55,8 +55,8 @@ static std::string FormatVersion(int nVersion)
 
 std::string FormatFullVersion()
 {
-    static const std::string CLIENT_BUILD(BUILD_DESC BUILD_SUFFIX);
-    return CLIENT_BUILD;
+    constexpr std::string_view CLIENT_BUILD{BUILD_DESC BUILD_SUFFIX};
+    return std::string{CLIENT_BUILD};
 }
 
 /**

(Happy to submit a proper pull making it constexpr, if you want)

forgot to remove the include?

yes -_-

However, the CLIENT_NAME symbol is still used in the kernel,

Mmh, that is done though the config header, and I am not sure how we should handle that yet. Seems like a separate problem to me? Then again the clientversion header is little more than some formatting helpers for some of these variables. Could also remove CLIENT_NAME in the few cases where it is relevant, but CLIENT_BUGREPORT is probably useful to keep.

I'd say it would be best to keep all of them. Maybe I am missing the context, but I fail to see how the client version is irrelevant. "they can easily find its version when reporting the bug" doesn't sound great, because some people forget it, and it will just be another round-trip.

Also, I'd say it is important to know if the user ran some local (or remote) modifications. Lately it seems common to fork random commits of bitcoin core and apply random (policy or non-policy) patches. We'd want to quickly reject those, after assessing the bug has nothing to do with any commit in a release or master branch of Bitcoin Core.

Also, I'd say it is important to know if the user ran some local (or remote) modifications. Lately it seems common to fork random commits of bitcoin core and apply random (policy or non-policy) patches. We'd want to quickly reject those, after assessing the bug has nothing to do with any commit in a release or master branch of Bitcoin Core.

I did not think about this yet. I guess that could save a bug report round-trip, or at least help with reducing confusion a bit. Then again, some people are just forking the project on master and tag some past version on it. That could be equally confusing, no?

Then again, some people are just forking the project on master and tag some past version on it. That could be equally confusing, no?

Hopefully that is rare. Though, just including the full commit hash in bug reports shouldn't hurt.