Here's an update, one week into the transition: ~35 packages have been successfully uploaded to unstable, including containerd, docker.io, etcd, and libpod.
* siretart and zhsj have been working on containerd, packaging a few new dependencies and getting its autopkgtest passing again. * etcd needs some attention to its autopkgtests, I think zhsj might be looking into this * For some reason golang-google-genproto hasn't yet migrated into testing. I pinged the release team this morning to see if they can help figure out why. * golang-google-grpc needs some cleanup of DH_GOLANG_EXCLUDES in d/rules to properly exclude source files that can't compile due to other missing dependencies. (Probably can be done after this migration completes.) Getting etcd happy once again and a new upload of golang-google-grpc with an additional Breaks line should, I think, finally get a large chunk of the recently uploaded packages fully happy and able to migrate to testing. Mathias On Sat, 2024-07-13 at 12:53 -0400, Reinhard Tartler wrote: > Hi, > > We currently ship docker version 20.10 in Debian oldstable, stable and > currently testing. This is an EOL version that I really don't think Debian > trixie should be shipping with. > > I've been working over the last couple of weeks (months?) on updating > podman and docker to recent versions, including: > > docker.io -> 26.1 > containerd -> 1.7 > podman -> 5 > > All of these packages are built successfully in experimental and I have > received test reports that they appear to work fine. So let's get them into > unstable/testing! > > While doing so, I've encountered that those new versions really require > updated versions of golang-grpc and protobuf. I've been looking at that set > of packages last month, see the thread starting at [1]. The situation is > not pretty. > > My takeaway is that we need to update a large number of packages at the > same time, starting with src:golang-google-genproto > and src:golang-google-grpc. This will unblock a number of packages that are > currently in experimental, and will allow them to enter unstable. However, > this comes with the risk of breaking other packages. > > I've been chasing down the stack of dependency fairly far, but I feel I'm > reaching my capacity of how far I'm able to push this transition. I'm > therefore requesting help from the Debian release and golang teams. It is > simply not feasible for me to backtest that large amount of packages. I've > been going through that stack all the way to podman 5.0.3, and can tell > that it is feasible for us as a project. I'm asking for your expertise on > what's the best way to get this project through. > > I'd like to have these transitions coordinated so that we can minimize the > disruption for testing. Dear Release Team, please have a look at let me > know what you think. When would be a good time for me (or anyone else) to > start the transition? What kind of information would be useful for that > decision making? > > For your convenience, I believe the following listing is a good starting > set of packages to look at: > > siretart@x1:/ $ build-rdeps --distribution testing > golang-google-genproto-dev > Reverse Build-depends in testing/main: > -------------------------------------- > > caddy > cloudsql-proxy > containerd > crowdsec > crowdsec-custom-bouncer > crowdsec-firewall-bouncer > distrobuilder > docker-libkv > docker.io > etcd > fastnetmon > fever > gh > go-containerregistry > gobgp > golang-collectd > golang-entgo-ent > golang-github-anacrolix-dms > golang-github-anacrolix-ffprobe > golang-github-anacrolix-missinggo > golang-github-anacrolix-tagflag > golang-github-backblaze-blazer > golang-github-canonical-candid > golang-github-census-instrumentation-opencensus-proto > golang-github-checkpoint-restore-checkpointctl > golang-github-containerd-errdefs > golang-github-containerd-nri > golang-github-containerd-stargz-snapshotter > golang-github-containers-buildah > golang-github-containers-common > golang-github-containers-image > golang-github-containers-ocicrypt > golang-github-containers-psgo > golang-github-containers-storage > golang-github-crc-org-crc > golang-github-crowdsecurity-go-cs-bouncer > golang-github-docker-leadership > golang-github-expediadotcom-haystack-client-go > golang-github-francoispqt-gojay > golang-github-fsouza-go-dockerclient > golang-github-go-kit-kit > golang-github-gogo-status > golang-github-googleapis-gax-go > golang-github-googlecloudplatform-guest-logging-go > golang-github-grafana-grafana-plugin-model > golang-github-gravitational-trace > golang-github-grpc-ecosystem-go-grpc-middleware > golang-github-grpc-ecosystem-go-grpc-prometheus > golang-github-grpc-ecosystem-grpc-gateway > golang-github-grpc-ecosystem-grpc-opentracing > golang-github-hashicorp-go-discover > golang-github-hashicorp-go-getter > golang-github-hashicorp-go-plugin > golang-github-jacobsa-gcloud > golang-github-juju-persistent-cookiejar > golang-github-katalix-go-l2tp > golang-github-kubernetes-cri-api > golang-github-lightstep-lightstep-tracer-common > golang-github-lucas-clemente-quic-go > golang-github-mendersoftware-mender-artifact > golang-github-micromdm-scep > golang-github-mudler-docker-companion > golang-github-newrelic-go-agent > golang-github-openshift-imagebuilder > golang-github-opentracing-contrib-go-grpc > golang-github-openzipkin-zipkin-go > golang-github-optiopay-kafka > golang-github-samalba-dockerclient > golang-github-seandolphin-bqschema > golang-github-sercand-kuberesolver > golang-github-sigstore-fulcio > golang-github-sigstore-protobuf-specs > golang-github-sigstore-sigstore > golang-github-smallstep-certificates > golang-github-spiffe-go-spiffe > golang-github-sylabs-sif > golang-github-tonistiigi-fsutil > golang-github-uber-jaeger-lib > golang-github-viant-assertly > golang-github-viant-toolbox > golang-github-vulcand-oxy > golang-github-vulcand-predicate > golang-github-xenolf-lego > golang-github-xordataexchange-crypt > golang-gitlab-gitlab-org-labkit > golang-go.opencensus > golang-go.uber-zap > golang-go4 > golang-gocloud > golang-gogottrpc > golang-google-api > golang-google-cloud > golang-google-genproto > golang-google-grpc > golang-opentelemetry-contrib > golang-step-linkedca > golang-v2ray-core > google-guest-agent > hugo > ignition > in-toto-golang > incus > influxdb > libpod > lxd > mirrorbits > mtail > nextcloud-spreed-signaling > nncp > notary > oci-seccomp-bpf-hook > open-vm-tools > opensnitch > prometheus > prometheus-blackbox-exporter > prometheus-hacluster-exporter > prometheus-mqtt-exporter > prometheus-postfix-exporter > prometheus-sql-exporter > protobuild > rclone > receptor > rekor > restic > shoelaces > skeema > skopeo > stenographer > syncthing > trillian > victoriametrics > vip-manager > vip-manager2 > yggdrasil > > Found a total of 134 reverse build-depend(s) for golang-google-genproto-dev. > > Unfortunately, I won't be able to make it to Busan this year. It would be > amazing if these transitions could be discussed in person and a plan could > be devised that would end with trixie shipping a modern version of docker > and related packages. > > Thank you so much for your help and interest. > > [1] > https://lists.debian.org/debian-go/2024/06/msg00008.html >
signature.asc
Description: This is a digitally signed message part
