Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: unstable go.mod when replacing main module with local path #45492

Closed
thaJeztah opened this issue Apr 10, 2021 · 2 comments
Closed

cmd/go: unstable go.mod when replacing main module with local path #45492

thaJeztah opened this issue Apr 10, 2021 · 2 comments
Labels
FrozenDueToAge GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@thaJeztah
Copy link
Contributor

What version of Go are you using (go version)?

$ go version
go version go1.16.3 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

MacOS, Linux (see reproduction steps below)

What did you do?

The containerd project has a circular dependency on itself through "plugins"
that are built in-tree, but maintained in separate repositories. Circular
dependencies can be a pain, and one can "go in circles" (literally) to deal
with transitional dependencies.

In an attempt to reduce the effects of these circular dependencies (from a
modules / dependency tree perspective), I was considering adding a "replace"
rule to the project's go.mod to make the local version of containerd the
"canonical" version:

replace github.com/containerd/containerd => ./

This appeared to work well, but then I discovered that, as a result of this
replace rule, go.mod became "unstable": repeatedly calling go mod tidy
resulted in the addition and removal of an indirect dependency.

I created a branch on my fork of containerd to reproduce the issue. Reproduction
steps are below.

Reproduction steps

  1. Check out the reproduction branch from github

    $ mkdir gomod_flip_flop && cd gomod_flip_flop
    $ git clone --single-branch --branch gomod_flip_flop https://github.com/thaJeztah/containerd.git
    $ cd containerd
  2. Run go mod tidy, and observe an indirect dependency being added:

    $ go mod tidy && git diff
    go: finding module for package github.com/satori/go.uuid
    go: found github.com/satori/go.uuid in github.com/satori/go.uuid v1.2.0
    diff --git a/go.mod b/go.mod
    index a0d3f7a2c..b63b125d2 100644
    --- a/go.mod
    +++ b/go.mod
    @@ -45,6 +45,7 @@ require (
            github.com/pelletier/go-toml v1.8.1
            github.com/pkg/errors v0.9.1
            github.com/prometheus/client_golang v1.7.1
    +       github.com/satori/go.uuid v1.2.0 // indirect
            github.com/sirupsen/logrus v1.7.0
            github.com/stretchr/testify v1.6.1
            github.com/tchap/go-patricia v2.2.6+incompatible
  3. Run go mod tidy again, and observe that the indirect is removed:

    $ go mod tidy && git diff
    # (no output)
  4. Repeat 2. and 3. and see the result repeat itself

Reproducing on other versions

Does not reproduce on:

  • go version go1.13.15 linux/amd64
  • go version go1.14.15 linux/amd64 (but see notes below)
  • go version go1.15.11 linux/amd64 (but see notes below)

Reproduces on:

  • go version go1.16beta1 linux/amd64 (and up), including:
  • go version go1.16.3 linux/amd64, and
  • go version go1.16.3 darwin/amd64

To make sure I started with a clean state for each version, I used docker to
run the reproducer in a container:

for ver in 1.13.15 1.14.15 1.15.11 1.16.3; do \
    git reset --quiet --hard HEAD \
    && docker run --rm -v $(pwd):/containerd -w /containerd golang:$ver \
        sh -xc 'go version; go env; go mod tidy; git diff; go mod tidy; git diff'; \
done

go1.13.15

In a fresh golang:1.13.15 container, the issue does not reproduce:

$ go mod tidy
go: downloading github.com/containerd/ttrpc v1.0.2
# (...)
go: finding github.com/satori/go.uuid v1.2.0
go: downloading github.com/satori/go.uuid v1.2.0
# (...)
go: extracting github.com/satori/go.uuid v1.2.0
# (...)

$ git diff
# (no output)

Repeating the above produces no output, and does not result in a diff:

$ go mod tidy
# (no output)
$ git diff
# (no output)

go1.14.15, go1.15.11

On go1.14.15, and go1.15.11, go.mod is not modified, but the behavior somewhat
reproduces, as the dependency is re-resolved on each iteration:

In a fresh golang:1.14.15 or golang:1.15.11 container:

$ go mod tidy
go: downloading github.com/gogo/protobuf v1.3.2
# (...)
go: finding module for package github.com/satori/go.uuid
# (...)
go: downloading github.com/satori/go.uuid v1.2.0
# (...)
go: found github.com/satori/go.uuid in github.com/satori/go.uuid v1.2.0

$ git diff
# (no output)

Every time after that, the dependency is resolved again, but go.mod is not modified:

$ go mod tidy
go: finding module for package github.com/satori/go.uuid
go: found github.com/satori/go.uuid in github.com/satori/go.uuid v1.2.0

$ git diff
# (no output)

What did you expect to see?

The same behavior as Go 1.13: go.mod file to not be updated with each go mod tidy

What did you see instead?

The go.mod file being updated with each iteration.

@seankhliao seankhliao changed the title [go1.16] cmd/go: go mod tidy with "directory" replace results in unstable go.mod cmd/go: unstable go.mod when replacing main module with local path Apr 10, 2021
@seankhliao seankhliao added GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Apr 10, 2021
@seankhliao
Copy link
Member

possibly duplicate of #34417 ?

cc @bcmills @jayconrod

@bcmills
Copy link
Contributor

bcmills commented Apr 12, 2021

Duplicate of #34417

@bcmills bcmills marked this as a duplicate of #34417 Apr 12, 2021
@bcmills bcmills closed this as completed Apr 12, 2021
thaJeztah added a commit to thaJeztah/containerd that referenced this issue May 1, 2021
This forces vendoring to only take dependencies of this repository to
be taken into account, effectively cutting the circular dependency (for
the vendored code), and to prevent depending on transitive dependencies
coming from older versions of containerd.

go mod does not allow using the main module as a local "replace" rule using
a path; see golang/go#45492 and golang/go#34417, so instead, an empty module
is used.

One change observed is that older versions containerd depended on an older
version of imgcrypt that had an "indirect" dependency on more current versions
of gopkg.in/yaml.v2 and prometheus/procfs.

For those, a temporary "indirect" dependency was added, until prometheus/client_golang
and kubernetes are updated.

from go mod graph (before):

    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba gopkg.in/yaml.v2@v2.4.0
    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba github.com/prometheus/procfs@v0.6.0

For some reason, some older versions of containerd are still taken into account,
causing satori/go.uuid to be added as "indirect" dependency, likely because some
modules have this dependency in their go.sum. This should likely disappear once
those plugins are updated to contain a current version of containerd.

    git grep 'github.com/satori/go.uuid'
    vendor/github.com/Microsoft/hcsshim/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/aufs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/imgcrypt/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/nri/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/zfs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
thaJeztah added a commit to thaJeztah/containerd that referenced this issue May 6, 2021
This forces vendoring to only take dependencies of this repository to
be taken into account, effectively cutting the circular dependency (for
the vendored code), and to prevent depending on transitive dependencies
coming from older versions of containerd.

go mod does not allow using the main module as a local "replace" rule using
a path; see golang/go#45492 and golang/go#34417, so instead, an empty module
is used.

One change observed is that older versions containerd depended on an older
version of imgcrypt that had an "indirect" dependency on more current versions
of gopkg.in/yaml.v2 and prometheus/procfs.

For those, a temporary "indirect" dependency was added, until prometheus/client_golang
and kubernetes are updated.

from go mod graph (before):

    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba gopkg.in/yaml.v2@v2.4.0
    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba github.com/prometheus/procfs@v0.6.0

For some reason, some older versions of containerd are still taken into account,
causing satori/go.uuid to be added as "indirect" dependency, likely because some
modules have this dependency in their go.sum. This should likely disappear once
those plugins are updated to contain a current version of containerd.

    git grep 'github.com/satori/go.uuid'
    vendor/github.com/Microsoft/hcsshim/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/aufs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/imgcrypt/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/nri/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/zfs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit e26fc84)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
fahedouch pushed a commit to fahedouch/containerd that referenced this issue Oct 15, 2021
This forces vendoring to only take dependencies of this repository to
be taken into account, effectively cutting the circular dependency (for
the vendored code), and to prevent depending on transitive dependencies
coming from older versions of containerd.

go mod does not allow using the main module as a local "replace" rule using
a path; see golang/go#45492 and golang/go#34417, so instead, an empty module
is used.

One change observed is that older versions containerd depended on an older
version of imgcrypt that had an "indirect" dependency on more current versions
of gopkg.in/yaml.v2 and prometheus/procfs.

For those, a temporary "indirect" dependency was added, until prometheus/client_golang
and kubernetes are updated.

from go mod graph (before):

    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba gopkg.in/yaml.v2@v2.4.0
    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba github.com/prometheus/procfs@v0.6.0

For some reason, some older versions of containerd are still taken into account,
causing satori/go.uuid to be added as "indirect" dependency, likely because some
modules have this dependency in their go.sum. This should likely disappear once
those plugins are updated to contain a current version of containerd.

    git grep 'github.com/satori/go.uuid'
    vendor/github.com/Microsoft/hcsshim/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/aufs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/imgcrypt/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/nri/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/zfs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
dims pushed a commit to dims/containerd-api-only that referenced this issue Mar 10, 2022
This forces vendoring to only take dependencies of this repository to
be taken into account, effectively cutting the circular dependency (for
the vendored code), and to prevent depending on transitive dependencies
coming from older versions of containerd.

go mod does not allow using the main module as a local "replace" rule using
a path; see golang/go#45492 and golang/go#34417, so instead, an empty module
is used.

One change observed is that older versions containerd depended on an older
version of imgcrypt that had an "indirect" dependency on more current versions
of gopkg.in/yaml.v2 and prometheus/procfs.

For those, a temporary "indirect" dependency was added, until prometheus/client_golang
and kubernetes are updated.

from go mod graph (before):

    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba gopkg.in/yaml.v2@v2.4.0
    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba github.com/prometheus/procfs@v0.6.0

For some reason, some older versions of containerd are still taken into account,
causing satori/go.uuid to be added as "indirect" dependency, likely because some
modules have this dependency in their go.sum. This should likely disappear once
those plugins are updated to contain a current version of containerd.

    git grep 'github.com/satori/go.uuid'
    vendor/github.com/Microsoft/hcsshim/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/aufs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/imgcrypt/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/nri/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/zfs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
dims pushed a commit to dims/containerd-api-only that referenced this issue Mar 10, 2022
This forces vendoring to only take dependencies of this repository to
be taken into account, effectively cutting the circular dependency (for
the vendored code), and to prevent depending on transitive dependencies
coming from older versions of containerd.

go mod does not allow using the main module as a local "replace" rule using
a path; see golang/go#45492 and golang/go#34417, so instead, an empty module
is used.

One change observed is that older versions containerd depended on an older
version of imgcrypt that had an "indirect" dependency on more current versions
of gopkg.in/yaml.v2 and prometheus/procfs.

For those, a temporary "indirect" dependency was added, until prometheus/client_golang
and kubernetes are updated.

from go mod graph (before):

    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba gopkg.in/yaml.v2@v2.4.0
    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba github.com/prometheus/procfs@v0.6.0

For some reason, some older versions of containerd are still taken into account,
causing satori/go.uuid to be added as "indirect" dependency, likely because some
modules have this dependency in their go.sum. This should likely disappear once
those plugins are updated to contain a current version of containerd.

    git grep 'github.com/satori/go.uuid'
    vendor/github.com/Microsoft/hcsshim/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/aufs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/imgcrypt/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/nri/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/zfs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit e26fc84)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
dims pushed a commit to dims/containerd-api-only that referenced this issue Mar 26, 2022
This forces vendoring to only take dependencies of this repository to
be taken into account, effectively cutting the circular dependency (for
the vendored code), and to prevent depending on transitive dependencies
coming from older versions of containerd.

go mod does not allow using the main module as a local "replace" rule using
a path; see golang/go#45492 and golang/go#34417, so instead, an empty module
is used.

One change observed is that older versions containerd depended on an older
version of imgcrypt that had an "indirect" dependency on more current versions
of gopkg.in/yaml.v2 and prometheus/procfs.

For those, a temporary "indirect" dependency was added, until prometheus/client_golang
and kubernetes are updated.

from go mod graph (before):

    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba gopkg.in/yaml.v2@v2.4.0
    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba github.com/prometheus/procfs@v0.6.0

For some reason, some older versions of containerd are still taken into account,
causing satori/go.uuid to be added as "indirect" dependency, likely because some
modules have this dependency in their go.sum. This should likely disappear once
those plugins are updated to contain a current version of containerd.

    git grep 'github.com/satori/go.uuid'
    vendor/github.com/Microsoft/hcsshim/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/aufs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/imgcrypt/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/nri/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/zfs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit e26fc84)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
dims pushed a commit to dims/containerd-api-only that referenced this issue Mar 26, 2022
This forces vendoring to only take dependencies of this repository to
be taken into account, effectively cutting the circular dependency (for
the vendored code), and to prevent depending on transitive dependencies
coming from older versions of containerd.

go mod does not allow using the main module as a local "replace" rule using
a path; see golang/go#45492 and golang/go#34417, so instead, an empty module
is used.

One change observed is that older versions containerd depended on an older
version of imgcrypt that had an "indirect" dependency on more current versions
of gopkg.in/yaml.v2 and prometheus/procfs.

For those, a temporary "indirect" dependency was added, until prometheus/client_golang
and kubernetes are updated.

from go mod graph (before):

    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba gopkg.in/yaml.v2@v2.4.0
    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba github.com/prometheus/procfs@v0.6.0

For some reason, some older versions of containerd are still taken into account,
causing satori/go.uuid to be added as "indirect" dependency, likely because some
modules have this dependency in their go.sum. This should likely disappear once
those plugins are updated to contain a current version of containerd.

    git grep 'github.com/satori/go.uuid'
    vendor/github.com/Microsoft/hcsshim/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/aufs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/imgcrypt/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/nri/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/zfs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
dims pushed a commit to dims/containerd-api-only that referenced this issue Mar 26, 2022
This forces vendoring to only take dependencies of this repository to
be taken into account, effectively cutting the circular dependency (for
the vendored code), and to prevent depending on transitive dependencies
coming from older versions of containerd.

go mod does not allow using the main module as a local "replace" rule using
a path; see golang/go#45492 and golang/go#34417, so instead, an empty module
is used.

One change observed is that older versions containerd depended on an older
version of imgcrypt that had an "indirect" dependency on more current versions
of gopkg.in/yaml.v2 and prometheus/procfs.

For those, a temporary "indirect" dependency was added, until prometheus/client_golang
and kubernetes are updated.

from go mod graph (before):

    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba gopkg.in/yaml.v2@v2.4.0
    github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba github.com/prometheus/procfs@v0.6.0

For some reason, some older versions of containerd are still taken into account,
causing satori/go.uuid to be added as "indirect" dependency, likely because some
modules have this dependency in their go.sum. This should likely disappear once
those plugins are updated to contain a current version of containerd.

    git grep 'github.com/satori/go.uuid'
    vendor/github.com/Microsoft/hcsshim/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/aufs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/imgcrypt/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/nri/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
    vendor/github.com/containerd/zfs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 6f72ef3)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@golang golang locked and limited conversation to collaborators Apr 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants