While:
  Installing lxml-python.

An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
  File "/mnt/buildout/eggs/zc.buildout-2.5.2+slapos005-py2.7.egg/zc/buildout/buildout.py", line 2211, in main
    getattr(buildout, command)(args)
  File "/mnt/buildout/eggs/zc.buildout-2.5.2+slapos005-py2.7.egg/zc/buildout/buildout.py", line 637, in install
    self._install_parts(install_args)
  File "/mnt/buildout/eggs/zc.buildout-2.5.2+slapos005-py2.7.egg/zc/buildout/buildout.py", line 806, in _install_parts
    installed_files = self[part]._call(recipe.install)
  File "/mnt/buildout/eggs/zc.buildout-2.5.2+slapos005-py2.7.egg/zc/buildout/buildout.py", line 1579, in _call
    return f()
  File "/home/slapos/software/eggs/zc.recipe.egg-1.3.2.post5-py2.7.egg/zc/recipe/egg/custom.py", line 49, in install
    return self._install()
  File "/home/slapos/software/eggs/zc.recipe.egg-1.3.2.post5-py2.7.egg/zc/recipe/egg/custom.py", line 161, in _install
    newest=self.newest, patch_dict=patch_dict)
  File "/mnt/buildout/eggs/zc.buildout-2.5.2+slapos005-py2.7.egg/zc/buildout/easy_install.py", line 1061, in build
    assert executable == sys.executable, (executable, sys.executable)
AssertionError: ('/home/slapos/software/parts/python2.7/bin/python2.7', '/usr/bin/python')

Same as for commit fcb6a81d,
but for the build of the 'hellorina' SR inside the VM.

Includes work of Douglas in nexedi/slapos!109
as long as improvements on it.


/reviewed-on nexedi/slapos!110

We want it next to eggs/parts/..., not in slapos.git/software/build-rina/

  This is required to support aarch64 systems.
  The edition of PYTHON_LIBS is probably wrong but it what made it work. In future, it would be
  better clean up it.

Error: Buildout now includes 'buildout-versions' (and part of the older 'buildout.dumppickedversions').

This is possible because this SR is only supposed to be run by a test node:
in this case, the owner of the software is the same as for the instance.

Buildout 2.x is required for automatic creation of the 'download-cache' folder.

of timeout of remote appium service which will close test session
if no command received within  usually 90s and thus fail this
script. And it costs processing time as well to keep test session needlessly opened.

for this .

Probably due to GCC6:
char_set.cpp:68:12: error: cannot convert 'bool' to 'tesseract::CharSet*' in return

Also update leptonica to 1.73 (>= 1.71 is required).

It uses Appium, which provides a Selenium WebDriver compatible API
to remotely control an iOS (or Android) simulator. This way we can
run tests in both mobile OSes without big changes to the current
test code and infrastructure.

This allows user to customize in the test suite module on which
system they want to run the tests (Firefox or iOS) through the
slapos parameters. In iOS, for example, it's possible to change
the iOS version and it's required that the user give the SauceLabs
credentials in form of user:apikey using the `appium_server_auth` parameter.

An example of parameters to use in a test suite:

```
{
  "mariadb": {
    "relaxed-writes": true,
    "mariadb-relaxed-writes": true,
    "test-database-amount": 30
  },
  "target": "iOS",
  "target-version": "9.3",
  "target-device": "iPhone Simulator",
  "target-browser": "Safari",
  "appium-server-auth": "username:auth_token",
  "test-suite" : "jio" ,
  "test-url": "jio-repository.git/test/tests.html"
}
```

This solves the issue of accessing any file hosted by the apache in every test node when there is no IPv6 access for the client.

The more there is data to backup, the more likely something can go wrong.
Running the exporter script several times will copy less and less things
at each run, so it should increase the probability to succeed.

  The monitor stack was refactored and this change was missing on this SR.

@vpelletier says:

    I do not think this is a "slave" instance, but just a sub-instance.

    "slave instance" is a way to pass parameter to a foreign instance. For example,
    frontend is an instance, and a slave instance is the rule given by an unrelated
    partition to make that existing frontend instance direct http://foo.com to 1.2.3.4:80 .

    OTOH, "balancer" is a sub-instance of ERP5's SR base instance (which is typically the root instance also).

/noticed-by @vpelletier (on nexedi/slapos!43)