By default Beremiz' runtime needs a staticly compiled open62541 library but the component one by default produces a shared one. Thus explicitly request it with BUILD_SHARED_LIBS=OFF flag.

fixes TypeError: cannot marshal <class 'dict_keys'> objects

See merge request nexedi/slapos!1250

this is the default

mostly packages with known vulnerabilities or causing failures/warnings
in the tests.

This also cleanup duplicates version definitions, sometimes the test
profiles overloaded some versions from stack/slapos.cfg

this is not used here and pulls many dependencies that we don't need

"image" is something else which depends on pillow, but also django,
which we don't need here.

This is a fixup of 99d9c776

This way of forcing python3.7 is better because the name of the part is
still "python3" hence in the package we have

/opt/slapos/parts/python3/bin/python3

instead of

/opt/slapos/parts/python3.7/bin/python3

See merge request !1249

software.cfg becomes python 3
software-py3.cfg no longer exists
software-py2.cfg is introduced

Test suites will have to be updated accordingly

default profile no longer exist, now we have a combination of explicit
zodb versions and python versions:

{zodb4,zodb4-wc2,zodb5} x {py2,py3}

software.cfg becomes python 3
software-py3.cfg no longer exists
software-py2.cfg is introduced

Test suites will have to be updated accordingly

NamedTemporaryFile are w+b by default.

In deploy test, this recipe is used with url encoded POST [1], but the
test only tested multipart encoded POSTs. In python 3, they are different,
with multipart POSTs, FieldStorage values are bytes, but with url encoded
POSTs, the values are string.

This small server from the recipe only supported multipart POSTs, this
change add support for url encoded POSTs.

[1]: https://lab.nexedi.com/nexedi/slapos/blob/dd7038feab70866e54028de89d0e0e1017fc276c/software/erp5testnode/testsuite/deploy-test/deploy-script-controller#L86

Result of getSoftwareURL can contain other replacements, so replace it very
early in order to avoid such issue.

This test is always failing and it's impossible to fix it (for now). As this
is well known issue with some workarounds available mark it with
expectedFailure.

Add a new SR to deploy scripts on drones to fly them

Add QuickJS wrapper for MAVSDK and open62541 librairies

Add the collection of libraries to interface with MAVLink systems mavsdk

This is the case in debian 11 when we don't have python2 installed.