see cloudooo@0b5ff71a

So that the service names match the backend names in haproxy

Libreoffice needs to run with an UTF-8 locale, otherwise it does not use proper
encoding for text files.
cloudooo sets a default locale as a fallback, but using en_US.UTF-8, which is
not always present (it is not present on capri testnodes). Anyway, this kind
of configuration is the job of slapos, so we prefer to have it done at slapos
level.

https://mesonbuild.com/

The keyboard option is actually not recommended in the QEMU
documentation
(https://manpages.debian.org/buster/qemu-system-x86/qemu-system-x86_64.1.en.html).
After some tests, it appears that noVNC is already sending raw keyCode
to QEMU since 2016 (see
https://github.com/novnc/noVNC/commit/f4f4e8993d6daeb43b957766cd6973993232ba13).

More information can be found in
https://github.com/novnc/noVNC/issues/21 and
https://www.berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/

rotate_size 0 or rotate_size -1 does not help to disable rotation, so
workaround it by setting very big rotation limit.

See merge request nexedi/slapos!968

It was formatted with a '\t', which json-schemas test does not allow.

We are not using this

This host header is not passed by default, because we are already using
proxy_set_header, so we need to set it explicitly.

It seems that since we updated some packages in in 279486fe (stack/slapos:
version up some eggs with known vulnerabilties, 2021-01-28) slaprunner was
producing URLs with "localhost" as hostname when using redirect(url_for(...))

As discussed in https://github.com/nextcloud/news/issues/1306 a new release was
uploaded.

See merge request !939

Commit 2f4d8cf8 fixed the following error:

  Generating phar.php
  .../parts/apache-php__compile__/php-7.3.6/sapi/cli/php: error while loading shared libraries: libzstd.so.1: cannot open shared object file: No such file or directory
  Makefile:420: recipe for target 'ext/phar/phar.php' failed

and only -rpath is needed.

apache-php does not actually depend on zstd (hence the removal of the 'extends'
line) but there's something not smart:

  $ ldd .../parts/apache-php__compile__/php-7.3.6/sapi/cli/php
        linux-vdso.so.1 (0x00007ffe29f86000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f625e64a000)
        libcrypto.so.1.1 => .../shared/openssl/.../lib/libcrypto.so.1.1 (0x00007f625e35e000)
        libssl.so.1.1 => .../shared/openssl/.../lib/libssl.so.1.1 (0x00007f625ea05000)
        libzip.so.5 => .../shared/libzip/.../lib/libzip.so.5 (0x00007f625e9ea000)
        libz.so.1 => .../shared/zlib/.../lib/libz.so.1 (0x00007f625e142000)
        libargon2.so.1 => /srv/slapgrid/slappart10/srv/runner/software/.../parts/argon2/lib/x86_64-linux-gnu/libargon2.so.1 (0x00007f625e9de000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f625df3a000)
        libldap-2.4.so.2 => .../shared/openldap/.../lib/libldap-2.4.so.2 (0x00007f625e991000)
        libsasl2.so.3 => .../shared/cyrus-sasl/.../lib/libsasl2.so.3 (0x00007f625e973000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f625dd36000)
        liblber-2.4.so.2 => .../shared/openldap/.../lib/liblber-2.4.so.2 (0x00007f625e963000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f625db1f000)
        libstdc++.so.6 => .../shared/gcc-8.4/.../lib/../lib64/libstdc++.so.6 (0x00007f625d994000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f625d690000)
        libintl.so.8 => .../shared/gettext/.../lib/libintl.so.8 (0x00007f625d485000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f625d0e6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f625e882000)
        libjpeg.so.9 => .../shared/libjpeg/.../lib/libjpeg.so.9 (0x00007f625e924000)
        libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f625cece000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f625ccb1000)
        libcurl.so.4 => .../shared/curl/.../lib/libcurl.so.4 (0x00007f625e8ac000)
        libnghttp2.so.14 => .../shared/nghttp2/.../lib/libnghttp2.so.14 (0x00007f625cc87000)
        libzstd.so.1 => not found
        libfreetype.so.6 => .../shared/freetype/.../lib/libfreetype.so.6 (0x00007f625cbe8000)
        libbz2.so.1.0 => .../shared/bzip2/.../lib/libbz2.so.1.0 (0x00007f625cbd5000)
        libpng16.so.16 => .../shared/libpng/.../lib/libpng16.so.16 (0x00007f625cba0000)
        libicui18n.so.58 => .../shared/icu/.../lib/libicui18n.so.58 (0x00007f625c914000)
        libicuuc.so.58 => .../shared/icu/.../lib/libicuuc.so.58 (0x00007f625c762000)
        libicudata.so.58 => .../shared/icu/.../lib/libicudata.so.58 (0x00007f625ae60000)
        libicuio.so.58 => .../shared/icu/.../lib/libicuio.so.58 (0x00007f625ae50000)
        libxml2.so.2 => .../shared/libxml2/.../lib/libxml2.so.2 (0x00007f625aaef000)
        libgcc_s.so.1 => .../shared/gcc-8.4/.../lib/../lib64/libgcc_s.so.1 (0x00007f625aad5000)
        libzstd.so.1 => .../shared/zstd/.../lib/libzstd.so.1 (0x00007f625a9fb000)

(look at the 2 'libzstd.so.1 => ' lines above)

  $ grep zstd .../shared/curl/.../lib/pkgconfig/libcurl.pc
  supported_features="..."
  Libs.private: -lnghttp2 -lssl -lcrypto -lssl -lcrypto -lzstd -lzstd -lz -pthread

  $ ldd .../shared/curl/.../lib/libcurl.so.4
        linux-vdso.so.1 (0x00007ffc42b15000)
        libnghttp2.so.14 => .../shared/nghttp2/.../lib/libnghttp2.so.14 (0x00007f54315d5000)
        libssl.so.1.1 => .../shared/openssl/.../lib/libssl.so.1.1 (0x00007f543153f000)
        libcrypto.so.1.1 => .../shared/openssl/.../lib/libcrypto.so.1.1 (0x00007f5431168000)
        libzstd.so.1 => .../shared/zstd/.../lib/libzstd.so.1 (0x00007f543108e000)
        libz.so.1 => .../shared/zlib/.../lib/libz.so.1 (0x00007f5430e72000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5430c55000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f54308b6000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f54306b2000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5431454000)

This fixes the following random failure:

   .../shared/nano/3a832cf2f5e8161a0cbd45936bbdac02/bin/rnano uses system library /lib/x86_64-linux-gnu/liblzma.so.5.2.2 for liblzma.so.5

Even though there is no integrated way of putting for fonts there, cloudooo supports additional fonts in `~/srv/font`

This was not working because of a leading space in the fontconfig

See merge request nexedi/slapos!966

This complements 7f877621 (Move wendelin.core from Wendelin to ERP5) and
introduces new WCFS service into ERP5 software-release to support
upcoming wendelin.core 2. Wendelin.core 2 will introduce new WCFS
filesystem server component that serves in-ZODB arrays data as OS files
for Zopes to memory-map. Please see the following links for overview of
what WCFS is and how it interoperates with and serves Python clients:

https://lab.nexedi.com/kirr/wendelin.core/blob/b5fc98bb/wcfs/wcfs.go#L20-247
https://lab.nexedi.com/kirr/wendelin.core/blob/b5fc98bb/wcfs/client/wcfs.h#L20-96

Implementation notes:

- WCFS is by default disabled in ERP5 - we do not want to load every
  ERP5 user with it in the early days of wendelin.core 2. WCFS service
  will also not work when ERP5 is built with wendelin.core 1, so keeping
  it disabled by default is reasonable for now.

- There is a duplication for instance-erp5.cfg.in in between stack/erp5/
  and software/slapos-master/ . It was negotiated with VIFIB developers
  to go this way instead of first deduplicating instance-erp5.cfg.in
  copying that was started in 87d13789 (slapos-master: Copy files from
  erp5 stack for local changes).

To enable wcfs one can either pass `wcfs` configuration parameter, or
add the following to a software-release that uses stack/erp5:

  [erp5-defaults]
  wcfs-enable-default = true

/cc @rafael, @tomo

This prevent some Fontconfig warnings ("empty font directory name ignored")
when the software includes empty items, which can easily happens with multi
level templates.

${directory:font} had an extra level of indentation, so in the rendered
fonts.conf it had a leading space and was not recognized.

This is the same permissions as all other log files from ERP5