On 1 Dec 2016, at 10:36 PM, Martín Ferrari <[email protected]> wrote: > > So google-cloud (and a bunch of other packages) started failing after my > upgrade of grpc, because of a symbol change, and because we were not > regenerating protobufs on compilation. > > This also caused #845453, and a bunch of other issues.
I was poking at this last year before Christmas and grpc is actually up to SupportPackageIsVersion4 now. )-: Should be make it a general policy to regenerate proto files for each new grpc release? This sounded good to me until I discovered that etcd3 has the grpc as an official API[1],[2]. I think that I saw the etcd.proto file (for etcd2) in the source of another package (swarmkit?). Not sure whether the version business is going to mess is up here as well - are the wire formats incompatible between the different versions? I think I decided that vendoring the source for grpc in each package where it's needed was going to be easier. The Debian way of having a single source for a library is not really working here. Will get back into things this week. Tim. [1] https://github.com/coreos/etcd/blob/v2.3.7/Documentation/rfc/v3api.md [2] https://github.com/coreos/etcd/blob/master/Documentation/dev-guide/api_reference_v3.md > > I have already prepared a replacement for google's proto definiions > (genproto), which regenerates all protobufs on build, and will solve > many of these issues. But we need to be careful to always regenerate > protobufs, because if the protobuf or grpc libraries change, they might > break again like this. > > Also, a comment about google-cloud: I finally upgraded to a new version > (it seems they had releases after all, but not in github), so now it is > using the new import path, and the old one is kept for compatibility. > Also, I created a new upstream branch (upstream-ng) that follows git > history. > > I did not upload yet, as it depends on genproto passing NEW. > > Also, the tests are accessing the network, so if anybody has some time, > please take a look at disabling the problematic ones. Upstream does not > even seem to have a bug tracker, so I could not report this. > > On 30/11/16 10:57, Santiago Vila wrote: > >> I tried to build this package in stretch with "dpkg-buildpackage -A" >> (which is what the "Arch: all" autobuilder would do to build it) >> but it failed: > >> src/github.com/googleapis/proto-client-go/logging/v2/logging.pb.go:216: >> undefined: grpc.SupportPackageIsVersion3 >> src/github.com/googleapis/proto-client-go/logging/v2/logging_config.pb.go:223: >> undefined: grpc.SupportPackageIsVersion3 >> src/github.com/googleapis/proto-client-go/logging/v2/logging_metrics.pb.go:183: >> undefined: grpc.SupportPackageIsVersion3 > > > > -- > Martín Ferrari (Tincho)
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Pkg-go-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
