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)

When originally in 0a446263 (ERP5 and Jupyter integrated together) I added
Jupyter support into ERP5 the parameter for whether to enable/disable it was
declared as boolean in JSON schema but processed as string in instance code,
this way preventing usage of real JSON's boolean.

Fix it.

(also fixing up software/slapos-master/ which copied the files for play in 87d13789)

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