Building G6K & FPyLLL currently fails

[ludopulles]

The newest cysignals package causes an error during ./bootstrap.sh resulting in a long list of error messages:

In file included from build/src/fpylll/fplll/lll.cpp:1359:
/pathtorepository/g6k/g6k-env/lib64/python3.12/site-packages/cysignals/macros.h: In function 'int _sig_on_prejmp(const char*, const char*, int)':
/pathtorepository/g6k/g6k-env/lib64/python3.12/site-packages/cysignals/macros.h:117:5: error: 'cysigs' was not declared in this scope
  117 |     cysigs.s = message;
      |     ^~~~~~
/pathtorepository/g6k/g6k-env/lib64/python3.12/site-packages/cysignals/macros.h:117:5: note: the macro 'cysigs' had not yet been defined
build/src/fpylll/fplll/lll.cpp:2815: note: it was later defined here
 2815 | #define cysigs (*__pyx_vp_9cysignals_7signals_cysigs)
      |
...

It's known: sagemath/cysignals#212

Temporary workaround: downgrade to cysignals version 1.11.4:

source ./activate
pip install --force-reinstall -v "cysignals==1.11.4"

[malb]

Yup, looks like we need to adapt FPyLLL to the current cysignals, I'll try to find some time to do this soon, but certainly not before the weekend. (Partial) PRs welcome :)

[ludopulles]

I'd say: wait for the issue in cysignals to be fixed and shipped :).

[AntonKueltz]

FYI poetry based builds are still broken because they use pyproject.toml to decide the cysignals version. I've proposed a change in the above PR and verified this locally. Happy to take any further steps needed to test and validate.

[dimpase]

Could we have a new minor release, as the now obsolete constraint on cysignals version blocks updating of a lot of stuff in sage?

[malb]

Done