What do you think about this approach to get modern grpc into unstable? Here is grpc: https://tracker.debian.org/pkg/golang-google-grpc 1) Upload a new package golang-google-grpc-legacy identical to golang-google-grpc 1.38.0+really1.33.3-1 from unstable. 2) Wait for golang-google-grpc-legacy to clear NEW. 3) Upload new versions of all the packages that FTBFS with modern grpc (see list of ~10 packages in e-mail quoted below) to experimental, changing their Build-Depends from golang-google-grpc to golang-google-grpc-legacy. 4) Verify they packages all build fine, passes self-tests and seem to work, and then upload them to unstable. 5) Rebuild all remaining reverse dependencies of grpc using version 1.60 (or newer, I see 1.61 has been released while we are working on this..) to make sure they are building properly. 6) Upload grpc 1.60 to unstable. 7) Upload all packages that need grpc 1.60 currently stuck in experimental, into unstable. We can then work on resolving the problems in the FTBFS packages incrementally until they are all moved from golang-google-grpc-legacy to golang-google-grpc. Would this scheme work? I haven't thought it through or tested it, just came up as some frustration trying to fix the FTBFS packages... I'll try to take a look at some more of the FTBFS packages below, but my lack of Go knowledge is a limiting factor... /Simon Simon Josefsson <simon@josefsson.org> writes: > Simon Josefsson <simon@josefsson.org> writes: > >> Further progress on grpc. I've rebuilt 1.60.1 with some EXCLUDE fixes >> thanks to help on irc, we've gone from 22 reverse build failures down to >> 16 failures, here is the pipeline: >> >> https://salsa.debian.org/jas/golang-google-grpc/-/pipelines/629139 > > I did a review of the FTBFS reverse dependencies on grpc 1.60.1... > > We have 10 packages left to fix. > > We can ignore cadvisor, crowdsec, gitlab-ci-multi-runner due to > https://lists.debian.org/debian-go/2024/01/msg00128.html and > golang-github-katalix-go-l2tp due to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063746 > > Remaining failing packages below. Some have already been discussed. If > anyone wants to help, please take a package below and somwhow make it > build with modern grpc (and preferrably also with old grpc), and upload > that to experimental. Maybe some of the packages could be ignored if it > already FTBFS in unstable, I didn't look into that. > > etcd > https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191029 > > golang-github-go-kit-kit > https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191059 > > golang-github-hashicorp-go-plugin > https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191071 > > golang-github-sercand-kuberesolver > https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191090 > > golang-google-api > https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191108 > > nextcloud-spreed-signaling > https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191124 > > notary > https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191126 > > prometheus-blackbox-exporter > https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191131 > > receptor > https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191137 > probably not a problem due to grpc?! see > https://tracker.debian.org/pkg/receptor > > victoriametrics > https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191146 > > vip-manager2 > https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191148 > > /Simon >
Attachment:
signature.asc
Description: PGP signature