Arch Linux User Repository

@gilcu3 ah yeah, I missed url when I updated the sources variable, thanks for pointing that out.

#3 is online, lmk if you find any other issues

@AquilaIrreale thank you for the long explanation. I agree with your conclusions, and would probably just go for 3. Maybe at some point they will stop adding these files upstream, and then the dirty patch can be removed.

BTW the upstream url is broken now, maybe it is time to change it to https://gitlab.inria.fr/cado-nfs/cado-nfs

@gilcu3 yeah, I've been thinking on the best way to tackle that since last time I upgraded cado myself, those headers make it incompatible with at least sagemath which I expect many OSS math people would like to have installed on their systems alongside cado.

This is where we at right now: cado needs gf2x, which arch distributes in the official repos as a shared object, and is used in this form by sagemath et al. Critically though, cado needs a version of gf2x which has a couple of additional header files that the official arch package doesn't provide (don't know why). cado's build system notices this and marks the system-provided gf2x copy as "not found", switching back to a vendored version they keep in the cado repo itself. They build it as a static library, link it and I'm pretty sure they don't need the headers after that, as you pointed out. The vendored gf2x copy uses a different build system than cado (automake-based). I guess cado's make install is wired to call gf2x's make install even though it really doesn't need to, since everything there is statically linked.

I could think of three ways to tackle this:

1. write a gf2x-cantor package based on the official one which provides+conflicts gf2x, make cado-nfs-git depend on that instead of the system one, have sage & co. use that instead of the official one.
2. try and find out how to unwire gf2x's make install from cado's make install
3. keep everything as is, rm gf2x files from the pkg directory right after cado's make install

#1 is the cleanest distro-wise, seems too much of a burden though as this gf2x-cantor package would need to keep up with arch's version to avoid breakages and not to hold up possible security updates, and I do not have much time to do package maintenance these days unfortunately.

I was thinking about #2, but haven't find a way to do it as of today.

#3 is quick & dirty but in the interest of keeping it working may be the way to go in the end, if you do not have a better idea...

This package is currently writing files at /usr/include/gf2x* and conflicts with gf2x. Best solution would be to avoid installing those files, but I am not sure if they were modified from upstream.

EDIT: Actually those files probably went there by mistake. Why would cado-nfs need header files? I dont think they are compiling things on the fly...

@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).