Control: tags -1 + upstream On Fri, Aug 30, 2024 at 11:00:25AM +0200, Helmut Grohne wrote: > gitlab-ci-multi-runner fails to build from source in unstable on amd64. > The tail of the build log does not make that much sense to me. I hope > that someone else can decypher it:
I looked into this a bit. The real error is this: | # gitlab.com/gitlab-org/gitlab-runner/helpers/docker | src/gitlab.com/gitlab-org/gitlab-runner/helpers/docker/client.go:27:51: undefined: types.ContainerListOptions | src/gitlab.com/gitlab-org/gitlab-runner/helpers/docker/client.go:33:36: undefined: container.ContainerCreateCreatedBody | src/gitlab.com/gitlab-org/gitlab-runner/helpers/docker/client.go:34:72: undefined: types.ContainerStartOptions | src/gitlab.com/gitlab-org/gitlab-runner/helpers/docker/client.go:41:17: undefined: types.ContainerAttachOptions | src/gitlab.com/gitlab-org/gitlab-runner/helpers/docker/client.go:43:73: undefined: types.ContainerRemoveOptions | src/gitlab.com/gitlab-org/gitlab-runner/helpers/docker/client.go:48:22: undefined: container.ContainerWaitOKBody | src/gitlab.com/gitlab-org/gitlab-runner/helpers/docker/client.go:49:69: undefined: types.ContainerLogsOptions | src/gitlab.com/gitlab-org/gitlab-runner/helpers/docker/client.go:63:51: undefined: volume.VolumeCreateBody | src/gitlab.com/gitlab-org/gitlab-runner/helpers/docker/client.go:63:76: undefined: types.Volume | src/gitlab.com/gitlab-org/gitlab-runner/helpers/docker/client.go:65:61: undefined: types.Volume | src/gitlab.com/gitlab-org/gitlab-runner/helpers/docker/client.go:65:61: too many errors What is being complained about comes from golang-github-docker-docker-dev, i.e. src:docker.io. It is that go module that changed API in significant ways. Quite definitely, https://gitlab.com/gitlab-org/gitlab-runner/-/commit/0a08de1ca95c527d388573161207484ea73dee81 is needed to adapt and this patch can be ported with some effort. Another patch that is likely needed is https://gitlab.com/gitlab-org/gitlab-runner/-/commit/452ac0a2eb7bdf2895467b2cdab95d5f253e8d48 but it ports less easily. Then version 14.10 is quite dated even by Debian's standards and I think a new upstream release (with lots of new go modules to be vendored or packaged) is needed here. This quite certainly is not an affair of just fixing the package but a larger effort. Any objections to removing the package from unstable? It already is not part of bookworm and trixie. Helmut
