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 <> 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/ In constructor
> 'google::protobuf::compiler::c::BytesFieldGenerator::BytesFieldGenerator(const
> google::protobuf::FieldDescriptor*)':
> protoc-c/ 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

"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
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
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."

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to