As we have runners with a section deployed using
collective.recipe.shelloutput, if collective.recipe.shelloutput isn't in
the SR folder anymore thisi section can't be uninstalled (as the
uninstall method is defined in the egg).

The output of buildout for this error was :

While:
  Installing.
  Uninstalling runner-sshkeys-publickey-fingerprint-shelloutput.
  Installing recipe collective.recipe.shelloutput.
  Getting distribution for 'collective.recipe.shelloutput'.
Error: We don't have a distribution for collective.recipe.shelloutput
and can't install one in offline (no-install) mode.
While:
  Installing switch_softwaretype.

The cause was f936ea2c

Starting from slapos.recipe.build@5e95d882 gitclone should have built-in support for submodules. Credit: Kirill.

The error was :

 Error: The following paths are already installed by other sections:
 {'/opt/slapgrid/4eb4146f38fc86ed2ad060217a1a95a6/bin/slapos-watchdog':
 'extra-eggs',
 '/opt/slapgrid/4eb4146f38fc86ed2ad060217a1a95a6/bin/networkcache-download':
 'slapos-cookbook',
 '/opt/slapgrid/4eb4146f38fc86ed2ad060217a1a95a6/bin/slapos':
 'extra-eggs',
 '/opt/slapgrid/4eb4146f38fc86ed2ad060217a1a95a6/bin/generate-signature-key':
 'slapos-cookbook',
 '/opt/slapgrid/4eb4146f38fc86ed2ad060217a1a95a6/bin/networkcache-upload':
 'slapos-cookbook'}

There was a typo and anyway it wouldn't have worked because of
nexedi/slapos.buildout!11

Mostly useful for components that are built with cmake.

c++ already exists. cmake searches for c++ in the same folder as it found cc.

Another part wrote to etc/service/frontend_apache, which resulted of
impossibility to start apache after instance is restarted.

The issue is that the upstream package has been bworked (it is not
a .tar.gz in reality), which explains why the md5sum changed).

The source code is also available on github, but with a 3rd md5sum.

This reverts commit 2f705697.

See merge request !723

See merge request !724

Since `buildout 2.7.1+slapos002`, we `Check that sections don't installed the same path`, so we need to adjust some profiles which were not respecting this rule.

This fixes the regression introduced by nexedi/slapos@bbd70f7d

See merge request !726

use another port so that we can run tests on test node, port 8080 is
already used by testnode.

Install a promise so that we know when instance is ready
Use a builout.hash.cfg for easier management

By using a short filenames like "httpd.crt" or "httpd.key", we risk have
conflict with users of this stack. Use a name with more context, that
should likely not be used by applications.

This solves an issue with lamp stack, that was visible with nextcloud
software:

     While:
       Installing ca-apache-php.
     Error: The following paths are already installed by other sections: {'/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/inst/ncs2/srv/ssl/certs/httpd.key': 'ca-monitor-httpd', '/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/inst/ncs2/srv/ssl/certs/httpd.crt': 'ca-monitor-httpd'}

We were using caddy-log-access-header to make sure we have at least one
file to include, but this was implemented in a way that the config file
was overwritten.
Reimplement this by using caddy-log-access-empty to create an empty file
when there are no slaves, caddy-log-access otherwise.

If we list eggs as eggs= of a zc.recipe.egg section, the scripts of these eggs
will be installed again.

This fixes this error while building:

    While:
      Installing extra-eggs.
    Error: The following paths are already installed by other sections: {'/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/soft/72b4c4e0472506664a0cb3cc44bbb0b2/bin/caucased-manage': 'caucase-eggs', '/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/soft/72b4c4e0472506664a0cb3cc44bbb0b2/bin/caucase-key-id': 'caucase-eggs', '/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/soft/72b4c4e0472506664a0cb3cc44bbb0b2/bin/caucase-updater': 'caucase-eggs', '/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/soft/72b4c4e0472506664a0cb3cc44bbb0b2/bin/caucase-rerequest': 'caucase-eggs', '/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/soft/72b4c4e0472506664a0cb3cc44bbb0b2/bin/caucase': 'caucase-eggs', '/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/soft/72b4c4e0472506664a0cb3cc44bbb0b2/bin/caucase-probe': 'caucase-eggs', '/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/soft/72b4c4e0472506664a0cb3cc44bbb0b2/bin/caucased': 'caucase-eggs'}

The same caddy-log-access section was defined more than once, keep only
one implementation.
Remove some trailing spaces.

library dir is lib64 in that case

npm invokes node from $PATH, so make sure we have proper node version in
PATH.

-e is already set by default in slapos.recipe.cmmi 0.13

let's use the one from stack/slapos.cfg because there's a version
confict

Test Mariadb in ERP5 SR test and a few cleanups, mainly around mariadb:
 - We need a more "strict" promise than just checking if something is listening on the port
 - We don't need to wait so long between setup retries
 - We can use mroonga provided setup script instead of writing the setup ourselves.

See merge request !722

Buildout complains that two sections can not write to same file (rightfully) thus rewrite in same section.

In Ubuntu 19.10, we use GCC 9.2.1 and glib was failing to compile with
the following message:

  CC       libgio_2_0_la-gdbusauth.lo
gdbusauth.c: In function '_g_dbus_auth_run_server':
gdbusauth.c:1302:11: error: '%s' directive argument is null [-Werror=format-overflow=]
 1302 |           debug_print ("SERVER: WaitingForBegin, read '%s'", line);
      |           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors

So we apply this MR:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/626
corresponding to this commit:
https://gitlab.gnome.org/GNOME/glib/-/commit/2a9ddc630341789c629c17c17565f5a7a7db8a8e

"gdbus: Avoid printing null strings"

This does not seem to use autoheader and automake, these commands exists
with error code and don't touch any local files when executed, so don't
run them, because since slapos.recipe.cmmi 0.13, we check exit code of
each command in multi line commands

This mysql_update service retries every 30 seconds, but what usually
happens is that it starts at same time as mariadb, make a first attempt
at connect which fails because mariadb is not ready, sleep for 30
seconds, reties and succeed. Which is not efficient because we don't
need to wait for so long.
Instead of sleeping for 30 seconds between each retries, start with a
short delay and increase each time, but not more than 30 seconds.