- 10 Apr, 2024 2 commits
-
-
Ivan Tyagov authored
See merge request nexedi/slapos!1559
-
Ivan Tyagov authored
This reverts commit 3ff25131d56c7f66066b70191ac828a666600e92.
-
- 09 Apr, 2024 2 commits
-
-
Thomas Gambier authored
-
Thomas Gambier authored
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.
-
- 08 Apr, 2024 2 commits
-
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
- 07 Apr, 2024 1 commit
-
-
Kazuhiko Shiozaki authored
-
- 05 Apr, 2024 3 commits
-
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Jérome Perrin authored
SlapOS.Eggs.UnitTest-Master.Python2 also installs old scipy so it needs old gcc
-
- 04 Apr, 2024 2 commits
-
-
Łukasz Nowak authored
-
Thomas Gambier authored
See merge request nexedi/slapos!1557
-
- 03 Apr, 2024 5 commits
-
-
Thomas Gambier authored
-
Thomas Gambier authored
Also remove old unused gcc version
-
Thomas Gambier authored
unfortunately, there is no official release anymore so use a commit from master.
-
Thomas Gambier authored
-
Thomas Gambier authored
-
- 28 Mar, 2024 3 commits
-
-
Rafael Monnerat authored
This reverts commit 3d63cd39.
-
Rafael Monnerat authored
This reverts commit 1bd75eee.
-
Rafael Monnerat authored
-
- 26 Mar, 2024 7 commits
-
-
Rafael Monnerat authored
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.
-
Rafael Monnerat authored
For now the only exception is slapos_configurator only
-
Jérome Perrin authored
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
-
Ivan Tyagov authored
See merge request nexedi/slapos!1551
-
Ivan Tyagov authored
-
Ivan Tyagov authored
See merge request nexedi/slapos!1548
-
Ivan Tyagov authored
This reverts commit 5814aadb.
-
- 25 Mar, 2024 1 commit
-
-
Lu Xu authored
-
- 22 Mar, 2024 1 commit
-
-
Julien Muchembled authored
Grrr Jinja2 does not want me to write: {%- if any(node.get(x, 1) for x in ('admin', 'master', 'storage-count')) %}
-
- 21 Mar, 2024 4 commits
-
-
Lu Xu authored
-
Lu Xu authored
-
Lu Xu authored
-
Jérome Perrin authored
See https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED Setting a value will set the environment variable for all zope processes and for the test runner. Default behavior is: - for zope: do not set the variable, so default python behavior will be used ( equivalent to setting `0` on python2 and `random` on python3) - for test runner: generate a random value for each execution and print it, to make it easy to re-run a failing test with the same seed. This means that ERP5 tests will likely reveal problems where code depends on python2 behavior of deterministic hashing. To keep previous behavior (and hide these problems), it's possible to set python-hash-seed to 0 in test suite parameters.
-
- 20 Mar, 2024 3 commits
-
-
Paul Graydon authored
See merge request nexedi/slapos!1553
-
Thomas Gambier authored
See: nexedi/rubygemsrecipe!10 nexedi/slapos.buildout!29
-
Titouan Soulard authored
The CertificateAuthority tool in ERP5 uses UTF8 encoding for certificates, but by default OpenSSL does not. This cause an error when using non-ascii characters: ``` The localityName field is different between CA certificate and the request ``` To solve the problem, the Certificate Authority recipe should use the same encoding as ERP5, which requires adding `-utf8` option when invoking OpenSSL. For instance, creating a certificate with `localityName` Москва will give the following with the default OpenSSL encoding: `\C3\90\C2\9C\C3\90\C2\BE\C3\91\C2\81\C3\90\C2\BA\C3\90\C2\B2\C3\90\C2\B0`. UTF8-encoding this same string gives `\D0\9C\D0\BE\D1\81\D0\BA\D0\B2\D0\B0`, which is what ERP5 expects.
-
- 19 Mar, 2024 3 commits
-
-
Paul Graydon authored
-
Jérome Perrin authored
-
Rafael Monnerat authored
See merge request nexedi/slapos!1552
-
- 18 Mar, 2024 1 commit
-
-
Rafael Monnerat authored
-