all: require Linux kernel version 2.6.32 #45964

OneOfOne · 2021-05-05T07:30:29Z

The last version of 2.6.23(.17) was released on February 2008 src.
The current CentOS LTS (v7) uses kernel 3.10 src.
Debian's minimum is 3.16 src.

A quick search shows lot of random issues that could have been avoided by supported a slightly newer kernel.

This is a request to bump the minimum required kernel version to at least 3.10.

mvdan · 2021-05-05T08:27:17Z

I support this change. Other GOOS variants fairly regularly drop support for older versions, and Linux 2.x hasn't had any upstream support at all since 2016 (2.6.32 got extended by Ubuntu/RHEL, other 2.x versions went EOL by 2012). Supporting dozens of Linux versions at once adds cost to maintenance and code complexity, makes testing more difficult, etc.

Worth noting that Debian Stretch, now "oldstable", has long-term support until mid-2022, and is on Linux 3.16 like you say. The actual stable release is on Linux 4.19, which is supported by upstream until 2024.

Similarly, CentOS v7 using Linux 3.10 is supported until 2024. So it seems like we could consider another bump sometime after.

andrius4669 · 2021-05-07T20:05:13Z

glibc now also requires at least 3.2 version since 2.27 (announcement) for all architectures, including x86 ones.
The only issue I can imagine at the moment is old kernels used in OpenVZ VPSes, but they're starting becoming a problem for newer debian versions already.
One I have is currently running "2.6.32-042stab134.7" and debian stretch works on it (uses glibc 2.24), however updating to jessie is not possible due to its use of glibc 2.28.
For non-x86 architectures this shouldn't be an issue, which was also possibly the reason (or at least was part of) why glibc delayed their requirement for 3.2 kernel only for x86 architectures (they required 3.2 kernel in 2.25 version on other architectures).

networkimprov · 2021-05-16T16:34:09Z

@ianlancetaylor perhaps this should be a proposal?

ianlancetaylor · 2021-05-17T03:11:50Z

Thanks, moved into proposal process.

rsc · 2021-05-19T18:31:00Z

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

rsc · 2021-05-26T17:19:43Z

glibc requires 3.2. CentOS apparently requires 3.10.
What are we thinking of changing the minimum to?

And what are the benefits of bumping the minimum?
The link in the top comment is a search for [kernel 2.6.23] in the issue tracker.
Not all of them are bugs in 2.6.23 kernels.

Is there code we will be able to delete, like when we dropped XP?
Would we make Go binaries crash at startup if running on an old kernel?

rsc · 2021-06-02T17:12:44Z

We are still trying to understand this change, specifically
the exact details (which version? do we take the time to check kernel version and crash at startup on old kernels?)
and benefits (which code can be simplified or deleted?).

Any thoughts?

mvdan · 2021-06-02T17:42:30Z

I'll give my opinion on those questions, but I'm not the author of this proposal.

which version?

I think changing the minimum to 3.10 would be sensible, given the Linux distro info given above. I don't see a clear reason to go lower than that; even if glibc still supports 3.2 today, that kernel version went EOL in 2018 and isn't used by any supported Linux distro that I can find.

do we take the time to check kernel version and crash at startup on old kernels

We don't do that check right now with our current minimum, right? Is a new minimum different from the existing minimum, given that we're choosing it to be very conservative?

which code can be simplified or deleted?

To me, one of the main benefits is testing. I'd assume that we want to have a GOOS=linux builder running the oldest version of the kernel we support, to have more confidence that it actually works as advertised. That's a lot harder to do if that version is EOL, and isn't used by any maintained distro.

Even if one wanted to have GOOS=linux builders at multiple major versions of Linux (maybe popular LTS versions), bumping the minimum would hopefully mean fewer of those versions to worry about.

Asking for a summary of code that could be simplified, or issues that could be closed, seems reasonable. I'm not experienced in this area, but with five minutes of grepping I found five likely candidates:

go/src/internal/poll/sock_cloexec.go

Line 19 in 6e189af

// On Linux the accept4 system call was introduced in 2.6.28

go/src/syscall/exec_linux.go

Line 557 in e11d142

// pipe2 was added in 2.6.27 and our minimum requirement is 2.6.23, so it

go/src/syscall/syscall_linux.go

Line 212 in e11d142

// in 2.6.22, Released, 8 July 2007) then fall back to utimes

go/src/syscall/syscall_linux.go

Line 556 in e11d142

// Try accept4 first for Android, then try accept for kernel older than 2.6.28

go/src/runtime/internal/atomic/sys_linux_arm.s

Line 18 in e11d142

// On older kernels (before 2.6.24) the function can incorrectly

rsc · 2021-06-09T17:20:56Z

iant points out that timerfd was added in 2.6.25 and we probably want to depend on it for time.ExternalNow, so we should bump at least that far. And the examples show we could bump to at least 2.6.28 to simplify some code.

bradfitz points out that Synology 6.2 ships with 2.6.32.
CentOS 6 (out of support but clearly still used) is running 2.6.32 as well.

So maybe we should raise to 2.6.32, which will let us eliminate some very old things, keep some existing known use cases working, and seems not to add any known burden compared to newer versions.

Thoughts on raising to 2.6.32?

OneOfOne · 2021-06-09T18:34:30Z

That would clean all of checks in the go runtime except one that requires 4.5+, sounds good!

mvdan · 2021-06-09T19:44:30Z

Bumping fewer versions is certainly better than bumping none :) We can always revisit for a newer Linux version in a couple of years.

andig · 2021-06-10T13:26:55Z

bradfitz points out that Synology 6.2 ships with 2.6.32.
CentOS 6 (out of support but clearly still used) is running 2.6.32 as well.

So maybe we should raise to 2.6.32, which will let us eliminate some very old things, keep some existing known use cases working, and seems not to add any known burden compared to newer versions.

Thoughts on raising to 2.6.32?

I'm not a linux pro, but Synology 6.2.4 on my NAS shows:

admin@NAS:~$ uname -a
Linux NAS 4.4.59+ #25556 SMP PREEMPT Thu Mar 4 18:03:46 CST 2021 x86_64 GNU/Linux synology_apollolake_218+

Suggestions above seem to target on 3.10, is 2.6.32 really a requirement?

rsc · 2021-06-10T14:08:11Z

We know of users of Go programs built for Synology 6.2 using 2.6.32, and we know of users of CentOS 6 using 2.6.32.

Suggestions above seem to target on 3.10, is 2.6.32 really a requirement?

The clear downside of 3.10 over 2.6.32 is dropping support for those systems, where we know of real instances where Go is running today.

What is the upside of 3.10 over 2.6.32?

rsc · 2021-06-16T17:41:38Z

Retitled to specify 2.6.32. Does anyone object to this change?

rsc · 2021-07-14T18:01:34Z

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

rsc · 2021-07-21T19:08:22Z

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

@horahoradev

- Test all GOOS/GOARCH combinations by looping over "go tool dist list"; this just tests if it compiles. - Add a Vagrant box to test Debian 6 / Linux 2.6.32; this was adapted from @horahoradev's patch at #434. - Update the minimum version requirements: we test Linux 2.6.32 now and turns out that's also the minimum version [Go supports] in recent releases, so just set it to that. Need Go 1.16 for retract in go.mod. I don't know, maybe we can just remove the retract? Latest Debian ships with Go 1.15. [Go supports]: golang/go#45964 - Test both Go 1.16 and 1.18 (the lowest supported version and newest version). I guess we could also test 1.17, but the CI already takes somewhat long and I can't recall ever having a situation where an intermediate version failed. - Test macOS 11 and 12; macOS 10.15 will (probably) end support in November, so probably not worth supporting this. GitHub will [remove] support for this at the end of August. [remove]: https://github.blog/changelog/2022-07-20-github-actions-the-macos-10-15-actions-runner-image-is-being-deprecated-and-will-be-removed-by-8-30-22/ - Test OpenBSD, NetBSD. - Move "lint" to its own YAML file. Future work: - Actually run tests for all systems Go supports. Bit pointless right now as many of these don't do anything. Currently untested are Solaris, illumios, plan9, AIX, Android, iOS, DragonflyBSD, WASM. Some of these might be difficult (AIX, iOS, Android), but haven't looked in to it. I tried setting up Solaris with the vmactions/solaris, but it doesn't seem to have an easy way to install Go. - GitHub only [supports] Windows Server 2019 and 2022; probabably also want to test Server 2016, but GitHub dropped support for this. Can maybe use AppVeyor(?) [supports]: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#choosing-github-hosted-runners - Could maybe test older versions of BSD, too. Not sure of it's worth it.

@horahoradev

* Test some more things in CI - Test all GOOS/GOARCH combinations by looping over "go tool dist list"; this just tests if it compiles. - Add a Vagrant box to test Debian 6 / Linux 2.6.32; this was adapted from @horahoradev's patch at #434. - Update the minimum version requirements: we test Linux 2.6.32 now and turns out that's also the minimum version [Go supports] in recent releases, so just set it to that. Need Go 1.16 for retract in go.mod. I don't know, maybe we can just remove the retract? Latest Debian ships with Go 1.15. [Go supports]: golang/go#45964 - Test both Go 1.16 and 1.18 (the lowest supported version and newest version). I guess we could also test 1.17, but the CI already takes somewhat long and I can't recall ever having a situation where an intermediate version failed. - Test macOS 11 and 12; macOS 10.15 will (probably) end support in November, so probably not worth supporting this. GitHub will [remove] support for this at the end of August. [remove]: https://github.blog/changelog/2022-07-20-github-actions-the-macos-10-15-actions-runner-image-is-being-deprecated-and-will-be-removed-by-8-30-22/ - Test OpenBSD, NetBSD. - Move "lint" to its own YAML file. Future work: - Actually run tests for all systems Go supports. Bit pointless right now as many of these don't do anything. Currently untested are Solaris, illumios, plan9, AIX, Android, iOS, DragonflyBSD, WASM. Some of these might be difficult (AIX, iOS, Android), but haven't looked in to it. I tried setting up Solaris with the vmactions/solaris, but it doesn't seem to have an easy way to install Go. - GitHub only [supports] Windows Server 2019 and 2022; probabably also want to test Server 2016, but GitHub dropped support for this. Can maybe use AppVeyor(?) [supports]: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#choosing-github-hosted-runners - Could maybe test older versions of BSD, too. Not sure of it's worth it. * Skip TestFsnotifyMultipleOperations on NetBSD This test doesn't seem to work; I'm sure it passed at least once in the CI, but locally I can't seem to get it to work. Fails with: === RUN TestFsnotifyMultipleOperations integration_test.go:114: event received: "/tmp/fsnotify2194826986/TestFsnotifySeq.testfile": CREATE integration_test.go:114: event received: "/tmp/fsnotify2194826986/TestFsnotifySeq.testfile": WRITE integration_test.go:114: event received: "/tmp/fsnotify2194826986/TestFsnotifySeq.testfile": REMOVE|RENAME integration_test.go:114: event received: "/tmp/fsnotify2194826986/TestFsnotifySeq.testfile": CREATE integration_test.go:186: incorrect number of rename+delete events received after 500 ms (2 vs 1) integration_test.go:114: event received: "/tmp/fsnotify2194826986/TestFsnotifySeq.testfile": REMOVE integration_test.go:114: event received: "/tmp/fsnotify2194826986": REMOVE|WRITE For reference, this is the output on Linux and OpenBSD (the output is identical): === RUN TestFsnotifyMultipleOperations integration_test.go:114: event received: "/tmp/fsnotify989736723/TestFsnotifySeq.testfile": CREATE integration_test.go:114: event received: "/tmp/fsnotify989736723/TestFsnotifySeq.testfile": WRITE integration_test.go:114: event received: "/tmp/fsnotify989736723/TestFsnotifySeq.testfile": RENAME integration_test.go:114: event received: "/tmp/fsnotify989736723/TestFsnotifySeq.testfile": CREATE integration_test.go:190: calling Close() integration_test.go:192: waiting for the event channel to become closed... integration_test.go:195: event channel closed * Fix "too many open files" on Debian 6, maybe I guess this started failing after I rebased on main; let's see if a small sleep works to clean up the file descriptors.

rsc · 2022-08-05T16:09:49Z

This was done and announced in go.dev/doc/go1.18.

gopherbot · 2022-08-09T15:37:11Z

Change https://go.dev/cl/422374 mentions this issue: syscall: remove cloexecSocket fallback path

gopherbot · 2022-08-09T15:55:38Z

Change https://go.dev/cl/422375 mentions this issue: internal/poll: remove fallback path in accept

gopherbot · 2022-08-17T17:13:48Z

Change https://go.dev/cl/424574 mentions this issue: internal/dl: update minimum Linux kernel to 2.6.32

All supported Go versions, that is Go 1.18 and newer, now share a common Linux kernel version requirement adopted in proposal 45964. For golang/go#45964. Change-Id: Iec386b75f71ebf192883e4aac9bb3634bffdfe35 Reviewed-on: https://go-review.googlesource.com/c/website/+/424574 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>

gopherbot · 2022-08-17T20:39:38Z

Change https://go.dev/cl/422979 mentions this issue: internal/poll: remove detection of buggy splice on old Linux versions

The splice syscall is buggy prior to Linux 2.6.29. CL 113999 added a workaround to detect buggy versions and disable use of splice for these. As of Go 1.18 the minumum Linux version is 2.6.32. Thus, a non-buggy implementation of the splice syscall can be assumed. For #45964 Fixes #54505 Change-Id: Ied3a3334da7a3f7fa1280b7c5b1dfb9030219336 Reviewed-on: https://go-review.googlesource.com/c/go/+/422979 Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

gopherbot · 2022-08-18T09:52:41Z

Change https://go.dev/cl/424556 mentions this issue: runtime/internal/atomic: remove double-check in kernelcas on linux/arm

Most newer architectures (e.g. arm64, riscv64, loong64) don't provide the epoll_create syscall. Some systems (e.g. Android) block it even if it were available. In the kernel, the epoll_create syscall is implemented [1] the same way EpollCreate is implemented in this package for platforms without the epoll_create syscall. The epoll_create1 syscall is available since Linux kernel 2.6.27 and the minimum required kernel version is 2.6.32 since Go 1.18 (see #45964). Thus, avoid the separate wrapper and consistently implement EpollCreate using EpollCreate1. [1] https://elixir.bootlin.com/linux/v5.15-rc1/source/fs/eventpoll.c#L2006 The same change was already done in CL 349809 for golang.org/x/sys/unix. For #45964 Change-Id: I5463b208aa7ae236fa2c175d6d3ec6568f1840b0 Reviewed-on: https://go-review.googlesource.com/c/go/+/411594 Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>

Support for operating system versions requiring the fallback to CloseOnExec/SetNonblock was dropped from recent Go versions. The minimum Linux kernel version is 2.6.32 as of Go 1.18. FreeBSD 10 is no longer supported as of Go 1.13. Follows a similar change for net.sysSocket in CL 403634 and syscall.Socket in CL 422374. For #45964 Change-Id: I60848415742a1d8204e1fda585462ff35ad6722f Reviewed-on: https://go-review.googlesource.com/c/go/+/422375 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>

Support for Linux kernel versions requiring the fallback to CloseOnExec was dropped from recent Go versions. The minimum Linux kernel version is 2.6.32 as of Go 1.18. The SOCK_CLOEXEC flag for the socket syscall is supported since kernel version 2.6.27. Follows a similar change for net.sysSocket in CL 403634. For #45964 Change-Id: I8b6311f07c4ed7900a9af3ecb2e146c49db08665 Reviewed-on: https://go-review.googlesource.com/c/go/+/422374 Reviewed-by: Joedian Reid <joedian@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>

Older kernels which require the double check of the __kuser_cmpxchg result are no longer supported as of Go 1.18 which requires at least Linux 2.6.32. For #45964 Change-Id: Ic3d6691bf006353ac51b9d43e742d970e3d4e961 Reviewed-on: https://go-review.googlesource.com/c/go/+/424556 Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com>

gopherbot · 2023-06-06T17:42:24Z

Change https://go.dev/cl/501275 mentions this issue: Revert "internal/poll: remove fallback path in accept"

gopherbot · 2023-06-06T17:47:33Z

Change https://go.dev/cl/501276 mentions this issue: Revert "net: remove fallback path in sysSocket"

This reverts CL 422375. Reason for revert: We still need the fallback path on Solaris. For #45964 For #59359 Change-Id: Ie598b9ef180708fb157080015aee44f67f6737c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/501275 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org>

gopherbot · 2023-06-07T18:29:01Z

Change https://go.dev/cl/501636 mentions this issue: internal/poll: update SOCK_CLOEXEC comment

For #45964 For #59359 Change-Id: I9f8f4c17ccd9711f81d152953a5e6aea50c6a28f Reviewed-on: https://go-review.googlesource.com/c/go/+/501636 Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com>

This reverts CL 40364. Reason for revert: Fallback path is still required on Solaris. For #45964 For #59359 Change-Id: I4b8c8af77ee987cad6617221793b90c9a8829c3e Reviewed-on: https://go-review.googlesource.com/c/go/+/501276 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>

gopherbot · 2023-06-09T00:23:02Z

Change https://go.dev/cl/501939 mentions this issue: net: update SOCK_CLOEXEC comment

For #45964 For #59359 Change-Id: I7fd295a096e5776102e057789d157da681df9073 Reviewed-on: https://go-review.googlesource.com/c/go/+/501939 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>

ALTree added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label May 5, 2021

tklauser changed the title ~~runtime: bump minimum linux kernel version~~ all: bump minimum linux kernel version May 5, 2021

ianlancetaylor changed the title ~~all: bump minimum linux kernel version~~ proposal: bump minimum linux kernel version May 17, 2021

gopherbot added this to the Proposal milestone May 17, 2021

gopherbot added Proposal and removed NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels May 17, 2021

ianlancetaylor added this to Incoming in Proposals (old) May 17, 2021

rsc changed the title ~~proposal: bump minimum linux kernel version~~ proposal: all: raise minimum required Linux kernel version May 19, 2021

rsc moved this from Incoming to Active in Proposals (old) May 19, 2021

rsc mentioned this issue May 19, 2021

proposal: review meeting minutes #33502

Open

rsc changed the title ~~proposal: all: raise minimum required Linux kernel version~~ proposal: all: require Linux kernel version 2.6.32 Jun 16, 2021

rsc moved this from Active to Likely Accept in Proposals (old) Jul 14, 2021

rsc added the Proposal-FinalCommentPeriod label Jul 14, 2021

rsc moved this from Likely Accept to Accepted in Proposals (old) Jul 21, 2021

arp242 mentioned this issue Jul 23, 2022

Test some more things in CI fsnotify/fsnotify#469

Merged

rsc closed this as completed Aug 5, 2022

dmitshur modified the milestones: Backlog, Go1.18 Aug 17, 2022

dmitshur mentioned this issue Aug 17, 2022

internal/poll: can update newPipe to take advantage of newer Linux kernel requirement #54505

Closed

bradfitz mentioned this issue Dec 15, 2022

syscall, internal/poll: accept4-to-accept fallback removal broke Go code on Synology DSM 6.2 ARM devices #57333

Closed

dmitshur mentioned this issue Jun 14, 2023

all: announce end of support for old Linux versions #60792

Open

rsc mentioned this issue Apr 23, 2024

proposal: all: require Linux 3.17 kernel for Go 1.24 #67001

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

all: require Linux kernel version 2.6.32 #45964

all: require Linux kernel version 2.6.32 #45964

OneOfOne commented May 5, 2021 •

edited

mvdan commented May 5, 2021

andrius4669 commented May 7, 2021 •

edited

networkimprov commented May 16, 2021

ianlancetaylor commented May 17, 2021

rsc commented May 19, 2021

rsc commented May 26, 2021

rsc commented Jun 2, 2021

mvdan commented Jun 2, 2021

rsc commented Jun 9, 2021

OneOfOne commented Jun 9, 2021

mvdan commented Jun 9, 2021

andig commented Jun 10, 2021

rsc commented Jun 10, 2021

rsc commented Jun 16, 2021

rsc commented Jul 14, 2021

rsc commented Jul 21, 2021

rsc commented Aug 5, 2022

gopherbot commented Aug 9, 2022

gopherbot commented Aug 9, 2022

gopherbot commented Aug 17, 2022

gopherbot commented Aug 17, 2022

gopherbot commented Aug 18, 2022

gopherbot commented Jun 6, 2023

gopherbot commented Jun 6, 2023

gopherbot commented Jun 7, 2023

gopherbot commented Jun 9, 2023

all: require Linux kernel version 2.6.32 #45964

all: require Linux kernel version 2.6.32 #45964

Comments

OneOfOne commented May 5, 2021 • edited

mvdan commented May 5, 2021

andrius4669 commented May 7, 2021 • edited

networkimprov commented May 16, 2021

ianlancetaylor commented May 17, 2021

rsc commented May 19, 2021

rsc commented May 26, 2021

rsc commented Jun 2, 2021

mvdan commented Jun 2, 2021

rsc commented Jun 9, 2021

OneOfOne commented Jun 9, 2021

mvdan commented Jun 9, 2021

andig commented Jun 10, 2021

rsc commented Jun 10, 2021

rsc commented Jun 16, 2021

rsc commented Jul 14, 2021

rsc commented Jul 21, 2021

rsc commented Aug 5, 2022

gopherbot commented Aug 9, 2022

gopherbot commented Aug 9, 2022

gopherbot commented Aug 17, 2022

gopherbot commented Aug 17, 2022

gopherbot commented Aug 18, 2022

gopherbot commented Jun 6, 2023

gopherbot commented Jun 6, 2023

gopherbot commented Jun 7, 2023

gopherbot commented Jun 9, 2023

OneOfOne commented May 5, 2021 •

edited

andrius4669 commented May 7, 2021 •

edited