On Tue, Apr 2, 2019 at 9:36 PM Mark Asselstine
<mark.asselstine@...> wrote:

We are currently seeing the following error:
type..eUfRrckI: missing section for relocation target type..FEeY9FdU
...

This is similar to the reported issues
http://www.lyddzz.com/github_/golang/go/issues/30768
and
https://github.com/hashicorp/consul/issues/5486 (but this one appears
to be a report of 'our' issue so isn't really valid)

The go.bbclass currently completes 2 builds (if GO_DYNLINK is set),
one without '-linkshared' and one with. The '--linkshared' option is
marked as experimental (https://golang.org/cmd/link/ -- "-linkshared
Link against installed Go shared libraries (experimental)").

By setting GO_LINKSHARED prior to inheriting go.bbclass we can
overwrite the default compile behavior and only perform the build
without the '-linkshared' option. This shouldn't change the
functionality of consul and we can revert to the default behavior when
the issues have been addressed.

Agreed, and this works for me as well.

Merged.

Bruce

Signed-off-by: Mark Asselstine <mark.asselstine@...>
---
recipes-connectivity/consul/consul_git.bb | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/recipes-connectivity/consul/consul_git.bb b/recipes-connectivity/consul/consul_git.bb
index f9fb236..ab78cbd 100644
--- a/recipes-connectivity/consul/consul_git.bb
+++ b/recipes-connectivity/consul/consul_git.bb
@@ -13,6 +13,11 @@ S = "${WORKDIR}/git"

RDEPENDS_${PN}-dev_append = " bash"

+# Temporarily workaround an issue with GO 1.12.1
+# http://www.lyddzz.com/github_/golang/go/issues/30768
+# Disable experimental use of '-linkshared'.
+GO_LINKSHARED = ""
+
inherit systemd go

# Besides the hosts specified in goarch, we do not build for mips.
--
2.7.4

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

arch.h does not contain macros for 32 bit arm or any mips arch.

Signed-off-by: Joe Slater <joe.slater@...>
---
recipes-extended/libibverbs/libibverbs_1.2.1.bb | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/recipes-extended/libibverbs/libibverbs_1.2.1.bb b/recipes-extended/libibverbs/libibverbs_1.2.1.bb
index dd74522..2becf35 100644
--- a/recipes-extended/libibverbs/libibverbs_1.2.1.bb
+++ b/recipes-extended/libibverbs/libibverbs_1.2.1.bb
@@ -29,3 +29,7 @@ do_install_append() {

PROVIDES = "virtual/libibverbs"
RPROVIDES_${PN} = "virtual/libibverbs"
+
+# We can build for arm64
+COMPATIBLE_HOST_mipsarch = "none"
+COMPATIBLE_HOST_arm = "none"
--
2.7.4

The oe-core layer sets a variable which intends that linux-dummy is
set for container building. This commit would allow you to have a
specific kernel and board setup as well as generate multiple
containers by turrning off the linux-dummy check found in:

oe-core/meta/classes/image-container.bbclass

Signed-off-by: Jason Wessel <jason.wessel@...>
---
recipes-extended/images/container-base.bb | 3 +++
1 file changed, 3 insertions(+)

diff --git a/recipes-extended/images/container-base.bb b/recipes-extended/images/container-base.bb
index 3e636ca..434239a 100644
--- a/recipes-extended/images/container-base.bb
+++ b/recipes-extended/images/container-base.bb
@@ -20,6 +20,9 @@ IMAGE_INSTALL = " \
netbase \
"

+# Allow build with or without a specific kernel
+IMAGE_CONTAINER_NO_DUMMY = "1"
+
# Workaround /var/volatile for now
ROOTFS_POSTPROCESS_COMMAND += "rootfs_fixup_var_volatile ; "
rootfs_fixup_var_volatile () {
--
2.18.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

We are currently seeing the following error:
type..eUfRrckI: missing section for relocation target type..FEeY9FdU
...

This is similar to the reported issues
http://www.lyddzz.com/github_/golang/go/issues/30768
and
https://github.com/hashicorp/consul/issues/5486 (but this one appears
to be a report of 'our' issue so isn't really valid)

The go.bbclass currently completes 2 builds (if GO_DYNLINK is set),
one without '-linkshared' and one with. The '--linkshared' option is
marked as experimental (https://golang.org/cmd/link/ -- "-linkshared
Link against installed Go shared libraries (experimental)").

By setting GO_LINKSHARED prior to inheriting go.bbclass we can
overwrite the default compile behavior and only perform the build
without the '-linkshared' option. This shouldn't change the
functionality of consul and we can revert to the default behavior when
the issues have been addressed.

Signed-off-by: Mark Asselstine <mark.asselstine@...>
---
recipes-connectivity/consul/consul_git.bb | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/recipes-connectivity/consul/consul_git.bb b/recipes-connectivity/consul/consul_git.bb
index f9fb236..ab78cbd 100644
--- a/recipes-connectivity/consul/consul_git.bb
+++ b/recipes-connectivity/consul/consul_git.bb
@@ -13,6 +13,11 @@ S = "${WORKDIR}/git"

RDEPENDS_${PN}-dev_append = " bash"

+# Temporarily workaround an issue with GO 1.12.1
+# http://www.lyddzz.com/github_/golang/go/issues/30768
+# Disable experimental use of '-linkshared'.
+GO_LINKSHARED = ""
+
inherit systemd go

# Besides the hosts specified in goarch, we do not build for mips.
--
2.7.4

On Mon, Mar 18, 2019 at 11:38 PM Bruce Ashfield
<bruce.ashfield@...> wrote:

On Mon, Mar 18, 2019 at 11:16 PM Hongzhi, Song
<hongzhi.song@...> wrote:

Hi Bruce,

There is a failure on do_compile of consul under meta-cloud-services.

This is introduced by go-1.12 which was upgraded several days ago.

Yep. I had also noticed this and reported it on the #overc freenode channel.
My hands are full with a few other issues, but I'm hoping to have a closer
look at it by the end of the week.

But if anyone else has a patch, I wouldn't object to it :D

The issue is we are often overwriting GOROOT when we should not be.
Actually the go.bbclass is doing this when it should not be. This is
covered in detail here:
https://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroot-really

As describe GOROOT is already properly set in our cross compiled go
tool and should not be overwritten. We can see this patch by doing the
equivalent of 'go env GOROOT' in a devshell (replacing go with the
full cross go toolname).

By overwriting GOROOT we are getting a mixmatch of std pkgs as well I
am not quite sure what tools are used as the GOROOT is used to define
two other paths:
$GOROOT/pkg/tool/$GOOS_$GOARCH and $GOROOT/pkg/$GOOS_$GOARCH
and $GOROOT/pkg/tool/$GOOS_$GOARCH simply doesn't exist.

I still need to do some investigation around this but I am able to
reproduce the issue and I am able to resolve the issue by not setting
GOROOT. Once I am satisfied with my findings I will send something
out, at this point it looks like a patch to oe-core's go.bbclass.

MarkA

Bruce

But it can't be reproduced on my ubuntu-host, while only be reproduced on Yocto.

I try my best to fix it but has no result.

So, I will be great appreciate for anyone's help.


Thanks,

Hongzhi


There are some info about the failure:


Error info:

[

# github.com/hashicorp/consul/connect/certgen
type..eUfRrckI: missing section for relocation target type..FEeY9FdU
type..eUfRrckI: reloc 8 (R_CALL) to non-elf symbol type..FEeY9FdU (outer=type..FEeY9FdU) 49 (SABIALIAS)
# github.com/hashicorp/consul
type..eUfRrckI: missing section for relocation target type..FEeY9FdU
type..K6Uq9NPs: missing section for relocation target type..tBBUxeDj

]

The above info come from go/src/cmd/link/internal/ld/data.go


Commit ID from go upstream:

685aca45dc8435df7b7e8059a42a8a98efdaf22c

cmd/compile, cmd/link: separate stable and internal ABIs


Script: consul: run.do_compile

The following command failed with -linkshared. It will pass if remove -linkshared.

x86_64-poky-linux-go install -linkshared -p 128 -v -ldflags="-r /usr/lib/go/pkg/linux_amd64_dynlink -extldflags ' -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/ala-lpggp22/hsong/poky/build/tmp/work/core2-64-poky-linux/consul/git-r0/recipe-sysroot -Wl,-rpath-link=/ala-lpggp22/hsong/poky/build/tmp/work/core2-64-poky-linux/consul/git-r0/recipe-sysroot/usr/lib/go/pkg/linux_amd64_dynlink -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong -Wl,-z,relro,-z,now'" -buildmode=pie `go_list_packages`


[EOF]

--
- 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@...
https://lists.yoctoproject.org/listinfo/meta-virtualization

On Sat, Mar 23, 2019 at 12:12 PM Manjukumar Matha
<manjukumar.harthikote-matha@...> wrote:

This commit switches over to using existing SERIAL_CONSOLES mechanism
for hvc0 inittab entry generation. This then results in
/bin/start_getty wrapper being used, which avoids the getty failure seen
when running a xen capable rootfs natively on linux.

merged.

Bruce

Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@...>
---
recipes-core/sysvinit/sysvinit-inittab_xen.inc | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/recipes-core/sysvinit/sysvinit-inittab_xen.inc b/recipes-core/sysvinit/sysvinit-inittab_xen.inc
index 9d0589c..4d56806 100644
--- a/recipes-core/sysvinit/sysvinit-inittab_xen.inc
+++ b/recipes-core/sysvinit/sysvinit-inittab_xen.inc
@@ -1,4 +1 @@
-do_install_append() {
- echo "" >> ${D}${sysconfdir}/inittab
- echo "X0:12345:respawn:/sbin/getty 115200 hvc0" >> ${D}${sysconfdir}/inittab
-}
+SERIAL_CONSOLES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ' 115200;hvc0', '', d)}"
--
2.7.4

--
_______________________________________________
meta-virtualization mailing list
meta-virtualization@...
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

merged

Bruce

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

merged (both 1 and 2 in the series).

Bruce

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

This commit switches over to using existing SERIAL_CONSOLES mechanism
for hvc0 inittab entry generation. This then results in
/bin/start_getty wrapper being used, which avoids the getty failure seen
when running a xen capable rootfs natively on linux.

Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@...>
---
recipes-core/sysvinit/sysvinit-inittab_xen.inc | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/recipes-core/sysvinit/sysvinit-inittab_xen.inc b/recipes-core/sysvinit/sysvinit-inittab_xen.inc
index 9d0589c..4d56806 100644
--- a/recipes-core/sysvinit/sysvinit-inittab_xen.inc
+++ b/recipes-core/sysvinit/sysvinit-inittab_xen.inc
@@ -1,4 +1 @@
-do_install_append() {
- echo "" >> ${D}${sysconfdir}/inittab
- echo "X0:12345:respawn:/sbin/getty 115200 hvc0" >> ${D}${sysconfdir}/inittab
-}
+SERIAL_CONSOLES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ' 115200;hvc0', '', d)}"
--
2.7.4

Remove the following patch, because the 3.11 version already contain it.
0001-kdat-Don-t-open-run-criu.kdat-if-doesn-t-exists.patch

Signed-off-by: Dengke Du <dengke.du@...>
---
recipes-containers/criu/criu_git.bb | 5 ++-
...on-t-open-run-criu.kdat-if-doesn-t-exists.patch | 42 ----------------------
2 files changed, 2 insertions(+), 45 deletions(-)
delete mode 100644 recipes-containers/criu/files/0001-kdat-Don-t-open-run-criu.kdat-if-doesn-t-exists.patch

diff --git a/recipes-containers/criu/criu_git.bb b/recipes-containers/criu/criu_git.bb
index 123f6a3..c6981c9 100644
--- a/recipes-containers/criu/criu_git.bb
+++ b/recipes-containers/criu/criu_git.bb
@@ -13,15 +13,14 @@ EXCLUDE_FROM_WORLD = "1"

LIC_FILES_CHKSUM = "file://COPYING;md5=412de458544c1cb6a2b512cd399286e2"

-SRCREV = "c49eab368a68682475c4e693258246e04232e6d2"
-PV = "3.10+git${SRCPV}"
+SRCREV = "c74b83cd49c00589c0c0468ba5fe685b67fdbd0a"
+PV = "3.11+git${SRCPV}"

SRC_URI = "git://github.com/xemul/criu.git;protocol=git \
file://0001-criu-Fix-toolchain-hardcode.patch \
file://0002-criu-Skip-documentation-install.patch \
file://0001-criu-Change-libraries-install-directory.patch \
file://lib-Makefile-overwrite-install-lib-to-allow-multiarc.patch \
- file://0001-kdat-Don-t-open-run-criu.kdat-if-doesn-t-exists.patch \
"

COMPATIBLE_HOST = "(x86_64|arm|aarch64).*-linux"
diff --git a/recipes-containers/criu/files/0001-kdat-Don-t-open-run-criu.kdat-if-doesn-t-exists.patch b/recipes-containers/criu/files/0001-kdat-Don-t-open-run-criu.kdat-if-doesn-t-exists.patch
deleted file mode 100644
index 805f799..0000000
--- a/recipes-containers/criu/files/0001-kdat-Don-t-open-run-criu.kdat-if-doesn-t-exists.patch
+++ /dev/null
@@ -1,42 +0,0 @@
-From b9760919eb3f805dd3d2af5692b49cba9c468595 Mon Sep 17 00:00:00 2001
-From: "Hongzhi.Song" <hongzhi.song@...>
-Date: Mon, 26 Nov 2018 02:39:59 -0500
-Subject: [PATCH] kdat: Don't open /run/criu.kdat if doesn't exists
-
-When CRIU is called for a first time and the /run/criu.kdat file does
-not exists, the following warning is shown:
- Warn (criu/kerndat.c:847): Can't load /run/criu.kdat
-
-This patch is replacing this warning with a more appropriate debug
-message.
- File /run/criu.kdat does not exist
-
-Signed-off-by: Radostin Stoyanov <rstoyanov1@...>
-Signed-off-by: Andrei Vagin <avagin@...>
-
-Upstream-Status: Backport [https://github.com/checkpoint-restore/criu/commit/868de91a099c00f099d8a41557d660d173f72521]
-
-Signed-off-by: Hongzhi.Song <hongzhi.song@...>
----
- criu/kerndat.c | 5 ++++-
- 1 file changed, 4 insertions(+), 1 deletion(-)
-
-diff --git a/criu/kerndat.c b/criu/kerndat.c
-index 8cb5690..9fb475c 100644
---- a/criu/kerndat.c
-+++ b/criu/kerndat.c
-@@ -789,7 +789,10 @@ static int kerndat_try_load_cache(void)
-
- fd = open(KERNDAT_CACHE_FILE, O_RDONLY);
- if (fd < 0) {
-- pr_warn("Can't load %s\n", KERNDAT_CACHE_FILE);
-+ if(ENOENT == errno)
-+ pr_debug("File %s does not exist\n", KERNDAT_CACHE_FILE);
-+ else
-+ pr_warn("Can't load %s\n", KERNDAT_CACHE_FILE);
- return 1;
- }
-
---
-2.8.1
-
--
2.7.4

Signed-off-by: Dengke Du <dengke.du@...>
---
...libdl.patch => 0001-librdmacm-needs-libdl.patch} | 21 ++++++++++++++++-----
.../{librdmacm_1.0.17.bb => librdmacm_1.1.0.bb} | 6 +++---
2 files changed, 19 insertions(+), 8 deletions(-)
rename recipes-extended/librdmacm/files/{librdmacm-needs-libdl.patch => 0001-librdmacm-needs-libdl.patch} (52%)
rename recipes-extended/librdmacm/{librdmacm_1.0.17.bb => librdmacm_1.1.0.bb} (86%)

diff --git a/recipes-extended/librdmacm/files/librdmacm-needs-libdl.patch b/recipes-extended/librdmacm/files/0001-librdmacm-needs-libdl.patch
similarity index 52%
rename from recipes-extended/librdmacm/files/librdmacm-needs-libdl.patch
rename to recipes-extended/librdmacm/files/0001-librdmacm-needs-libdl.patch
index bf15bea..8e62f4b 100644
--- a/recipes-extended/librdmacm/files/librdmacm-needs-libdl.patch
+++ b/recipes-extended/librdmacm/files/0001-librdmacm-needs-libdl.patch
@@ -1,15 +1,23 @@
+From d2c39b265f397256482154ad7807260b347176fb Mon Sep 17 00:00:00 2001
+From: Dengke Du <dengke.du@...>
+Date: Thu, 21 Mar 2019 15:58:32 +0800
+Subject: [PATCH] librdmacm needs libdl
+
Librdmacm links against libibverbs, and the current version of libibverbs
uses dlopen(), so librdmacm must also link against libdl.

Upstream-Status: Pending

Signed-off-by: Donn Seeley <donn.seeley@...>
+Signed-off-by: Dengke Du <dengke.du@...>
---
- configure.in | 2 ++
+ configure.ac | 2 ++
1 file changed, 2 insertions(+)

---- a/configure.in
-+++ b/configure.in
+diff --git a/configure.ac b/configure.ac
+index 4a43995..2a7f4b9 100644
+--- a/configure.ac
++++ b/configure.ac
@@ -39,6 +39,8 @@ AC_CHECK_SIZEOF(long)
dnl Checks for libraries
AC_CHECK_LIB(pthread, pthread_mutex_init, [],
@@ -17,5 +25,8 @@ Signed-off-by: Donn Seeley <donn.seeley@...>
+AC_CHECK_LIB(dl, dlsym, [],
+ AC_MSG_ERROR([dlsym() not found. librdmacm requires libdl.]))
if test "$disable_libcheck" != "yes"; then
- AC_CHECK_LIB(ibverbs, ibv_get_device_list, [],
- AC_MSG_ERROR([ibv_get_device_list() not found. librdmacm requires libibverbs.]))
+ AC_CHECK_LIB(ibverbs, ibv_cmd_open_xrcd, [],
+ AC_MSG_ERROR([ibv_cmd_open_xrcd() not found. librdmacm requires libibverbs 1.1.8 or later.]))
+--
+2.7.4
+
diff --git a/recipes-extended/librdmacm/librdmacm_1.0.17.bb b/recipes-extended/librdmacm/librdmacm_1.1.0.bb
similarity index 86%
rename from recipes-extended/librdmacm/librdmacm_1.0.17.bb
rename to recipes-extended/librdmacm/librdmacm_1.1.0.bb
index 0ece665..30a0c94 100644
--- a/recipes-extended/librdmacm/librdmacm_1.0.17.bb
+++ b/recipes-extended/librdmacm/librdmacm_1.1.0.bb
@@ -16,10 +16,10 @@ DEPENDS = "virtual/libibverbs"

# Repo is at http://git.openfabrics.org/git?p=~shefty/librdmacm.git
SRC_URI = "https://www.openfabrics.org/downloads/rdmacm/${BPN}-${PV}.tar.gz \
- file://librdmacm-needs-libdl.patch"
+ file://0001-librdmacm-needs-libdl.patch"

-SRC_URI[md5sum] = "da6fad887e9c24cb01b74b75f8449cb1"
-SRC_URI[sha256sum] = "9381e1bf2c7079fc257b8eee74e731d3e7eec70e539bb4245084a7b05aeecb2a"
+SRC_URI[md5sum] = "9459e523002978ef6e7b852e01d8b29e"
+SRC_URI[sha256sum] = "8f10848d4810585d6d70b443abc876c1db8df5e9b8b07e095c7e6eaf4ac380c5"

inherit autotools

--
2.7.4

Signed-off-by: Dengke Du <dengke.du@...>
---
.../libibverbs/{libibverbs_1.1.7.bb => libibverbs_1.2.1.bb} | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
rename recipes-extended/libibverbs/{libibverbs_1.1.7.bb => libibverbs_1.2.1.bb} (83%)

diff --git a/recipes-extended/libibverbs/libibverbs_1.1.7.bb b/recipes-extended/libibverbs/libibverbs_1.2.1.bb
similarity index 83%
rename from recipes-extended/libibverbs/libibverbs_1.1.7.bb
rename to recipes-extended/libibverbs/libibverbs_1.2.1.bb
index e7e8d65..dd74522 100644
--- a/recipes-extended/libibverbs/libibverbs_1.1.7.bb
+++ b/recipes-extended/libibverbs/libibverbs_1.2.1.bb
@@ -9,11 +9,12 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=7c557f27dd795ba77cc419dddc656b51"
# Official repo is at git://git.kernel.org/pub/scm/libs/infiniband/libibverbs.git
SRC_URI = "https://www.openfabrics.org/downloads/verbs/${BPN}-${PV}.tar.gz"

-SRC_URI[md5sum] = "5aea59e4766ae4548419010ac84032ff"
-SRC_URI[sha256sum] = "31b4114bf32d41c9fc81a862ec5febed1e982975f21fa177ea9c7516c9064690"
+SRC_URI[md5sum] = "1544ebb89d861ce84057ab43dfcd22a0"
+SRC_URI[sha256sum] = "c352a7f24e9a9d30ea74faa35d1b721d78d770506a0c03732e3132b7c85ac330"

inherit autotools

+DEPENDS = "libnl pkgconfig-native"
PACKAGES += "${PN}-utils"
FILES_${PN} = "${sysconfdir} ${libdir}/*.so.*"
FILES_${PN}-utils = "${bindir}"
--
2.7.4

merged.

Bruce

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

On Mon, Mar 18, 2019 at 9:13 PM Hongzhi, Song
<hongzhi.song@...> wrote:

On 3/18/19 8:41 PM, Bruce Ashfield wrote:

On Mon, Mar 18, 2019 at 2:28 AM Hongzhi, Song
<hongzhi.song@...> wrote:

On 2/20/19 9:47 PM, Bruce Ashfield wrote:

On Wed, Feb 20, 2019 at 8:42 AM Bruce Ashfield <bruce.ashfield@...> wrote:

On Wed, Feb 20, 2019 at 8:06 AM Pascal Bach <pascal.bach@...> wrote:

Docker revision is taken from https://github.com/docker/engine/releases/tag/v18.09.2
and libnetwork is extracted from there.
I also switched the repo from moby/moby to docker/engine as it makes it easier to find the tags.

In this case, I'm going to stick with moby. The reason that it was
being used was
to keep the linkage between moby and the -ce builds. Since we have various other
components that are sometimes in sync, sometimes out of sync, having that common
repository was important. The point of having the docker-ce and
'docker' split was
that one tracked community, and one only tracks what docker "the
company" was doing.

The formatting of that email came out horribly. Sorry about that.
(let's see if this one comes out more readable)

I thought I should add that I'm working on a refresh of the docker
components as well, and was considering using some naming to make the
community/docker-ce split a bit more clear.

Hi Bruce,

Could I uprev docker to v18.09.3 compliant with moby?

I have patches ready for this already, I was traveling last week and
couldn't complete
them. I expect to have them done and tested by end of week.

Bruce

Ok, thanks

FYI: I just pushed the following commits to master-next of meta-virt:

d19fda3 docker: consolidate common depends/options
9e4957d docker: fixup redepends and clean rsuggests
1c424ca docker-ce: fixup redepends and clean rsuggests
9ce802c containerd: remove docker/lxc RRECOMMENDS
ceae7b6 docker-runc: drop docker RRECOMMENDS
2890f19 docker: uprev docker/moby to 18.09.3
7bddcb3 docker-ce: update to 18.09.3

I'm letting them soak overnight, and will push them on Friday.

Bruce

Hongzhi

Hongzhi

So perhaps that would help
make hunting for the right SRCREV in moby make a bit more sense.

Bruce

Bruce

What is odd is that the Copyright year in LICENSE went backwards in this release.

I didn't touch runc and containerd as they are already updated.

Cc: Bruce Ashfield <bruce.ashfield@...>
Signed-off-by: Pascal Bach <pascal.bach@...>
---
recipes-containers/docker/docker-ce_git.bb | 6 +++---
recipes-containers/docker/docker_git.bb | 12 ++++++------
2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/recipes-containers/docker/docker-ce_git.bb b/recipes-containers/docker/docker-ce_git.bb
index 05eac21..5e9f060 100644
--- a/recipes-containers/docker/docker-ce_git.bb
+++ b/recipes-containers/docker/docker-ce_git.bb
@@ -18,8 +18,8 @@ DESCRIPTION = "Linux container runtime \
subtle and/or glaring issues. \
"

-SRCREV_docker = "6e632f7fc395d15bce46f426086e91c01598cf59"
-SRCREV_libnetwork = "6da50d1978302f04c3e2089e29112ea24812f05b"
+SRCREV_docker = "62479626f213818ba5b4565105a05277308587d5"
+SRCREV_libnetwork = "2cfbf9b1f98162a55829a21cc603c76072a75382"
SRC_URI = "\
git://github.com/docker/docker-ce.git;branch=18.09;name=docker \
git://github.com/docker/libnetwork.git;branch=bump_18.09;name=libnetwork;destsuffix=git/libnetwork \
@@ -34,7 +34,7 @@ GO_IMPORT = "import"

S = "${WORKDIR}/git"

-DOCKER_VERSION = "18.09.0-ce"
+DOCKER_VERSION = "18.09.2-ce"
PV = "${DOCKER_VERSION}+git${SRCREV_docker}"

DEPENDS = " \
diff --git a/recipes-containers/docker/docker_git.bb b/recipes-containers/docker/docker_git.bb
index 19e773b..5a0e483 100644
--- a/recipes-containers/docker/docker_git.bb
+++ b/recipes-containers/docker/docker_git.bb
@@ -18,11 +18,11 @@ DESCRIPTION = "Linux container runtime \
subtle and/or glaring issues. \
"

-SRCREV_docker = "489b8eda6674523df8b82a210399b7d2954427d0"
-SRCREV_libnetwork = "6da50d1978302f04c3e2089e29112ea24812f05b"
-SRCREV_cli = "51668a30f26250ccfce31bcc13d9334eaafabe36"
+SRCREV_docker = "eb137ff1765faeb29c2d99025bfd8ed41836dd06"
+SRCREV_libnetwork = "2cfbf9b1f98162a55829a21cc603c76072a75382"
+SRCREV_cli = "af2647d55b1dff69f5684f5991b9690fddd75c69"
SRC_URI = "\
- git://github.com/moby/moby.git;nobranch=1;name=docker \
+ git://github.com/docker/engine.git;nobranch=1;name=docker \
git://github.com/docker/libnetwork.git;branch=bump_18.09;name=libnetwork;destsuffix=git/libnetwork \
git://github.com/docker/cli;branch=18.09;name=cli;destsuffix=git/cli \
file://docker.init \
@@ -31,13 +31,13 @@ SRC_URI = "\

# Apache-2.0 for docker
LICENSE = "Apache-2.0"
-LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=4859e97a9c7780e77972d989f0823f28"
+LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=9740d093a080530b5c5c6573df9af45a"

GO_IMPORT = "import"

S = "${WORKDIR}/git"

-DOCKER_VERSION = "18.09.0"
+DOCKER_VERSION = "18.09.2"
PV = "${DOCKER_VERSION}+git${SRCREV_docker}"

DEPENDS = " \
--
2.11.0

--
- 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

From: Kai Kang <kai.kang@...>

Fix installed-vs-shipped qa issue of glusterfs:

| ERROR: glusterfs-5.4-r0 do_package: QA Issue: glusterfs:
Files/directories were installed but not shipped in any package:
| /usr/libexec/glusterfs/mount-shared-storage.sh

Signed-off-by: Kai Kang <kai.kang@...>
---
recipes-extended/glusterfs/glusterfs.inc | 1 +
1 file changed, 1 insertion(+)

diff --git a/recipes-extended/glusterfs/glusterfs.inc b/recipes-extended/glusterfs/glusterfs.inc
index 17aaf75..5843d7c 100644
--- a/recipes-extended/glusterfs/glusterfs.inc
+++ b/recipes-extended/glusterfs/glusterfs.inc
@@ -152,6 +152,7 @@ FILES_${PN} = "${libdir}/glusterfs/${PV}/auth \
${libexecdir}/glusterfs/events \
${libexecdir}/glusterfs/glusterfind \
${libexecdir}/glusterfs/gfind_missing_files \
+ ${libexecdir}/glusterfs/mount-shared-storage.sh \
${libexecdir}/glusterfs/peer_mountbroker.py \
${libexecdir}/glusterfs/peer_eventsapi.py \
${libexecdir}/glusterfs/peer_mountbroker \
--
2.20.0

On Wed, Mar 20, 2019 at 2:41 PM Bruce Ashfield <bruce.ashfield@...> wrote:

On Mon, Mar 18, 2019 at 2:48 PM Mark Asselstine
<mark.asselstine@...> wrote:

Attempting to build for x86-64 will result in an error:
cannot find package runtime/cgo (using -importcfg)
...go/pkg/tool/linux_amd64/link: cannot open file : open : no such file or directory

As a workaround we switch the build target to 'build' which results in
a slightly smaller executable but does mean that several dynamic
libraries are required to run the generated executable. This shouldn't
be a problem as the build system will ensure the libraries are present
on images where the executable will be included. This change only
means the executable can't be copied as a single entity to a different
machine and run.

We do also patch the Makefile to allow the 'static' target to build
successfully and in the patch commit log we describe the issue in full
(at least in as much detail as we currently have on the issue). But
since the issue isn't fully understood we don't recommend the 'static'
build to be used at this time, thus default to the 'build' target.

Signed-off-by: Mark Asselstine <mark.asselstine@...>
---

Bruce, Paul,

Just a few notes on this.
* Do I understand what is going on in full, no. The behavior is
matching what was described in earlier version of GO but I don't
know why we are being affected when we should not be.
* This brings up a question around GO recipes, we should most likely
be consistent in building fully static vs not. This should most
likely be addressed in the go.bbclass. A topic for further discussion.
* Do I want to get to 100% understanding yes. But as you two have seen
there are other GO related changes/work that I have underway that
I want to get done to make building GO packages consistent. I have
a gut feeling that part of the issue here is related to a build
inconsistency so I want to rule that out before I dig in any further.
* Related to the previous point, the reason I found this and the reason
I want a fix merged is to get me to a point where all GO packages in
meta-virtualization build correctly, so I can affect other changes and
cleanup accross all GO recipes knowing they are kept in a working
state.

I do want to have this merged as we are going from a not working to a
working state, freeing me up to tackle some needed GO cleanup, to
address the consistency issues I mention above. That being said, I
will definitely understand if you or others object to this change
being merged.

I don't see any objections, so I've gone ahead and merged this. If it
causes us problems in the future, we can revisit it.

Bruce

Thanks Bruce. I will be sure to follow up with the list when I circle
around and get any more findings. I do believe there is value in fully
static images so we haven't heard the last word on this yet.

MarkA

...orce-rebuilding-all-packages-to-avoid-cgo.patch | 54 ++++++++++++++++++++++
recipes-networking/netns/netns_git.bb | 5 +-
2 files changed, 58 insertions(+), 1 deletion(-)
create mode 100644 recipes-networking/netns/files/Makefile-force-rebuilding-all-packages-to-avoid-cgo.patch

diff --git a/recipes-networking/netns/files/Makefile-force-rebuilding-all-packages-to-avoid-cgo.patch b/recipes-networking/netns/files/Makefile-force-rebuilding-all-packages-to-avoid-cgo.patch
new file mode 100644
index 0000000..3b0c0a4
--- /dev/null
+++ b/recipes-networking/netns/files/Makefile-force-rebuilding-all-packages-to-avoid-cgo.patch
@@ -0,0 +1,54 @@
+From 09524d187ef108784c854a0c247ac6476a10bb67 Mon Sep 17 00:00:00 2001
+From: Mark Asselstine <mark.asselstine@...>
+Date: Mon, 18 Mar 2019 14:04:16 -0400
+Subject: [PATCH] Makefile: force rebuilding all packages to avoid cgo
+
+We are running into an issue when attempting to build 'static',
+similar to what is described by
+
+https://plus.google.com/117192131596509381660/posts/eNnNePihYnK
+and
+https://github.com/golang/go/issues/9369
+
+In our case we can see that it manifests as a build error
+
+ cannot find package runtime/cgo (using -importcfg)
+ ...go/pkg/tool/linux_amd64/link: cannot open file : open : no such file or directory
+
+Although the descriptions of issue indicate that newer versions of GO,
+such as the version we are using, should not have this issue it is
+clear from the error that cgo is being referenced when it should be
+out of the picture.
+
+Interesting enough this issue only manifests when we are building on
+x86-64 and building for x86-64 which might indicate that GO might be
+finding -native packages and not -cross packages.
+
+This change works around the issue and will allow for the building of
+the 'static' make target, but at this time and until the issue is
+completely understood, it is recommended that the 'build' target is
+used.
+
+Upstream-Status: Inappropriate [only an issue with our builds]
+
+Signed-off-by: Mark Asselstine <mark.asselstine@...>
+---
+ Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile b/Makefile
+index 476cb9b..ecd0df4 100644
+--- a/src/import/Makefile
++++ b/src/import/Makefile
+@@ -41,7 +41,7 @@ $(NAME): *.go VERSION.txt
+ .PHONY: static
+ static: ## Builds a static executable
+ @echo "+ $@"
+- CGO_ENABLED=0 $(GO) build \
++ CGO_ENABLED=0 $(GO) build -a -pkgdir dontusecurrentpkgs \
+ -tags "$(BUILDTAGS) static_build" \
+ ${GO_LDFLAGS_STATIC} -o $(NAME) .
+
+--
+2.7.4
+
diff --git a/recipes-networking/netns/netns_git.bb b/recipes-networking/netns/netns_git.bb
index b6d3594..f5cdace 100644
--- a/recipes-networking/netns/netns_git.bb
+++ b/recipes-networking/netns/netns_git.bb
@@ -5,6 +5,7 @@ LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=48ef0979a2bcc3fae14ff30b8a7f5d

SRC_URI = "git://github.com/genuinetools/netns;branch=master \
file://0001-Allow-selection-of-go-compiler.patch \
+ file://Makefile-force-rebuilding-all-packages-to-avoid-cgo.patch \
"
SRCREV = "0da6ab0997707024debe68c91e940c9168041bf8"
PV = "0.4.0"
@@ -42,7 +43,9 @@ do_compile() {
export CGO_LDFLAGS="${BUILDSDK_LDFLAGS} --sysroot=${STAGING_DIR_TARGET}"

cd ${S}/src/import
- oe_runmake static
+ # Static builds work but are not recommended. See Makefile*cgo patch.
+ #oe_runmake static
+ oe_runmake build
}

do_install() {
--
2.7.4

--
- 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@...
https://lists.yoctoproject.org/listinfo/meta-virtualization

merged.

Bruce

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

merged

Bruce

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

merged

Bruce

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