On 2021-04-01 13:31 +0200, Yun Peng wrote: > To make sure Bazel fails when trying to download anything from internet, > you can set > export http_proxy=127.0.0.1:9 > export https_proxy=127.0.0.1:9 Using this handy trick I find that (if trying to build the C library (//tensorflow:tensorflow target)) it is also downloading com_google_googleapis from https://github.com/googleapis/googleapis That wasn't in your list. But it is in workspace.bzl, and is not in debian (well sort-of - see below). What is this used for? If its only needed for the actual downloading (e.g. from https://storage.googleapis.com/* URLS) then maybe it's not actually needed? Anyone know for sure? What I've done for now is use the mechanism in debian/embedded to have a local .zip file to upack which allows the build to get further. There is a package in debian built from https://github.com/googleapis/googleapis ruby-googleapis-common-protos-types but its 'source' is the _output_ of processing upstream with the protocol buffer compiler. Arguably that's not the 'preferred form of modification' and that package should be fixed? it's also a version from 2018 so probably quite a lot has changed It seems to me that the right way to package this is to generate all the language outputs from one source package (ruby, java, gp, python, nodejs, php, csharp) maybe thre are more?, Am I misunderstanding how this works? I did try just building the package from upstream and had some success after installing protobuf-compiler and protobuf-compiler-grpc and python3-grpc-tools, ruby-google-protobuf and protobuf-compiler-grpc-java-plugin 3 out of 7 languages build. I don't know which language bindings tensorflow actually wants. These succeed: make OUTPUT=./debian/java LANGUAGE=java make OUTPUT=./debian/python3 LANGUAGE=python make OUTPUT=./debian/csharp LANGUAGE=csharp If anyone has any bright ideas about these failures that would be helpful. The cpp one is odd. Slightly odd that ruby fails, given that that is the one binding we do already have in debian, but maybe it's just because it was done a while ago. These get a fair way thourgh but fail: make OUTPUT=./debian/cpp LANGUAGE=cpp ... protoc --proto_path=.:/usr/include --cpp_out=./debian/cpp --grpc_out=./debian/cpp --plugin=protoc-gen-grpc=/usr/bin/grpc_cpp_plugin google/maps/routes/v1/route_service.proto [libprotobuf FATAL google/protobuf/io/printer.cc:142] Unclosed variable name. terminate called after throwing an instance of 'google::protobuf::FatalException' what(): Unclosed variable name. --grpc_out: protoc-gen-grpc: Plugin killed by signal 6. make: *** [Makefile:45: google/maps/routes/v1/route_service.pb.cc] Error 1 make OUTPUT=./debian/ruby LANGUAGE=ruby ... protoc --proto_path=.:/usr/include --ruby_out=./debian/ruby --grpc_out=./debian/ruby --plugin=protoc-gen-grpc=/usr/bin/grpc_ruby_plugin google/cloud/bigquery/storage/v1alpha2/protobuf.proto --ruby_out: google/cloud/bigquery/storage/v1alpha2/protobuf.proto: proto3 message field google.cloud.bigquery.storage.v1alpha2.ProtoSchema.proto_descriptor in file google/protobuf/descriptor.proto has a dependency on a type from proto2 file google/protobuf/descriptor.proto. Ruby doesn't support proto2 yet, so we must fail. make: *** [Makefile:45: google/cloud/bigquery/storage/v1alpha2/protobuf.pb.cc] Error 1 make OUTPUT=./debian/php LANGUAGE=php ... protoc --proto_path=.:/usr/include --php_out=./debian/php --grpc_out=./debian/php --plugin=protoc-gen-grpc=/usr/bin/grpc_php_plugin google/maps/routes/v1/route_service.proto [libprotobuf FATAL google/protobuf/io/printer.cc:142] Unclosed variable name. terminate called after throwing an instance of 'google::protobuf::FatalException' what(): Unclosed variable name. --grpc_out: protoc-gen-grpc: Plugin killed by signal 6. make: *** [Makefile:45: google/maps/routes/v1/route_service.pb.cc] Error 1 make OUTPUT=./debian/nodejs LANGUAGE=node make OUTPUT=./debian/nodejs LANGUAGE=nodejs both complain of a missing executable, but grpc_node_plugin is present: file /usr/bin/grpc_node_plugin /usr/bin/grpc_node_plugin: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=ecc2b404b7e89960f58146fc2b030654b4f9884f, for GNU/Linux 3.2.0, stripped mkdir -p ./debian/nodejs protoc --proto_path=.:/usr/include --node_out=./debian/nodejs --grpc_out=./debian/nodejs --plugin=protoc-gen-grpc=/usr/bin/grpc_node_plugin google/bytestream/bytestream.proto google/bytestream/bytestream.proto:20:1: warning: Import google/protobuf/wrappers.proto is unused. google/bytestream/bytestream.proto:19:1: warning: Import google/api/annotations.proto is unused. protoc-gen-node: program not found or is not executable Please specify a program using absolute path or make sure the program is available in your PATH system variable --node_out: protoc-gen-node: Plugin failed with status code 1. make: *** [Makefile:45: google/bytestream/bytestream.pb.cc] Error 1 Not sure what's going on there. Do we agree that one source package making a lot of these language bindings packages is the right way to go? I see that go bindings are built from a different source tree. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: PGP signature