[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Plans for backporting golang 1.13 to buster



On Jan 4, 2020, at 7:57 PM, Daniel Swarbrick <daniel.swarbrick@cloud.ionos.com> 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 <praveen@onenetbeyond.org> wrote:
Hi,

I got this build error today with gitaly.
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

Reply to: