Control: reassign -1 release.debian.org Control: user release.debian....@packages.debian.org Control: usertag transition Control: severity -1 normal
Dear Release Team, I am aware that right now we have a number of transitions going on right now https://release.debian.org/transitions/, however, none of them are obviously interfering with the transition I'm proposing below. Therefore it seems to me that now'ish might be a good time to start to give us enough time to deal with surprises. I have also not seen a response to my inquiry below in 10 days. I understand that at least some of you might be on vacation or traveling to Debcamp/Debconf. I am actively seeking your input, guidance, and ideally a simple "yes, the plan sounds agreeable and the risk is acceptable". In order to make this easier to track for you, I'm usertagging this bug and re-assigning this to "release.debian.org". I'm CC'ing the list of DDs who have agreed to help with triaging, fixing and uploading packages that are affected by this transition. I'm banking on the help of the whole golang team to assist with making this transition as smooth as humanly possible. I'd appreciate any kind of reply, ideally in the form of: "please hold of, here is a list of things we need to consider and/or look at first.". thank you so much for your assistance! -rt On Sat, Jul 13, 2024 at 6:53 PM Reinhard Tartler <siret...@gmail.com> 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 > > -- > regards, > Reinhard > -- regards, Reinhard
