Re: RFS: golang-google-grpc + golang-github-google-s2a-go
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 writes: > Simon Josefsson 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 > signature.asc Description: PGP signature
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Jérémy Lal writes: > Le lun. 12 févr. 2024 à 22:11, Simon Josefsson a > écrit : > >> Jérémy Lal writes: >> >> > golang-github-grpc-ecosystem-go-grpc-prometheus should be deprecated in >> > debian as well, and replaced by >> > https://github.com/grpc-ecosystem/go-grpc-middleware >> > >> > First move is to report a RC-bug on that package, so it gets removed from >> > testing if no one steps in. >> > Second move is to start packaging go-grpc-middleware... >> >> Yes I noticed that upstream had moved on, and exploring >> go-grpc-middleware seems like the right thing to do. That means fixing >> (or deprecating) all the reverse dependencies of >> golang-github-grpc-ecosystem-go-grpc-prometheus to use >> go-grpc-middleware instead... and how to handle if some of the reverse >> dependencies cannot easily be fixed or deprecated? That could stall the >> effort. >> > > Not sure there are much of them > build-rdeps golang-github-grpc-ecosystem-go-grpc-prometheus > didn't return anything but I'm not sure it works on my system. Try installing 'dose-extra' for more complete output from build-rdeps, it is misleading otherwise. The list of rdeps below is based on build-rdeps with dose-extra: https://salsa.debian.org/jas/golang-github-grpc-ecosystem-go-grpc-prometheus/-/pipelines/638083 You can confirm using the official buildd logs, for example see podman build log that installs golang-github-grpc-ecosystem-go-grpc-prometheus: https://buildd.debian.org/status/fetch.php?pkg=libpod=amd64=4.9.2%2Bds1-2=1707306847=0 /Simon signature.asc Description: PGP signature
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Le lun. 12 févr. 2024 à 22:11, Simon Josefsson a écrit : > Jérémy Lal writes: > > > golang-github-grpc-ecosystem-go-grpc-prometheus should be deprecated in > > debian as well, and replaced by > > https://github.com/grpc-ecosystem/go-grpc-middleware > > > > First move is to report a RC-bug on that package, so it gets removed from > > testing if no one steps in. > > Second move is to start packaging go-grpc-middleware... > > Yes I noticed that upstream had moved on, and exploring > go-grpc-middleware seems like the right thing to do. That means fixing > (or deprecating) all the reverse dependencies of > golang-github-grpc-ecosystem-go-grpc-prometheus to use > go-grpc-middleware instead... and how to handle if some of the reverse > dependencies cannot easily be fixed or deprecated? That could stall the > effort. > Not sure there are much of them build-rdeps golang-github-grpc-ecosystem-go-grpc-prometheus didn't return anything but I'm not sure it works on my system.
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Jérémy Lal writes: > golang-github-grpc-ecosystem-go-grpc-prometheus should be deprecated in > debian as well, and replaced by > https://github.com/grpc-ecosystem/go-grpc-middleware > > First move is to report a RC-bug on that package, so it gets removed from > testing if no one steps in. > Second move is to start packaging go-grpc-middleware... Yes I noticed that upstream had moved on, and exploring go-grpc-middleware seems like the right thing to do. That means fixing (or deprecating) all the reverse dependencies of golang-github-grpc-ecosystem-go-grpc-prometheus to use go-grpc-middleware instead... and how to handle if some of the reverse dependencies cannot easily be fixed or deprecated? That could stall the effort. I think your plan could happen in parallel with my effort to get modern grpc into unstable by fixing the reverse dependencies in the most simple way possible. The plans don't necessarily conflict. /Simon signature.asc Description: PGP signature
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Simon Josefsson 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 signature.asc Description: PGP signature
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Hello Le lun. 12 févr. 2024 à 21:49, Simon Josefsson a écrit : > Simon Josefsson 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 > > Getting grpc into unstable is going to be some work... > > Today I worked on one of the failures above: > golang-github-grpc-ecosystem-go-grpc-prometheus. With new grpc it fail > like this: > > https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191066 > > === RUN TestNativeErrorUnwrapping > grpcstatus1.13+_test.go:24: > ... > - Message: (string) (len=16) "Userspace > error.", > + Message: (string) (len=85) "go native > wrapped error: rpc error: code = FailedPrecondition desc = Userspace > error.", > > Building the version we have in unstable including reverse dependencies: > > > https://salsa.debian.org/jas/golang-github-grpc-ecosystem-go-grpc-prometheus/-/pipelines/638044 > > All good -- ignoring failures in 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 > > Lacking a better fix, I patched out the failing self-test since it seems > related to error message string mismatches, and I lack the Go skills to > come up with a better fix. Upstream seems gone, the project is > archived, so I didn't file a upstream bug report. I fixed some other > small packaging nits too. Changes here: > golang-github-grpc-ecosystem-go-grpc-prometheus should be deprecated in debian as well, and replaced by https://github.com/grpc-ecosystem/go-grpc-middleware First move is to report a RC-bug on that package, so it gets removed from testing if no one steps in. Second move is to start packaging go-grpc-middleware... Jérémy
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Simon Josefsson 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 Getting grpc into unstable is going to be some work... Today I worked on one of the failures above: golang-github-grpc-ecosystem-go-grpc-prometheus. With new grpc it fail like this: https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191066 === RUN TestNativeErrorUnwrapping grpcstatus1.13+_test.go:24: ... - Message: (string) (len=16) "Userspace error.", + Message: (string) (len=85) "go native wrapped error: rpc error: code = FailedPrecondition desc = Userspace error.", Building the version we have in unstable including reverse dependencies: https://salsa.debian.org/jas/golang-github-grpc-ecosystem-go-grpc-prometheus/-/pipelines/638044 All good -- ignoring failures in 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 Lacking a better fix, I patched out the failing self-test since it seems related to error message string mismatches, and I lack the Go skills to come up with a better fix. Upstream seems gone, the project is archived, so I didn't file a upstream bug report. I fixed some other small packaging nits too. Changes here: https://salsa.debian.org/go-team/packages/golang-github-grpc-ecosystem-go-grpc-prometheus/-/compare/debian%2F1.2.0+git20191002.6af20e3-3...debian%2F1.2.0+git20191002.6af20e3-4?from_project_id=20089=false I built locally against grpc 1.60.1-2 without problems. Build of the new version (except for a tiny fix to d/watch) including reverse dependencies: https://salsa.debian.org/jas/golang-github-grpc-ecosystem-go-grpc-prometheus/-/pipelines/638083 I did not make golang-github-grpc-ecosystem-go-grpc-prometheus require grpc >= 1.60 since the package works fine with old grpc too. This decision enable quicker upload into unstable: no need to wait for new grpc to enter unstable. I have uploaded to experimental, so please test golang-github-grpc-ecosystem-go-grpc-prometheus now! Especially if you have a ratt setup. If there hasn't been feedback in a week, I suggest to upload this to unstable. /Simon signature.asc Description: PGP signature
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Hi Simon, On Tue, 2024-01-23 at 18:01 +0100, Simon Josefsson wrote: > Thank you -- I have uploaded s2a to experimental. Thanks for the upload. > Trying to build > golang-google-api 0.157.0 fails with error below - are these > dependencies important? FYI, M Hickford is working on updating golang-google- api, and has added blockers to #1059087 corresponding to the dependencies that need updating. I'll try to update those packages to get this moving along. > src/google.golang.org/api/internal/cert/enterprise_cert.go:19:2: cannot find > package "github.com/googleapis/enterprise-certificate-proxy/client" in any of: > > /usr/lib/go-1.21/src/github.com/googleapis/enterprise-certificate-proxy/client > (from $GOROOT) > > /build/golang-google-api-0.157.0/obj-x86_64-linux-gnu/src/github.com/googleapis/enterprise-certificate-proxy/client > (from $GOPATH) Anything that uses github.com/googleapis/enterprise-certificate-proxy needs to be excluded (as has been done in golang-google-grpc), as it adds unneeded complexity and isn't necessary. > src/google.golang.org/api/internal/gensupport/error.go:10:2: cannot find > package "github.com/googleapis/gax-go/v2/apierror" in any of: > /usr/lib/go-1.21/src/github.com/googleapis/gax-go/v2/apierror (from > $GOROOT) > > /build/golang-google-api-0.157.0/obj-x86_64-linux-gnu/src/github.com/googleapis/gax-go/v2/apierror > (from $GOPATH) > src/google.golang.org/api/internal/gensupport/send.go:18:2: cannot find > package "github.com/googleapis/gax-go/v2/callctx" in any of: > /usr/lib/go-1.21/src/github.com/googleapis/gax-go/v2/callctx (from > $GOROOT) golang-github-googleapis-gax-go is outdated (#1059570). > > /build/golang-google-api-0.157.0/obj-x86_64-linux-gnu/src/github.com/googleapis/gax-go/v2/callctx > (from $GOPATH) > src/google.golang.org/api/transport/http/dial.go:19:2: cannot find package > "go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp" in any of: > > /usr/lib/go-1.21/src/go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp > (from $GOROOT) > > /build/golang-google-api-0.157.0/obj-x86_64-linux-gnu/src/go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp > (from $GOPATH) > src/google.golang.org/api/internal/kokoro/discogen/main.go:20:2: cannot find > package "github.com/google/go-github/v52/github" in any of: > /usr/lib/go-1.21/src/github.com/google/go-github/v52/github (from > $GOROOT) > > /build/golang-google-api-0.157.0/obj-x86_64-linux-gnu/src/github.com/google/go-github/v52/github > (from $GOPATH) golang-github-google-go-github is outdated. > src/google.golang.org/api/transport/grpc/dial.go:22:2: cannot find package > "go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc" > in any of: > > /usr/lib/go-1.21/src/go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc > (from $GOROOT) > > /build/golang-google-api-0.157.0/obj-x86_64-linux-gnu/src/go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc > (from $GOPATH) golang-opentelemetry-contrib is outdated, and is only present in experimental (#1059573) > > > Error outputs below, is anyone familiar with any of these packages or > > > error messages? Several packages have new upstream versions that may > > > fix these problems. > > > > With cadvisor, debian/vendor is not required anymore as all of it's contents > > exist as Debian packages now, so it needs to be removed and replaced with > > additions to Build-Depends. This should fix the build and allow it to build > > successfully (unless there are API changes between the older versions in > > d/vendor and the packaged versions in Debian, then the new version of > > cadvisor > > will need to be packaged). > > > > The rest of the failing rdeps are likely due to outdated packages, as you've > > said. > > I'll take a look when time permits. Lots of dependencies, and it seems > they all lead to each other in a twisty maze... I'll also have a look when I can and start contacting maintainers. Kind regards, Maytham signature.asc Description: This is a digitally signed message part
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
On Tue, Jan 23, 2024 at 18:05:23 +0100, Simon Josefsson wrote: > Tom Parkin writes: > > > Hi Simon, > > > > On Mon, Jan 22, 2024 at 20:15:11 +0100, Simon Josefsson wrote: > >> golang-github-katalix-go-l2tp > >> https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191076 > >> === RUN TestBasicSendReceive/5:_send/recv_[::1]:9000_[::1]:9001_L2TPv3_IP > >> level=info function=transport message=retransmit > >> message_type=avpMsgTypeHello > >> level=info function=transport message=retransmit > >> message_type=avpMsgTypeHello > >> level=info function=transport message=retransmit > >> message_type=avpMsgTypeHello > >> level=error function=transport message="socket read failed" > >> error="resource temporarily unavailable" > >> level=error function=transport message="transport down" error="transmit of > >> avpMsgTypeHello failed after 3 retry attempts" > >> transport_test.go:388: test sender function reported an error: > >> failed to send Hello message: transmit of avpMsgTypeHello failed > >> after 3 retry attempts > >> panic: test timed out after 10m0s > > > > This test is failing to send a packet over an IPv6 L2TPIP socket: it > > will depend on the go runtime support for L2TPIP (which has been in > > for ages), and also the kernel having the l2tp_ipv6 driver loaded. > > > > I'd sort of expect to see messages along those lines when trying to > > open the socket, though, rather than tx/rx failing :-/ > > > > I'm not at all familiar with the environment of the Salsa test > > pipeline -- could you expand on what the configuration is here? > > Thanks for looking at the logs Tom. I don't really know much about the > environment except for these pointers: > > https://wiki.debian.org/Salsa/Doc#Runners > https://salsa.debian.org/salsa-ci-team/pipeline/ > > Does it setup a server on ::1 properly? Any outbound connections? Only > http(s) is allowed. So I *think* the runtime env is a VM using the "Google Container-Optimized OS". The fact that the socket opens successfully but the packet is apparently lost is suggestive of some kind of firewalling. I'll see if I can figure anything out from the Google docs. The tests work OK when run manually and when run as part of the package build here, so I think it must be something specific to the pipeline VM but I'm not sure what at the moment. In terms of the test configuration, it basically opens a socket for each end of the connection and verifies it can send/receive over those sockets. It's the same test code for each configuration. signature.asc Description: PGP signature
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Tom Parkin writes: > Hi Simon, > > On Mon, Jan 22, 2024 at 20:15:11 +0100, Simon Josefsson wrote: >> golang-github-katalix-go-l2tp >> https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191076 >> === RUN TestBasicSendReceive/5:_send/recv_[::1]:9000_[::1]:9001_L2TPv3_IP >> level=info function=transport message=retransmit message_type=avpMsgTypeHello >> level=info function=transport message=retransmit message_type=avpMsgTypeHello >> level=info function=transport message=retransmit message_type=avpMsgTypeHello >> level=error function=transport message="socket read failed" error="resource >> temporarily unavailable" >> level=error function=transport message="transport down" error="transmit of >> avpMsgTypeHello failed after 3 retry attempts" >> transport_test.go:388: test sender function reported an error: >> failed to send Hello message: transmit of avpMsgTypeHello failed >> after 3 retry attempts >> panic: test timed out after 10m0s > > This test is failing to send a packet over an IPv6 L2TPIP socket: it > will depend on the go runtime support for L2TPIP (which has been in > for ages), and also the kernel having the l2tp_ipv6 driver loaded. > > I'd sort of expect to see messages along those lines when trying to > open the socket, though, rather than tx/rx failing :-/ > > I'm not at all familiar with the environment of the Salsa test > pipeline -- could you expand on what the configuration is here? Thanks for looking at the logs Tom. I don't really know much about the environment except for these pointers: https://wiki.debian.org/Salsa/Doc#Runners https://salsa.debian.org/salsa-ci-team/pipeline/ Does it setup a server on ::1 properly? Any outbound connections? Only http(s) is allowed. /Simon signature.asc Description: PGP signature
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Maytham Alsudany writes: >> https://salsa.debian.org/jas/golang-google-grpc/-/pipelines/629139 >> >> The failures now suggest problems on other packages, list of initial 10 >> broken packages that I looked at: >> >> cadvisor: >> crowdsec: >> etcd: >> gitlab-ci-multi-runner: >> golang-github-go-kit-kit: >> golang-github-grpc-ecosystem-go-grpc-prometheus: >> golang-github-hashicorp-go-plugin >> golang-github-katalix-go-l2tp >> golang-github-sercand-kuberesolver >> golang-google-api > > golang-google-api is outdated (#1061362) and needs an updated package, but > golang-google-grpc and golang-github-google-s2a-go are blockers to getting it > updated. > > Could you please have a look at golang-github-google-s2a-go and see if you can > upload it to experimental as well? Thank you -- I have uploaded s2a to experimental. Trying to build golang-google-api 0.157.0 fails with error below - are these dependencies important? src/google.golang.org/api/internal/cert/enterprise_cert.go:19:2: cannot find package "github.com/googleapis/enterprise-certificate-proxy/client" in any of: /usr/lib/go-1.21/src/github.com/googleapis/enterprise-certificate-proxy/client (from $GOROOT) /build/golang-google-api-0.157.0/obj-x86_64-linux-gnu/src/github.com/googleapis/enterprise-certificate-proxy/client (from $GOPATH) src/google.golang.org/api/internal/gensupport/error.go:10:2: cannot find package "github.com/googleapis/gax-go/v2/apierror" in any of: /usr/lib/go-1.21/src/github.com/googleapis/gax-go/v2/apierror (from $GOROOT) /build/golang-google-api-0.157.0/obj-x86_64-linux-gnu/src/github.com/googleapis/gax-go/v2/apierror (from $GOPATH) src/google.golang.org/api/internal/gensupport/send.go:18:2: cannot find package "github.com/googleapis/gax-go/v2/callctx" in any of: /usr/lib/go-1.21/src/github.com/googleapis/gax-go/v2/callctx (from $GOROOT) /build/golang-google-api-0.157.0/obj-x86_64-linux-gnu/src/github.com/googleapis/gax-go/v2/callctx (from $GOPATH) src/google.golang.org/api/transport/http/dial.go:19:2: cannot find package "go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp" in any of: /usr/lib/go-1.21/src/go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp (from $GOROOT) /build/golang-google-api-0.157.0/obj-x86_64-linux-gnu/src/go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp (from $GOPATH) src/google.golang.org/api/internal/kokoro/discogen/main.go:20:2: cannot find package "github.com/google/go-github/v52/github" in any of: /usr/lib/go-1.21/src/github.com/google/go-github/v52/github (from $GOROOT) /build/golang-google-api-0.157.0/obj-x86_64-linux-gnu/src/github.com/google/go-github/v52/github (from $GOPATH) src/google.golang.org/api/transport/grpc/dial.go:22:2: cannot find package "go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc" in any of: /usr/lib/go-1.21/src/go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc (from $GOROOT) /build/golang-google-api-0.157.0/obj-x86_64-linux-gnu/src/go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc (from $GOPATH) >> Error outputs below, is anyone familiar with any of these packages or >> error messages? Several packages have new upstream versions that may >> fix these problems. > > With cadvisor, debian/vendor is not required anymore as all of it's contents > exist as Debian packages now, so it needs to be removed and replaced with > additions to Build-Depends. This should fix the build and allow it to build > successfully (unless there are API changes between the older versions in > d/vendor and the packaged versions in Debian, then the new version of cadvisor > will need to be packaged). > > The rest of the failing rdeps are likely due to outdated packages, as you've > said. I'll take a look when time permits. Lots of dependencies, and it seems they all lead to each other in a twisty maze... /Simon signature.asc Description: PGP signature
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Hi Simon, On Mon, Jan 22, 2024 at 20:15:11 +0100, Simon Josefsson wrote: > golang-github-katalix-go-l2tp > https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191076 > === RUN TestBasicSendReceive/5:_send/recv_[::1]:9000_[::1]:9001_L2TPv3_IP > level=info function=transport message=retransmit message_type=avpMsgTypeHello > level=info function=transport message=retransmit message_type=avpMsgTypeHello > level=info function=transport message=retransmit message_type=avpMsgTypeHello > level=error function=transport message="socket read failed" error="resource > temporarily unavailable" > level=error function=transport message="transport down" error="transmit of > avpMsgTypeHello failed after 3 retry attempts" > transport_test.go:388: test sender function reported an error: failed to > send Hello message: transmit of avpMsgTypeHello failed after 3 retry attempts > panic: test timed out after 10m0s This test is failing to send a packet over an IPv6 L2TPIP socket: it will depend on the go runtime support for L2TPIP (which has been in for ages), and also the kernel having the l2tp_ipv6 driver loaded. I'd sort of expect to see messages along those lines when trying to open the socket, though, rather than tx/rx failing :-/ I'm not at all familiar with the environment of the Salsa test pipeline -- could you expand on what the configuration is here? Thanks, Tom signature.asc Description: PGP signature
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Hi Simon, On Mon, 2024-01-22 at 20:15 +0100, Simon Josefsson wrote: > 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 > > The failures now suggest problems on other packages, list of initial 10 > broken packages that I looked at: > > cadvisor: > crowdsec: > etcd: > gitlab-ci-multi-runner: > golang-github-go-kit-kit: > golang-github-grpc-ecosystem-go-grpc-prometheus: > golang-github-hashicorp-go-plugin > golang-github-katalix-go-l2tp > golang-github-sercand-kuberesolver > golang-google-api golang-google-api is outdated (#1061362) and needs an updated package, but golang-google-grpc and golang-github-google-s2a-go are blockers to getting it updated. Could you please have a look at golang-github-google-s2a-go and see if you can upload it to experimental as well? > Error outputs below, is anyone familiar with any of these packages or > error messages? Several packages have new upstream versions that may > fix these problems. With cadvisor, debian/vendor is not required anymore as all of it's contents exist as Debian packages now, so it needs to be removed and replaced with additions to Build-Depends. This should fix the build and allow it to build successfully (unless there are API changes between the older versions in d/vendor and the packaged versions in Debian, then the new version of cadvisor will need to be packaged). The rest of the failing rdeps are likely due to outdated packages, as you've said. Kind regards, Maytham IRC: maytha8 signature.asc Description: This is a digitally signed message part
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
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
The failures now suggest problems on other packages, list of initial 10
broken packages that I looked at:
cadvisor:
crowdsec:
etcd:
gitlab-ci-multi-runner:
golang-github-go-kit-kit:
golang-github-grpc-ecosystem-go-grpc-prometheus:
golang-github-hashicorp-go-plugin
golang-github-katalix-go-l2tp
golang-github-sercand-kuberesolver
golang-google-api
Error outputs below, is anyone familiar with any of these packages or
error messages? Several packages have new upstream versions that may
fix these problems.
/Simon
cadvisor:
https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191020
github.com/google/cadvisor/vendor/k8s.io/klog/v2
# github.com/google/cadvisor/vendor/k8s.io/klog/v2
src/github.com/google/cadvisor/vendor/k8s.io/klog/v2/klog.go:694:13: invalid
operation: logr != nil (mismatched types logr.Logger and untyped nil)
src/github.com/google/cadvisor/vendor/k8s.io/klog/v2/klog.go:710:13: invalid
operation: logr != nil (mismatched types logr.Logger and untyped nil)
...
crowdsec:
https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191024
=== RUN TestStreamingAcquisition/privileged_port
time="2024-01-22T18:42:03Z" level=info msg="Starting syslog datasource
configuration" type=syslog
syslog_test.go:146:
Error Trace:
/builds/jas/golang-google-grpc/debian/output/crowdsec-1.4.6/_build/src/github.com/crowdsecurity/crowdsec/pkg/cstest/utils.go:14
/builds/jas/golang-google-grpc/debian/output/crowdsec-1.4.6/_build/src/github.com/crowdsecurity/crowdsec/pkg/acquisition/modules/syslog/syslog_test.go:146
Error: An error is expected but got nil.
Test: TestStreamingAcquisition/privileged_port
--- FAIL: TestStreamingAcquisition (6.03s)
--- PASS: TestStreamingAcquisition/invalid_msgs (2.01s)
--- PASS: TestStreamingAcquisition/RFC5424 (2.01s)
--- PASS: TestStreamingAcquisition/RFC3164 (2.01s)
--- FAIL: TestStreamingAcquisition/privileged_port (0.00s)
FAIL
FAILgithub.com/crowdsecurity/crowdsec/pkg/acquisition/modules/syslog
6.041s
=== RUN TestPri
etcd:
https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191029
go.etcd.io/etcd/clientv3/balancer/resolver/endpoint
# go.etcd.io/etcd/clientv3/balancer/resolver/endpoint
src/go.etcd.io/etcd/clientv3/balancer/resolver/endpoint/endpoint.go:115:16:
target.Authority undefined (type resolver.Target has no field or method
Authority)
src/go.etcd.io/etcd/clientv3/balancer/resolver/endpoint/endpoint.go:118:15:
target.Authority undefined (type resolver.Target has no field or method
Authority)
gitlab-ci-multi-runner:
https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191033
gitlab.com/gitlab-org/gitlab-runner/commands/helpers
# gitlab.com/gitlab-org/gitlab-runner/commands/helpers
src/gitlab.com/gitlab-org/gitlab-runner/commands/helpers/file_archiver.go:134:35:
not enough arguments in call to doublestar.Glob
have (string)
want ("io/fs".FS, string, ...doublestar.GlobOption)
gitlab.com/gitlab-org/gitlab-runner/vendor/k8s.io/apimachinery/pkg/runtime/serializer/recognizer
golang-github-go-kit-kit:
https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191059
go.etcd.io/etcd/clientv3/balancer/picker
# go.etcd.io/etcd/clientv3/balancer/picker
src/go.etcd.io/etcd/clientv3/balancer/picker/roundrobin_balanced.go:93:41: too
few values in struct literal of type balancer.PickResult
google.golang.org/grpc/resolver/passthrough
golang-github-grpc-ecosystem-go-grpc-prometheus:
https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191066
=== RUN TestNativeErrorUnwrapping
grpcstatus1.13+_test.go:24:
Error Trace:
/builds/jas/golang-google-grpc/debian/output/golang-github-grpc-ecosystem-go-grpc-prometheus-1.2.0+git20191002.6af20e3/build_/src/github.com/grpc-ecosystem/go-grpc-prometheus/packages/grpcstatus/grpcstatus1.13+_test.go:24
Error: Not equal:
expected:
{s:(*status.Status)(0xc163c0)}
actual :
{s:(*status.Status)(0xc165a0)}
Diff:
--- Expected
+++ Actual
@@ -3,3 +3,3 @@
Code: (int32) 9,
- Message: (string) (len=16) "Userspace
error.",
+ Message: (string) (len=85) "go native
wrapped error: rpc error: code = FailedPrecondition desc = Userspace error.",
Details: ([]*any.Any) ,
Test: TestNativeErrorUnwrapping
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Simon Josefsson writes: > It seems clear that grpc cannot go to unstable right now due to reverse > dependency build failures: > > https://salsa.debian.org/jas/golang-google-grpc/-/pipelines/627711 I took a look at some of these failures. For example, golang-github-mendersoftware-mender-artifact fails with grpc 1.59: https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5175835 google.golang.org/grpc/credentials/alts/internal/proto/grpc_gcp # google.golang.org/grpc/credentials/alts/internal/proto/grpc_gcp src/google.golang.org/grpc/credentials/alts/internal/proto/grpc_gcp/altscontext.pb.go:50:16: undefined: SecurityLevel src/google.golang.org/grpc/credentials/alts/internal/proto/grpc_gcp/altscontext.pb.go:56:19: undefined: RpcProtocolVersions src/google.golang.org/grpc/credentials/alts/internal/proto/grpc_gcp/altscontext.pb.go:107:42: undefined: SecurityLevel src/google.golang.org/grpc/credentials/alts/internal/proto/grpc_gcp/altscontext.pb.go:128:45: undefined: RpcProtocolVersions src/google.golang.org/grpc/credentials/alts/internal/proto/grpc_gcp/altscontext.pb.go:207:3: undefined: SecurityLevel src/google.golang.org/grpc/credentials/alts/internal/proto/grpc_gcp/altscontext.pb.go:208:4: undefined: RpcProtocolVersions src/google.golang.org/grpc/credentials/alts/internal/proto/grpc_gcp/handshaker.pb.go:331:15: undefined: RpcProtocolVersions src/google.golang.org/grpc/credentials/alts/internal/proto/grpc_gcp/handshaker.pb.go:424:53: undefined: RpcProtocolVersions src/google.golang.org/grpc/credentials/alts/internal/proto/grpc_gcp/handshaker.pb.go:521:15: undefined: RpcProtocolVersions src/google.golang.org/grpc/credentials/alts/internal/proto/grpc_gcp/handshaker.pb.go:788:19: undefined: RpcProtocolVersions src/google.golang.org/grpc/credentials/alts/internal/proto/grpc_gcp/handshaker.pb.go:424:53: too many errors google.golang.org/grpc/credentials/alts/internal/conn Similarily golang-gocloud fails in a the same way: https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5175861 Same for golang-google-api: https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5175863 I think that some other package than grpc may be too old too, but haven't been able to locate it. Maybe something proto related? I've tried searching for these text strings. Does anyone have ideas? /Simon Btw, I am now subscribed to the debian-go list and cc's aren't necessary. If you want me to stop sending direct e-mails let me know =) signature.asc Description: PGP signature
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Shengjing Zhu writes: > For safety, yes please upload to experimental, and people can try > rebuilding their packages and test them. I have uploaded grpc 1.59.0 to experimental, to allow build testing of reverse dependencies. Rekor needs grpc via in-toto via spiffe, and looks like it may need newer than 1.59.0 so I've pushed 1.60.1 to git but will wait with an upload until after the 1.59.0 builds have stabilized in experimental. At least 1.60.1 builds fine on Salsa: https://salsa.debian.org/jas/golang-google-grpc/-/pipelines/627701 https://salsa.debian.org/go-team/packages/golang-google-grpc/-/pipelines/627707 It seems clear that grpc cannot go to unstable right now due to reverse dependency build failures: https://salsa.debian.org/jas/golang-google-grpc/-/pipelines/627711 It isn't 100% certain that all those build failures are because of the newer grpc: it could be that the other packages stopped building for other reasons. We can do a similar pipeline for 1.38.0 but it is wasteful of resources unless somebody will look at logs and compare them. My focus is getting rekor into experimental, after that I can return to getting grpc into unstable somehow. /Simon signature.asc Description: PGP signature
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Hi. What is the status of golang-google-grpc? My packaging effort of sigstore's rekor needs golang-google-grpc 1.53 according to github.com/spiffe/go-spiffe and fails with errors below. I have built golang-google-grpc from debian/experimental and the packages works fine for spiffe. When can a modern golang-google-grpc enter Debian unstable? /Simon src/github.com/spiffe/go-spiffe/v2/workloadapi/client.go:20:2: cannot find package "google.golang.org/grpc/credentials/insecure" in any of: /usr/lib/go-1.21/src/google.golang.org/grpc/credentials/insecure (from $GOROOT) /build/golang-github-spiffe-go-spiffe-2.1.6/_build/src/google.golang.org/grpc/credentials/insecure (from $GOPATH) src/github.com/spiffe/go-spiffe/v2/examples/spiffe-grpc/client/main.go:13:2: cannot find package "google.golang.org/grpc/examples/helloworld/helloworld" in any of: /usr/lib/go-1.21/src/google.golang.org/grpc/examples/helloworld/helloworld (from $GOROOT) /build/golang-github-spiffe-go-spiffe-2.1.6/_build/src/google.golang.org/grpc/examples/helloworld/helloworld (from $GOPATH) signature.asc Description: PGP signature
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Hi Nilesh, On Thu, 2023-12-28 at 18:38 +0530, Nilesh Patra wrote: > On Wed, Dec 27, 2023 at 06:36:48AM +0800, Maytham Alsudany wrote: > > > Updates of gRPC can usually never go to unstable directly. IMHO you > > > probably should've pushed to d/experimental > > > branch instead. > > > > My mistake, wrong branch! > > Can you please push your changes to experimental branch and rebase+remove > your commits (and only *your* commits) > from unstable? Done! Kind regards, Maytham signature.asc Description: This is a digitally signed message part
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
On Wed, Dec 27, 2023 at 06:36:48AM +0800, Maytham Alsudany wrote: > > Updates of gRPC can usually never go to unstable directly. IMHO you > > probably should've pushed to d/experimental > > branch instead. > > My mistake, wrong branch! Can you please push your changes to experimental branch and rebase+remove your commits (and only *your* commits) from unstable? You should have the according permissions. > > > > [1]: https://tracker.debian.org/pkg/ratt > > > > [2]: https://salsa.debian.org/ruby-team/meta > > Kind regards, > Maytham Best, Nilesh signature.asc Description: PGP signature
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Hi Nilesh, On Tue, 2023-12-26 at 21:54 +0530, Nilesh Patra wrote: > On 12/24/2023 7:29 AM IST Maytham Alsudany wrote: > > > This is a package with a lot of (important) reverse-dependencies and this > > > is a minor > > > version (assuming they comply with semver.org) bump. > > > Have you verified that it does not cause any regressions in the > > > reverse-deps > > > with ratt[1] or ruby-team/meta[2]? > > > > I haven't yet, but hopefully I can leave rutt to build the 127 reverse > > B-Deps. > > I've changed d/control to Depend on either 1-3 or 1-5 of > > golang-github-golang- > > protobuf (to resolve conflicts with golang-goprotobuf). > > Do you need golang-github-google-s2a-go as a dependency for any other package? It's blocking updates to golang-google-api and golang-google-cloud. > > I know that grpc is a pretty important package, so should > > golang-google-grpc and > > golang-github-google-s2a-go be uploaded to experimental instead of unstable? > > Then, I can go through any packages that FTBFS or fail autopkgtest and > > ensure > > nothing is broken. > > Updates of gRPC can usually never go to unstable directly. IMHO you probably > should've pushed to d/experimental > branch instead. My mistake, wrong branch! > > > [1]: https://tracker.debian.org/pkg/ratt > > > [2]: https://salsa.debian.org/ruby-team/meta Kind regards, Maytham signature.asc Description: This is a digitally signed message part
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
On 12/24/2023 7:29 AM IST Maytham Alsudany wrote: > > This is a package with a lot of (important) reverse-dependencies and this > > is a minor > > version (assuming they comply with semver.org) bump. > > Have you verified that it does not cause any regressions in the reverse-deps > > with ratt[1] or ruby-team/meta[2]? > > I haven't yet, but hopefully I can leave rutt to build the 127 reverse B-Deps. > I've changed d/control to Depend on either 1-3 or 1-5 of golang-github-golang- > protobuf (to resolve conflicts with golang-goprotobuf). Do you need golang-github-google-s2a-go as a dependency for any other package? > I know that grpc is a pretty important package, so should golang-google-grpc > and > golang-github-google-s2a-go be uploaded to experimental instead of unstable? > Then, I can go through any packages that FTBFS or fail autopkgtest and ensure > nothing is broken. Updates of gRPC can usually never go to unstable directly. IMHO you probably should've pushed to d/experimental branch instead. > > [1]: https://tracker.debian.org/pkg/ratt > > [2]: https://salsa.debian.org/ruby-team/meta Best, Nilesh
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
On Mon, Dec 25, 2023 at 1:56 PM Nilesh Patra wrote: > > On Mon, Dec 25, 2023 at 07:56:23AM +0800, Maytham Alsudany wrote: > > Hi Nilesh, > > > This is a package with a lot of (important) reverse-dependencies and this > > > is a minor > > > version (assuming they comply with semver.org) bump. > > > Have you verified that it does not cause any regressions in the > > > reverse-deps > > > with ratt[1] or ruby-team/meta[2]? > > > > > > [1]: https://tracker.debian.org/pkg/ratt > > > [2]: https://salsa.debian.org/ruby-team/meta > > > > > > I've run ratt on golang-google-grpc, and 22 packages fail to build out of > > 127. > > I'll go through and try to update and/or fix the failing packages. > > > > Does this call for a migration, since it affects a lot of packages? > > If I am not wrong, the situation is (far) more complicated than just this, > sorry I missed > highlighting this earlier. > IIRC, there was some discussion a while back that just running ratt isn't > enough (even for experimental) > and that grpc may break things at run-time as well. It also had some > entanglement with the protobuf > package. > grpc-go itself shouldn't be a problem, but IIRC the new version requires some packages that need to use new protobuf implementation at runtime, which would cause problems for packages using both old protobuf and grpc-go. For safety, yes please upload to experimental, and people can try rebuilding their packages and test them. > I realise I'm speaking at a very surface level so I am adding in Shengjing > (zhsj) to the > thread and recluse myself from any uploads for this package meanwhile. > > Best, > Nilesh -- Shengjing Zhu
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
On Mon, Dec 25, 2023 at 07:56:23AM +0800, Maytham Alsudany wrote: > Hi Nilesh, > > This is a package with a lot of (important) reverse-dependencies and this > > is a minor > > version (assuming they comply with semver.org) bump. > > Have you verified that it does not cause any regressions in the reverse-deps > > with ratt[1] or ruby-team/meta[2]? > > > > [1]: https://tracker.debian.org/pkg/ratt > > [2]: https://salsa.debian.org/ruby-team/meta > > > I've run ratt on golang-google-grpc, and 22 packages fail to build out of 127. > I'll go through and try to update and/or fix the failing packages. > > Does this call for a migration, since it affects a lot of packages? If I am not wrong, the situation is (far) more complicated than just this, sorry I missed highlighting this earlier. IIRC, there was some discussion a while back that just running ratt isn't enough (even for experimental) and that grpc may break things at run-time as well. It also had some entanglement with the protobuf package. I realise I'm speaking at a very surface level so I am adding in Shengjing (zhsj) to the thread and recluse myself from any uploads for this package meanwhile. Best, Nilesh signature.asc Description: PGP signature
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Hi Nilesh, > This is a package with a lot of (important) reverse-dependencies and this is > a minor > version (assuming they comply with semver.org) bump. > Have you verified that it does not cause any regressions in the reverse-deps > with ratt[1] or ruby-team/meta[2]? > > [1]: https://tracker.debian.org/pkg/ratt > [2]: https://salsa.debian.org/ruby-team/meta I've run ratt on golang-google-grpc, and 22 packages fail to build out of 127. I'll go through and try to update and/or fix the failing packages. Does this call for a migration, since it affects a lot of packages? Kind regards, Maytham signature.asc Description: This is a digitally signed message part
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
Hi Nilesh, > This is a package with a lot of (important) reverse-dependencies and this is > a minor > version (assuming they comply with semver.org) bump. > Have you verified that it does not cause any regressions in the reverse-deps > with ratt[1] or ruby-team/meta[2]? I haven't yet, but hopefully I can leave rutt to build the 127 reverse B-Deps. I've changed d/control to Depend on either 1-3 or 1-5 of golang-github-golang- protobuf (to resolve conflicts with golang-goprotobuf). I know that grpc is a pretty important package, so should golang-google-grpc and golang-github-google-s2a-go be uploaded to experimental instead of unstable? Then, I can go through any packages that FTBFS or fail autopkgtest and ensure nothing is broken. > [1]: https://tracker.debian.org/pkg/ratt > [2]: https://salsa.debian.org/ruby-team/meta Kind regards, Maytham signature.asc Description: This is a digitally signed message part
Re: RFS: golang-google-grpc + golang-github-google-s2a-go
On Sat, Dec 23, 2023 at 09:32:37PM +0800, Maytham Alsudany wrote: > I'm looking for a sponsor to review and upload the following packages. > > New packages: > - golang-github-google-s2a-go > > Updated packages: > - golang-google-grpc (Team upload, update to 1.59.0) > > I know golang-google-grpc's latest version is 1.60.0, but it was only recently > released and I've been working on 1.59.0. As soon as this version gets > uploaded, > I'll update it. This is a package with a lot of (important) reverse-dependencies and this is a minor version (assuming they comply with semver.org) bump. Have you verified that it does not cause any regressions in the reverse-deps with ratt[1] or ruby-team/meta[2]? > The packaging can be found at the corresponding Salsa repos under go- > team/packages. [1]: https://tracker.debian.org/pkg/ratt [2]: https://salsa.debian.org/ruby-team/meta Best, Nilesh signature.asc Description: PGP signature
RFS: golang-google-grpc + golang-github-google-s2a-go
Hi Go team, I'm looking for a sponsor to review and upload the following packages. New packages: - golang-github-google-s2a-go Updated packages: - golang-google-grpc (Team upload, update to 1.59.0) I know golang-google-grpc's latest version is 1.60.0, but it was only recently released and I've been working on 1.59.0. As soon as this version gets uploaded, I'll update it. The packaging can be found at the corresponding Salsa repos under go- team/packages. Kind regards, Maytham signature.asc Description: This is a digitally signed message part
