Control: affects -1 src:collectd src:criu src:knot libgadu3 Control: affects -1 src:riemann-c-client ocserv php-pinba Control: affects -1 postgresql-10-postgis-2.4 unbound
On Sat, 2 Jun 2018 13:48:16 +0530 Pirate Praveen <prav...@debian.org> wrote: > package: protobuf-c > version: 1.2.1-2 > severity: important > > Dear maintainer, > > protobuf 3.5.2 is available in experimental and it will be soon uploaded > to unstable (once we complete rebuilding all the reverse dependencies > and evaluating its impact). > > During a test rebuild of all packages depending on libprotobuf-dev, your > package failed to build with this error message. > > > protoc-c/c_bytes_field.cc: In constructor > 'google::protobuf::compiler::c::BytesFieldGenerator::BytesFieldGenerator(const > google::protobuf::FieldDescriptor*)': > protoc-c/c_bytes_field.cc:89:34: error: 'variables_' was not declared in > this scope > SetBytesVariables(descriptor, &variables_); > ^~~~~~~~~~ > > Please fix it so we can proceed with the transition. > Quoting László Böszörményi (GCS) from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901015#12 "The most problematic point is the protobuf-c dependency package. It was developed (and packaged) by one of us (an other DD), Robert S. Edmonds. It is the most complete C language implementation of Protocol Buffers. While it has a newer upstream release in Git than the packaged version, it's still not compatible with protobuf 3.6.0.1 which is in experimental. Main reason is that scoped_array (a class template to store pointers to a dynamically allocated array) is removed from newer protobuf releases, still protobuf-c still would like to use it. While Boost has a similar (same?) scoped_array implementation since its 1.49 version, I highly doubt protobuf-c should be altered to use that. As I can't reach Robert for about nine months and I don't see any life sign from him either, protobuf-c definitely needs a new upstream maintainer with internal protobuf knowledge. Of course, several other C implementation of protobuf exist. PBC[1] seems to be dead for more than a year now and does _not_ have a code generator. Nanopb[2] is a trim down version for 32 bits and microcontrollers only. protobluff[3] seems to be the most viable alternative. It's modular, seems to be in development and integrates with the upstream code generator. None of these are packaged as I know. But why is all the fuzz you may ask. The protobuf-c library is used by several big / important projects. Like Knot DNS (a high-performance DNS server, knot), CRIU (Checkpoint/Restore In Userspace, criu) and PostGIS (geographic objects support for PostgreSQL, postgis) - maintained by people like Ondřej Surý and Carnil (Salvatore Bonaccorso), ones that I bow before them for their knowledge. These packages and others would break with starting the protobuf transition without protobuf-c being updated. Porting these to protobluff might be an even bigger task."
signature.asc
Description: OpenPGP digital signature
