Sometimes, gitlab and qemu are reported by software release tests to link against libcap-ng and libzma from system. This happens when the development packages are installed on the system.

Approach here is to build with slapos version of the libraries.

See merge request nexedi/slapos!789

Using an script to set the environment is easier to use, but the main
reason is that if we want to be able to use shared part from outer
slapos (like when using in theia or slaprunner), the working directory
for test must be contained in the instance directory of the outer
slapos, so that when we run slapos node prune in the outer slapos this
command can see that shared parts are used.

This was using zlib and lzma from system if they are available, so we
tell bundler to use the slapos version.

We have to use both in --with-cflags for nokogiri itself and as CFLAGS
environ for when nokogiri build its included libxml2

don't let configure autodetect and build something different depending
on the presence of this library on the host system

Explicitly build with libcap-ng instead of depending on presence of the
development library on the host.

Also fix the way of disabling tinfo, there was warning at the end of
configure saying this option is not used

Backend logs are exposed as usual access and error logs.

By using rsyslogd templates and regex filtering, the rsyslogd reacts itself
and creates needed files per each slave which accesses it. Thanks to this, it's
configuration is static from point of view of SlapOS profiles, and can be
generated once.

As the rsyslogd configuration became fully special to backend-haproxy, the
rsyslogd template filename and its references has been correctly renamed.

Logs are critical for caddy-frontend, so let's configure rotate-num locally,
as changes in the stack can come unattended, and can result with loosing logs.

We moved out from local logrotate configuration long time ago, it was just
leftover.

haproxy by itself provides good information, so there is no need to add
information from rsyslogd itself.

The logrotate folder also serves as an publication folder for logs, so be sure
that logs are linked there.

While building haproxy on one machine, and using it on another, the CPU
optimisations can lead to haproxy not working at all on other CPUs.

In context of SlapOS packages are distributed in binary form, so haproxy
binary has to support all CPUs.

ATS was upgraded from 7.1.6 to 7.1.11

Patches taken from https://github.com/spack/spack/pull/15403

Setting max_version to 0 is less hacky. Also, it's not only for tarball
preparation, the package is created the same way.

There is no reason to drop connection to the backend and then reinitate it on
each request. It's better to keep connected and avoid additional work,
especially in SSL handshake.

Note: This was kept as the file has been copied from other place (haproxy
      on a backend), and slipped MR review, where MR author wanted to drop it
      anyway.

version up to current version (0.13.0) and include configuration to make use of slapos.core!218

Also switch to gopls and include jdk, with all preliminary support for patchelf.

See merge request !774

we need the patch to be able to build with gcc 10 (used on Archlinux for example).
See https://bugs.gentoo.org/705898
patch is coming from https://705898.bugs.gentoo.org/attachment.cgi?id=603950

When running tasks, shell is invoked like:

   $THEIA_SHELL -c "command with arguments that\ can\ contain\ spaces"

The version from theia images does not support running from a plugin
installed in a read only folder, this newest version seem to work.

Also set the required java.home setting

So that gitlens extension (which can be installed per-workspace) knows
how to open files from lab.nexedi.com in browser

so that we can easily use python version 2 or 3 during development and
local testing.

This python is not directly usable with python extension, pip needs to
be installed as user, following:
https://pip.pypa.io/en/stable/installing/#installing-with-get-pip-py

by logging the process output

so that frontend requests are requested as theia computer partition.
Practically this means that if theia is installed on slapos master,
frontend requests for slapos inside theia partition will be requested as
this theia instance.

When updated to 4.8.1 the cursor "shadow" rendering is incorrect

workaround for https://github.com/eclipse-theia/theia/issues/8158

So that parts are shared when we install ERP5 in theia

Not much tested but it looks working