pysvn 1.7.10 already supports Python 3, but this patch did not.

/reviewed-on nexedi/slapos!693

We don't want to build against system library that might or might not be
present on the host.

This also cause SR test to fail with:

    RuntimeError: ./parts/trafficserver7/bin/traffic_manager uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
    ./parts/trafficserver7/bin/traffic_crashlog uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
    ./parts/trafficserver7/bin/traffic_server uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
    ./parts/trafficserver7/bin/traffic_ctl uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
    ./parts/trafficserver7/bin/traffic_logstats uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
    ./parts/trafficserver7/bin/traffic_via uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
    ./parts/trafficserver7/bin/traffic_cop uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
    ./parts/trafficserver7/bin/traffic_layout uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
    ./parts/trafficserver7/bin/traffic_logcat uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
    ./parts/trafficserver7/lib/libtsutil.so.7.1.6 uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
    ./parts/trafficserver7/lib/libtsmgmt.so.7.1.6 uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
    ./parts/trafficserver7/lib/libtsmgmt.so.7 uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
    ./parts/trafficserver7/lib/libtsmgmt.so uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
    ./parts/trafficserver7/lib/libtsutil.so.7 uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
    ./parts/trafficserver7/lib/libtsutil.so uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2

/reviewed-on nexedi/slapos!691

This reverts commit d57770ac,
and adds 2 patches from Debian.

It no longer exist at this URL

/reviewed-on nexedi/slapos!622

https://github.com/grafana/loki/blob/master/docs/README.md

> Grafana Loki is a set of components that can be composed into a fully featured logging stack.

The plan is not to really use this, just to see what interesting ideas are in there.

/reviewed-on nexedi/slapos!658

/reviewed-on nexedi/slapos!695

Many parts were still built for nothing now that cloudooo is removed
from this SR. This saves 14MB.

Many extends and many parts from ${buildout:parts}
also don't need to be listed explicitly.

Monitoring promise break instanciation:
  UserError: No section named 'monitor-base-promise'

and telegraf startup script is using influxdb promise, because it has a
bug that it needs to start only after influxdb is available, so it does
not look so easy to switch to monitoring stack.

Also, this software is experimental (and also is conceptually a
monitoring software on its own), so it does not need monitoring for now.

This reverts commit 48b6c27c.

Because we run egg tests with setup.py test, which installs missing
eggs, if an egg was not installed by buildout, then it installed before
running test. This was the case for mock, which is now python3 only (
https://pypi.org/project/mock/4.0.0b1/ ) and we started to see test
failures.

To solve this issue, refactor the setup definition to use
extra_requires, which seems to work fine in buildout now. Keep
test_requires because it's the what `python setup.py test` uses.

Clean buildout profiles to install slapos.cookbook[test] for test
instead of duplicating the content of test_requires.

/reviewed-on nexedi/slapos!690

This enable vieiwing applications logs directly in grafana, as long as
loki agent can access the log file and the regular expressions to parse
the logs are defined

Other changes:
 - provision data sources automatically so that user do not have to add
   them manually
 - update TODO in README
 - introduce a SR test
 - switch to dep to install dependencies, because that's how these
  packages manage their dependencies.

Versions up:
  grafana: v6.3.0
  telegraf: v1.11.1-0
  influxdb: v1.7.8rc1
New:
  loki: v0.3.0

It seems some programs can only be built by the same gcc than the one used to
build golang itself.

For example, when system gcc is gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516,
grafana-server fail to build with:

    /data/slappart11_testnode/cqg/inst/test0-0/tmp/shared/golang1.12/fbee59cfb3c995382cf70d409615aa54/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
    /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info
    /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info
    /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info
    /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info
    /tmp/go-link-305363633/000000.o: file not recognized: File format not recognized
    collect2: error: ld returned 1 exit status

Also generally, if we don't trust system gcc to build golang, we cannot trust
it to build golang programs.

The downside is that if components or software want to use a specifig
golang version they have to set both golang= and the corresponding
gcc-bin-directory= in their [gowork]

/reviewed-on nexedi/slapos!627