This new recipe allow to request an instance with a first software type, which is
called clone instance. Then as soon the instance is ready (connection parameter is
published) then request method will now request the instance normally.

It's used to install clone stack in a partition, the clone stack will sync data
then when all done publish a paramter to say that the instance can be requested
with the real software type.

Auth server is an apache httpd which validate client certificate for authentification.
It autmatically request certificate to CA web (required to this work on SlapOS)

Tests passing here:

https://nexedi.erp5.net/test_result_module/20161117-147BEEA9

/reviewed-on nexedi/slapos!118

because zope.interface is not required to build rebootstrap python.

This reverts commit ae808179.

Reason for revert: zodbtools depend on ZODB while currently neoppod &
erp5 are depending on `ZODB3 = 3.10` so upon installing both ZODB3 and
ZODB are installed. Together with our requirement

    stack/erp5/zope-versions.cfg:transaction = 1.1.1

This creates version conflict and installation fails:

2016-11-17 14:56:35,858 testsuite    : INFO     slapgrid_sr : 2016-11-17 14:56:35 slapos[3698] INFO The version, 1.1.1, is not consistent with the requirement, 'transaction>=1.6.1'.
2016-11-17 14:56:35,937 testsuite    : INFO     slapgrid_sr : 2016-11-17 14:56:35 slapos[3698] INFO While:
2016-11-17 14:56:35,937 testsuite    : INFO     slapgrid_sr : 2016-11-17 14:56:35 slapos[3698] INFO   Installing neoppod.
2016-11-17 14:56:35,937 testsuite    : INFO     slapgrid_sr : 2016-11-17 14:56:35 slapos[3698] INFO Error: Bad version 1.1.1

So revert zodbtools hooking for now until we upgrade our ZODB to ZODB > 3.

As advised by @Tyagov this adds zodbutils egg [1,2] to our software
stack: both NEO and ERP5 (since stack/erp5/ inherits from
neoppod/software-common.cfg)

I have not build-tested this patch but I hope it should be ok.

/cc @nexedi

[1] https://lab.nexedi.com/nexedi/zodbtools  
[2] https://pypi.python.org/pypi/zodbtools

/reviewed-on nexedi/slapos!116

*  Includes a new recipe to get a random time
*  Moves generatepassword and generatemac into random.py
*  Fixes up some recipe, as the creation of a "random.py" file may collide
   with the import of the standard library random

This reverts commit 2b0c61d9.

Reading the .installed.cfg file is not the correct way of storing values. The publish_early
recipe should be used instead

This reverts commit 8787716d.

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 nexedi/slapos!114

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

Same issue of avoiding publishing private code, this time with nothing published by default.

Ivan, can you quickly try this apache config and give your opinion if it acceptable that you add .htaccess in the code to be tested ?

/cc @jm @Tyagov @rafael

/reviewed-on nexedi/slapos!113

This reverts commit 292be60ff42edc2ce57f2e6701ad283c18e9772b because of
a regression in tesseract > 3.02:
  https://github.com/tesseract-ocr/tesseract/issues/360#issuecomment-258775303

Related Unit Tests failures:
  * test_PDFDocument_asTextConversion (testDms.TestDocument)
  * test_MonochromeImageResize (testDms.TestDocument)
  * test_CMYKImageTextContent (testDms.TestDocument)
  => AssertionError: 'ERP5 is a free software\n\n' != 'ERPS is a free software.\n\n'

Tested versions:
  * 3.04.01 (leptnonica: 1.73): NOK
  * 3.03.03 (leptonica: 1.71): NOK
  * 3.03-rc1 (leptonica: 1.71): NOK
  * 3.02.01 (leptonica: 1.69): OK
  * 3.02 (leptonica: 1.71): OK

…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 nexedi/slapos!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.

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.