golang: 1.16 update breaks dependent packages

[cotequeiroz]

Maintainer: @jefferyto
Environment: master, 21.02, apparently all arches

Description:

Since the update, packages are failing like:

cni

/builder/shared-workdir/build/sdk/staging_dir/target-mipsel_74kc_musl/usr/share/gocode/src does not exist, skipping symlinks

Finding targets
no required module provides package github.com/containernetworking/cni/cnitool: working directory is not part of a module

Building targets
go: cannot find main module; see 'go help modules'

Makefile:50: recipe for target '/builder/shared-workdir/build/sdk/build_dir/target-mipsel_74kc_musl/cni-0.8.0/.built' failed
make[3]: *** [/builder/shared-workdir/build/sdk/build_dir/target-mipsel_74kc_musl/cni-0.8.0/.built] Error 1

Docker

Building statically linked build/docker-linux-mipsle
no required module provides package github.com/docker/cli/cmd/docker: working directory is not part of a module
Makefile:54: recipe for target '/builder/shared-workdir/build/sdk/build_dir/target-mipsel_74kc_musl/docker-20.10.2/.built' failed

[jefferyto]

I think this is related to module-aware mode being enabled by default in 1.16. I'll take a look at this tonight.

GOPATH mode (non-module mode) is going away in 1.17 - we may need to look into migrating/removing non-module Go packages in the near future.

[cotequeiroz]

Sure is. Adding GO_PKG_BUILD_VARS += GO111MODULE=auto solves (momentarily) the problem. I've tested it with cni. I think it is best to not add this by default, as doing it on a package level ,we can have a record of which packages need it. What do you think?

[jefferyto]

Sounds good to me - do you want to do a PR for this fix or should I?

[cotequeiroz]

Here's a quick assessment, using the buildbots' faillog as a parameter:

$ for Make in $(git grep -l 'include.*golang-package\.mk'); do \
pkg="$(basename $(dirname $Make))"; printf "%-30s" "${pkg}"; \
curl -sI "https://downloads.openwrt.org/releases/faillogs-21.02/mipsel_24kc/packages/${pkg}/compile.txt" \
| grep -q '404 Not Found' && echo OK || { printf "%s " Fail; grep MAINT $Make;} \
 done
gitlab-runner                 OK
packr                         OK
golang                        OK
adguardhome                   OK
dnscrypt-proxy2               OK
dnstap                        OK
frp                           OK
gateway-go                    OK
geth                          OK
git-lfs                       OK
kcptun                        OK
nebula                        OK
nextdns                       OK
obfs4proxy                    OK
ooniprobe                     OK
overture                      OK
restic-rest-server            Fail PKG_MAINTAINER:=Markus Weippert <markus@gekmihesg.de>
tor-fw-helper                 Fail PKG_MAINTAINER:=Jeffery To <jeffery.to@gmail.com>
xray-core                     OK
yggdrasil                     OK
cni-plugins                   OK
cni                           Fail PKG_MAINTAINER:=Daniel Golle <daniel@makrotopia.org>, Paul Spooren <mail@aparcar.org>
containerd                    Fail PKG_MAINTAINER:=Gerard Ryan <G.M0N3Y.2503@gmail.com>
ctop                          OK
docker                        Fail PKG_MAINTAINER:=Gerard Ryan <G.M0N3Y.2503@gmail.com>
dockerd                       Fail PKG_MAINTAINER:=Gerard Ryan <G.M0N3Y.2503@gmail.com>
libnetwork                    Fail PKG_MAINTAINER:=Gerard Ryan <G.M0N3Y.2503@gmail.com>
oci-runtime-tools             Fail PKG_MAINTAINER:=Daniel Golle <daniel@makrotopia.org>
podman                        OK
prometheus-statsd-exporter    OK
prometheus                    OK
restic                        OK
runc                          OK
syncthing                     OK
yq                            OK

If I add GO_PKG_BUILD_VARS += GO111MODULE=auto to the Makefile of each failed package, then they all compile. However, if support for GOPATHC mode will be removed at the next release, it would only be a temporary hack, really.
Ping @gekmihesg @jefferyto @dangowrt @aparcar @G-M0N3Y-2503

[cotequeiroz]

Sounds good to me - do you want to do a PR for this fix or should I?

I have the files all ready, I just have to commit them, so I could easily do it.
Between you posting that and I noticing it, I'd already pinged the maintainers. Upstream may have taken care of this. I'll open PRs for each package, then we can adjust them to what each maintainer would rather do. If we don't hear from them in, say a week (I never know how long is a reasonable time to leave a package broken 😕), we can merge the PR.

On a second thought, why leave otherwise working packages broken? I figure the change will only keep the status quo, so might as well just do it. I'll just open a PR.