Go1.18 is the next stable go release. There is already Go1.19
(released 2022-08-02), but we incrementally increase versions.
For Go1.18 there are already many bug fix releases (last one
2022-12-06) which gives it a more stable/mature impression.

/reviewed-on nexedi/slapos!1305

Go 1.18 is the incremental improvement for earlier go 1.17 release.
Is "is a significant release, including changes to the language,
implementation of the toolchain, runtime, and libraries". Please find
all details in the official release note:

    https://go.dev/doc/go1.18

It was released on 2022-03-15. Due to the go promise of compatibility
most software should still compile without any problems.

/reviewed-on nexedi/slapos!1305

2.x series do not have python3 support

keep 2.9.3 in ERP5 for now, because on master branch we are still
expecting version 2 (zope4py2 branch on the other hand needs version 3)

we have component/kerberos/

Include hash into revision to ensure reproducibility.

See nexedi/slapos!1309 (comment 175109).

New WC2 alpha release provides us with various small fixes:

    wendelin.core@5e5ad598...7ce0978d

It also prepares upgrading SlapOS go default version to v1.18
(WC2 alpha2 doesn't work with go1.18).

Tests passed: https://erp5js.nexedi.net/#/test_result_module/20221221-5FEF9030

/reviewed-on !1309

 Going from 1.17.6 to 1.17.13 gives us security and bug fixes.
 See at official changelog for details:
    https://go.dev/doc/devel/release#go1.17.minor

Passed tests: https://erp5js.nexedi.net/#/test_result_module/20221219-8E2857F

/reviewed at !1304
/reviewed-by @kirr

This is a fixup of 431eed50

The version of pandas was overwritten in
02fad6a8 but didn't work with python2.

Then the version was downgraded to 0.24.2 in
15569ea9 but ERP5 doesn't work with this
pandas version:
Traceback (most recent call last):
  File "/srv/slapgrid/slappart3/t/dgg/soft/63c49071f5be63057dd48d7a85c10226/bin/runTestSuite", line 325, in <module>
    import Products.ERP5Type.tests.runTestSuite
  File "/srv/slapgrid/slappart3/t/dgg/soft/63c49071f5be63057dd48d7a85c10226/parts/erp5/product/ERP5Type/__init__.py", line 92, in <module>
    from . import ZopePatch
  File "/srv/slapgrid/slappart3/t/dgg/soft/63c49071f5be63057dd48d7a85c10226/parts/erp5/product/ERP5Type/ZopePatch.py", line 30, in <module>
    from Products.ERP5Type.patches import Restricted
  File "/srv/slapgrid/slappart3/t/dgg/soft/63c49071f5be63057dd48d7a85c10226/parts/erp5/product/ERP5Type/patches/Restricted.py", line 491, in <module>
    allow_type(pd.indexes.range.RangeIndex)
AttributeError: 'module' object has no attribute 'indexes'

So reuse old version 0.19.2

version 0.25.3 is not python2 compatible.

Use version 0.24.2 as it is compatible with both python2 and python3.7
(even though we have no reason to use python3.7 nowadays).
See https://pypi.org/project/pandas/0.24.2/

This is a followup of 0d717989

This is a followup of 02fad6a8

This is a frontend used to provide information about various aspect of the
master instance status, like rejected slaves, failed failsafe slave
publication and maybe more.

Due to various reasons there might be an error while publishing information
about a slave, and such error would end up with stopping the processing of
the partition. This is undesired effect, thus switch to publish_failsafe style
in order to continue processing.

Publish only for active slaves.

Empty extra_slave_instance_list is a leftover of never fully working approach
of slaveless caddy-frontend implementation, so just drop it.

See merge request nexedi/slapos!1280

In some contexts it's required to not stop buildout processing on publishing
errors, thus such recipe is required in those cases.

By providing -error-status-file it's possible to check status of the publish,
the file will be created on error and removed on successful call or during
uninstall. It's responsibility of the caller to handle such errors, for example
by using proper promises.

Introduce macro.pythonpath.egg to compute during install the PYTHONPATH
of setup eggs required to install other eggs, and insert the PYTHONPATH
into the environment section such as used by zc.recipe.egg:custom.

Both numpy and scipy use a Python subprocess to call Cython in their
setup.py, therefore the setup-eggs option of zc.recipe.egg:custom
does not work because sys.path is not propagated to the subprocess.

See merge request nexedi/slapos!1301

See nexedi/slapos@22cc8e7e

See merge request nexedi/slapos!1251