linux/meta-virtualization.git/recipes-containers, branch krogoth

docker: override GOROOT at build time

2018-01-30T22:11:17+00:00

Usually $GOROOT is set by go tool, but if sstate is specified, $GOROOT is set to the path in the first project. If docker is built in the another project(with same SSTATE_DIR) later, and the first project is removed, the following error will be seen: | go: cannot find GOROOT directory: /path/to/previous/project/bitbake_build/tmp/sysroots/x86_64-linux/usr/lib/x86_64-wrs-linux/go This commit is overriding $GOROOT stored in the go tool in sstate cache, making sure it is set to the correct path in current project. See more information here: https://golang.org/doc/install#install Signed-off-by: Yunguo Wei Signed-off-by: Bruce Ashfield (cherry picked from commit 01aa8f18196d76d4554649c47348fb68277574c5)

docker-registry: Make version dependence compatible with opkg

2016-06-17T12:34:19+00:00

Some recipes in RDEPENDS are installing specific version of package, for example: gunicorn (= 19.1.1) If usigin ipk for PACKAGE_CLASSES, opkg prints error: Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for docker: * gunicorn (= 19.1.1) * * opkg_install: Cannot install package docker. This error is caused because opkg appends package revision to version. In this case: gunicorn_19.1.1-r0.1 If we use comparator >= this error doesn't appear. Signed-off-by: Fabio Berton Signed-off-by: Bruce Ashfield

docker: drop obselete dependencies

2016-06-14T15:00:13+00:00

We no longer need go-net and go-sqlite for the docker build and runtime. The upstream repos are no longer properly fetching, so we can simply drop the recipes and dependency. If they are ever needed in the future, we can revisit the upstream source for them. Signed-off-by: Bruce Ashfield

lxc: update to 2.0.0

2016-04-25T20:26:23+00:00

2.0.0 is released, and contains many of the patches we've been carrying for 1.x. With this updated, we drop upstream backports (and submitted patches), and refresh on patch. Otherwise, everything is the same. Sanity tested on x86-64. Signed-off-by: Bruce Ashfield

lxc: inherit python native to fix configure error

2016-04-22T16:57:43+00:00

Recently the configure with python enabled has become the default here. However, if the host doesn't have python3, configure fails with: checking for a Python interpreter with version >= 3.2... none configure: error: You must install python3 We have a python3 in the sysroot, but we need to inherit it for it to be available for lxc's configure step. Signed-off-by: Paul Gortmaker Signed-off-by: Bruce Ashfield

meta-virtualization: enable lxc-start support wlan0

2016-04-22T14:27:40+00:00

Cherry picked patch from lxc upstream commit: f2e206ff47 to enable lxc-start command support wlan0 device and make cube-essential support paththrough wlan device from host to lxc containers. Signed-off-by: fli Signed-off-by: Bruce Ashfield

docker: uprev to 1.9.0

2016-04-19T19:51:14+00:00

Signed-off-by: Zongchun Yu Signed-off-by: Bruce Ashfield

lxc: uprev to latest stable 1.1.4 -> 1.1.5

2016-04-05T00:03:30+00:00

This is the latest stable release and includes many important bug fixes as well as CVE fixes such as CVE-2015-1335. Signed-off-by: Mark Asselstine Signed-off-by: Bruce Ashfield

lxc: warning fixes in busybox template

2016-03-29T16:35:41+00:00

Warnings fixes: - optional mounts when dirs not available - busybox dynamically linked - fstab not available in container Signed-off-by: Bogdan Purcareata Signed-off-by: Bruce Ashfield

lxc: fix build issue - unable to find Python.h

2016-03-21T14:26:01+00:00

Prior to poky commit 3d45853eef1269b455d840a60491802251368378 [python3: fix do_configure check platform triplet error] lxc's configure scripts would fail to find python3 and would therefor configure with python3 support disabled. After poky integrated the above commit lxc can, and does, detect python3 and attempts to configure with python support. Unfortunately it would detect the host's python3 which it would use to run setup.py and therefor get the host's include path etc. and ultimately fail to build. To fix this we make 'python' support configurable via a PACKAGECONFIG and we default to not configuring with this support, to match our previous configuration. We also fix things such that 'python' support can be enabled in the PACKAGECONFIG and the build will complete successfully, using our python3 and not the host's. We might want to eventually enable the python support but since this not only enables python extensions but even goes as far as turning scripts like lxc-ls into python scripts, instead of shell scripts, keeping it disabled for now is the minimally invasive approach. Signed-off-by: Mark Asselstine Signed-off-by: Bruce Ashfield