repositories if configured are public. Thus such a check will by design fail.

@seb, @rafael  please review. I tested this and it works.

/reviewed-on !114

Then we'll upgrade setuptools for everyone at the same time as we switch to
zc.buildout 2.x

…se default way to provide backwards compatability.

This commit fixes backwards compatibility after a regressions introduced in !109.

Following test results prove it works:

https://nexedi.erp5.net/test_result_module/20161104-7A7E676

https://nexedi.erp5.net/test_result_module/20161104-15D828A5

/reviewed-on !112

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.

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

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 .

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 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 !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 !43)

  Use 2 different ports on apache for cached slaves, to differ http and https accesses.
  Introduce the parameter https-url (with fallback to url) to include specific https urls,
    if they are different from url.
  Include /HTTPS/ mapping to traffic server to differ the backends based on the input.

  Not all frontend clusers setup uses the same re6stnet network.