prepare release v1.6.9

[thaJeztah]

• Update containerd to v1.6.9
• Update Golang runtime to 1.18.7

[tianon]

Can you remind me how we actually make sure this change is correct? 🙈

[tianon]

(as in, where is 1.18.7 actually specified?)

[thaJeztah]

It's picked up from the upstream dockerfile (and we have an override if needed); I may have to check that override in our internal pipeline, but it prints the version it uses during build, and I check that one 😁

[thaJeztah]

https://github.com/docker/containerd-packaging/blob/master/common/common.mk#L22

[thaJeztah]

All well 👍

--------------------------------------------------------------------
Building packages on docker.io/library/ubuntu:focal

containerd   : v1.6.9 (commit: 1c90a44)
INFO: detected runc version (v1.1.4) from script/setup/runc-version
runc         : v1.1.4 (commit: 5fd4c4d)
architecture : x86_64
build image  : docker.io/library/ubuntu:focal
golang image : golang:1.18.7
--------------------------------------------------------------------

[thaJeztah]

Ah, fun, Windows is failing (we don't ship those binaries currently, but wondering what caused this)

docker run \
	--rm \
	-v "d:/jenkins/workspace/containerd-packaging_PR-293/src/:C:/gopath/src" \
	-v "d:/jenkins/workspace/containerd-packaging_PR-293/build/windows:C:/gopath/src/github.com/containerd/containerd/bin" \
	-w "C:/gopath/src/github.com/containerd/containerd" \
	dockereng/containerd-windows-builder \
	make bin/containerd
+ bin/containerd
go build  -gcflags=-trimpath=C/src  -o bin/containerd -ldflags '-X github.com/containerd/containerd/version.Version=e7311db -X github.com/containerd/containerd/version.Revision=e7311db1f6c19eca2446efd38553ab81a5a0aabd -X github.com/containerd/containerd/version.Package=github.com/containerd/containerd -s -w ' -tags "urfave_cli_no_docs"  ./cmd/containerd
# github.com/containerd/containerd/cmd/containerd
C:\Program Files\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
c:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\ContainerAdministrator\AppData\Local\Temp\go-link-1314783741\000007.o: in function `_cgo_preinit_init':
\\_\_\runtime\cgo/gcc_libinit_windows.c:40: undefined reference to `__imp___iob_func'
c:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\ContainerAdministrator\AppData\Local\Temp\go-link-1314783741\000007.o: in function `x_cgo_notify_runtime_init_done':
\\_\_\runtime\cgo/gcc_libinit_windows.c:105: undefined reference to `__imp___iob_func'
c:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\ContainerAdministrator\AppData\Local\Temp\go-link-1314783741\000007.o: in function `_cgo_beginthread':
\\_\_\runtime\cgo/gcc_libinit_windows.c:149: undefined reference to `__imp___iob_func'
c:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\ContainerAdministrator\AppData\Local\Temp\go-link-1314783741\000008.o: in function `x_cgo_thread_start':
\\_\_\runtime\cgo/gcc_util.c:18: undefined reference to `__imp___iob_func'
collect2.exe: error: ld returned 1 exit status

[thaJeztah]

Related to https://stackoverflow.com/a/36504365 ?

[thaJeztah]

Looks like a known issue in Go;

• cmd/link: cgo linking fails on Windows with GCC 11.2.0 + MinGW-w64 9.0.0 (UCRT) from winlibs.com golang/go#51007

[thaJeztah]

Perhaps we need to do the same as the Tailscale people;

• .github/workflows: downgrade MinGW to work around windows-race failures tailscale/tailscale#4977

[tianon]

tailscale/tailscale#4977 (comment) is interesting 👀

[thaJeztah]

Ah, yes, but that probably needs changes in the containerd makefiles? or is that an option to pass when installing MinGW?

[thaJeztah]

Opened #294 (included a first commit in this PR as well)

[tianon]

We might be able to abuse GOFLAGS if the containerd Makefile isn't already abusing it. 👀

[thaJeztah]

Yeah, I could look into the GOFLAGS - I suspect it may already be used. Let's keep that for a follow-up (will have to dig through containerd makefiles 😂)