by default on riscv architecture, the libffi.so will be placed in
lib/lp64d but everywhere else in buildout (and especially for the
compilation of python3) we expect the lib to be in lib/ directory.

Revert "component/default: system gcc can be used only if all gcc, g++ and gfortran exist and their versions are same."

This reverts commit eb7edc8ff1cba0667e31d75bc0dc61031ae1ba53.

component/default: system gcc can be used only if all gcc, g++ and gfortran exist and their versions are same.

software/slapos-sr-testing: add erp5-py3

---

WIP ERP5: XXX dumps() parameter for longrequest promise 🚧

Not sure why it was OK on python2 and not sure if this has to be done
or the promise code needs to cast the results of getConfig()

---

py3: do not enable NEO test yet 🚧

at this point they all fail after long timeouts, because neo does not
support py3 yet

stack/erp5: version up APacheDEX 2.0 (py3 only)
Co-authored-by: Kazuhiko SHIOZAKI <kazuhiko@nexedi.com>
Co-authored-by: Arnaud Fontaine <arnaud.fontaine@nexedi.com>
Co-authored-by: Bryton Lacquement <bryton.lacquement@nexedi.com>

This reverts commit 6c399134.

SlapOS.Eggs.UnitTest-Master.Python2 also installs old scipy so it needs
old gcc

See merge request nexedi/slapos!1557

Also remove old unused gcc version

unfortunately, there is no official release anymore so use a commit from
master.

This reverts commit 3d63cd39.

This reverts commit 1bd75eee.

  The backend haproxy must not handle the arbitrary variable Remote-User from headers.

It isn't implemented authentication on this backend, so this setting is irrelevant by default.

The proper way to handle authentication is use a trustfull frontend that will set this variable after properly authenticate the certificate and extract the user.

  For now the only exception is slapos_configurator only

While running tests using all.bash, `$HOME/.cache/go-build/` is
populated with data referencing the build folder. This is problematic
when using shared parts and installing a not pinned software release
multiple times, like it is the case on test node.

A scenario like this can happen:

 - a first succesful build install in `<shared>/golang1.21/<HASH1>`
 - golang1.21 section is changed in a the software release
 - golang1.21 is installed in `<shared>/golang1.21/<HASH2>`, running
   test fails because the cache `<software_folder>/.cache/go-build/` in
   references paths from `<shared>/golang1.21/<HASH1>/.build/go/src`,
   that was used when building the first build and have been removed
   while installing.

This is visible with errors like this:

    2024-03-21 20:52:37,214 INFO     slapgrid_sr: 2024-03-21 20:52:37 slapos[23849] INFO vet: can't parse raw cgo file: open ../../../../a984f246a1b2789081965ab5c05674a8/.build/go/src/net/cgo_linux.go: no such file or directory

See merge request nexedi/slapos!1551

See merge request nexedi/slapos!1548

This reverts commit 5814aadb7234c6772e855c5549afbb09feeb1f5e.