See merge request nexedi/slapos!863

Allow each instance to support a zone list instead of a single zone.
Each slave is set for only one defined zone.

While caucase-updater aibcc was added, it was copy & pasted from aikc, and
by mistake it shared data_dir, which results with not working update of
certificates.

This fixes this issue introduced in "caddy-frontend: Setup backend client auth"

We are starting to use wendelin.core not only in Wendelin context.
So it makes sense to have it installed in base ERP5, like we already do for
example for NumPy and SciPy.

/reviewed-by @rafael, @jp
/reviewed-on nexedi/slapos!874

Having only one section [wendelin.core] instead of [wendelin.core] and
[wendelin.core-dev] is easier to handle in "we want to use such and such
particular version" scenarious without deciding in advance whether an SR needs
to inherit from wendelin/software.cfg or wendelin/software-dev.cfg

/reviewed-on nexedi/slapos!874

we no longer run tests with `python setup.py test`, so this hack is no
longer necessary.

See merge request nexedi/slapos!871

Further work by Vincent Pelletier:
- do not enable openldap dependency, we do not need such advanced features
  (yet ?)
- refresh noroot.patch
- if we this component is to reference m4, then it should extend it

Fixes FTBFS on gcc 10.

See merge request nexedi/slapos!872

This upgrade mainly fixes gpython and pymain to be more compatible with
CPython when handling command line. In particular it moves
sys.executable setup and -O handling into pymain:

nexedi/pygolang!10
nexedi/pygolang@21756bd3
nexedi/pygolang@11b367c6
nexedi/pygolang@8564dfdd

we no longer run tests with `python setup.py test`, so this hack is no
longer necessary.

in ceb063a4 (software/repman: tests python3 compliance, 2020-10-23), test
profile was changed to run on python3 only but this was accidentally
reverted in 3a1e5628 (software/slapos-sr-testing: use nxdtest, 2020-10-28),
by running repman also on python2.

Restore the situation where we run repman only on python3

The initial intent was to use an interpreter named `python_for_test` and not
`python`, so that software do not accidentally pick up this python during
compilation.
6033e4fa (software/slapos-sr-testing: fix python3 profile, 2020-12-01)
was a quick fix for some python3 compatibility issues discovered after merge,
but it was not correct, because by using ${python-interpreter:eggs}, it was
installing the default python-interpreter section, which has an interpreter
named `python`.

This caused issues while building proxysql, which assumes /usr/bin/env python
is python2.

The fix is to override python-interpreter directly, we don't need another
section eggs here.

This code seems not used, before 51c3773e and b77d7bae it was not possible to import.

See merge request !869

See merge request !870

the version up is needed to support more CPU architectures. For example,
version 0.2.18 was failing with Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz

This code error when it's imported, because it imports from a non existing,
slapos.tool module.
This is an "emergency commit" to repair the tests on python 3 after
 3a1e5628 (software/slapos-sr-testing: use nxdtest, 2020-10-28)

This code error when it's imported, because `install` does not exist on
this class, so the assignment caused NamError.
This is an "emergency commit" to repair the tests on python 3 after
 3a1e5628 (software/slapos-sr-testing: use nxdtest, 2020-10-28)

It got broken in 3a1e5628 (software/slapos-sr-testing: use nxdtest, 2020-10-28)

See merge request nexedi/slapos!865

This is to match Theia file hierarchy

See merge request nexedi/slapos!866

https://github.com/eclipse-theia/theia/blob/v1.8.0/CHANGELOG.md#v180---26112020

Until now, standalone subsystem was started as a daemon first time a terminal
was openned and since it was running as daemon, stopping the theia instance
did not stop any of the services running in the embedded slapos.

Before nexedi/slapos.core!265 there was
two supervisor running as daemon:
 - ~/srv/slapos/etc/supervisord.conf which runs slapos proxy etc
 - ~/srv/slapos/inst/etc/supervisord.conf with runs instances in the embedded
   slapos
After, the second one runs as a service in the first one, but the first one
was still running as daemon.

This changes so that the first supervisor runs as a service managed by the
Theia instance, so stopping Theia instance will effectively stop the services.

When upgrading, running instances should continue to run as detached. To
attach them to the new service, procedure could be something like this

Stop supervisors inside Theia instance:

  supervisorctl -c ~/srv/slapos/etc/supervisord.conf shutdown
  supervisorctl -c ~/srv/slapos/inst/etc/supervisord.conf shutdown

Restart slappartX:slapos-standalone-instance-XXX-on-watch from host slapos