make vendor fails on github.com/chenzhuoyu/[email protected] and v0.9.1 with "unknown revision"

[gtjoseph]

Issue Description

I was about to submit PRs for both podman and common and for testing purposes did a go mod edit -replace for common and a make vendor which failed because github.com/chenzhuoyu/iasm is apparently no longer maintained. Is this something CI is supposed to catch and fix (maybe via renovate) or should contributors update go.mod with the correct entries and submit PRs?

Steps to reproduce the issue

Steps to reproduce the issue

1. git clone https://github.com/containers/podman.git
2. cd podman
3. make vendor

Describe the results you received

$ make vendor
go mod tidy
go: downloading github.com/chenzhuoyu/iasm v0.9.1
go: github.com/bytedance/[email protected] requires
	github.com/chenzhuoyu/[email protected]: reading github.com/chenzhuoyu/iasm/go.mod at revision v0.9.0: unknown revision v0.9.0
make: *** [Makefile:348: vendor] Error 1

bytedance/sonic apparently fixed it for themselves so if I update github.com/bytedance/[email protected] to v1.12.4...

$ make vendor
go mod tidy
go: github.com/containers/podman/v5/cmd/podman-testing imports
	github.com/containers/storage/types tested by
	github.com/containers/storage/types.test imports
	gotest.tools/assert: github.com/chenzhuoyu/[email protected]: reading github.com/chenzhuoyu/iasm/go.mod at revision v0.9.1: unknown revision v0.9.1
go: github.com/containers/podman/v5/cmd/podman/machine imports
	gopkg.in/yaml.v3 tested by
	gopkg.in/yaml.v3.test imports
	gopkg.in/check.v1: github.com/chenzhuoyu/[email protected]: reading github.com/chenzhuoyu/iasm/go.mod at revision v0.9.1: unknown revision v0.9.1
...
make: *** [Makefile:348: vendor] Error 1

It fails for every other package. In the end I had to update bytedance/sonic to v1.12.4 and replace the base64x and iasm packages from chenzhuoyu with equivalents from cloudwego.

github.com/bytedance/sonic v1.10.2 // indirect
github.com/chenzhuoyu/base64x v0.0.0-20230717121745-296ad89f973d // indirect
github.com/chenzhuoyu/iasm v0.9.1 // indirect

to

github.com/bytedance/sonic v1.12.4 // indirect
github.com/cloudwego/base64x v0.1.4 // indirect
github.com/cloudwego/iasm v0.2.0 // indirect

Describe the results you expected

$ make vendor      
go mod tidy
go mod vendor
go mod verify
all modules verified
go mod edit -toolchain none

podman info output

N/A  Trying to build podman, not run it.

Podman in a container

No

Privileged Or Rootless

Privileged

Upstream Latest Release

Yes

Additional environment details

Fedora 41

Additional information

No response

[Luap99]

Thanks for the report, yes this seems like a serious problem.
Are you using GOPROXY=direct instead of the go proxy (GOPROXY=https://proxy.golang.org)? The google module cache will keep old tags around to not break things like this which would explain why CI is not breaking.

Normally indirect dependencies are not updated manually but rather by the direct consumers of said dependencies.

$ go mod why github.com/bytedance/sonic
# github.com/bytedance/sonic
github.com/containers/podman/v5/pkg/machine/apple
github.com/crc-org/vfkit/pkg/rest
github.com/gin-gonic/gin
github.com/gin-gonic/gin/internal/json
github.com/bytedance/sonic

And it looks like github.com/crc-org/vfkit was already updated on main but there hasn't been a release in a while so there is no update that podman can consume.
https://github.com/crc-org/vfkit/blob/main/go.mod

@cfergeau Is there are plan for a new vfkit release?
If there is no plan for a new release there we can update the indirect deps ourselves here.

[cfergeau]

@cfergeau Is there are plan for a new vfkit release?
If there is no plan for a new release there we can update the indirect deps ourselves here.

I was saying last week that it is high time there is a new vfkit release. Since you need it, it makes it even more needed. I'll try to get one out this week.

[gtjoseph]

Are you using GOPROXY=direct instead of the go proxy (GOPROXY=https://proxy.golang.org)? The google module cache will keep old tags around to not break things like this which would explain why CI is not breaking.

Yeah, GOPROXY wasn't set so it defaulted to "direct". When I changed it to "https://proxy.golang.org" the issue went away.

I'm OK with closing this issue without any further action but if you want to keep it open until the underlying issue is fixed that's fine.

[Luap99]

Let's keep it open until we updated the deps, it highlights a real issue in our dependency chain.