[PATCH 0/6] podman: add initial recipe

[PATCH 0/6] podman: add initial recipe

[Stefan Agner]

From: Stefan Agner <stefan.agner@toradex.com>

This adds Podman a daemonless container engine for developing,
managing, and running OCI Containers on your Linux System.
Containers can either be run as root or in rootless mode.
Simply put: `alias docker=podman`.

Currently a minimal set of features is supported. It requires
meta-security since libseccomp seems to be mandatory.

--
Stefan

Stefan Agner (6):
  conmon: initial add
  go-metalinter: add recipe for gometalinter
  go-md2man: add md2man
  skopeo: add skopeo
  cni: move cni tools to /usr/lib/cni
  podmon: add the Pod Manager tool

 recipes-containers/conmon/conmon_2.0.0.bb     | 30 ++++++
 ...ail-if-clean-is-called-without-a-bui.patch | 31 +++++++
 recipes-containers/cri-o/files/crio.conf      |  2 +-
 recipes-containers/podman/podman_git.bb       | 91 +++++++++++++++++++
 recipes-containers/skopeo/skopeo_git.bb       | 73 +++++++++++++++
 recipes-devtools/go/go-md2man_git.bb          | 20 ++++
 recipes-devtools/go/go-metalinter_git.bb      | 24 +++++
 recipes-networking/cni/cni_git.bb             |  4 +-
 8 files changed, 272 insertions(+), 3 deletions(-)
 create mode 100644 recipes-containers/conmon/conmon_2.0.0.bb
 create mode 100644 recipes-containers/conmon/files/0001-Makefile-don-t-fail-if-clean-is-called-without-a-bui.patch
 create mode 100644 recipes-containers/podman/podman_git.bb
 create mode 100644 recipes-containers/skopeo/skopeo_git.bb
 create mode 100644 recipes-devtools/go/go-md2man_git.bb
 create mode 100644 recipes-devtools/go/go-metalinter_git.bb

-- 
2.20.1

[PATCH 1/6] conmon: initial add

[Stefan Agner]

From: Stefan Agner <stefan.agner@toradex.com>

Add conmon, a OCI container runtime monitor.

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
---
 recipes-containers/conmon/conmon_2.0.0.bb     | 30 ++++++++++++++++++
 ...ail-if-clean-is-called-without-a-bui.patch | 31 +++++++++++++++++++
 2 files changed, 61 insertions(+)
 create mode 100644 recipes-containers/conmon/conmon_2.0.0.bb
 create mode 100644 recipes-containers/conmon/files/0001-Makefile-don-t-fail-if-clean-is-called-without-a-bui.patch

diff --git a/recipes-containers/conmon/conmon_2.0.0.bb b/recipes-containers/conmon/conmon_2.0.0.bb
new file mode 100644
index 0000000..f4e2cd6
--- /dev/null
+++ b/recipes-containers/conmon/conmon_2.0.0.bb
@@ -0,0 +1,30 @@
+SUMMARY = "An OCI container runtime monitor"
+SECTION = "console/utils"
+HOMEPAGE = "https://github.com/containers/conmon"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=61af0b6932ea7b12fb9142721043bc77"
+
+DEPENDS = "glib-2.0"
+
+SRCREV = "e217fdff82e0b1a6184a28c43043a4065083407f"
+SRC_URI = "\
+    git://github.com/containers/conmon.git \
+    file://0001-Makefile-don-t-fail-if-clean-is-called-without-a-bui.patch \
+"
+
+SRC_URI[md5sum] = "5c711911d766d76813333c3812277574"
+SRC_URI[sha256sum] = "4c31278b2c03e5be5a696c3088bc86cf2557a70e00f697799c163aba18e3c40e"
+
+S = "${WORKDIR}/git"
+
+inherit pkgconfig
+
+EXTRA_OEMAKE = "PREFIX=${prefix} BINDIR=${bindir} LIBEXECDIR=${libexecdir}"
+
+do_install() {
+    oe_runmake 'DESTDIR=${D}' install
+}
+
+FILES_${PN} += " \
+    ${bindir}/conmon \
+"
diff --git a/recipes-containers/conmon/files/0001-Makefile-don-t-fail-if-clean-is-called-without-a-bui.patch b/recipes-containers/conmon/files/0001-Makefile-don-t-fail-if-clean-is-called-without-a-bui.patch
new file mode 100644
index 0000000..8d2b473
--- /dev/null
+++ b/recipes-containers/conmon/files/0001-Makefile-don-t-fail-if-clean-is-called-without-a-bui.patch
@@ -0,0 +1,31 @@
+From 6ef63dfcc65d5401bc7cc7170d569cefcdadcb38 Mon Sep 17 00:00:00 2001
+From: Stefan Agner <stefan@agner.ch>
+Date: Fri, 30 Aug 2019 17:49:22 +0200
+Subject: [PATCH] Makefile: don't fail if clean is called without a build
+
+Do not fail when calling the clean target without building first.
+
+Upstream-Status: Backport
+
+Signed-off-by: Stefan Agner <stefan@agner.ch>
+---
+ Makefile | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index fb0e4fb..b525595 100644
+--- a/Makefile
++++ b/Makefile
+@@ -66,8 +66,7 @@ bin:
+ 
+ .PHONY: clean
+ clean:
+-	rm -f bin/conmon src/*.o
+-	rmdir bin
++	rm -rf bin/ src/*.o
+ 
+ .PHONY: install install.bin install.crio install.podman podman crio
+ install: install.bin
+-- 
+2.23.0
+
-- 
2.20.1

[PATCH 2/6] go-metalinter: add recipe for gometalinter

[Stefan Agner]

From: Stefan Agner <stefan.agner@toradex.com>

A tool that concurrently runs a whole bunch of go linters and
normalises their output to a standard format. Useful to build
podman.

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
---
 recipes-devtools/go/go-metalinter_git.bb | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 recipes-devtools/go/go-metalinter_git.bb

diff --git a/recipes-devtools/go/go-metalinter_git.bb b/recipes-devtools/go/go-metalinter_git.bb
new file mode 100644
index 0000000..668b431
--- /dev/null
+++ b/recipes-devtools/go/go-metalinter_git.bb
@@ -0,0 +1,24 @@
+DESCRIPTION = "Go Meta Linter."
+HOMEPAGE = "https://github.com/alecthomas/gometalinter"
+SECTION = "devel/go"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://COPYING;md5=dee20b35647295553d32faef05846a7b"
+
+BBCLASSEXTEND = "native"
+
+SRCNAME = "gometalinter"
+
+PKG_NAME = "github.com/alecthomas/${SRCNAME}"
+SRC_URI = "git://${PKG_NAME}.git"
+
+SRCREV = "e8d801238da6f0dfd14078d68f9b53fa50a7eeb5"
+PV = "0.0+git${SRCPV}"
+
+S = "${WORKDIR}/git"
+
+do_install() {
+	install -d ${D}${prefix}/local/go/src/${PKG_NAME}
+	cp -r ${S}/* ${D}${prefix}/local/go/src/${PKG_NAME}/
+}
+
+FILES_${PN} += "${prefix}/local/go/src/${PKG_NAME}/*"
-- 
2.20.1

[PATCH 3/6] go-md2man: add md2man

[Stefan Agner]

From: Stefan Agner <stefan.agner@toradex.com>

This tool converts markdown into roff (man pages). Useful to build
podman.

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
---
 recipes-devtools/go/go-md2man_git.bb | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 recipes-devtools/go/go-md2man_git.bb

diff --git a/recipes-devtools/go/go-md2man_git.bb b/recipes-devtools/go/go-md2man_git.bb
new file mode 100644
index 0000000..cc8dd5c
--- /dev/null
+++ b/recipes-devtools/go/go-md2man_git.bb
@@ -0,0 +1,20 @@
+DESCRIPTION = "A markdown to manpage generator."
+HOMEPAGE = "https://github.com/cpuguy83/go-md2man"
+SECTION = "devel/go"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://src/${GO_IMPORT}/LICENSE.md;md5=80794f9009df723bbc6fe19234c9f517"
+
+BBCLASSEXTEND = "native"
+
+GO_IMPORT = "github.com/cpuguy83/go-md2man"
+#GO_INSTALL = "${GO_IMPORT}/bin/go-md2man"
+
+SRC_URI = "git://${GO_IMPORT}.git"
+
+SRCREV = "f79a8a8ca69da163eee19ab442bedad7a35bba5a"
+PV = "1.0.10+git${SRCPV}"
+
+S = "${WORKDIR}/git"
+
+inherit go
+
-- 
2.20.1

[PATCH 4/6] skopeo: add skopeo

[Stefan Agner]

From: Stefan Agner <stefan.agner@toradex.com>

skopeo is a command line utility that performs various operations on
container images and image repositories.

skopeo can work with OCI images as well as the original Docker v2
images.

The recipe originates from from meta-overc commit a497792. It has
been updated with the new project URL and v0.1.39.

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
---
 recipes-containers/skopeo/skopeo_git.bb | 73 +++++++++++++++++++++++++
 1 file changed, 73 insertions(+)
 create mode 100644 recipes-containers/skopeo/skopeo_git.bb

diff --git a/recipes-containers/skopeo/skopeo_git.bb b/recipes-containers/skopeo/skopeo_git.bb
new file mode 100644
index 0000000..82d3f23
--- /dev/null
+++ b/recipes-containers/skopeo/skopeo_git.bb
@@ -0,0 +1,73 @@
+HOMEPAGE = "https://github.com/containers/skopeo"
+SUMMARY = "Work with remote images registries - retrieving information, images, signing content"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=7e611105d3e369954840a6668c438584"
+
+DEPENDS = " \
+    gpgme \
+    multipath-tools \
+    btrfs-tools \
+    glib-2.0 \
+    ostree \
+"
+
+inherit go
+
+RDEPENDS_${PN} = " \
+     gpgme \
+     libgpg-error \
+     libassuan \
+"
+
+SRC_URI = "git://github.com/containers/skopeo"
+
+SRCREV = "1cf1e06582142c522543560f2bc6d6756696e8ad"
+PV = "v0.1.39-dev+git${SRCPV}"
+GO_IMPORT = "import"
+
+S = "${WORKDIR}/git"
+
+inherit goarch
+inherit pkgconfig
+
+# This disables seccomp and apparmor, which are on by default in the
+# go package. 
+EXTRA_OEMAKE="BUILDTAGS=''"
+
+do_compile() {
+	export GOARCH="${TARGET_GOARCH}"
+
+	# Setup vendor directory so that it can be used in GOPATH.
+	#
+	# Go looks in a src directory under any directory in GOPATH but riddler
+	# uses 'vendor' instead of 'vendor/src'. We can fix this with a symlink.
+	#
+	# We also need to link in the ipallocator directory as that is not under
+	# a src directory.
+	ln -sfn . "${S}/src/import/vendor/src"
+	mkdir -p "${S}/src/import/vendor/src/github.com/projectatomic/skopeo"
+	ln -sfn "${S}/src/import/skopeo" "${S}/src/import/vendor/src/github.com/projectatomic/skopeo"
+	ln -sfn "${S}/src/import/version" "${S}/src/import/vendor/src/github.com/projectatomic/skopeo/version"
+	export GOPATH="${S}/src/import/vendor"
+
+	# Pass the needed cflags/ldflags so that cgo
+	# can find the needed headers files and libraries
+	export CGO_ENABLED="1"
+	export CFLAGS=""
+	export LDFLAGS=""
+	export CGO_CFLAGS="${BUILDSDK_CFLAGS} --sysroot=${STAGING_DIR_TARGET}"
+	export CGO_LDFLAGS="${BUILDSDK_LDFLAGS} --sysroot=${STAGING_DIR_TARGET}"
+	cd ${S}/src/import
+
+	oe_runmake binary-local
+}
+
+do_install() {
+	install -d ${D}/${sbindir}
+	install -d ${D}/${sysconfdir}/containers
+
+	install ${S}/src/import/skopeo ${D}/${sbindir}/
+	install ${S}/src/import/default-policy.json ${D}/${sysconfdir}/containers/policy.json
+}
+
+INSANE_SKIP_${PN} += "ldflags"
-- 
2.20.1

[PATCH 5/6] cni: move cni tools to /usr/lib/cni

[Stefan Agner]

From: Stefan Agner <stefan.agner@toradex.com>

Use a standard location to store the cni tools and plugins. This
is more in line how other distributions package cni.

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
---
 recipes-containers/cri-o/files/crio.conf | 2 +-
 recipes-networking/cni/cni_git.bb        | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-containers/cri-o/files/crio.conf b/recipes-containers/cri-o/files/crio.conf
index 51d7f40..dd22465 100644
--- a/recipes-containers/cri-o/files/crio.conf
+++ b/recipes-containers/cri-o/files/crio.conf
@@ -144,4 +144,4 @@ registries = [
 network_dir = "/etc/cni/net.d/"
 
 # plugin_dir is is where CNI plugin binaries are stored.
-plugin_dir = "/opt/cni/bin/"
+plugin_dir = "/usr/lib/cni/"
diff --git a/recipes-networking/cni/cni_git.bb b/recipes-networking/cni/cni_git.bb
index 5348b95..86e5e0f 100644
--- a/recipes-networking/cni/cni_git.bb
+++ b/recipes-networking/cni/cni_git.bb
@@ -63,7 +63,7 @@ do_compile() {
 }
 
 do_install() {
-    localbindir="/opt/cni/bin"
+    localbindir="${libdir}/cni/"
 
     install -d ${D}${localbindir}
     install -d ${D}/${sysconfdir}/cni/net.d
@@ -72,7 +72,7 @@ do_install() {
     install -m 755 -D ${WORKDIR}/plugins/bin/* ${D}/${localbindir}
 }
 
-FILES_${PN} += "/opt/cni/bin/*"
+FILES_${PN} += "${libdir}/cni/*"
 
 INSANE_SKIP_${PN} += "ldflags already-stripped"
 
-- 
2.20.1

[PATCH 6/6] podmon: add the Pod Manager tool

[Stefan Agner]

From: Stefan Agner <stefan.agner@toradex.com>

Podman is a daemonless container engine for developing, managing, and
running OCI Containers on your Linux System. Containers can either be
run as root or in rootless mode.

This patch adds the initial recipe for podman. Currently a minimal
feature set is supported. It seems that libseccomp is mandatory, which
makes meta-security a mandatory dependency for this recipe.

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
---
 recipes-containers/podman/podman_git.bb | 91 +++++++++++++++++++++++++
 1 file changed, 91 insertions(+)
 create mode 100644 recipes-containers/podman/podman_git.bb

diff --git a/recipes-containers/podman/podman_git.bb b/recipes-containers/podman/podman_git.bb
new file mode 100644
index 0000000..6f4e7d4
--- /dev/null
+++ b/recipes-containers/podman/podman_git.bb
@@ -0,0 +1,91 @@
+HOMEPAGE = "https://podman.io/"
+SUMMARY =  "A daemonless container engine"
+DESCRIPTION = "Podman is a daemonless container engine for developing, \
+    managing, and running OCI Containers on your Linux System. Containers can \
+    either be run as root or in rootless mode. Simply put: \
+    `alias docker=podman`. \
+    "
+
+DEPENDS = " \
+    go-metalinter-native \
+    go-md2man-native \
+    gpgme \
+    libseccomp \
+    ${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)} \
+"
+
+SRCREV = "00057929f5acfd98341964d85722383363376d52"
+SRC_URI = " \
+    git://github.com/containers/libpod.git;branch=master \
+"
+
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=e3fc50a88d0a364313df4b21ef20c29e"
+
+GO_IMPORT = "import"
+
+S = "${WORKDIR}/git"
+
+PV = "1.5.1+git${SRCREV}"
+
+PACKAGES =+ "${PN}-contrib"
+
+PODMAN_PKG = "github.com/containers/libpod"
+BUILDTAGS = "seccomp systemd exclude_graphdriver_btrfs exclude_graphdriver_devicemapper"
+
+# overide LDFLAGS to allow criu to build without: "x86_64-poky-linux-ld: unrecognized option '-Wl,-O1'"
+export LDFLAGS=""
+
+inherit go goarch
+inherit systemd pkgconfig
+
+do_configure[noexec] = "1"
+
+EXTRA_OEMAKE = " \
+     PREFIX=${prefix} BINDIR=${bindir} LIBEXECDIR=${libexecdir} \
+     ETCDIR=${sysconfdir} TMPFILESDIR=${nonarch_libdir}/tmpfiles.d \
+     SYSTEMDDIR=${systemd_unitdir}/system USERSYSTEMDDIR=${systemd_unitdir}/user \
+"
+
+do_compile() {
+	# Set GOPATH. See 'PACKAGERS.md'. Don't rely on
+	# docker to download its dependencies but rather
+	# use dependencies packaged independently.
+	cd ${S}/src
+	rm -rf .gopath
+	mkdir -p .gopath/src/"$(dirname "${PODMAN_PKG}")"
+	ln -sf ../../../../import/ .gopath/src/"${PODMAN_PKG}"
+
+	ln -sf "../../../import/vendor/github.com/varlink/" ".gopath/src/github.com/varlink"
+
+	export GOPATH="${S}/src/.gopath"
+	export GOROOT="${STAGING_DIR_NATIVE}/${nonarch_libdir}/${HOST_SYS}/go"
+
+	cd ${S}/src/.gopath/src/"${PODMAN_PKG}"
+
+	make cmd/podman/varlink/iopodman.go GO=go
+
+	# Pass the needed cflags/ldflags so that cgo
+	# can find the needed headers files and libraries
+	export GOARCH=${TARGET_GOARCH}
+	export CGO_ENABLED="1"
+	export CGO_CFLAGS="${CFLAGS} --sysroot=${STAGING_DIR_TARGET}"
+	export CGO_LDFLAGS="${LDFLAGS} --sysroot=${STAGING_DIR_TARGET}"
+
+	make BUILDTAGS="${BUILDTAGS}"
+}
+
+do_install() {
+	cd ${S}/src/.gopath/src/"${PODMAN_PKG}"
+
+	oe_runmake install install.docker DESTDIR="${D}"
+}
+
+FILES_${PN} += " \
+    ${systemd_unitdir}/system/* \
+    ${systemd_unitdir}/user/* \
+    ${nonarch_libdir}/tmpfiles.d/* \
+    ${sysconfdir}/docker \
+"
+
+RDEPENDS_${PN} += "conmon runc-opencontainers iptables cni skopeo"
-- 
2.20.1

Re: [PATCH 5/6] cni: move cni tools to /usr/lib/cni

[ChenQi]

On 09/02/2019 04:33 AM, Stefan Agner wrote:
> From: Stefan Agner <stefan.agner@toradex.com>
>
> Use a standard location to store the cni tools and plugins. This
> is more in line how other distributions package cni.

But from what I see, at least Fedora and Ubuntu are using /opt/cni/bin 
directory.
Also, have you tested such change with simple k8s setup which makes use 
of these plugins? E.g. flannel?

Best Regards,
Chen Qi

> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> ---
>   recipes-containers/cri-o/files/crio.conf | 2 +-
>   recipes-networking/cni/cni_git.bb        | 4 ++--
>   2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/recipes-containers/cri-o/files/crio.conf b/recipes-containers/cri-o/files/crio.conf
> index 51d7f40..dd22465 100644
> --- a/recipes-containers/cri-o/files/crio.conf
> +++ b/recipes-containers/cri-o/files/crio.conf
> @@ -144,4 +144,4 @@ registries = [
>   network_dir = "/etc/cni/net.d/"
>   
>   # plugin_dir is is where CNI plugin binaries are stored.
> -plugin_dir = "/opt/cni/bin/"
> +plugin_dir = "/usr/lib/cni/"
> diff --git a/recipes-networking/cni/cni_git.bb b/recipes-networking/cni/cni_git.bb
> index 5348b95..86e5e0f 100644
> --- a/recipes-networking/cni/cni_git.bb
> +++ b/recipes-networking/cni/cni_git.bb
> @@ -63,7 +63,7 @@ do_compile() {
>   }
>   
>   do_install() {
> -    localbindir="/opt/cni/bin"
> +    localbindir="${libdir}/cni/"
>   
>       install -d ${D}${localbindir}
>       install -d ${D}/${sysconfdir}/cni/net.d
> @@ -72,7 +72,7 @@ do_install() {
>       install -m 755 -D ${WORKDIR}/plugins/bin/* ${D}/${localbindir}
>   }
>   
> -FILES_${PN} += "/opt/cni/bin/*"
> +FILES_${PN} += "${libdir}/cni/*"
>   
>   INSANE_SKIP_${PN} += "ldflags already-stripped"
>   

Re: [PATCH 4/6] skopeo: add skopeo

[Bruce Ashfield]

On Sun, Sep 1, 2019 at 4:35 PM Stefan Agner <stefan@agner.ch> wrote:
>
> From: Stefan Agner <stefan.agner@toradex.com>
>
> skopeo is a command line utility that performs various operations on
> container images and image repositories.
>
> skopeo can work with OCI images as well as the original Docker v2
> images.
>
> The recipe originates from from meta-overc commit a497792. It has
> been updated with the new project URL and v0.1.39.

Nice!

This was on my list to bring into meta-virtualization. Once I can
confirm that it passes the meta-overc use cases, I'll merge this and
drop the one from meta-overc.

Bruce

>
> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> ---
>  recipes-containers/skopeo/skopeo_git.bb | 73 +++++++++++++++++++++++++
>  1 file changed, 73 insertions(+)
>  create mode 100644 recipes-containers/skopeo/skopeo_git.bb
>
> diff --git a/recipes-containers/skopeo/skopeo_git.bb b/recipes-containers/skopeo/skopeo_git.bb
> new file mode 100644
> index 0000000..82d3f23
> --- /dev/null
> +++ b/recipes-containers/skopeo/skopeo_git.bb
> @@ -0,0 +1,73 @@
> +HOMEPAGE = "https://github.com/containers/skopeo"
> +SUMMARY = "Work with remote images registries - retrieving information, images, signing content"
> +LICENSE = "Apache-2.0"
> +LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=7e611105d3e369954840a6668c438584"
> +
> +DEPENDS = " \
> +    gpgme \
> +    multipath-tools \
> +    btrfs-tools \
> +    glib-2.0 \
> +    ostree \
> +"
> +
> +inherit go
> +
> +RDEPENDS_${PN} = " \
> +     gpgme \
> +     libgpg-error \
> +     libassuan \
> +"
> +
> +SRC_URI = "git://github.com/containers/skopeo"
> +
> +SRCREV = "1cf1e06582142c522543560f2bc6d6756696e8ad"
> +PV = "v0.1.39-dev+git${SRCPV}"
> +GO_IMPORT = "import"
> +
> +S = "${WORKDIR}/git"
> +
> +inherit goarch
> +inherit pkgconfig
> +
> +# This disables seccomp and apparmor, which are on by default in the
> +# go package.
> +EXTRA_OEMAKE="BUILDTAGS=''"
> +
> +do_compile() {
> +       export GOARCH="${TARGET_GOARCH}"
> +
> +       # Setup vendor directory so that it can be used in GOPATH.
> +       #
> +       # Go looks in a src directory under any directory in GOPATH but riddler
> +       # uses 'vendor' instead of 'vendor/src'. We can fix this with a symlink.
> +       #
> +       # We also need to link in the ipallocator directory as that is not under
> +       # a src directory.
> +       ln -sfn . "${S}/src/import/vendor/src"
> +       mkdir -p "${S}/src/import/vendor/src/github.com/projectatomic/skopeo"
> +       ln -sfn "${S}/src/import/skopeo" "${S}/src/import/vendor/src/github.com/projectatomic/skopeo"
> +       ln -sfn "${S}/src/import/version" "${S}/src/import/vendor/src/github.com/projectatomic/skopeo/version"
> +       export GOPATH="${S}/src/import/vendor"
> +
> +       # Pass the needed cflags/ldflags so that cgo
> +       # can find the needed headers files and libraries
> +       export CGO_ENABLED="1"
> +       export CFLAGS=""
> +       export LDFLAGS=""
> +       export CGO_CFLAGS="${BUILDSDK_CFLAGS} --sysroot=${STAGING_DIR_TARGET}"
> +       export CGO_LDFLAGS="${BUILDSDK_LDFLAGS} --sysroot=${STAGING_DIR_TARGET}"
> +       cd ${S}/src/import
> +
> +       oe_runmake binary-local
> +}
> +
> +do_install() {
> +       install -d ${D}/${sbindir}
> +       install -d ${D}/${sysconfdir}/containers
> +
> +       install ${S}/src/import/skopeo ${D}/${sbindir}/
> +       install ${S}/src/import/default-policy.json ${D}/${sysconfdir}/containers/policy.json
> +}
> +
> +INSANE_SKIP_${PN} += "ldflags"
> --
> 2.20.1
>
> --
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [PATCH 0/6] podman: add initial recipe

[Bruce Ashfield]

On Sun, Sep 1, 2019 at 4:34 PM Stefan Agner <stefan@agner.ch> wrote:
>
> From: Stefan Agner <stefan.agner@toradex.com>
>
> This adds Podman a daemonless container engine for developing,
> managing, and running OCI Containers on your Linux System.
> Containers can either be run as root or in rootless mode.
> Simply put: `alias docker=podman`.
>

Also nice! This was also on my list, since I've been using runc/OCI
containers without any daemons for quite some time, and I thought this
would make a good addition to that support.

> Currently a minimal set of features is supported. It requires

Did you have a list of those features ? It might be a good idea to
document them in a  README, so we'll know when someone is asking for
something that isn't supported by design.

Bruce

> meta-security since libseccomp seems to be mandatory.
>
> --
> Stefan
>
> Stefan Agner (6):
>   conmon: initial add
>   go-metalinter: add recipe for gometalinter
>   go-md2man: add md2man
>   skopeo: add skopeo
>   cni: move cni tools to /usr/lib/cni
>   podmon: add the Pod Manager tool
>
>  recipes-containers/conmon/conmon_2.0.0.bb     | 30 ++++++
>  ...ail-if-clean-is-called-without-a-bui.patch | 31 +++++++
>  recipes-containers/cri-o/files/crio.conf      |  2 +-
>  recipes-containers/podman/podman_git.bb       | 91 +++++++++++++++++++
>  recipes-containers/skopeo/skopeo_git.bb       | 73 +++++++++++++++
>  recipes-devtools/go/go-md2man_git.bb          | 20 ++++
>  recipes-devtools/go/go-metalinter_git.bb      | 24 +++++
>  recipes-networking/cni/cni_git.bb             |  4 +-
>  8 files changed, 272 insertions(+), 3 deletions(-)
>  create mode 100644 recipes-containers/conmon/conmon_2.0.0.bb
>  create mode 100644 recipes-containers/conmon/files/0001-Makefile-don-t-fail-if-clean-is-called-without-a-bui.patch
>  create mode 100644 recipes-containers/podman/podman_git.bb
>  create mode 100644 recipes-containers/skopeo/skopeo_git.bb
>  create mode 100644 recipes-devtools/go/go-md2man_git.bb
>  create mode 100644 recipes-devtools/go/go-metalinter_git.bb
>
> --
> 2.20.1
>
> --
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [PATCH 6/6] podmon: add the Pod Manager tool

[Bruce Ashfield]

I'm assuming the subject should be "podman" and not "podmon".

On Sun, Sep 1, 2019 at 4:34 PM Stefan Agner <stefan@agner.ch> wrote:
>
> From: Stefan Agner <stefan.agner@toradex.com>
>
> Podman is a daemonless container engine for developing, managing, and
> running OCI Containers on your Linux System. Containers can either be
> run as root or in rootless mode.
>
> This patch adds the initial recipe for podman. Currently a minimal
> feature set is supported. It seems that libseccomp is mandatory, which
> makes meta-security a mandatory dependency for this recipe.
>
> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> ---
>  recipes-containers/podman/podman_git.bb | 91 +++++++++++++++++++++++++
>  1 file changed, 91 insertions(+)
>  create mode 100644 recipes-containers/podman/podman_git.bb
>
> diff --git a/recipes-containers/podman/podman_git.bb b/recipes-containers/podman/podman_git.bb
> new file mode 100644
> index 0000000..6f4e7d4
> --- /dev/null
> +++ b/recipes-containers/podman/podman_git.bb
> @@ -0,0 +1,91 @@
> +HOMEPAGE = "https://podman.io/"
> +SUMMARY =  "A daemonless container engine"
> +DESCRIPTION = "Podman is a daemonless container engine for developing, \
> +    managing, and running OCI Containers on your Linux System. Containers can \
> +    either be run as root or in rootless mode. Simply put: \
> +    `alias docker=podman`. \
> +    "
> +
> +DEPENDS = " \
> +    go-metalinter-native \
> +    go-md2man-native \
> +    gpgme \
> +    libseccomp \
> +    ${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)} \
> +"
> +
> +SRCREV = "00057929f5acfd98341964d85722383363376d52"
> +SRC_URI = " \
> +    git://github.com/containers/libpod.git;branch=master \
> +"
> +
> +LICENSE = "Apache-2.0"
> +LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=e3fc50a88d0a364313df4b21ef20c29e"
> +
> +GO_IMPORT = "import"
> +
> +S = "${WORKDIR}/git"
> +
> +PV = "1.5.1+git${SRCREV}"
> +
> +PACKAGES =+ "${PN}-contrib"
> +
> +PODMAN_PKG = "github.com/containers/libpod"
> +BUILDTAGS = "seccomp systemd exclude_graphdriver_btrfs exclude_graphdriver_devicemapper"

On my other similar recipes, I've been asked to make this a ?= so it
can be easily overridden. Is that possible here ?

> +
> +# overide LDFLAGS to allow criu to build without: "x86_64-poky-linux-ld: unrecognized option '-Wl,-O1'"

Is this a debug statement left in, or is it relevant to podman ?

> +export LDFLAGS=""
> +
> +inherit go goarch
> +inherit systemd pkgconfig
> +
> +do_configure[noexec] = "1"
> +
> +EXTRA_OEMAKE = " \
> +     PREFIX=${prefix} BINDIR=${bindir} LIBEXECDIR=${libexecdir} \
> +     ETCDIR=${sysconfdir} TMPFILESDIR=${nonarch_libdir}/tmpfiles.d \
> +     SYSTEMDDIR=${systemd_unitdir}/system USERSYSTEMDDIR=${systemd_unitdir}/user \
> +"
> +
> +do_compile() {
> +       # Set GOPATH. See 'PACKAGERS.md'. Don't rely on
> +       # docker to download its dependencies but rather
> +       # use dependencies packaged independently.
> +       cd ${S}/src
> +       rm -rf .gopath
> +       mkdir -p .gopath/src/"$(dirname "${PODMAN_PKG}")"
> +       ln -sf ../../../../import/ .gopath/src/"${PODMAN_PKG}"
> +
> +       ln -sf "../../../import/vendor/github.com/varlink/" ".gopath/src/github.com/varlink"
> +
> +       export GOPATH="${S}/src/.gopath"
> +       export GOROOT="${STAGING_DIR_NATIVE}/${nonarch_libdir}/${HOST_SYS}/go"
> +
> +       cd ${S}/src/.gopath/src/"${PODMAN_PKG}"
> +
> +       make cmd/podman/varlink/iopodman.go GO=go

I've been trying to squash out all the raw calls to make. Does this
work if oe_runmake is used ?

Also, out of curiosity, if GO=go isn't set .. what executable does it
try to run ?

> +
> +       # Pass the needed cflags/ldflags so that cgo
> +       # can find the needed headers files and libraries
> +       export GOARCH=${TARGET_GOARCH}
> +       export CGO_ENABLED="1"
> +       export CGO_CFLAGS="${CFLAGS} --sysroot=${STAGING_DIR_TARGET}"
> +       export CGO_LDFLAGS="${LDFLAGS} --sysroot=${STAGING_DIR_TARGET}"
> +
> +       make BUILDTAGS="${BUILDTAGS}"

Same here. Does oe_runmake work ?

Bruce

> +}
> +
> +do_install() {
> +       cd ${S}/src/.gopath/src/"${PODMAN_PKG}"
> +
> +       oe_runmake install install.docker DESTDIR="${D}"
> +}
> +
> +FILES_${PN} += " \
> +    ${systemd_unitdir}/system/* \
> +    ${systemd_unitdir}/user/* \
> +    ${nonarch_libdir}/tmpfiles.d/* \
> +    ${sysconfdir}/docker \
> +"
> +
> +RDEPENDS_${PN} += "conmon runc-opencontainers iptables cni skopeo"
> --
> 2.20.1
>
> --
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [PATCH 5/6] cni: move cni tools to /usr/lib/cni

[Bruce Ashfield]

On Sun, Sep 1, 2019 at 9:33 PM ChenQi <Qi.Chen@windriver.com> wrote:
>
> On 09/02/2019 04:33 AM, Stefan Agner wrote:
> > From: Stefan Agner <stefan.agner@toradex.com>
> >
> > Use a standard location to store the cni tools and plugins. This
> > is more in line how other distributions package cni.
>
> But from what I see, at least Fedora and Ubuntu are using /opt/cni/bin
> directory.
> Also, have you tested such change with simple k8s setup which makes use
> of these plugins? E.g. flannel?

Indeed. I haven't seen anything that looks like a standard location
for these. I'd be interested to hear how testing went.

Is this something that we can make configurable ? That would be my
preference, that way we can be sure to not break anyone's use case.

Bruce

>
> Best Regards,
> Chen Qi
>
> > Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> > ---
> >   recipes-containers/cri-o/files/crio.conf | 2 +-
> >   recipes-networking/cni/cni_git.bb        | 4 ++--
> >   2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/recipes-containers/cri-o/files/crio.conf b/recipes-containers/cri-o/files/crio.conf
> > index 51d7f40..dd22465 100644
> > --- a/recipes-containers/cri-o/files/crio.conf
> > +++ b/recipes-containers/cri-o/files/crio.conf
> > @@ -144,4 +144,4 @@ registries = [
> >   network_dir = "/etc/cni/net.d/"
> >
> >   # plugin_dir is is where CNI plugin binaries are stored.
> > -plugin_dir = "/opt/cni/bin/"
> > +plugin_dir = "/usr/lib/cni/"
> > diff --git a/recipes-networking/cni/cni_git.bb b/recipes-networking/cni/cni_git.bb
> > index 5348b95..86e5e0f 100644
> > --- a/recipes-networking/cni/cni_git.bb
> > +++ b/recipes-networking/cni/cni_git.bb
> > @@ -63,7 +63,7 @@ do_compile() {
> >   }
> >
> >   do_install() {
> > -    localbindir="/opt/cni/bin"
> > +    localbindir="${libdir}/cni/"
> >
> >       install -d ${D}${localbindir}
> >       install -d ${D}/${sysconfdir}/cni/net.d
> > @@ -72,7 +72,7 @@ do_install() {
> >       install -m 755 -D ${WORKDIR}/plugins/bin/* ${D}/${localbindir}
> >   }
> >
> > -FILES_${PN} += "/opt/cni/bin/*"
> > +FILES_${PN} += "${libdir}/cni/*"
> >
> >   INSANE_SKIP_${PN} += "ldflags already-stripped"
> >
>
>
> --
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [PATCH 4/6] skopeo: add skopeo

[Mark Asselstine]

On Tue, Sep 3, 2019 at 1:18 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
> On Sun, Sep 1, 2019 at 4:35 PM Stefan Agner <stefan@agner.ch> wrote:
> >
> > From: Stefan Agner <stefan.agner@toradex.com>
> >
> > skopeo is a command line utility that performs various operations on
> > container images and image repositories.
> >
> > skopeo can work with OCI images as well as the original Docker v2
> > images.
> >
> > The recipe originates from from meta-overc commit a497792. It has
> > been updated with the new project URL and v0.1.39.
>
> Nice!
>
> This was on my list to bring into meta-virtualization. Once I can
> confirm that it passes the meta-overc use cases, I'll merge this and
> drop the one from meta-overc.

Which takes an item off my todo list. So double nice!

Eventually I want to have this build -native and an addition to the
fetcher so it can be used to populate a rootfs with container images
from something like docker hub.

MarkA

>
> Bruce
>
> >
> > Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> > ---
> >  recipes-containers/skopeo/skopeo_git.bb | 73 +++++++++++++++++++++++++
> >  1 file changed, 73 insertions(+)
> >  create mode 100644 recipes-containers/skopeo/skopeo_git.bb
> >
> > diff --git a/recipes-containers/skopeo/skopeo_git.bb b/recipes-containers/skopeo/skopeo_git.bb
> > new file mode 100644
> > index 0000000..82d3f23
> > --- /dev/null
> > +++ b/recipes-containers/skopeo/skopeo_git.bb
> > @@ -0,0 +1,73 @@
> > +HOMEPAGE = "https://github.com/containers/skopeo"
> > +SUMMARY = "Work with remote images registries - retrieving information, images, signing content"
> > +LICENSE = "Apache-2.0"
> > +LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=7e611105d3e369954840a6668c438584"
> > +
> > +DEPENDS = " \
> > +    gpgme \
> > +    multipath-tools \
> > +    btrfs-tools \
> > +    glib-2.0 \
> > +    ostree \
> > +"
> > +
> > +inherit go
> > +
> > +RDEPENDS_${PN} = " \
> > +     gpgme \
> > +     libgpg-error \
> > +     libassuan \
> > +"
> > +
> > +SRC_URI = "git://github.com/containers/skopeo"
> > +
> > +SRCREV = "1cf1e06582142c522543560f2bc6d6756696e8ad"
> > +PV = "v0.1.39-dev+git${SRCPV}"
> > +GO_IMPORT = "import"
> > +
> > +S = "${WORKDIR}/git"
> > +
> > +inherit goarch
> > +inherit pkgconfig
> > +
> > +# This disables seccomp and apparmor, which are on by default in the
> > +# go package.
> > +EXTRA_OEMAKE="BUILDTAGS=''"
> > +
> > +do_compile() {
> > +       export GOARCH="${TARGET_GOARCH}"
> > +
> > +       # Setup vendor directory so that it can be used in GOPATH.
> > +       #
> > +       # Go looks in a src directory under any directory in GOPATH but riddler
> > +       # uses 'vendor' instead of 'vendor/src'. We can fix this with a symlink.
> > +       #
> > +       # We also need to link in the ipallocator directory as that is not under
> > +       # a src directory.
> > +       ln -sfn . "${S}/src/import/vendor/src"
> > +       mkdir -p "${S}/src/import/vendor/src/github.com/projectatomic/skopeo"
> > +       ln -sfn "${S}/src/import/skopeo" "${S}/src/import/vendor/src/github.com/projectatomic/skopeo"
> > +       ln -sfn "${S}/src/import/version" "${S}/src/import/vendor/src/github.com/projectatomic/skopeo/version"
> > +       export GOPATH="${S}/src/import/vendor"
> > +
> > +       # Pass the needed cflags/ldflags so that cgo
> > +       # can find the needed headers files and libraries
> > +       export CGO_ENABLED="1"
> > +       export CFLAGS=""
> > +       export LDFLAGS=""
> > +       export CGO_CFLAGS="${BUILDSDK_CFLAGS} --sysroot=${STAGING_DIR_TARGET}"
> > +       export CGO_LDFLAGS="${BUILDSDK_LDFLAGS} --sysroot=${STAGING_DIR_TARGET}"
> > +       cd ${S}/src/import
> > +
> > +       oe_runmake binary-local
> > +}
> > +
> > +do_install() {
> > +       install -d ${D}/${sbindir}
> > +       install -d ${D}/${sysconfdir}/containers
> > +
> > +       install ${S}/src/import/skopeo ${D}/${sbindir}/
> > +       install ${S}/src/import/default-policy.json ${D}/${sysconfdir}/containers/policy.json
> > +}
> > +
> > +INSANE_SKIP_${PN} += "ldflags"
> > --
> > 2.20.1
> >
> > --
> > _______________________________________________
> > meta-virtualization mailing list
> > meta-virtualization@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-virtualization
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
> --
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization

Re: [PATCH 4/6] skopeo: add skopeo

[Bruce Ashfield]

On Tue, Sep 3, 2019 at 4:41 PM Mark Asselstine
<mark.asselstine@windriver.com> wrote:
>
> On Tue, Sep 3, 2019 at 1:18 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> >
> > On Sun, Sep 1, 2019 at 4:35 PM Stefan Agner <stefan@agner.ch> wrote:
> > >
> > > From: Stefan Agner <stefan.agner@toradex.com>
> > >
> > > skopeo is a command line utility that performs various operations on
> > > container images and image repositories.
> > >
> > > skopeo can work with OCI images as well as the original Docker v2
> > > images.
> > >
> > > The recipe originates from from meta-overc commit a497792. It has
> > > been updated with the new project URL and v0.1.39.
> >
> > Nice!
> >
> > This was on my list to bring into meta-virtualization. Once I can
> > confirm that it passes the meta-overc use cases, I'll merge this and
> > drop the one from meta-overc.
>
> Which takes an item off my todo list. So double nice!
>
> Eventually I want to have this build -native and an addition to the
> fetcher so it can be used to populate a rootfs with container images
> from something like docker hub.

I can honestly say "good luck wit that". There has to be an easier
route than skopeo for that functionality.

It simply has too many dependencies (and yet unused functionality) to
be built -native. IMHO, it's just not the right tool for that job.

Bruce

>
> MarkA
>
> >
> > Bruce
> >
> > >
> > > Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> > > ---
> > >  recipes-containers/skopeo/skopeo_git.bb | 73 +++++++++++++++++++++++++
> > >  1 file changed, 73 insertions(+)
> > >  create mode 100644 recipes-containers/skopeo/skopeo_git.bb
> > >
> > > diff --git a/recipes-containers/skopeo/skopeo_git.bb b/recipes-containers/skopeo/skopeo_git.bb
> > > new file mode 100644
> > > index 0000000..82d3f23
> > > --- /dev/null
> > > +++ b/recipes-containers/skopeo/skopeo_git.bb
> > > @@ -0,0 +1,73 @@
> > > +HOMEPAGE = "https://github.com/containers/skopeo"
> > > +SUMMARY = "Work with remote images registries - retrieving information, images, signing content"
> > > +LICENSE = "Apache-2.0"
> > > +LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=7e611105d3e369954840a6668c438584"
> > > +
> > > +DEPENDS = " \
> > > +    gpgme \
> > > +    multipath-tools \
> > > +    btrfs-tools \
> > > +    glib-2.0 \
> > > +    ostree \
> > > +"
> > > +
> > > +inherit go
> > > +
> > > +RDEPENDS_${PN} = " \
> > > +     gpgme \
> > > +     libgpg-error \
> > > +     libassuan \
> > > +"
> > > +
> > > +SRC_URI = "git://github.com/containers/skopeo"
> > > +
> > > +SRCREV = "1cf1e06582142c522543560f2bc6d6756696e8ad"
> > > +PV = "v0.1.39-dev+git${SRCPV}"
> > > +GO_IMPORT = "import"
> > > +
> > > +S = "${WORKDIR}/git"
> > > +
> > > +inherit goarch
> > > +inherit pkgconfig
> > > +
> > > +# This disables seccomp and apparmor, which are on by default in the
> > > +# go package.
> > > +EXTRA_OEMAKE="BUILDTAGS=''"
> > > +
> > > +do_compile() {
> > > +       export GOARCH="${TARGET_GOARCH}"
> > > +
> > > +       # Setup vendor directory so that it can be used in GOPATH.
> > > +       #
> > > +       # Go looks in a src directory under any directory in GOPATH but riddler
> > > +       # uses 'vendor' instead of 'vendor/src'. We can fix this with a symlink.
> > > +       #
> > > +       # We also need to link in the ipallocator directory as that is not under
> > > +       # a src directory.
> > > +       ln -sfn . "${S}/src/import/vendor/src"
> > > +       mkdir -p "${S}/src/import/vendor/src/github.com/projectatomic/skopeo"
> > > +       ln -sfn "${S}/src/import/skopeo" "${S}/src/import/vendor/src/github.com/projectatomic/skopeo"
> > > +       ln -sfn "${S}/src/import/version" "${S}/src/import/vendor/src/github.com/projectatomic/skopeo/version"
> > > +       export GOPATH="${S}/src/import/vendor"
> > > +
> > > +       # Pass the needed cflags/ldflags so that cgo
> > > +       # can find the needed headers files and libraries
> > > +       export CGO_ENABLED="1"
> > > +       export CFLAGS=""
> > > +       export LDFLAGS=""
> > > +       export CGO_CFLAGS="${BUILDSDK_CFLAGS} --sysroot=${STAGING_DIR_TARGET}"
> > > +       export CGO_LDFLAGS="${BUILDSDK_LDFLAGS} --sysroot=${STAGING_DIR_TARGET}"
> > > +       cd ${S}/src/import
> > > +
> > > +       oe_runmake binary-local
> > > +}
> > > +
> > > +do_install() {
> > > +       install -d ${D}/${sbindir}
> > > +       install -d ${D}/${sysconfdir}/containers
> > > +
> > > +       install ${S}/src/import/skopeo ${D}/${sbindir}/
> > > +       install ${S}/src/import/default-policy.json ${D}/${sysconfdir}/containers/policy.json
> > > +}
> > > +
> > > +INSANE_SKIP_${PN} += "ldflags"
> > > --
> > > 2.20.1
> > >
> > > --
> > > _______________________________________________
> > > meta-virtualization mailing list
> > > meta-virtualization@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/meta-virtualization
> >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
> > --
> > _______________________________________________
> > meta-virtualization mailing list
> > meta-virtualization@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-virtualization



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [PATCH 4/6] skopeo: add skopeo

[Mark Asselstine]

On Tuesday, September 3, 2019 5:00:18 P.M. EDT Bruce Ashfield wrote:
> On Tue, Sep 3, 2019 at 4:41 PM Mark Asselstine
> 
> <mark.asselstine@windriver.com> wrote:
> > On Tue, Sep 3, 2019 at 1:18 PM Bruce Ashfield <bruce.ashfield@gmail.com> 
wrote:
> > > On Sun, Sep 1, 2019 at 4:35 PM Stefan Agner <stefan@agner.ch> wrote:
> > > > From: Stefan Agner <stefan.agner@toradex.com>
> > > > 
> > > > skopeo is a command line utility that performs various operations on
> > > > container images and image repositories.
> > > > 
> > > > skopeo can work with OCI images as well as the original Docker v2
> > > > images.
> > > > 
> > > > The recipe originates from from meta-overc commit a497792. It has
> > > > been updated with the new project URL and v0.1.39.
> > > 
> > > Nice!
> > > 
> > > This was on my list to bring into meta-virtualization. Once I can
> > > confirm that it passes the meta-overc use cases, I'll merge this and
> > > drop the one from meta-overc.
> > 
> > Which takes an item off my todo list. So double nice!
> > 
> > Eventually I want to have this build -native and an addition to the
> > fetcher so it can be used to populate a rootfs with container images
> > from something like docker hub.
> 
> I can honestly say "good luck wit that". There has to be an easier
> route than skopeo for that functionality.
> 
> It simply has too many dependencies (and yet unused functionality) to
> be built -native. IMHO, it's just not the right tool for that job.
> 

For sure and knowing that you have spent quite a bit of time looking at this I 
am not about to argue against your assessment. I don't think this closes the 
door on working with the skopeo folks to break up the functionality in order 
to make this more feasible. At any rate, this is a ways off.

MarkA

> Bruce
> 
> > MarkA
> > 
> > > Bruce
> > > 
> > > > Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> > > > ---
> > > > 
> > > >  recipes-containers/skopeo/skopeo_git.bb | 73
> > > >  +++++++++++++++++++++++++
> > > >  1 file changed, 73 insertions(+)
> > > >  create mode 100644 recipes-containers/skopeo/skopeo_git.bb
> > > > 
> > > > diff --git a/recipes-containers/skopeo/skopeo_git.bb
> > > > b/recipes-containers/skopeo/skopeo_git.bb new file mode 100644
> > > > index 0000000..82d3f23
> > > > --- /dev/null
> > > > +++ b/recipes-containers/skopeo/skopeo_git.bb
> > > > @@ -0,0 +1,73 @@
> > > > +HOMEPAGE = "https://github.com/containers/skopeo"
> > > > +SUMMARY = "Work with remote images registries - retrieving
> > > > information, images, signing content" +LICENSE = "Apache-2.0"
> > > > +LIC_FILES_CHKSUM =
> > > > "file://src/import/LICENSE;md5=7e611105d3e369954840a6668c438584" +
> > > > +DEPENDS = " \
> > > > +    gpgme \
> > > > +    multipath-tools \
> > > > +    btrfs-tools \
> > > > +    glib-2.0 \
> > > > +    ostree \
> > > > +"
> > > > +
> > > > +inherit go
> > > > +
> > > > +RDEPENDS_${PN} = " \
> > > > +     gpgme \
> > > > +     libgpg-error \
> > > > +     libassuan \
> > > > +"
> > > > +
> > > > +SRC_URI = "git://github.com/containers/skopeo"
> > > > +
> > > > +SRCREV = "1cf1e06582142c522543560f2bc6d6756696e8ad"
> > > > +PV = "v0.1.39-dev+git${SRCPV}"
> > > > +GO_IMPORT = "import"
> > > > +
> > > > +S = "${WORKDIR}/git"
> > > > +
> > > > +inherit goarch
> > > > +inherit pkgconfig
> > > > +
> > > > +# This disables seccomp and apparmor, which are on by default in the
> > > > +# go package.
> > > > +EXTRA_OEMAKE="BUILDTAGS=''"
> > > > +
> > > > +do_compile() {
> > > > +       export GOARCH="${TARGET_GOARCH}"
> > > > +
> > > > +       # Setup vendor directory so that it can be used in GOPATH.
> > > > +       #
> > > > +       # Go looks in a src directory under any directory in GOPATH
> > > > but riddler +       # uses 'vendor' instead of 'vendor/src'. We can
> > > > fix this with a symlink. +       #
> > > > +       # We also need to link in the ipallocator directory as that is
> > > > not under +       # a src directory.
> > > > +       ln -sfn . "${S}/src/import/vendor/src"
> > > > +       mkdir -p
> > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo" +      
> > > > ln -sfn "${S}/src/import/skopeo"
> > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo" +      
> > > > ln -sfn "${S}/src/import/version"
> > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo/version"
> > > > +       export GOPATH="${S}/src/import/vendor"
> > > > +
> > > > +       # Pass the needed cflags/ldflags so that cgo
> > > > +       # can find the needed headers files and libraries
> > > > +       export CGO_ENABLED="1"
> > > > +       export CFLAGS=""
> > > > +       export LDFLAGS=""
> > > > +       export CGO_CFLAGS="${BUILDSDK_CFLAGS}
> > > > --sysroot=${STAGING_DIR_TARGET}" +       export
> > > > CGO_LDFLAGS="${BUILDSDK_LDFLAGS} --sysroot=${STAGING_DIR_TARGET}" +  
> > > >     cd ${S}/src/import
> > > > +
> > > > +       oe_runmake binary-local
> > > > +}
> > > > +
> > > > +do_install() {
> > > > +       install -d ${D}/${sbindir}
> > > > +       install -d ${D}/${sysconfdir}/containers
> > > > +
> > > > +       install ${S}/src/import/skopeo ${D}/${sbindir}/
> > > > +       install ${S}/src/import/default-policy.json
> > > > ${D}/${sysconfdir}/containers/policy.json +}
> > > > +
> > > > +INSANE_SKIP_${PN} += "ldflags"
> > > > --
> > > > 2.20.1
> > > > 
> > > > --
> > > > _______________________________________________
> > > > meta-virtualization mailing list
> > > > meta-virtualization@yoctoproject.org
> > > > https://lists.yoctoproject.org/listinfo/meta-virtualization
> > > 
> > > --
> > > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > > thee at its end
> > > - "Use the force Harry" - Gandalf, Star Trek II
> > > --
> > > _______________________________________________
> > > meta-virtualization mailing list
> > > meta-virtualization@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/meta-virtualization

Re: [PATCH 4/6] skopeo: add skopeo

[Bruce Ashfield]

On Tue, Sep 3, 2019 at 5:06 PM Mark Asselstine
<mark.asselstine@windriver.com> wrote:
>
> On Tuesday, September 3, 2019 5:00:18 P.M. EDT Bruce Ashfield wrote:
> > On Tue, Sep 3, 2019 at 4:41 PM Mark Asselstine
> >
> > <mark.asselstine@windriver.com> wrote:
> > > On Tue, Sep 3, 2019 at 1:18 PM Bruce Ashfield <bruce.ashfield@gmail.com>
> wrote:
> > > > On Sun, Sep 1, 2019 at 4:35 PM Stefan Agner <stefan@agner.ch> wrote:
> > > > > From: Stefan Agner <stefan.agner@toradex.com>
> > > > >
> > > > > skopeo is a command line utility that performs various operations on
> > > > > container images and image repositories.
> > > > >
> > > > > skopeo can work with OCI images as well as the original Docker v2
> > > > > images.
> > > > >
> > > > > The recipe originates from from meta-overc commit a497792. It has
> > > > > been updated with the new project URL and v0.1.39.
> > > >
> > > > Nice!
> > > >
> > > > This was on my list to bring into meta-virtualization. Once I can
> > > > confirm that it passes the meta-overc use cases, I'll merge this and
> > > > drop the one from meta-overc.
> > >
> > > Which takes an item off my todo list. So double nice!
> > >
> > > Eventually I want to have this build -native and an addition to the
> > > fetcher so it can be used to populate a rootfs with container images
> > > from something like docker hub.
> >
> > I can honestly say "good luck wit that". There has to be an easier
> > route than skopeo for that functionality.
> >
> > It simply has too many dependencies (and yet unused functionality) to
> > be built -native. IMHO, it's just not the right tool for that job.
> >
>
> For sure and knowing that you have spent quite a bit of time looking at this I
> am not about to argue against your assessment. I don't think this closes the
> door on working with the skopeo folks to break up the functionality in order
> to make this more feasible. At any rate, this is a ways off.

... or there just might be something in development for this already.
I've heard of some oci / standards stuff that might address this, or
maybe some of the alternate tools to skope are a better starting
point.

I'm just warning anyone that tries this, that they'll either have to
split / drop functionality or chase a LOT of -native dependencies.

Bruce

>
> MarkA
>
> > Bruce
> >
> > > MarkA
> > >
> > > > Bruce
> > > >
> > > > > Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> > > > > ---
> > > > >
> > > > >  recipes-containers/skopeo/skopeo_git.bb | 73
> > > > >  +++++++++++++++++++++++++
> > > > >  1 file changed, 73 insertions(+)
> > > > >  create mode 100644 recipes-containers/skopeo/skopeo_git.bb
> > > > >
> > > > > diff --git a/recipes-containers/skopeo/skopeo_git.bb
> > > > > b/recipes-containers/skopeo/skopeo_git.bb new file mode 100644
> > > > > index 0000000..82d3f23
> > > > > --- /dev/null
> > > > > +++ b/recipes-containers/skopeo/skopeo_git.bb
> > > > > @@ -0,0 +1,73 @@
> > > > > +HOMEPAGE = "https://github.com/containers/skopeo"
> > > > > +SUMMARY = "Work with remote images registries - retrieving
> > > > > information, images, signing content" +LICENSE = "Apache-2.0"
> > > > > +LIC_FILES_CHKSUM =
> > > > > "file://src/import/LICENSE;md5=7e611105d3e369954840a6668c438584" +
> > > > > +DEPENDS = " \
> > > > > +    gpgme \
> > > > > +    multipath-tools \
> > > > > +    btrfs-tools \
> > > > > +    glib-2.0 \
> > > > > +    ostree \
> > > > > +"
> > > > > +
> > > > > +inherit go
> > > > > +
> > > > > +RDEPENDS_${PN} = " \
> > > > > +     gpgme \
> > > > > +     libgpg-error \
> > > > > +     libassuan \
> > > > > +"
> > > > > +
> > > > > +SRC_URI = "git://github.com/containers/skopeo"
> > > > > +
> > > > > +SRCREV = "1cf1e06582142c522543560f2bc6d6756696e8ad"
> > > > > +PV = "v0.1.39-dev+git${SRCPV}"
> > > > > +GO_IMPORT = "import"
> > > > > +
> > > > > +S = "${WORKDIR}/git"
> > > > > +
> > > > > +inherit goarch
> > > > > +inherit pkgconfig
> > > > > +
> > > > > +# This disables seccomp and apparmor, which are on by default in the
> > > > > +# go package.
> > > > > +EXTRA_OEMAKE="BUILDTAGS=''"
> > > > > +
> > > > > +do_compile() {
> > > > > +       export GOARCH="${TARGET_GOARCH}"
> > > > > +
> > > > > +       # Setup vendor directory so that it can be used in GOPATH.
> > > > > +       #
> > > > > +       # Go looks in a src directory under any directory in GOPATH
> > > > > but riddler +       # uses 'vendor' instead of 'vendor/src'. We can
> > > > > fix this with a symlink. +       #
> > > > > +       # We also need to link in the ipallocator directory as that is
> > > > > not under +       # a src directory.
> > > > > +       ln -sfn . "${S}/src/import/vendor/src"
> > > > > +       mkdir -p
> > > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo" +
> > > > > ln -sfn "${S}/src/import/skopeo"
> > > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo" +
> > > > > ln -sfn "${S}/src/import/version"
> > > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo/version"
> > > > > +       export GOPATH="${S}/src/import/vendor"
> > > > > +
> > > > > +       # Pass the needed cflags/ldflags so that cgo
> > > > > +       # can find the needed headers files and libraries
> > > > > +       export CGO_ENABLED="1"
> > > > > +       export CFLAGS=""
> > > > > +       export LDFLAGS=""
> > > > > +       export CGO_CFLAGS="${BUILDSDK_CFLAGS}
> > > > > --sysroot=${STAGING_DIR_TARGET}" +       export
> > > > > CGO_LDFLAGS="${BUILDSDK_LDFLAGS} --sysroot=${STAGING_DIR_TARGET}" +
> > > > >     cd ${S}/src/import
> > > > > +
> > > > > +       oe_runmake binary-local
> > > > > +}
> > > > > +
> > > > > +do_install() {
> > > > > +       install -d ${D}/${sbindir}
> > > > > +       install -d ${D}/${sysconfdir}/containers
> > > > > +
> > > > > +       install ${S}/src/import/skopeo ${D}/${sbindir}/
> > > > > +       install ${S}/src/import/default-policy.json
> > > > > ${D}/${sysconfdir}/containers/policy.json +}
> > > > > +
> > > > > +INSANE_SKIP_${PN} += "ldflags"
> > > > > --
> > > > > 2.20.1
> > > > >
> > > > > --
> > > > > _______________________________________________
> > > > > meta-virtualization mailing list
> > > > > meta-virtualization@yoctoproject.org
> > > > > https://lists.yoctoproject.org/listinfo/meta-virtualization
> > > >
> > > > --
> > > > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > > > thee at its end
> > > > - "Use the force Harry" - Gandalf, Star Trek II
> > > > --
> > > > _______________________________________________
> > > > meta-virtualization mailing list
> > > > meta-virtualization@yoctoproject.org
> > > > https://lists.yoctoproject.org/listinfo/meta-virtualization
>
>
>
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [PATCH 4/6] skopeo: add skopeo

[Mark Asselstine]

On Tuesday, September 3, 2019 5:13:54 P.M. EDT Bruce Ashfield wrote:
> On Tue, Sep 3, 2019 at 5:06 PM Mark Asselstine
> 
> <mark.asselstine@windriver.com> wrote:
> > On Tuesday, September 3, 2019 5:00:18 P.M. EDT Bruce Ashfield wrote:
> > > On Tue, Sep 3, 2019 at 4:41 PM Mark Asselstine
> > > 
> > > <mark.asselstine@windriver.com> wrote:
> > > > On Tue, Sep 3, 2019 at 1:18 PM Bruce Ashfield
> > > > <bruce.ashfield@gmail.com>
> > 
> > wrote:
> > > > > On Sun, Sep 1, 2019 at 4:35 PM Stefan Agner <stefan@agner.ch> wrote:
> > > > > > From: Stefan Agner <stefan.agner@toradex.com>
> > > > > > 
> > > > > > skopeo is a command line utility that performs various operations
> > > > > > on
> > > > > > container images and image repositories.
> > > > > > 
> > > > > > skopeo can work with OCI images as well as the original Docker v2
> > > > > > images.
> > > > > > 
> > > > > > The recipe originates from from meta-overc commit a497792. It has
> > > > > > been updated with the new project URL and v0.1.39.
> > > > > 
> > > > > Nice!
> > > > > 
> > > > > This was on my list to bring into meta-virtualization. Once I can
> > > > > confirm that it passes the meta-overc use cases, I'll merge this and
> > > > > drop the one from meta-overc.
> > > > 
> > > > Which takes an item off my todo list. So double nice!
> > > > 
> > > > Eventually I want to have this build -native and an addition to the
> > > > fetcher so it can be used to populate a rootfs with container images
> > > > from something like docker hub.
> > > 
> > > I can honestly say "good luck wit that". There has to be an easier
> > > route than skopeo for that functionality.
> > > 
> > > It simply has too many dependencies (and yet unused functionality) to
> > > be built -native. IMHO, it's just not the right tool for that job.
> > 
> > For sure and knowing that you have spent quite a bit of time looking at
> > this I am not about to argue against your assessment. I don't think this
> > closes the door on working with the skopeo folks to break up the
> > functionality in order to make this more feasible. At any rate, this is a
> > ways off.
> 
> ... or there just might be something in development for this already.
> I've heard of some oci / standards stuff that might address this, or
> maybe some of the alternate tools to skope are a better starting
> point.
> 
> I'm just warning anyone that tries this, that they'll either have to
> split / drop functionality or chase a LOT of -native dependencies.

Fair enough. When this actually gets to a point that I might be looking at it 
I will be sure to check in with folks here to sort out options and a plan to 
move things along.

MarkA

> 
> Bruce
> 
> > MarkA
> > 
> > > Bruce
> > > 
> > > > MarkA
> > > > 
> > > > > Bruce
> > > > > 
> > > > > > Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> > > > > > ---
> > > > > > 
> > > > > >  recipes-containers/skopeo/skopeo_git.bb | 73
> > > > > >  +++++++++++++++++++++++++
> > > > > >  1 file changed, 73 insertions(+)
> > > > > >  create mode 100644 recipes-containers/skopeo/skopeo_git.bb
> > > > > > 
> > > > > > diff --git a/recipes-containers/skopeo/skopeo_git.bb
> > > > > > b/recipes-containers/skopeo/skopeo_git.bb new file mode 100644
> > > > > > index 0000000..82d3f23
> > > > > > --- /dev/null
> > > > > > +++ b/recipes-containers/skopeo/skopeo_git.bb
> > > > > > @@ -0,0 +1,73 @@
> > > > > > +HOMEPAGE = "https://github.com/containers/skopeo"
> > > > > > +SUMMARY = "Work with remote images registries - retrieving
> > > > > > information, images, signing content" +LICENSE = "Apache-2.0"
> > > > > > +LIC_FILES_CHKSUM =
> > > > > > "file://src/import/LICENSE;md5=7e611105d3e369954840a6668c438584" +
> > > > > > +DEPENDS = " \
> > > > > > +    gpgme \
> > > > > > +    multipath-tools \
> > > > > > +    btrfs-tools \
> > > > > > +    glib-2.0 \
> > > > > > +    ostree \
> > > > > > +"
> > > > > > +
> > > > > > +inherit go
> > > > > > +
> > > > > > +RDEPENDS_${PN} = " \
> > > > > > +     gpgme \
> > > > > > +     libgpg-error \
> > > > > > +     libassuan \
> > > > > > +"
> > > > > > +
> > > > > > +SRC_URI = "git://github.com/containers/skopeo"
> > > > > > +
> > > > > > +SRCREV = "1cf1e06582142c522543560f2bc6d6756696e8ad"
> > > > > > +PV = "v0.1.39-dev+git${SRCPV}"
> > > > > > +GO_IMPORT = "import"
> > > > > > +
> > > > > > +S = "${WORKDIR}/git"
> > > > > > +
> > > > > > +inherit goarch
> > > > > > +inherit pkgconfig
> > > > > > +
> > > > > > +# This disables seccomp and apparmor, which are on by default in
> > > > > > the
> > > > > > +# go package.
> > > > > > +EXTRA_OEMAKE="BUILDTAGS=''"
> > > > > > +
> > > > > > +do_compile() {
> > > > > > +       export GOARCH="${TARGET_GOARCH}"
> > > > > > +
> > > > > > +       # Setup vendor directory so that it can be used in GOPATH.
> > > > > > +       #
> > > > > > +       # Go looks in a src directory under any directory in
> > > > > > GOPATH
> > > > > > but riddler +       # uses 'vendor' instead of 'vendor/src'. We
> > > > > > can
> > > > > > fix this with a symlink. +       #
> > > > > > +       # We also need to link in the ipallocator directory as
> > > > > > that is
> > > > > > not under +       # a src directory.
> > > > > > +       ln -sfn . "${S}/src/import/vendor/src"
> > > > > > +       mkdir -p
> > > > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo" +
> > > > > > ln -sfn "${S}/src/import/skopeo"
> > > > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo" +
> > > > > > ln -sfn "${S}/src/import/version"
> > > > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo/versio
> > > > > > n"
> > > > > > +       export GOPATH="${S}/src/import/vendor"
> > > > > > +
> > > > > > +       # Pass the needed cflags/ldflags so that cgo
> > > > > > +       # can find the needed headers files and libraries
> > > > > > +       export CGO_ENABLED="1"
> > > > > > +       export CFLAGS=""
> > > > > > +       export LDFLAGS=""
> > > > > > +       export CGO_CFLAGS="${BUILDSDK_CFLAGS}
> > > > > > --sysroot=${STAGING_DIR_TARGET}" +       export
> > > > > > CGO_LDFLAGS="${BUILDSDK_LDFLAGS} --sysroot=${STAGING_DIR_TARGET}"
> > > > > > +
> > > > > > 
> > > > > >     cd ${S}/src/import
> > > > > > 
> > > > > > +
> > > > > > +       oe_runmake binary-local
> > > > > > +}
> > > > > > +
> > > > > > +do_install() {
> > > > > > +       install -d ${D}/${sbindir}
> > > > > > +       install -d ${D}/${sysconfdir}/containers
> > > > > > +
> > > > > > +       install ${S}/src/import/skopeo ${D}/${sbindir}/
> > > > > > +       install ${S}/src/import/default-policy.json
> > > > > > ${D}/${sysconfdir}/containers/policy.json +}
> > > > > > +
> > > > > > +INSANE_SKIP_${PN} += "ldflags"
> > > > > > --
> > > > > > 2.20.1
> > > > > > 
> > > > > > --
> > > > > > _______________________________________________
> > > > > > meta-virtualization mailing list
> > > > > > meta-virtualization@yoctoproject.org
> > > > > > https://lists.yoctoproject.org/listinfo/meta-virtualization
> > > > > 
> > > > > --
> > > > > - Thou shalt not follow the NULL pointer, for chaos and madness
> > > > > await
> > > > > thee at its end
> > > > > - "Use the force Harry" - Gandalf, Star Trek II
> > > > > --
> > > > > _______________________________________________
> > > > > meta-virtualization mailing list
> > > > > meta-virtualization@yoctoproject.org
> > > > > https://lists.yoctoproject.org/listinfo/meta-virtualization

Re: [PATCH 0/6] podman: add initial recipe

[Stefan Agner]

On 2019-09-03 19:20, Bruce Ashfield wrote:
> On Sun, Sep 1, 2019 at 4:34 PM Stefan Agner <stefan@agner.ch> wrote:
>>
>> From: Stefan Agner <stefan.agner@toradex.com>
>>
>> This adds Podman a daemonless container engine for developing,
>> managing, and running OCI Containers on your Linux System.
>> Containers can either be run as root or in rootless mode.
>> Simply put: `alias docker=podman`.
>>
> 
> Also nice! This was also on my list, since I've been using runc/OCI
> containers without any daemons for quite some time, and I thought this
> would make a good addition to that support.
> 
>> Currently a minimal set of features is supported. It requires
> 
> Did you have a list of those features ? It might be a good idea to
> document them in a  README, so we'll know when someone is asking for
> something that isn't supported by design.

The feature list actually grew to a bit more than minimal during
development, so "minimal" is not quite accurate. But will be a bit more
clear on what works in the next revision.

--
Stefan

> 
> Bruce
> 
>> meta-security since libseccomp seems to be mandatory.
>>
>> --
>> Stefan
>>
>> Stefan Agner (6):
>>   conmon: initial add
>>   go-metalinter: add recipe for gometalinter
>>   go-md2man: add md2man
>>   skopeo: add skopeo
>>   cni: move cni tools to /usr/lib/cni
>>   podmon: add the Pod Manager tool
>>
>>  recipes-containers/conmon/conmon_2.0.0.bb     | 30 ++++++
>>  ...ail-if-clean-is-called-without-a-bui.patch | 31 +++++++
>>  recipes-containers/cri-o/files/crio.conf      |  2 +-
>>  recipes-containers/podman/podman_git.bb       | 91 +++++++++++++++++++
>>  recipes-containers/skopeo/skopeo_git.bb       | 73 +++++++++++++++
>>  recipes-devtools/go/go-md2man_git.bb          | 20 ++++
>>  recipes-devtools/go/go-metalinter_git.bb      | 24 +++++
>>  recipes-networking/cni/cni_git.bb             |  4 +-
>>  8 files changed, 272 insertions(+), 3 deletions(-)
>>  create mode 100644 recipes-containers/conmon/conmon_2.0.0.bb
>>  create mode 100644 recipes-containers/conmon/files/0001-Makefile-don-t-fail-if-clean-is-called-without-a-bui.patch
>>  create mode 100644 recipes-containers/podman/podman_git.bb
>>  create mode 100644 recipes-containers/skopeo/skopeo_git.bb
>>  create mode 100644 recipes-devtools/go/go-md2man_git.bb
>>  create mode 100644 recipes-devtools/go/go-metalinter_git.bb
>>
>> --
>> 2.20.1
>>
>> --
>> _______________________________________________
>> meta-virtualization mailing list
>> meta-virtualization@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-virtualization

Re: [PATCH 4/6] skopeo: add skopeo

[Stefan Agner]

On 2019-09-03 23:13, Bruce Ashfield wrote:
> On Tue, Sep 3, 2019 at 5:06 PM Mark Asselstine
> <mark.asselstine@windriver.com> wrote:
>>
>> On Tuesday, September 3, 2019 5:00:18 P.M. EDT Bruce Ashfield wrote:
>> > On Tue, Sep 3, 2019 at 4:41 PM Mark Asselstine
>> >
>> > <mark.asselstine@windriver.com> wrote:
>> > > On Tue, Sep 3, 2019 at 1:18 PM Bruce Ashfield <bruce.ashfield@gmail.com>
>> wrote:
>> > > > On Sun, Sep 1, 2019 at 4:35 PM Stefan Agner <stefan@agner.ch> wrote:
>> > > > > From: Stefan Agner <stefan.agner@toradex.com>
>> > > > >
>> > > > > skopeo is a command line utility that performs various operations on
>> > > > > container images and image repositories.
>> > > > >
>> > > > > skopeo can work with OCI images as well as the original Docker v2
>> > > > > images.
>> > > > >
>> > > > > The recipe originates from from meta-overc commit a497792. It has
>> > > > > been updated with the new project URL and v0.1.39.
>> > > >
>> > > > Nice!
>> > > >
>> > > > This was on my list to bring into meta-virtualization. Once I can
>> > > > confirm that it passes the meta-overc use cases, I'll merge this and
>> > > > drop the one from meta-overc.
>> > >
>> > > Which takes an item off my todo list. So double nice!
>> > >
>> > > Eventually I want to have this build -native and an addition to the
>> > > fetcher so it can be used to populate a rootfs with container images
>> > > from something like docker hub.

I was actually thinking about something along those lines too...

>> >
>> > I can honestly say "good luck wit that". There has to be an easier
>> > route than skopeo for that functionality.
>> >
>> > It simply has too many dependencies (and yet unused functionality) to
>> > be built -native. IMHO, it's just not the right tool for that job.
>> >

Skopeo Github days "Work with remote images registries - retrieving
information, images, signing content", doesn't seem that wrong either.
Sure, it comes with some extra features, and if there is a more
lightweight solution that would be nice. But then, its still better than
running a complete container engine to fetch an image, as some people do
:-)

>>
>> For sure and knowing that you have spent quite a bit of time looking at this I
>> am not about to argue against your assessment. I don't think this closes the
>> door on working with the skopeo folks to break up the functionality in order
>> to make this more feasible. At any rate, this is a ways off.
> 
> ... or there just might be something in development for this already.
> I've heard of some oci / standards stuff that might address this, or
> maybe some of the alternate tools to skope are a better starting
> point.
> 
> I'm just warning anyone that tries this, that they'll either have to
> split / drop functionality or chase a LOT of -native dependencies.

It does not seem that bad anymore now that we use the go build systems
dependency stuff. In the OE recipe there are only a hand full
dependencies now. Isn't it just a matter of invoking native go and
things should work out automagically?

--
Stefan


> 
> Bruce
> 
>>
>> MarkA
>>
>> > Bruce
>> >
>> > > MarkA
>> > >
>> > > > Bruce
>> > > >
>> > > > > Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
>> > > > > ---
>> > > > >
>> > > > >  recipes-containers/skopeo/skopeo_git.bb | 73
>> > > > >  +++++++++++++++++++++++++
>> > > > >  1 file changed, 73 insertions(+)
>> > > > >  create mode 100644 recipes-containers/skopeo/skopeo_git.bb
>> > > > >
>> > > > > diff --git a/recipes-containers/skopeo/skopeo_git.bb
>> > > > > b/recipes-containers/skopeo/skopeo_git.bb new file mode 100644
>> > > > > index 0000000..82d3f23
>> > > > > --- /dev/null
>> > > > > +++ b/recipes-containers/skopeo/skopeo_git.bb
>> > > > > @@ -0,0 +1,73 @@
>> > > > > +HOMEPAGE = "https://github.com/containers/skopeo"
>> > > > > +SUMMARY = "Work with remote images registries - retrieving
>> > > > > information, images, signing content" +LICENSE = "Apache-2.0"
>> > > > > +LIC_FILES_CHKSUM =
>> > > > > "file://src/import/LICENSE;md5=7e611105d3e369954840a6668c438584" +
>> > > > > +DEPENDS = " \
>> > > > > +    gpgme \
>> > > > > +    multipath-tools \
>> > > > > +    btrfs-tools \
>> > > > > +    glib-2.0 \
>> > > > > +    ostree \
>> > > > > +"
>> > > > > +
>> > > > > +inherit go
>> > > > > +
>> > > > > +RDEPENDS_${PN} = " \
>> > > > > +     gpgme \
>> > > > > +     libgpg-error \
>> > > > > +     libassuan \
>> > > > > +"
>> > > > > +
>> > > > > +SRC_URI = "git://github.com/containers/skopeo"
>> > > > > +
>> > > > > +SRCREV = "1cf1e06582142c522543560f2bc6d6756696e8ad"
>> > > > > +PV = "v0.1.39-dev+git${SRCPV}"
>> > > > > +GO_IMPORT = "import"
>> > > > > +
>> > > > > +S = "${WORKDIR}/git"
>> > > > > +
>> > > > > +inherit goarch
>> > > > > +inherit pkgconfig
>> > > > > +
>> > > > > +# This disables seccomp and apparmor, which are on by default in the
>> > > > > +# go package.
>> > > > > +EXTRA_OEMAKE="BUILDTAGS=''"
>> > > > > +
>> > > > > +do_compile() {
>> > > > > +       export GOARCH="${TARGET_GOARCH}"
>> > > > > +
>> > > > > +       # Setup vendor directory so that it can be used in GOPATH.
>> > > > > +       #
>> > > > > +       # Go looks in a src directory under any directory in GOPATH
>> > > > > but riddler +       # uses 'vendor' instead of 'vendor/src'. We can
>> > > > > fix this with a symlink. +       #
>> > > > > +       # We also need to link in the ipallocator directory as that is
>> > > > > not under +       # a src directory.
>> > > > > +       ln -sfn . "${S}/src/import/vendor/src"
>> > > > > +       mkdir -p
>> > > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo" +
>> > > > > ln -sfn "${S}/src/import/skopeo"
>> > > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo" +
>> > > > > ln -sfn "${S}/src/import/version"
>> > > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo/version"
>> > > > > +       export GOPATH="${S}/src/import/vendor"
>> > > > > +
>> > > > > +       # Pass the needed cflags/ldflags so that cgo
>> > > > > +       # can find the needed headers files and libraries
>> > > > > +       export CGO_ENABLED="1"
>> > > > > +       export CFLAGS=""
>> > > > > +       export LDFLAGS=""
>> > > > > +       export CGO_CFLAGS="${BUILDSDK_CFLAGS}
>> > > > > --sysroot=${STAGING_DIR_TARGET}" +       export
>> > > > > CGO_LDFLAGS="${BUILDSDK_LDFLAGS} --sysroot=${STAGING_DIR_TARGET}" +
>> > > > >     cd ${S}/src/import
>> > > > > +
>> > > > > +       oe_runmake binary-local
>> > > > > +}
>> > > > > +
>> > > > > +do_install() {
>> > > > > +       install -d ${D}/${sbindir}
>> > > > > +       install -d ${D}/${sysconfdir}/containers
>> > > > > +
>> > > > > +       install ${S}/src/import/skopeo ${D}/${sbindir}/
>> > > > > +       install ${S}/src/import/default-policy.json
>> > > > > ${D}/${sysconfdir}/containers/policy.json +}
>> > > > > +
>> > > > > +INSANE_SKIP_${PN} += "ldflags"
>> > > > > --
>> > > > > 2.20.1
>> > > > >
>> > > > > --
>> > > > > _______________________________________________
>> > > > > meta-virtualization mailing list
>> > > > > meta-virtualization@yoctoproject.org
>> > > > > https://lists.yoctoproject.org/listinfo/meta-virtualization
>> > > >
>> > > > --
>> > > > - Thou shalt not follow the NULL pointer, for chaos and madness await
>> > > > thee at its end
>> > > > - "Use the force Harry" - Gandalf, Star Trek II
>> > > > --
>> > > > _______________________________________________
>> > > > meta-virtualization mailing list
>> > > > meta-virtualization@yoctoproject.org
>> > > > https://lists.yoctoproject.org/listinfo/meta-virtualization
>>
>>
>>
>>

Re: [PATCH 0/6] podman: add initial recipe

[Bruce Ashfield]

On Wed, Sep 4, 2019 at 2:44 AM Stefan Agner <stefan@agner.ch> wrote:
>
> On 2019-09-03 19:20, Bruce Ashfield wrote:
> > On Sun, Sep 1, 2019 at 4:34 PM Stefan Agner <stefan@agner.ch> wrote:
> >>
> >> From: Stefan Agner <stefan.agner@toradex.com>
> >>
> >> This adds Podman a daemonless container engine for developing,
> >> managing, and running OCI Containers on your Linux System.
> >> Containers can either be run as root or in rootless mode.
> >> Simply put: `alias docker=podman`.
> >>
> >
> > Also nice! This was also on my list, since I've been using runc/OCI
> > containers without any daemons for quite some time, and I thought this
> > would make a good addition to that support.
> >
> >> Currently a minimal set of features is supported. It requires
> >
> > Did you have a list of those features ? It might be a good idea to
> > document them in a  README, so we'll know when someone is asking for
> > something that isn't supported by design.
>
> The feature list actually grew to a bit more than minimal during
> development, so "minimal" is not quite accurate. But will be a bit more
> clear on what works in the next revision.

Even better!

Thanks for contributing the support.

Bruce

>
> --
> Stefan
>
> >
> > Bruce
> >
> >> meta-security since libseccomp seems to be mandatory.
> >>
> >> --
> >> Stefan
> >>
> >> Stefan Agner (6):
> >>   conmon: initial add
> >>   go-metalinter: add recipe for gometalinter
> >>   go-md2man: add md2man
> >>   skopeo: add skopeo
> >>   cni: move cni tools to /usr/lib/cni
> >>   podmon: add the Pod Manager tool
> >>
> >>  recipes-containers/conmon/conmon_2.0.0.bb     | 30 ++++++
> >>  ...ail-if-clean-is-called-without-a-bui.patch | 31 +++++++
> >>  recipes-containers/cri-o/files/crio.conf      |  2 +-
> >>  recipes-containers/podman/podman_git.bb       | 91 +++++++++++++++++++
> >>  recipes-containers/skopeo/skopeo_git.bb       | 73 +++++++++++++++
> >>  recipes-devtools/go/go-md2man_git.bb          | 20 ++++
> >>  recipes-devtools/go/go-metalinter_git.bb      | 24 +++++
> >>  recipes-networking/cni/cni_git.bb             |  4 +-
> >>  8 files changed, 272 insertions(+), 3 deletions(-)
> >>  create mode 100644 recipes-containers/conmon/conmon_2.0.0.bb
> >>  create mode 100644 recipes-containers/conmon/files/0001-Makefile-don-t-fail-if-clean-is-called-without-a-bui.patch
> >>  create mode 100644 recipes-containers/podman/podman_git.bb
> >>  create mode 100644 recipes-containers/skopeo/skopeo_git.bb
> >>  create mode 100644 recipes-devtools/go/go-md2man_git.bb
> >>  create mode 100644 recipes-devtools/go/go-metalinter_git.bb
> >>
> >> --
> >> 2.20.1
> >>
> >> --
> >> _______________________________________________
> >> meta-virtualization mailing list
> >> meta-virtualization@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/meta-virtualization



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [PATCH 4/6] skopeo: add skopeo

[Bruce Ashfield]

On Wed, Sep 4, 2019 at 2:56 AM Stefan Agner <stefan@agner.ch> wrote:
>
> On 2019-09-03 23:13, Bruce Ashfield wrote:
> > On Tue, Sep 3, 2019 at 5:06 PM Mark Asselstine
> > <mark.asselstine@windriver.com> wrote:
> >>
> >> On Tuesday, September 3, 2019 5:00:18 P.M. EDT Bruce Ashfield wrote:
> >> > On Tue, Sep 3, 2019 at 4:41 PM Mark Asselstine
> >> >
> >> > <mark.asselstine@windriver.com> wrote:
> >> > > On Tue, Sep 3, 2019 at 1:18 PM Bruce Ashfield <bruce.ashfield@gmail.com>
> >> wrote:
> >> > > > On Sun, Sep 1, 2019 at 4:35 PM Stefan Agner <stefan@agner.ch> wrote:
> >> > > > > From: Stefan Agner <stefan.agner@toradex.com>
> >> > > > >
> >> > > > > skopeo is a command line utility that performs various operations on
> >> > > > > container images and image repositories.
> >> > > > >
> >> > > > > skopeo can work with OCI images as well as the original Docker v2
> >> > > > > images.
> >> > > > >
> >> > > > > The recipe originates from from meta-overc commit a497792. It has
> >> > > > > been updated with the new project URL and v0.1.39.
> >> > > >
> >> > > > Nice!
> >> > > >
> >> > > > This was on my list to bring into meta-virtualization. Once I can
> >> > > > confirm that it passes the meta-overc use cases, I'll merge this and
> >> > > > drop the one from meta-overc.
> >> > >
> >> > > Which takes an item off my todo list. So double nice!
> >> > >
> >> > > Eventually I want to have this build -native and an addition to the
> >> > > fetcher so it can be used to populate a rootfs with container images
> >> > > from something like docker hub.
>
> I was actually thinking about something along those lines too...
>
> >> >
> >> > I can honestly say "good luck wit that". There has to be an easier
> >> > route than skopeo for that functionality.
> >> >
> >> > It simply has too many dependencies (and yet unused functionality) to
> >> > be built -native. IMHO, it's just not the right tool for that job.
> >> >
>
> Skopeo Github days "Work with remote images registries - retrieving
> information, images, signing content", doesn't seem that wrong either.

Indeed. I use skopeo extensively, so I do like it. But I'm still
holding out hopes that something else will come out of the CNCF/OCI
working groups that is smaller, or at least a better defined and
focused.

When someone asked this before, the tooling really isn't the hard
part. It is going to be licensing, reproducibility, support, etc, etc.
So if we were able to do this, there's many landmines that aren't
technical.

> Sure, it comes with some extra features, and if there is a more
> lightweight solution that would be nice. But then, its still better than
> running a complete container engine to fetch an image, as some people do
> :-)
>
> >>
> >> For sure and knowing that you have spent quite a bit of time looking at this I
> >> am not about to argue against your assessment. I don't think this closes the
> >> door on working with the skopeo folks to break up the functionality in order
> >> to make this more feasible. At any rate, this is a ways off.
> >
> > ... or there just might be something in development for this already.
> > I've heard of some oci / standards stuff that might address this, or
> > maybe some of the alternate tools to skope are a better starting
> > point.
> >
> > I'm just warning anyone that tries this, that they'll either have to
> > split / drop functionality or chase a LOT of -native dependencies.
>
> It does not seem that bad anymore now that we use the go build systems
> dependency stuff. In the OE recipe there are only a hand full
> dependencies now. Isn't it just a matter of invoking native go and
> things should work out automagically?

It wasn't that easy in my experimenting. All of the different disk
support was spidering through a lot of utilities that weren't easy to
build as -native.

But absolutely, the go packaging is better now, and we have just
captured / fetched what we need in most of the recipes, so there's no
longer 30 or 40 go recipes to extend to native (and of which 20 broke
when I tried it).

Cheers,

Bruce

>
> --
> Stefan
>
>
> >
> > Bruce
> >
> >>
> >> MarkA
> >>
> >> > Bruce
> >> >
> >> > > MarkA
> >> > >
> >> > > > Bruce
> >> > > >
> >> > > > > Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> >> > > > > ---
> >> > > > >
> >> > > > >  recipes-containers/skopeo/skopeo_git.bb | 73
> >> > > > >  +++++++++++++++++++++++++
> >> > > > >  1 file changed, 73 insertions(+)
> >> > > > >  create mode 100644 recipes-containers/skopeo/skopeo_git.bb
> >> > > > >
> >> > > > > diff --git a/recipes-containers/skopeo/skopeo_git.bb
> >> > > > > b/recipes-containers/skopeo/skopeo_git.bb new file mode 100644
> >> > > > > index 0000000..82d3f23
> >> > > > > --- /dev/null
> >> > > > > +++ b/recipes-containers/skopeo/skopeo_git.bb
> >> > > > > @@ -0,0 +1,73 @@
> >> > > > > +HOMEPAGE = "https://github.com/containers/skopeo"
> >> > > > > +SUMMARY = "Work with remote images registries - retrieving
> >> > > > > information, images, signing content" +LICENSE = "Apache-2.0"
> >> > > > > +LIC_FILES_CHKSUM =
> >> > > > > "file://src/import/LICENSE;md5=7e611105d3e369954840a6668c438584" +
> >> > > > > +DEPENDS = " \
> >> > > > > +    gpgme \
> >> > > > > +    multipath-tools \
> >> > > > > +    btrfs-tools \
> >> > > > > +    glib-2.0 \
> >> > > > > +    ostree \
> >> > > > > +"
> >> > > > > +
> >> > > > > +inherit go
> >> > > > > +
> >> > > > > +RDEPENDS_${PN} = " \
> >> > > > > +     gpgme \
> >> > > > > +     libgpg-error \
> >> > > > > +     libassuan \
> >> > > > > +"
> >> > > > > +
> >> > > > > +SRC_URI = "git://github.com/containers/skopeo"
> >> > > > > +
> >> > > > > +SRCREV = "1cf1e06582142c522543560f2bc6d6756696e8ad"
> >> > > > > +PV = "v0.1.39-dev+git${SRCPV}"
> >> > > > > +GO_IMPORT = "import"
> >> > > > > +
> >> > > > > +S = "${WORKDIR}/git"
> >> > > > > +
> >> > > > > +inherit goarch
> >> > > > > +inherit pkgconfig
> >> > > > > +
> >> > > > > +# This disables seccomp and apparmor, which are on by default in the
> >> > > > > +# go package.
> >> > > > > +EXTRA_OEMAKE="BUILDTAGS=''"
> >> > > > > +
> >> > > > > +do_compile() {
> >> > > > > +       export GOARCH="${TARGET_GOARCH}"
> >> > > > > +
> >> > > > > +       # Setup vendor directory so that it can be used in GOPATH.
> >> > > > > +       #
> >> > > > > +       # Go looks in a src directory under any directory in GOPATH
> >> > > > > but riddler +       # uses 'vendor' instead of 'vendor/src'. We can
> >> > > > > fix this with a symlink. +       #
> >> > > > > +       # We also need to link in the ipallocator directory as that is
> >> > > > > not under +       # a src directory.
> >> > > > > +       ln -sfn . "${S}/src/import/vendor/src"
> >> > > > > +       mkdir -p
> >> > > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo" +
> >> > > > > ln -sfn "${S}/src/import/skopeo"
> >> > > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo" +
> >> > > > > ln -sfn "${S}/src/import/version"
> >> > > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo/version"
> >> > > > > +       export GOPATH="${S}/src/import/vendor"
> >> > > > > +
> >> > > > > +       # Pass the needed cflags/ldflags so that cgo
> >> > > > > +       # can find the needed headers files and libraries
> >> > > > > +       export CGO_ENABLED="1"
> >> > > > > +       export CFLAGS=""
> >> > > > > +       export LDFLAGS=""
> >> > > > > +       export CGO_CFLAGS="${BUILDSDK_CFLAGS}
> >> > > > > --sysroot=${STAGING_DIR_TARGET}" +       export
> >> > > > > CGO_LDFLAGS="${BUILDSDK_LDFLAGS} --sysroot=${STAGING_DIR_TARGET}" +
> >> > > > >     cd ${S}/src/import
> >> > > > > +
> >> > > > > +       oe_runmake binary-local
> >> > > > > +}
> >> > > > > +
> >> > > > > +do_install() {
> >> > > > > +       install -d ${D}/${sbindir}
> >> > > > > +       install -d ${D}/${sysconfdir}/containers
> >> > > > > +
> >> > > > > +       install ${S}/src/import/skopeo ${D}/${sbindir}/
> >> > > > > +       install ${S}/src/import/default-policy.json
> >> > > > > ${D}/${sysconfdir}/containers/policy.json +}
> >> > > > > +
> >> > > > > +INSANE_SKIP_${PN} += "ldflags"
> >> > > > > --
> >> > > > > 2.20.1
> >> > > > >
> >> > > > > --
> >> > > > > _______________________________________________
> >> > > > > meta-virtualization mailing list
> >> > > > > meta-virtualization@yoctoproject.org
> >> > > > > https://lists.yoctoproject.org/listinfo/meta-virtualization
> >> > > >
> >> > > > --
> >> > > > - Thou shalt not follow the NULL pointer, for chaos and madness await
> >> > > > thee at its end
> >> > > > - "Use the force Harry" - Gandalf, Star Trek II
> >> > > > --
> >> > > > _______________________________________________
> >> > > > meta-virtualization mailing list
> >> > > > meta-virtualization@yoctoproject.org
> >> > > > https://lists.yoctoproject.org/listinfo/meta-virtualization
> >>
> >>
> >>
> >>



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [PATCH 5/6] cni: move cni tools to /usr/lib/cni

[Stefan Agner]

On 2019-09-03 19:28, Bruce Ashfield wrote:
> On Sun, Sep 1, 2019 at 9:33 PM ChenQi <Qi.Chen@windriver.com> wrote:
>>
>> On 09/02/2019 04:33 AM, Stefan Agner wrote:
>> > From: Stefan Agner <stefan.agner@toradex.com>
>> >
>> > Use a standard location to store the cni tools and plugins. This
>> > is more in line how other distributions package cni.
>>
>> But from what I see, at least Fedora and Ubuntu are using /opt/cni/bin
>> directory.

Fedora uses /usr/libexec/cni:
https://koji.fedoraproject.org/koji/rpminfo?rpmID=18850786

As far as I can tell there is no upstream Debian/Ubuntu package for this
yet.

Arch Linux uses /usr/lib/cni:
https://www.archlinux.org/packages/community/x86_64/cni-plugins/

I haven't seen distribution typically use /opt.

>> Also, have you tested such change with simple k8s setup which makes use
>> of these plugins? E.g. flannel?

I haven't. In fact I am not familiar with k8s setups, so this would need
me some time to understand and test...

> 
> Indeed. I haven't seen anything that looks like a standard location
> for these. I'd be interested to hear how testing went.
> 
> Is this something that we can make configurable ? That would be my
> preference, that way we can be sure to not break anyone's use case.

I guess one always can do a bbappend...?

I don't think that we can configure at runtime (E.g. have the package
manager install it into different location depending on...)

--
Stefan


> 
> Bruce
> 
>>
>> Best Regards,
>> Chen Qi
>>
>> > Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
>> > ---
>> >   recipes-containers/cri-o/files/crio.conf | 2 +-
>> >   recipes-networking/cni/cni_git.bb        | 4 ++--
>> >   2 files changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/recipes-containers/cri-o/files/crio.conf b/recipes-containers/cri-o/files/crio.conf
>> > index 51d7f40..dd22465 100644
>> > --- a/recipes-containers/cri-o/files/crio.conf
>> > +++ b/recipes-containers/cri-o/files/crio.conf
>> > @@ -144,4 +144,4 @@ registries = [
>> >   network_dir = "/etc/cni/net.d/"
>> >
>> >   # plugin_dir is is where CNI plugin binaries are stored.
>> > -plugin_dir = "/opt/cni/bin/"
>> > +plugin_dir = "/usr/lib/cni/"
>> > diff --git a/recipes-networking/cni/cni_git.bb b/recipes-networking/cni/cni_git.bb
>> > index 5348b95..86e5e0f 100644
>> > --- a/recipes-networking/cni/cni_git.bb
>> > +++ b/recipes-networking/cni/cni_git.bb
>> > @@ -63,7 +63,7 @@ do_compile() {
>> >   }
>> >
>> >   do_install() {
>> > -    localbindir="/opt/cni/bin"
>> > +    localbindir="${libdir}/cni/"
>> >
>> >       install -d ${D}${localbindir}
>> >       install -d ${D}/${sysconfdir}/cni/net.d
>> > @@ -72,7 +72,7 @@ do_install() {
>> >       install -m 755 -D ${WORKDIR}/plugins/bin/* ${D}/${localbindir}
>> >   }
>> >
>> > -FILES_${PN} += "/opt/cni/bin/*"
>> > +FILES_${PN} += "${libdir}/cni/*"
>> >
>> >   INSANE_SKIP_${PN} += "ldflags already-stripped"
>> >
>>
>>
>> --
>> _______________________________________________
>> meta-virtualization mailing list
>> meta-virtualization@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-virtualization
> 
> 
> 
> -- 
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II

Re: [PATCH 5/6] cni: move cni tools to /usr/lib/cni

[Bruce Ashfield]

On Fri, Sep 6, 2019 at 8:07 AM Stefan Agner <stefan@agner.ch> wrote:
>
> On 2019-09-03 19:28, Bruce Ashfield wrote:
> > On Sun, Sep 1, 2019 at 9:33 PM ChenQi <Qi.Chen@windriver.com> wrote:
> >>
> >> On 09/02/2019 04:33 AM, Stefan Agner wrote:
> >> > From: Stefan Agner <stefan.agner@toradex.com>
> >> >
> >> > Use a standard location to store the cni tools and plugins. This
> >> > is more in line how other distributions package cni.
> >>
> >> But from what I see, at least Fedora and Ubuntu are using /opt/cni/bin
> >> directory.
>
> Fedora uses /usr/libexec/cni:
> https://koji.fedoraproject.org/koji/rpminfo?rpmID=18850786
>
> As far as I can tell there is no upstream Debian/Ubuntu package for this
> yet.
>
> Arch Linux uses /usr/lib/cni:
> https://www.archlinux.org/packages/community/x86_64/cni-plugins/
>
> I haven't seen distribution typically use /opt.
>
> >> Also, have you tested such change with simple k8s setup which makes use
> >> of these plugins? E.g. flannel?
>
> I haven't. In fact I am not familiar with k8s setups, so this would need
> me some time to understand and test...

Indeed. It isn't easy to setup and test, so don't worry about it.

But I can say, the reason that the recipe installs to /opt/cni/bin is
that there are many parts of k8s that do expect the cni binaries to be
there. I did a quick search this morning, and that expectation is
still the case. So there may be a disconnect from standalone distro
packaged cni components, and k8s specific things.  Plus it isn't just
k8s managed cni plugins that go into that directory, there are
instructions for installing unmanaged ones to that same location.

So to avoid breaking those large software stacks, we do need to keep
/opt/cni/bin around at some level.

>
> >
> > Indeed. I haven't seen anything that looks like a standard location
> > for these. I'd be interested to hear how testing went.
> >
> > Is this something that we can make configurable ? That would be my
> > preference, that way we can be sure to not break anyone's use case.
>
> I guess one always can do a bbappend...?
>
> I don't think that we can configure at runtime (E.g. have the package
> manager install it into different location depending on...)

I was more thinking at build time. Have a packageconfig value, and
just have the CNI package grab files from both directories. That way a
bbappend would just be a packageconfig setting, and nothing more
extensive than that.

Alternatively, we could symlink one directory to the other, so they
could be found in either location.

Bruce

>
> --
> Stefan
>
>
> >
> > Bruce
> >
> >>
> >> Best Regards,
> >> Chen Qi
> >>
> >> > Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> >> > ---
> >> >   recipes-containers/cri-o/files/crio.conf | 2 +-
> >> >   recipes-networking/cni/cni_git.bb        | 4 ++--
> >> >   2 files changed, 3 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/recipes-containers/cri-o/files/crio.conf b/recipes-containers/cri-o/files/crio.conf
> >> > index 51d7f40..dd22465 100644
> >> > --- a/recipes-containers/cri-o/files/crio.conf
> >> > +++ b/recipes-containers/cri-o/files/crio.conf
> >> > @@ -144,4 +144,4 @@ registries = [
> >> >   network_dir = "/etc/cni/net.d/"
> >> >
> >> >   # plugin_dir is is where CNI plugin binaries are stored.
> >> > -plugin_dir = "/opt/cni/bin/"
> >> > +plugin_dir = "/usr/lib/cni/"
> >> > diff --git a/recipes-networking/cni/cni_git.bb b/recipes-networking/cni/cni_git.bb
> >> > index 5348b95..86e5e0f 100644
> >> > --- a/recipes-networking/cni/cni_git.bb
> >> > +++ b/recipes-networking/cni/cni_git.bb
> >> > @@ -63,7 +63,7 @@ do_compile() {
> >> >   }
> >> >
> >> >   do_install() {
> >> > -    localbindir="/opt/cni/bin"
> >> > +    localbindir="${libdir}/cni/"
> >> >
> >> >       install -d ${D}${localbindir}
> >> >       install -d ${D}/${sysconfdir}/cni/net.d
> >> > @@ -72,7 +72,7 @@ do_install() {
> >> >       install -m 755 -D ${WORKDIR}/plugins/bin/* ${D}/${localbindir}
> >> >   }
> >> >
> >> > -FILES_${PN} += "/opt/cni/bin/*"
> >> > +FILES_${PN} += "${libdir}/cni/*"
> >> >
> >> >   INSANE_SKIP_${PN} += "ldflags already-stripped"
> >> >
> >>
> >>
> >> --
> >> _______________________________________________
> >> meta-virtualization mailing list
> >> meta-virtualization@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/meta-virtualization
> >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [PATCH 6/6] podmon: add the Pod Manager tool

[Stefan Agner]

On 2019-09-03 19:26, Bruce Ashfield wrote:
> I'm assuming the subject should be "podman" and not "podmon".

Whoops, thanks for pointing out.

> 
> On Sun, Sep 1, 2019 at 4:34 PM Stefan Agner <stefan@agner.ch> wrote:
>>
>> From: Stefan Agner <stefan.agner@toradex.com>
>>
>> Podman is a daemonless container engine for developing, managing, and
>> running OCI Containers on your Linux System. Containers can either be
>> run as root or in rootless mode.
>>
>> This patch adds the initial recipe for podman. Currently a minimal
>> feature set is supported. It seems that libseccomp is mandatory, which
>> makes meta-security a mandatory dependency for this recipe.
>>
>> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
>> ---
>>  recipes-containers/podman/podman_git.bb | 91 +++++++++++++++++++++++++
>>  1 file changed, 91 insertions(+)
>>  create mode 100644 recipes-containers/podman/podman_git.bb
>>
>> diff --git a/recipes-containers/podman/podman_git.bb b/recipes-containers/podman/podman_git.bb
>> new file mode 100644
>> index 0000000..6f4e7d4
>> --- /dev/null
>> +++ b/recipes-containers/podman/podman_git.bb
>> @@ -0,0 +1,91 @@
>> +HOMEPAGE = "https://podman.io/"
>> +SUMMARY =  "A daemonless container engine"
>> +DESCRIPTION = "Podman is a daemonless container engine for developing, \
>> +    managing, and running OCI Containers on your Linux System. Containers can \
>> +    either be run as root or in rootless mode. Simply put: \
>> +    `alias docker=podman`. \
>> +    "
>> +
>> +DEPENDS = " \
>> +    go-metalinter-native \
>> +    go-md2man-native \
>> +    gpgme \
>> +    libseccomp \
>> +    ${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)} \
>> +"
>> +
>> +SRCREV = "00057929f5acfd98341964d85722383363376d52"
>> +SRC_URI = " \
>> +    git://github.com/containers/libpod.git;branch=master \
>> +"
>> +
>> +LICENSE = "Apache-2.0"
>> +LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=e3fc50a88d0a364313df4b21ef20c29e"
>> +
>> +GO_IMPORT = "import"
>> +
>> +S = "${WORKDIR}/git"
>> +
>> +PV = "1.5.1+git${SRCREV}"
>> +
>> +PACKAGES =+ "${PN}-contrib"
>> +
>> +PODMAN_PKG = "github.com/containers/libpod"
>> +BUILDTAGS = "seccomp systemd exclude_graphdriver_btrfs exclude_graphdriver_devicemapper"
> 
> On my other similar recipes, I've been asked to make this a ?= so it
> can be easily overridden. Is that possible here ?
> 

Yes, seems to work just fine.

>> +
>> +# overide LDFLAGS to allow criu to build without: "x86_64-poky-linux-ld: unrecognized option '-Wl,-O1'"
> 
> Is this a debug statement left in, or is it relevant to podman ?
> 

This actually applies to podman as well, so I copied the export and the
comment from the criu recipe.

Will fix the comment though to mention podman.


>> +export LDFLAGS=""
>> +
>> +inherit go goarch
>> +inherit systemd pkgconfig
>> +
>> +do_configure[noexec] = "1"
>> +
>> +EXTRA_OEMAKE = " \
>> +     PREFIX=${prefix} BINDIR=${bindir} LIBEXECDIR=${libexecdir} \
>> +     ETCDIR=${sysconfdir} TMPFILESDIR=${nonarch_libdir}/tmpfiles.d \
>> +     SYSTEMDDIR=${systemd_unitdir}/system USERSYSTEMDDIR=${systemd_unitdir}/user \
>> +"
>> +
>> +do_compile() {
>> +       # Set GOPATH. See 'PACKAGERS.md'. Don't rely on
>> +       # docker to download its dependencies but rather
>> +       # use dependencies packaged independently.

This comment is actually a leftover so removed this.

>> +       cd ${S}/src
>> +       rm -rf .gopath
>> +       mkdir -p .gopath/src/"$(dirname "${PODMAN_PKG}")"
>> +       ln -sf ../../../../import/ .gopath/src/"${PODMAN_PKG}"
>> +
>> +       ln -sf "../../../import/vendor/github.com/varlink/" ".gopath/src/github.com/varlink"
>> +
>> +       export GOPATH="${S}/src/.gopath"
>> +       export GOROOT="${STAGING_DIR_NATIVE}/${nonarch_libdir}/${HOST_SYS}/go"
>> +
>> +       cd ${S}/src/.gopath/src/"${PODMAN_PKG}"
>> +
>> +       make cmd/podman/varlink/iopodman.go GO=go
> 

After cleaning and rebuilding I actually noticed that the current state
does not build. I must have interfered manually to make it build and
forgot to fix-up.

This make call needs this before executing:
export GOARCH="${BUILD_GOARCH}"

> I've been trying to squash out all the raw calls to make. Does this
> work if oe_runmake is used ?

With the above, oe_runmake seems to work just fine.

> 
> Also, out of curiosity, if GO=go isn't set .. what executable does it
> try to run ?

Without GO=go it seems to use "arm-...-linux-gnueabi-go", and fails with
a exec format error:

NOTE: make -j 40 PREFIX=/usr BINDIR=/usr/bin LIBEXECDIR=/usr/libexec
ETCDIR=/etc TMPFILESDIR=/usr/lib/tmpfiles.d
SYSTEMDDIR=/usr/lib/systemd/system USERSYSTEMDDIR=/usr/lib/systemd/user
cmd/podman/varlink/iopodman.go
GO111MODULE=off arm-tdx-linux-gnueabi-go generate
./cmd/podman/varlink/...
fork/exec
/home/ags/torizoncore/build-colibri-imx7/tmp-torizon/work/cortexa7t2hf-neon-tdx-linux-gnueabi/podman/1.5.1+git00057929f5acfd98341964d85722383363376d52-r0/go-tmp/go-build868339522/b001/exe/main:
exec format error
cmd/podman/varlink/generate.go:3: running "go": exit status 1
make: *** [Makefile:475: cmd/podman/varlink/iopodman.go] Error 1
ERROR: oe_runmake failed



> 
>> +
>> +       # Pass the needed cflags/ldflags so that cgo
>> +       # can find the needed headers files and libraries
>> +       export GOARCH=${TARGET_GOARCH}
>> +       export CGO_ENABLED="1"
>> +       export CGO_CFLAGS="${CFLAGS} --sysroot=${STAGING_DIR_TARGET}"
>> +       export CGO_LDFLAGS="${LDFLAGS} --sysroot=${STAGING_DIR_TARGET}"
>> +
>> +       make BUILDTAGS="${BUILDTAGS}"
> 
> Same here. Does oe_runmake work ?

Yes, also here oe_runmake seems to do no harm.

Thanks for reviewing!

--
Stefan

> 
> Bruce
> 
>> +}
>> +
>> +do_install() {
>> +       cd ${S}/src/.gopath/src/"${PODMAN_PKG}"
>> +
>> +       oe_runmake install install.docker DESTDIR="${D}"
>> +}
>> +
>> +FILES_${PN} += " \
>> +    ${systemd_unitdir}/system/* \
>> +    ${systemd_unitdir}/user/* \
>> +    ${nonarch_libdir}/tmpfiles.d/* \
>> +    ${sysconfdir}/docker \
>> +"
>> +
>> +RDEPENDS_${PN} += "conmon runc-opencontainers iptables cni skopeo"
>> --
>> 2.20.1
>>
>> --
>> _______________________________________________
>> meta-virtualization mailing list
>> meta-virtualization@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-virtualization

Re: [PATCH 5/6] cni: move cni tools to /usr/lib/cni

[Stefan Agner]

On 2019-09-06 14:42, Bruce Ashfield wrote:
> On Fri, Sep 6, 2019 at 8:07 AM Stefan Agner <stefan@agner.ch> wrote:
>>
>> On 2019-09-03 19:28, Bruce Ashfield wrote:
>> > On Sun, Sep 1, 2019 at 9:33 PM ChenQi <Qi.Chen@windriver.com> wrote:
>> >>
>> >> On 09/02/2019 04:33 AM, Stefan Agner wrote:
>> >> > From: Stefan Agner <stefan.agner@toradex.com>
>> >> >
>> >> > Use a standard location to store the cni tools and plugins. This
>> >> > is more in line how other distributions package cni.
>> >>
>> >> But from what I see, at least Fedora and Ubuntu are using /opt/cni/bin
>> >> directory.
>>
>> Fedora uses /usr/libexec/cni:
>> https://koji.fedoraproject.org/koji/rpminfo?rpmID=18850786
>>
>> As far as I can tell there is no upstream Debian/Ubuntu package for this
>> yet.
>>
>> Arch Linux uses /usr/lib/cni:
>> https://www.archlinux.org/packages/community/x86_64/cni-plugins/
>>
>> I haven't seen distribution typically use /opt.
>>
>> >> Also, have you tested such change with simple k8s setup which makes use
>> >> of these plugins? E.g. flannel?
>>
>> I haven't. In fact I am not familiar with k8s setups, so this would need
>> me some time to understand and test...
> 
> Indeed. It isn't easy to setup and test, so don't worry about it.
> 
> But I can say, the reason that the recipe installs to /opt/cni/bin is
> that there are many parts of k8s that do expect the cni binaries to be
> there. I did a quick search this morning, and that expectation is
> still the case. So there may be a disconnect from standalone distro
> packaged cni components, and k8s specific things.  Plus it isn't just
> k8s managed cni plugins that go into that directory, there are
> instructions for installing unmanaged ones to that same location.
> 
> So to avoid breaking those large software stacks, we do need to keep
> /opt/cni/bin around at some level.
> 
>>
>> >
>> > Indeed. I haven't seen anything that looks like a standard location
>> > for these. I'd be interested to hear how testing went.
>> >
>> > Is this something that we can make configurable ? That would be my
>> > preference, that way we can be sure to not break anyone's use case.
>>
>> I guess one always can do a bbappend...?
>>
>> I don't think that we can configure at runtime (E.g. have the package
>> manager install it into different location depending on...)
> 
> I was more thinking at build time. Have a packageconfig value, and
> just have the CNI package grab files from both directories. That way a
> bbappend would just be a packageconfig setting, and nothing more
> extensive than that.
> 
> Alternatively, we could symlink one directory to the other, so they
> could be found in either location.

I kinda like this alternative better. Will try this approach in v2.

--
Stefan

> 
> Bruce
> 
>>
>> --
>> Stefan
>>
>>
>> >
>> > Bruce
>> >
>> >>
>> >> Best Regards,
>> >> Chen Qi
>> >>
>> >> > Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
>> >> > ---
>> >> >   recipes-containers/cri-o/files/crio.conf | 2 +-
>> >> >   recipes-networking/cni/cni_git.bb        | 4 ++--
>> >> >   2 files changed, 3 insertions(+), 3 deletions(-)
>> >> >
>> >> > diff --git a/recipes-containers/cri-o/files/crio.conf b/recipes-containers/cri-o/files/crio.conf
>> >> > index 51d7f40..dd22465 100644
>> >> > --- a/recipes-containers/cri-o/files/crio.conf
>> >> > +++ b/recipes-containers/cri-o/files/crio.conf
>> >> > @@ -144,4 +144,4 @@ registries = [
>> >> >   network_dir = "/etc/cni/net.d/"
>> >> >
>> >> >   # plugin_dir is is where CNI plugin binaries are stored.
>> >> > -plugin_dir = "/opt/cni/bin/"
>> >> > +plugin_dir = "/usr/lib/cni/"
>> >> > diff --git a/recipes-networking/cni/cni_git.bb b/recipes-networking/cni/cni_git.bb
>> >> > index 5348b95..86e5e0f 100644
>> >> > --- a/recipes-networking/cni/cni_git.bb
>> >> > +++ b/recipes-networking/cni/cni_git.bb
>> >> > @@ -63,7 +63,7 @@ do_compile() {
>> >> >   }
>> >> >
>> >> >   do_install() {
>> >> > -    localbindir="/opt/cni/bin"
>> >> > +    localbindir="${libdir}/cni/"
>> >> >
>> >> >       install -d ${D}${localbindir}
>> >> >       install -d ${D}/${sysconfdir}/cni/net.d
>> >> > @@ -72,7 +72,7 @@ do_install() {
>> >> >       install -m 755 -D ${WORKDIR}/plugins/bin/* ${D}/${localbindir}
>> >> >   }
>> >> >
>> >> > -FILES_${PN} += "/opt/cni/bin/*"
>> >> > +FILES_${PN} += "${libdir}/cni/*"
>> >> >
>> >> >   INSANE_SKIP_${PN} += "ldflags already-stripped"
>> >> >
>> >>
>> >>
>> >> --
>> >> _______________________________________________
>> >> meta-virtualization mailing list
>> >> meta-virtualization@yoctoproject.org
>> >> https://lists.yoctoproject.org/listinfo/meta-virtualization
>> >
>> >
>> >
>> > --
>> > - Thou shalt not follow the NULL pointer, for chaos and madness await
>> > thee at its end
>> > - "Use the force Harry" - Gandalf, Star Trek II

Re: [PATCH 6/6] podmon: add the Pod Manager tool

[akuster]

On 9/9/19 2:30 PM, Stefan Agner wrote:
> On 2019-09-03 19:26, Bruce Ashfield wrote:
>> I'm assuming the subject should be "podman" and not "podmon".
Hey, Maybe he is from Jamaica mon ; )
> Whoops, thanks for pointing out.
>
>> On Sun, Sep 1, 2019 at 4:34 PM Stefan Agner <stefan@agner.ch> wrote:
>>> From: Stefan Agner <stefan.agner@toradex.com>
>>>
>>> Podman is a daemonless container engine for developing, managing, and
>>> running OCI Containers on your Linux System. Containers can either be
>>> run as root or in rootless mode.
>>>
>>> This patch adds the initial recipe for podman. Currently a minimal
>>> feature set is supported. It seems that libseccomp is mandatory, which
>>> makes meta-security a mandatory dependency for this recipe.
>>>
>>> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
>>> ---
>>>  recipes-containers/podman/podman_git.bb | 91 +++++++++++++++++++++++++
>>>  1 file changed, 91 insertions(+)
>>>  create mode 100644 recipes-containers/podman/podman_git.bb
>>>
>>> diff --git a/recipes-containers/podman/podman_git.bb b/recipes-containers/podman/podman_git.bb
>>> new file mode 100644
>>> index 0000000..6f4e7d4
>>> --- /dev/null
>>> +++ b/recipes-containers/podman/podman_git.bb
>>> @@ -0,0 +1,91 @@
>>> +HOMEPAGE = "https://podman.io/"
>>> +SUMMARY =  "A daemonless container engine"
>>> +DESCRIPTION = "Podman is a daemonless container engine for developing, \
>>> +    managing, and running OCI Containers on your Linux System. Containers can \
>>> +    either be run as root or in rootless mode. Simply put: \
>>> +    `alias docker=podman`. \
>>> +    "
>>> +
>>> +DEPENDS = " \
>>> +    go-metalinter-native \
>>> +    go-md2man-native \
>>> +    gpgme \
>>> +    libseccomp \
>>> +    ${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)} \
>>> +"
>>> +
>>> +SRCREV = "00057929f5acfd98341964d85722383363376d52"
>>> +SRC_URI = " \
>>> +    git://github.com/containers/libpod.git;branch=master \
>>> +"
>>> +
>>> +LICENSE = "Apache-2.0"
>>> +LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=e3fc50a88d0a364313df4b21ef20c29e"
>>> +
>>> +GO_IMPORT = "import"
>>> +
>>> +S = "${WORKDIR}/git"
>>> +
>>> +PV = "1.5.1+git${SRCREV}"
>>> +
>>> +PACKAGES =+ "${PN}-contrib"
>>> +
>>> +PODMAN_PKG = "github.com/containers/libpod"
>>> +BUILDTAGS = "seccomp systemd exclude_graphdriver_btrfs exclude_graphdriver_devicemapper"
>> On my other similar recipes, I've been asked to make this a ?= so it
>> can be easily overridden. Is that possible here ?
>>
> Yes, seems to work just fine.
>
>>> +
>>> +# overide LDFLAGS to allow criu to build without: "x86_64-poky-linux-ld: unrecognized option '-Wl,-O1'"
>> Is this a debug statement left in, or is it relevant to podman ?
>>
> This actually applies to podman as well, so I copied the export and the
> comment from the criu recipe.
>
> Will fix the comment though to mention podman.
>
>
>>> +export LDFLAGS=""
>>> +
>>> +inherit go goarch
>>> +inherit systemd pkgconfig
>>> +
>>> +do_configure[noexec] = "1"
>>> +
>>> +EXTRA_OEMAKE = " \
>>> +     PREFIX=${prefix} BINDIR=${bindir} LIBEXECDIR=${libexecdir} \
>>> +     ETCDIR=${sysconfdir} TMPFILESDIR=${nonarch_libdir}/tmpfiles.d \
>>> +     SYSTEMDDIR=${systemd_unitdir}/system USERSYSTEMDDIR=${systemd_unitdir}/user \
>>> +"
>>> +
>>> +do_compile() {
>>> +       # Set GOPATH. See 'PACKAGERS.md'. Don't rely on
>>> +       # docker to download its dependencies but rather
>>> +       # use dependencies packaged independently.
> This comment is actually a leftover so removed this.
>
>>> +       cd ${S}/src
>>> +       rm -rf .gopath
>>> +       mkdir -p .gopath/src/"$(dirname "${PODMAN_PKG}")"
>>> +       ln -sf ../../../../import/ .gopath/src/"${PODMAN_PKG}"
>>> +
>>> +       ln -sf "../../../import/vendor/github.com/varlink/" ".gopath/src/github.com/varlink"
>>> +
>>> +       export GOPATH="${S}/src/.gopath"
>>> +       export GOROOT="${STAGING_DIR_NATIVE}/${nonarch_libdir}/${HOST_SYS}/go"
>>> +
>>> +       cd ${S}/src/.gopath/src/"${PODMAN_PKG}"
>>> +
>>> +       make cmd/podman/varlink/iopodman.go GO=go
> After cleaning and rebuilding I actually noticed that the current state
> does not build. I must have interfered manually to make it build and
> forgot to fix-up.
>
> This make call needs this before executing:
> export GOARCH="${BUILD_GOARCH}"
>
>> I've been trying to squash out all the raw calls to make. Does this
>> work if oe_runmake is used ?
> With the above, oe_runmake seems to work just fine.
>
>> Also, out of curiosity, if GO=go isn't set .. what executable does it
>> try to run ?
> Without GO=go it seems to use "arm-...-linux-gnueabi-go", and fails with
> a exec format error:
>
> NOTE: make -j 40 PREFIX=/usr BINDIR=/usr/bin LIBEXECDIR=/usr/libexec
> ETCDIR=/etc TMPFILESDIR=/usr/lib/tmpfiles.d
> SYSTEMDDIR=/usr/lib/systemd/system USERSYSTEMDDIR=/usr/lib/systemd/user
> cmd/podman/varlink/iopodman.go
> GO111MODULE=off arm-tdx-linux-gnueabi-go generate
> ./cmd/podman/varlink/...
> fork/exec
> /home/ags/torizoncore/build-colibri-imx7/tmp-torizon/work/cortexa7t2hf-neon-tdx-linux-gnueabi/podman/1.5.1+git00057929f5acfd98341964d85722383363376d52-r0/go-tmp/go-build868339522/b001/exe/main:
> exec format error
> cmd/podman/varlink/generate.go:3: running "go": exit status 1
> make: *** [Makefile:475: cmd/podman/varlink/iopodman.go] Error 1
> ERROR: oe_runmake failed
>
>
>
>>> +
>>> +       # Pass the needed cflags/ldflags so that cgo
>>> +       # can find the needed headers files and libraries
>>> +       export GOARCH=${TARGET_GOARCH}
>>> +       export CGO_ENABLED="1"
>>> +       export CGO_CFLAGS="${CFLAGS} --sysroot=${STAGING_DIR_TARGET}"
>>> +       export CGO_LDFLAGS="${LDFLAGS} --sysroot=${STAGING_DIR_TARGET}"
>>> +
>>> +       make BUILDTAGS="${BUILDTAGS}"
>> Same here. Does oe_runmake work ?
> Yes, also here oe_runmake seems to do no harm.
>
> Thanks for reviewing!
>
> --
> Stefan
>
>> Bruce
>>
>>> +}
>>> +
>>> +do_install() {
>>> +       cd ${S}/src/.gopath/src/"${PODMAN_PKG}"
>>> +
>>> +       oe_runmake install install.docker DESTDIR="${D}"
>>> +}
>>> +
>>> +FILES_${PN} += " \
>>> +    ${systemd_unitdir}/system/* \
>>> +    ${systemd_unitdir}/user/* \
>>> +    ${nonarch_libdir}/tmpfiles.d/* \
>>> +    ${sysconfdir}/docker \
>>> +"
>>> +
>>> +RDEPENDS_${PN} += "conmon runc-opencontainers iptables cni skopeo"
>>> --
>>> 2.20.1
>>>
>>> --
>>> _______________________________________________
>>> meta-virtualization mailing list
>>> meta-virtualization@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/meta-virtualization