Date: Sat, 18 Jan 2025 11:17:09 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 284132] Set GOTOOLCHAIN during all go builds Message-ID: <bug-284132-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D284132 Bug ID: 284132 Summary: Set GOTOOLCHAIN during all go builds Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: ports-bugs@FreeBSD.org Reporter: rudolphfroger@dreamsolution.nl I recently ran into an issue for a go project (Forgejo 10.0.0) which specif= ies a `toolchain` in `go.mod`. If this specifies a newer go version (i.e. 1.23.4 while FreeBSD ports has 1.23.3) then go will try to download this newer ver= sion and build it. Poudriere will however prevent this from happening because du= ring builds no network access is allowed. Also it seems logical that all go ports use the go version specified in the `lang/go*` ports, and not some other version. Go allows one to disable this behaviour, it seems, but I'm not very familiar with Go. See https://go.dev/doc/toolchain It may be worth while to set `GOTOOLCHAIN` to a Go version, instead of the default value of "auto" which causes this Go upgrade mechanism. I also files a bug report at Forgejo, and I could write a patch file for the Forgejo port to patch the `go.mod`. That would solve this specific case, bu= t I think no "USES=3Dgo" port should ever have this "auto" toolchain behaviour = of Go, so all builds use a consistent Go (patch) version for all ports. And that w= ould only be achieved by setting `GOTOOLCHAIN` explicitly. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-284132-7788>