[pkg-go] golang-google-cloud and other breakage

[Potter, Tim]

On 1 Dec 2016, at 10:36 PM, Martín Ferrari <tincho at tincho.org> 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)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20170104/7bd9703f/attachment.sig>