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 22.214.171.124 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 seems to be dead for more than a year now and does _not_ have a code generator. Nanopb is a trim down version for 32 bits and microcontrollers only. protobluff 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."
Description: OpenPGP digital signature