Arch Linux User Repository

@nkeck72 eh, good question... it's the first time I see this happening to someone; I think it's safe to say your sources were up to date, makepkg pulls unpinned VCS sources every time it's run and I assume it stops the build on fetch failure. The build directory isn't cleaned unless one passes -C, but, AFAIK CMake is smart enough to track changes to project configuration as well as actual code, so it should trigger reconfiguration on make if CMakeLists.txt or its dependencies are newer than CMakeCache. Maybe something weird happened on your file system that made sources' mtimes unexpectedly older than your cache's mtimes. Could happen with an unreliable system clock if you are unlucky enough though I think you would have noticed. That or upstream is doing something very wacky with their project confs that breaks change detection (and it's the most complex piece of CMake I've seen by a mile so not totally unlikely). Either way I guess cleaning the build directory is the best first troubleshooting step if something goes wrong on something as complex as this piece of work ^^" but I wouldn't necessarily be doing it on a regular basis unless it's actually needed. Feel free to send more feedback as you go on updating to new versions just in case it's actually something broken with the build system after all.

@AquilaIrreale doing a clean build did indeed fix it. Thanks! In general, do PKGBIULDs based off CMake projects need occasional clean building like this to refresh what I assume is stale CMakeCache files?

@nkeck72 you may be building with stale sources, cmake_minimum_required version was updated to 3.18 by upstream Oct 9 2024, merged Oct 20 into the master branch used by PKGBUILD. Have you tried doing a clean build? (makepkg -C)

It appears that this package is set to a compatibility level in CMakeLists.txt that cmake no longer supports:

CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.


-- Configuring incomplete, errors occurred!

Unless CMakeLists.txt is written with explicit behavior that is only supported below version 3.5, it might be a good idea to patch the cmake_minimum_required line to report 3.5 or higher. I realize this is an upstream problem but it's easily patched in the meantime until they get their sources fixed.

@ccorn Thank you, fixed.

The current CADO-NFS git snapshot needs depends+=(python-flask python-requests).

@Robin_Jadoul patch wiggled, thank you for your report

fmt.patch doesn't apply anymore. Regenerating it by manually commenting out the line and saving the resulting git diff seems to make everything work fine again.

@gilcu3 the [ was not extra (it is a special character to be escaped) but apparently, depending on the sed implementation, when present inside a character class it has to be at the very end of it; fixed.

Regarding the strip option, if that's the case then we'll have to keep the sed and -ffile-prefix-map in as you proposed.

@AquilaIrreale in the last version there is an extra character in the sed command line 70 (one extra '[') which breaks the packaging.

Regarding fixing the commit hash, yes I only had it because at some point building was not working in the last commit, must have been fixed already.

Regarding the strip option, yes I get ==> WARNING: Package contains reference to $srcdir even with the option on.