On Jan 4, 2020, at 7:57 PM, Daniel Swarbrick <[email protected]> wrote: > > I have noticed a lot of CNCF projects have made the switch to Go 1.13. I > think that for some of them, it's simply been more or less a housekeeping > thing, but for others, they are genuinely starting to use Go 1.13 features. > > As an example, I updated a couple of Prometheus exporters yesterday. The > blackbox_exporter now supports reporting TLS versions of HTTP probes, and > references TLS 1.3 constants only found in Go 1.13's net/http package. These > could of course be patched out in a buster / Go 1.11 build. The snmp_exporter > now uses signed bit-shifts in their code, which first landed in Go 1.13. > Patching this would be slightly more involved, but still feasible. > > I'm in favour of backporting Go 1.13 to buster. After all, stretch shipped > with Go 1.7, yet has Go 1.11 in stretch-backports. To support Go 1.13 in > buster, dh-golang would also need to be backported, since Go 1.12 introduced > the requirement that the GOCACHE env var must point to a writable directory. > See changelog entry for dh-golang 1.40. > > On Fri, Jan 3, 2020 at 9:13 PM Pirate Praveen <[email protected] > <mailto:[email protected]>> wrote: > Hi, > > I got this build error today with gitaly. > https://gitlab.com/gitlab-org/gitaly/issues/2312 > <https://gitlab.com/gitlab-org/gitaly/issues/2312> > > I think more and more packages will be expecting golang 1.13 from now > on. Is there any plan to backport golang 1.13 to buster? Or any > objections if I were to backport it? > > Thanks > Praveen > > > > > -- > Daniel Swarbrick
I’d also be in favor of backporting: I’ve already had to patch one thing to backport git-lfs and I’d expect more to follow in the future. Happy to help with the backport if nobody else wants to take a stab at it. Stephen
