See merge request !1341

Running theia with yarn start cause PATHs like this to be
added to $PATH

/srv/slapgrid/slappart15/tmp/yarn--1675226243379-0.20314216826775944/node

Similar to debian's default /etc/skel

this can be used to install linters such as pylint when the python
extension prompts for it

also add ~/.local/bin in user $PATH to prevent warning and to be
able to use pip installed packages from the shell.

update all egg versions for python packages used in theia

make zc-buildout.python.executable relative to instance

This settings.json is only generated one, so we can not use the
absolute path, because this will reference an old version of software

This does not work as expected with in this situation :

   bash-5.1$ which slapos
   /usr/bin/slapos
   bash-5.1$ /usr/bin/which slapos
   /opt/slapgrid/d4af5a4bc0958cc5f60fac0dbf6c916e/bin/slapos
   bash-5.1$ ls -al /opt/slapgrid/d4af5a4bc0958cc5f60fac0dbf6c916e/bin/slapos
   -rwxr-x--- 1 slapsoft slapsoft 3492 Jan 31 10:01 /opt/slapgrid/d4af5a4bc0958cc5f60fac0dbf6c916e/bin/slapos
   bash-5.1$ id
   uid=957(slapuser39) gid=1041(slapuser39) groups=1041(slapuser39),1001(slapsoft)

This was downloading pcre2 from git or using system package if available

This is a fixup of 665166e2 (see
especially 665166e2 (comment 177402))

see https://chromium.googlesource.com/chromium/tools/depot_tools.git#updating

as a result, this checkout was not pinned and software was not
reproducible

also make sure component/slapos/buildout.cfg is installable in Theia:
 * we can't compile old gobject-introspection with Python3.9
 * we can't patch dbus as it is read only

See merge request nexedi/slapos!1299

See merge request nexedi/slapos!1333

no need to have an exception here, long time ago bytes had an insecure
default, but we changed to make the default secure

We need to fix the rpath to pass the software release test.

See merge request !1343

For xproto, xextproto and renderproto

When user ran out of inotify watch, starting wrappers using
wait-for-files is not possible:

    AssertionError: Traceback (most recent call last):
      File "/srv/slapgrid/slappart15/tmp/tmpzurwmg4q/wrapper", line 13, in <module>
        sys.exit(slapos.recipe.librecipe.execute.generic_exec(['/bin/echo', 'done'], wait_list=['/srv/slapgrid/slappart15/tmp/tmpzurwmg4q/wait']))
      File "/srv/slapgrid/slappart15/srv/project/slapos-clean/slapos/recipe/librecipe/execute.py", line 100, in generic_exec
        _wait_files_creation(wait_list)
      File "/srv/slapgrid/slappart15/srv/project/slapos-clean/slapos/recipe/librecipe/execute.py", line 30, in _wait_files_creation
        watchdescriptors = {inotify.add_watch(dirname,
      File "/srv/slapgrid/slappart15/srv/project/slapos-clean/slapos/recipe/librecipe/execute.py", line 30, in <dictcomp>
        watchdescriptors = {inotify.add_watch(dirname,
      File "/srv/slapgrid/slappart15/srv/project/venv/lib/python3.9/site-packages/inotify_simple.py", line 110, in add_watch
        return _libc_call(_libc.inotify_add_watch, self.fileno(), fsencode(path), mask)
      File "/srv/slapgrid/slappart15/srv/project/venv/lib/python3.9/site-packages/inotify_simple.py", line 39, in _libc_call
        raise OSError(errno, os.strerror(errno))
    OSError: [Errno 28] No space left on device

This catches inotify errors and fallback to simple polling in that case.

Running logrotate -d on cluster with a lot of slaves results with execution
taking a lot of time (>10s, one some nodes ~20s), which leads to random
promise timeouts.