linux/meta-cloud-services.git/recipes-connectivity/consul, branch hardknott

consul: export GO111MODULE=off

2021-03-16T12:58:39+00:00

With the latest go version bump in oe-core export GO111MODULE is on by default. Our build is not setup to use go modules, so we disable it and avoid configuration errors. Signed-off-by: Chen Qi Signed-off-by: Bruce Ashfield

consul: fix compile failure while go upgraded to 1.13

2019-12-02T04:08:28+00:00

While go was upgraded to 1.13, there is a do_compile failure, Refer upstream envoyproxy to rename imports throughout https://github.com/envoyproxy/protoc-gen-validate/pull/161/commits/7428b5f8e7fdabbcc7c9710e23e6f438ba4ff021 Signed-off-by: Hongxu Jia Signed-off-by: Bruce Ashfield

consul: Not automatically start system service on boot

2019-09-09T17:34:53+00:00

The systemd service needs to be tuned according to various use cases and cannot be able to always start successfully for example when there is no network interface named br0 by default. Thus the default configuration is mainly used as an example. Let's not automatically start it on boot. Signed-off-by: He Zhe Signed-off-by: Bruce Ashfield

consul: Upgrade to 1.6.0

2019-09-09T17:34:53+00:00

1.6.0 is the latest release. Signed-off-by: He Zhe Signed-off-by: Bruce Ashfield

consul: don't build with the '-linkshared' option

2019-04-08T03:08:31+00:00

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 Signed-off-by: Bruce Ashfield

consul: uprev to v1.4.3

2019-03-08T21:01:44+00:00

Uprev to v1.4.3 and remove invalid patch. Signed-off-by: Hongzhi.Song Signed-off-by: Bruce Ashfield

consul: do not try to build for mips

2019-02-21T03:17:34+00:00

Use COMPATIBLE_HOST to prevent building for mipsarch. Signed-off-by: Joe Slater Signed-off-by: Bruce Ashfield

consul: add INSANE_SKIP for textrel

2018-10-11T18:33:36+00:00

1. for i586, bitbake consul will have QA error of textrel. consul-git-r0 do_package_qa: QA Issue: ELF binary i 'work/i586-wrs-linux/consul/git-r0/packages-split/consul/usr/bin/consul' has relocations in .text [textrel] according to go doc: -buildmode=pie Build the listed main packages and everything they import into position independent executables (PIE). Packages not named main are ignored. checked use command "eu-findtextrel ./consul", functions not compiled with -fpic/-fPIC are from packages not named main, and also not imported into package main. so -buildmode=pie cannot reslove this problem. so refer commit b689c72a of oe-core, just skip it. 2. This problem is caused since security_flags.inc is used by default. so alternative work around is: SECURITY_CFLAGS_pn-consul = "${SECURITY_NOPIE_CFLAGS}" SECURITY_LDFLAGS_pn-consul = "" Signed-off-by: Changqing Li Signed-off-by: Bruce Ashfield

consul-migrate: update to use go.bbclass

2018-09-25T21:40:49+00:00

We do not want meta-cloud-services to depend on meta-overc so we switch to use the go.bbclass which is now part of oe-core/yocto. We also capture all the licenses for all source packages which are included in consul-migrate and adjust paths to account for the different handling of go.bbclass vs. golang.bbclass. Signed-off-by: Mark Asselstine Signed-off-by: Bruce Ashfield

consul-migrate: use SRC_URIs not DEPENDS

2018-09-25T21:40:49+00:00

It is common to have two GO packages, A and B, and they both depend on a GO dependency, C. This can be satisfied using the current technique of writing recipes for each dependency. BUT it is also common for GO packages to not only specify other packages in their GoDeps but also specific dependency versions. In the case that A and B share a dependency on C, but require different versions, there is no easy way to accomplish this using recipes. Since GO dependencies are also source dependencies and these dependencies are overwhelmingly useless on their own, writing recipes for each is overkill. We therefor replace DEPENDS with SRC_URIs and SRCREVs as a mechanism to provide build dependencies. Signed-off-by: Mark Asselstine Signed-off-by: Bruce Ashfield