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.

So that parts are shared when we install ERP5 in theia

Even if we don't use this, the debug pane cause an error when jdk is not
installed

Some optional extensions installable from the "marketplace" ( like the
XML supports from redhat) also need java and it's better to have
something to edit XML

extracted from nexedi/slapos!735

We now patch the binaries to have everything in rpath

Instead of relying on wrapper script, modify the binary to add the
necessary rpath

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

for an incompatbility with strip

extracted from !735

This reverts commit ef5aca54.

software-shared.cfg is used on master from scalability tests, let's keep
it for now.

We don't need a section here, we inherit this from jupyter stack

See merge request !756

Since e5687602 it's instance
responsability to generate a fonts.conf if they need fonts, but we
realized to late that if there is no /etc/fonts/fonts.conf on the
machine firefox does not start.

In recent ERP5 software release, we have a $FONTCONFIG_FILE, but on
older versions we don't.

To keep compatibility with old ERP5 software release, we generate a
default FONTCONFIG_FILE that will be used as fallback when
$FONTCONFIG_FILE environment variable is not set.

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

The output of buildout for this error was :

Installing switch_softwaretype.
Uninstalling frontend-port.
While:
  Installing.
  Uninstalling frontend-port.
  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.

The cause was a7a36453

See merge request !700

now that we have a patch to support gcc 8 we should support all known
versions of gcc

gcc-5.5 compiles a bit slower python and we are observing failures in
ERP5 performance tests.

Fix build errors on gcc 8:

   ../glibmm/threads.h: In member function 'GPrivate* Glib::Threads::Private<T>::gobj()':
   ../glibmm/threads.h:661:29: error: cannot convert 'GPrivate' {aka '_GPrivate'} to 'GPrivate*' {aka '_GPrivate*'} in return
      GPrivate* gobj() { return gobject_; }
                                ^~~~~~~~

This backport fixes from
https://github.com/GNOME/glibmm/commit/37d57ae9572b7d74aa385a30313eceae7f2d3fce
plus changes to generated files, as found in
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=85e6e0e04ae19670b071820947d941e521d1200e
or
https://src.fedoraproject.org/rpms/glibmm24/c/ecc4276486706c0ebc55aff3ac592499dc9df2a9?branch=master