Bug#755212: closed by Emilio Pozuelo Monfort (Re: Bug#755212: transition: protobuf-c)
Emilio Pozuelo Monfort wrote: > On 13/08/14 01:15, Robert Edmonds wrote: > > Emilio Pozuelo Monfort wrote: > >> On 12/08/14 03:11, Robert Edmonds wrote: > >>> Hi, > >>> > >>> I think the transition is not quite over; there is still #756422, which > >>> blocks #755212. We need a sourceful upload of collectd in order to > >>> rebuild (or possibly remove) the .pb-c.[ch] files in the collectd-dev > >>> package, which is an "Architecture: all" package. > >>> > >>> I would be happy to NMU collectd, BTW... > >> > >> Great, then do it :) > >> > >> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu has > >> the > >> guidelines: if you only fix the RC bug, you could upload directly without > >> going > >> through the delayed queue. > > > > That's a little aggressive IMO. I've uploaded a fixed version of > > collectd to DELAYED/7, with just the libprotobuf-c0-dev -> > > libprotobuf-c-dev fix. > > That's fixed now. Shall we close this? > > Emilio Yes, please, AFAICT the transition is over. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: closed by Emilio Pozuelo Monfort (Re: Bug#755212: transition: protobuf-c)
On 13/08/14 01:15, Robert Edmonds wrote: > Emilio Pozuelo Monfort wrote: >> On 12/08/14 03:11, Robert Edmonds wrote: >>> Hi, >>> >>> I think the transition is not quite over; there is still #756422, which >>> blocks #755212. We need a sourceful upload of collectd in order to >>> rebuild (or possibly remove) the .pb-c.[ch] files in the collectd-dev >>> package, which is an "Architecture: all" package. >>> >>> I would be happy to NMU collectd, BTW... >> >> Great, then do it :) >> >> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu has the >> guidelines: if you only fix the RC bug, you could upload directly without >> going >> through the delayed queue. > > That's a little aggressive IMO. I've uploaded a fixed version of > collectd to DELAYED/7, with just the libprotobuf-c0-dev -> > libprotobuf-c-dev fix. That's fixed now. Shall we close this? Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: closed by Emilio Pozuelo Monfort (Re: Bug#755212: transition: protobuf-c)
Emilio Pozuelo Monfort wrote: > On 12/08/14 03:11, Robert Edmonds wrote: > > Hi, > > > > I think the transition is not quite over; there is still #756422, which > > blocks #755212. We need a sourceful upload of collectd in order to > > rebuild (or possibly remove) the .pb-c.[ch] files in the collectd-dev > > package, which is an "Architecture: all" package. > > > > I would be happy to NMU collectd, BTW... > > Great, then do it :) > > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu has the > guidelines: if you only fix the RC bug, you could upload directly without > going > through the delayed queue. That's a little aggressive IMO. I've uploaded a fixed version of collectd to DELAYED/7, with just the libprotobuf-c0-dev -> libprotobuf-c-dev fix. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: closed by Emilio Pozuelo Monfort (Re: Bug#755212: transition: protobuf-c)
On 12/08/14 03:11, Robert Edmonds wrote: > Hi, > > I think the transition is not quite over; there is still #756422, which > blocks #755212. We need a sourceful upload of collectd in order to > rebuild (or possibly remove) the .pb-c.[ch] files in the collectd-dev > package, which is an "Architecture: all" package. > > I would be happy to NMU collectd, BTW... Great, then do it :) https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu has the guidelines: if you only fix the RC bug, you could upload directly without going through the delayed queue. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: closed by Emilio Pozuelo Monfort (Re: Bug#755212: transition: protobuf-c)
Hi, I think the transition is not quite over; there is still #756422, which blocks #755212. We need a sourceful upload of collectd in order to rebuild (or possibly remove) the .pb-c.[ch] files in the collectd-dev package, which is an "Architecture: all" package. I would be happy to NMU collectd, BTW... Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the release.debian.org package: > > #755212: transition: protobuf-c > > It has been closed by Emilio Pozuelo Monfort . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Emilio Pozuelo Monfort > by > replying to this email. > > > -- > 755212: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755212 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > Date: Fri, 08 Aug 2014 00:00:24 +0200 > From: Emilio Pozuelo Monfort > To: 755212-d...@bugs.debian.org > Subject: Re: Bug#755212: transition: protobuf-c > Return-path: > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 > Icedove/31.0 > > On 18/07/14 22:19, Robert Edmonds wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Hello, > > > > I am requesting an upload slot to upload protobuf-c 1.0.0-1 to unstable. > > I am hoping to accomplish a transition to protobuf-c 1.0.0 in time for > > the jessie release. (Disclaimer: I am also one of the protobuf-c > > upstream maintainers.) This requires an ABI bump as well as some other > > changes that affect reverse (build-) dependencies, described below. > > The transition is over, closing. > > Emilio -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
Robert Edmonds wrote: > Emilio Pozuelo Monfort wrote: > > I have binNMUed collectd and criu. Let me know if there's anything else that > > needs binNMUs. > > Hi, Emilio: > > I don't see binNMUs for collectd or criu. I see collectd at version > 5.4.1-3. But a recent criu upload transitioned the package to > libprotobuf-c1. So I think the only thing left for this transition is > to get an updated collectd with re-generated .pb-c.h files into the > archive. Oh, nevermind, I see the binNMU for collectd now. However, I think the issue is that the affected package (collectd-dev) is Architecture: all, so it won't get rebuilt during a binNMU. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
Emilio Pozuelo Monfort wrote: > I have binNMUed collectd and criu. Let me know if there's anything else that > needs binNMUs. Hi, Emilio: I don't see binNMUs for collectd or criu. I see collectd at version 5.4.1-3. But a recent criu upload transitioned the package to libprotobuf-c1. So I think the only thing left for this transition is to get an updated collectd with re-generated .pb-c.h files into the archive. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
On 27/07/14 10:44, Gergely Nagy wrote:
> Robert Edmonds writes:
>
>> Emilio Pozuelo Monfort wrote:
>>> On 18/07/14 22:19, Robert Edmonds wrote:
* The header file (protobuf-c.h) which compiled .pb-c.h files must
include. This is shipped in the libprotobuf-c0-dev package
(protobuf-c < 1.0.0), or the libprotobuf-c-dev package (protobuf-c
>= 1.0.0). (libprotobuf-c-dev Provides: libprotobuf-c0-dev, which
smoothes the transition for packages with an unversioned
build-dependency on libprotobuf-c0-dev.)
>>>
>>> I just realized that that's not going to work, because the old
>>> libprotobuf-c0-dev is still available, and so packages that build-depend on
>>> that
>>> will get libprotobuf-c0-dev. So they'll need sourceful uploads to
>>> build-depend
>>> on the new (unversioned) libprotobuf-c-dev.
>>
>> Hi, Emilio:
>>
>> Are you sure about that? protobuf-c-compiler has:
>>
>> Depends: ${shlibs:Depends}, ${misc:Depends}, libprotobuf-c-dev (=
>> ${binary:Version})
>>
>
> I believe the problem arises when you (build-)depend on
> libprotobuf-c0-dev, without protobuf-c-compiler. That happened with
> riemann-c-client:
Yes, that's where it would happen. I didn't think about protobuf-c-compiler,
indeed packages that build-depend on it should be fine.
> * I changed the build-dependency to libprotobuf-c-dev |
>libprotobuf-c0-dev + protobuf-c-compiler.
> * On unstable, that correctly pulled in libprotobuf-c-dev
> * Headers were generated using the new protobuf-c-compiler
> * The libriemann-client-dev package still had a dependency on
>libprotobuf-c0-dev, though.
> * syslog-ng-incubator build-depends on libriemann-client-dev, which
>pulled in libprotobuf-c0-dev and libprotobuf-c1!
> * syslog-ng-incubator FTBFS'd because of the generated header
>conflicted.
>
> I ended up changing the libriemann-client-dev dependency to
> libprotobuf-c-dev, and all is well.
>
> So another thing to pay attention to is transitive build-dependency, as
> that can - and will - break if one's not forcing libprotobuf-c-dev onto
> the system.
>
>> I think all of the packages I listed in my original email had a
>> build-dep on either protobuf-c-compiler only, or protobuf-c-compiler and
>> libprotobuf-c0-dev. (I don't think there are any with just
>> libprotobuf-c0-dev.)
>
> Not directly, but transitively, syslog-ng-incubator build-depends on
> libriemann-client-dev, which depended on libprotobuf-c0-dev only,
> without protobuf-c-compiler. I'm not sure if there are other packages
> like this, but the riemann-c-client + syslog-ng-incubator combo has been
> taken care of.
I have binNMUed collectd and criu. Let me know if there's anything else that
needs binNMUs.
Emilio
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
Robert Edmonds writes:
> Emilio Pozuelo Monfort wrote:
>> On 18/07/14 22:19, Robert Edmonds wrote:
>> > * The header file (protobuf-c.h) which compiled .pb-c.h files must
>> > include. This is shipped in the libprotobuf-c0-dev package
>> > (protobuf-c < 1.0.0), or the libprotobuf-c-dev package (protobuf-c
>> > >= 1.0.0). (libprotobuf-c-dev Provides: libprotobuf-c0-dev, which
>> > smoothes the transition for packages with an unversioned
>> > build-dependency on libprotobuf-c0-dev.)
>>
>> I just realized that that's not going to work, because the old
>> libprotobuf-c0-dev is still available, and so packages that build-depend on
>> that
>> will get libprotobuf-c0-dev. So they'll need sourceful uploads to
>> build-depend
>> on the new (unversioned) libprotobuf-c-dev.
>
> Hi, Emilio:
>
> Are you sure about that? protobuf-c-compiler has:
>
> Depends: ${shlibs:Depends}, ${misc:Depends}, libprotobuf-c-dev (=
> ${binary:Version})
>
I believe the problem arises when you (build-)depend on
libprotobuf-c0-dev, without protobuf-c-compiler. That happened with
riemann-c-client:
* I changed the build-dependency to libprotobuf-c-dev |
libprotobuf-c0-dev + protobuf-c-compiler.
* On unstable, that correctly pulled in libprotobuf-c-dev
* Headers were generated using the new protobuf-c-compiler
* The libriemann-client-dev package still had a dependency on
libprotobuf-c0-dev, though.
* syslog-ng-incubator build-depends on libriemann-client-dev, which
pulled in libprotobuf-c0-dev and libprotobuf-c1!
* syslog-ng-incubator FTBFS'd because of the generated header
conflicted.
I ended up changing the libriemann-client-dev dependency to
libprotobuf-c-dev, and all is well.
So another thing to pay attention to is transitive build-dependency, as
that can - and will - break if one's not forcing libprotobuf-c-dev onto
the system.
> I think all of the packages I listed in my original email had a
> build-dep on either protobuf-c-compiler only, or protobuf-c-compiler and
> libprotobuf-c0-dev. (I don't think there are any with just
> libprotobuf-c0-dev.)
Not directly, but transitively, syslog-ng-incubator build-depends on
libriemann-client-dev, which depended on libprotobuf-c0-dev only,
without protobuf-c-compiler. I'm not sure if there are other packages
like this, but the riemann-c-client + syslog-ng-incubator combo has been
taken care of.
--
|8]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
Emilio Pozuelo Monfort wrote:
> On 18/07/14 22:19, Robert Edmonds wrote:
> > * The header file (protobuf-c.h) which compiled .pb-c.h files must
> > include. This is shipped in the libprotobuf-c0-dev package
> > (protobuf-c < 1.0.0), or the libprotobuf-c-dev package (protobuf-c
> > >= 1.0.0). (libprotobuf-c-dev Provides: libprotobuf-c0-dev, which
> > smoothes the transition for packages with an unversioned
> > build-dependency on libprotobuf-c0-dev.)
>
> I just realized that that's not going to work, because the old
> libprotobuf-c0-dev is still available, and so packages that build-depend on
> that
> will get libprotobuf-c0-dev. So they'll need sourceful uploads to build-depend
> on the new (unversioned) libprotobuf-c-dev.
Hi, Emilio:
Are you sure about that? protobuf-c-compiler has:
Depends: ${shlibs:Depends}, ${misc:Depends}, libprotobuf-c-dev (=
${binary:Version})
Which will force libprotobuf-c-dev to be installed. And
libprotobuf-c-dev has:
Depends: libprotobuf-c1 (= ${binary:Version}), ${misc:Depends}
Provides: libprotobuf-c0-dev
Conflicts: libprotobuf-c0-dev
Replaces: libprotobuf-c0-dev
Breaks: protobuf-c-compiler (<< 1.0.0~)
Which will force libprotobuf-c0-dev to be uninstalled.
I *think* what will happen is that if a package does:
Build-Depends: protobuf-c-compiler
or
Build-Depends: protobuf-c-compiler, libprotobuf-c0-dev
They will end up with protobuf-c-compiler (1.0.0-1) and
libprotobuf-c-dev (1.0.0-1) installed, which is what is desired.
I think all of the packages I listed in my original email had a
build-dep on either protobuf-c-compiler only, or protobuf-c-compiler and
libprotobuf-c0-dev. (I don't think there are any with just
libprotobuf-c0-dev.)
The only package with a versioned build-dep on libprotobuf-c0-dev is
osm2pgsql, which needs other sourceful changes anyway. I think with the
pending upload of osm2pgsql (#756112) there will be no more packages in
the Debian archive with a versioned build-dep on libprotobuf-c0-dev, and
it can be removed from the archive?
--
Robert Edmonds
edmo...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
On 18/07/14 22:19, Robert Edmonds wrote: > * The header file (protobuf-c.h) which compiled .pb-c.h files must > include. This is shipped in the libprotobuf-c0-dev package > (protobuf-c < 1.0.0), or the libprotobuf-c-dev package (protobuf-c > >= 1.0.0). (libprotobuf-c-dev Provides: libprotobuf-c0-dev, which > smoothes the transition for packages with an unversioned > build-dependency on libprotobuf-c0-dev.) I just realized that that's not going to work, because the old libprotobuf-c0-dev is still available, and so packages that build-depend on that will get libprotobuf-c0-dev. So they'll need sourceful uploads to build-depend on the new (unversioned) libprotobuf-c-dev. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
Gergely Nagy wrote: > I gave this some more thought, and there's a problem: while generating > riemann events and similar can be done with opaque types, if I do a > query, then I want to access the results, and to do that with opaque > types would mean I need a lot of getter functions (and an API + ABI > bump). So I'll stick to how it is done today, for the foreseeable > future. > > But I'll keep your suggestions in mind in case I end up writing another > library that uses protobuf, I'll hide the protobuf stuff deeper then! :) Ah, OK, I did miss the fact that the protoc-c generated message structures get de-referenced. I am fairly sure that the layout of those structures has not changed in protobuf-c 1.0.0, but I will verify with abi-compliance-checker. The ProtobufCMessageDescriptor structures *have* changed, but I don't think you export those anywhere. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
Robert Edmonds writes:
>> The various riemann-c-client headers in /usr/include/riemann include
>> proto/riemann.pb-c.h, and there's syslog-ng-mod-riemann (from
>> syslog-ng-incubator) that uses the library, thus, the generated header
>> too, transitively.
>
> Ah, right. From a brief look at the source code for that module it
> looks like it doesn't require a (bin-)NMU at all, if I'm understanding
> the libriemann-client API correctly.
Yep, I agree. syslog-ng-incubator should not need a bin-NMU, as it uses
everything through the libriemann-client API, and never touches the
protobuf structures directly.
>> > I would recommend that the upstream developers ship a .proto file
>> > instead.
>>
>> I'd rather not ship a .proto file, if at all possible. I'll see if I can
>> hide it completely.
>
> This would eliminate the problem, too.
>
> It looks like you typedef the structures generated by protoc-c and wrap
> them in your own API, e.g. from :
>
> #include
>
> typedef Query riemann_query_t;
>
> riemann_query_t *riemann_query_new (const char *string);
> void riemann_query_free (riemann_query_t *query);
>
> int riemann_query_set_string (riemann_query_t *query, const char *string);
>
> ("Query" is from "typedef struct _Query Query" in riemann.pb-c.h.)
>
> If your API callers always use the *_new(), *_free(), etc. functions and
> never try to dereference or calculate sizeof() on the wrapped struct's
> it might be possible to remove the #include of the .pb-c.h file and
> change your typedef to, e.g.:
>
> typedef struct _Query riemann_query_t;
>
> And then have "riemann_query_t" be an opaque type. Though this depends
> on protoc-c continuing to generate structure tags with leading
> underscores, which may not always be the case. (I've wanted to get rid
> of the leading underscores for a while now.)
>
> (Similiarly for the other riemann_*_t types that wrap protoc-c generated
> structures.)
>
> It might also be possible to wrap the structure types generated by
> protoc-c in your own opaque structure type and expose that wrapper type
> via your API. Something like:
>
> typedef struct riemann_query riemann_query_t;
>
> riemann_query_t *riemann_query_new (const char *string);
> void riemann_query_free (riemann_query_t *query);
>
> int riemann_query_set_string (riemann_query_t *query, const char *string);
>
> (In .)
>
> #include "proto/riemann.pb-c.h"
>
> struct riemann_query {
> Query query;
> };
>
> /* rest of the implementation... */
>
> (In lib/riemann/query.c.)
>
> That's a bit uglier since you have to update accesses to go via the
> wrapper but would provide the maximum amount of insulation between the
> libriemann-client API and the underlying structures generated by the
> protoc-c code generator.
I gave this some more thought, and there's a problem: while generating
riemann events and similar can be done with opaque types, if I do a
query, then I want to access the results, and to do that with opaque
types would mean I need a lot of getter functions (and an API + ABI
bump). So I'll stick to how it is done today, for the foreseeable
future.
But I'll keep your suggestions in mind in case I end up writing another
library that uses protobuf, I'll hide the protobuf stuff deeper then! :)
--
|8]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
2014-07-21 23:41 GMT+02:00 Robert Edmonds : > I looked over the changes to libgadu's convenience copy of protobuf-c.c > and I *believe* that all the changes are relatively minor (fixing up > warnings due to libgadu compiling with more -W flags, replacing > C++-style comments with C89-compatible comments, etc.), or, at least, > they don't change any of the semantics of the protobuf-c library. Awesome, thanks for checking that. Changed semantics was what I was worried about - until a few years ago the gadu-gadu protocol was completely proprietary, so I thought maybe they "improved" the protobuf-based done too. I'll do my best to upload this week. Marcin
Bug#755212: transition: protobuf-c
Hi, Gergely:
Gergely Nagy wrote:
> Robert Edmonds writes:
>
> > riemann-c-client
> >
> >
> > Rebuilt by hand successfully against protobuf-c 1.0.0~rc2-1 from
> > experimental.
> >
> > Has an unversioned build dependency on libprotobuf-c0-dev. This
> > needs to be updated to libprotobuf-c-dev eventually.
>
> I can switch that to libprotobuf-c-dev | libprotobuf-c0-dev in the next
> upload (I'd like to be able to compile the package on wheezy without
> changes, hence the alternative). Since I just released a new upstream
> version of the library, I'll be doing an upload at some point anyway,
> I'll try to make it so that binNMUs won't be required after.
OK, "Build-Depends: protobuf-c-compiler, libprotobuf-c-dev |
libprotobuf-c0-dev" will work fine to preserve the ability to build on
wheezy. Eventually (post-jessie) I'd like to get rid of the
"libprotobuf-c0-dev" package name entirely.
> > Has a build dependency on protobuf-c-compiler and runs protoc-c
> > during the build.
> >
> > No protoc-c generated symbols are exported by libriemann-client0.
> >
> > The libriemann-client-dev package exports the following header files
> > generated by protoc-c:
> >
> > /usr/include/riemann/proto/riemann.pb-c.h
> >
> > However, I have not found any packages in the Debian archive which
> > utilize this file.
>
> The various riemann-c-client headers in /usr/include/riemann include
> proto/riemann.pb-c.h, and there's syslog-ng-mod-riemann (from
> syslog-ng-incubator) that uses the library, thus, the generated header
> too, transitively.
Ah, right. From a brief look at the source code for that module it
looks like it doesn't require a (bin-)NMU at all, if I'm understanding
the libriemann-client API correctly.
> > I would recommend that the upstream developers ship a .proto file
> > instead.
>
> I'd rather not ship a .proto file, if at all possible. I'll see if I can
> hide it completely.
This would eliminate the problem, too.
It looks like you typedef the structures generated by protoc-c and wrap
them in your own API, e.g. from :
#include
typedef Query riemann_query_t;
riemann_query_t *riemann_query_new (const char *string);
void riemann_query_free (riemann_query_t *query);
int riemann_query_set_string (riemann_query_t *query, const char *string);
("Query" is from "typedef struct _Query Query" in riemann.pb-c.h.)
If your API callers always use the *_new(), *_free(), etc. functions and
never try to dereference or calculate sizeof() on the wrapped struct's
it might be possible to remove the #include of the .pb-c.h file and
change your typedef to, e.g.:
typedef struct _Query riemann_query_t;
And then have "riemann_query_t" be an opaque type. Though this depends
on protoc-c continuing to generate structure tags with leading
underscores, which may not always be the case. (I've wanted to get rid
of the leading underscores for a while now.)
(Similiarly for the other riemann_*_t types that wrap protoc-c generated
structures.)
It might also be possible to wrap the structure types generated by
protoc-c in your own opaque structure type and expose that wrapper type
via your API. Something like:
typedef struct riemann_query riemann_query_t;
riemann_query_t *riemann_query_new (const char *string);
void riemann_query_free (riemann_query_t *query);
int riemann_query_set_string (riemann_query_t *query, const char *string);
(In .)
#include "proto/riemann.pb-c.h"
struct riemann_query {
Query query;
};
/* rest of the implementation... */
(In lib/riemann/query.c.)
That's a bit uglier since you have to update accesses to go via the
wrapper but would provide the maximum amount of insulation between the
libriemann-client API and the underlying structures generated by the
protoc-c code generator.
--
Robert Edmonds
edmo...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
On 21/07/14 23:13, Robert Edmonds wrote: > OK, IIUC, protobuf-c 1.0.0-1 may be uploaded to unstable? Yes, or even rc2 if you feel comfortable with that. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
Hi, Marcin: Marcin Owsiany wrote: > The problem with libgadu is that the embedded copy also seems to have > libgadu-specific modifications applied. I've asked upstream to clarify > whether these could be dropped. I was able to build libgadu successfully with libprotobuf-c-dev added to Build-Depends and it picked up the system provided copy of libprotobuf-c automatically. I don't have a Gadu-Gadu account so I was unable to test the libgadu binary built this way, unfortunately. It did pass the test suite, FWIW. I looked over the changes to libgadu's convenience copy of protobuf-c.c and I *believe* that all the changes are relatively minor (fixing up warnings due to libgadu compiling with more -W flags, replacing C++-style comments with C89-compatible comments, etc.), or, at least, they don't change any of the semantics of the protobuf-c library. There might be some changes from libgadu that we might want to rebase and apply to upstream libprotobuf-c, but it doesn't look like anything will break if libgadu is built against the system's protobuf-c. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
Hi, Emilio: Emilio Pozuelo Monfort wrote: > Hi Robert, > > On 18/07/14 22:19, Robert Edmonds wrote: > > I am requesting an upload slot to upload protobuf-c 1.0.0-1 to unstable. > > I am hoping to accomplish a transition to protobuf-c 1.0.0 in time for > > the jessie release. (Disclaimer: I am also one of the protobuf-c > > upstream maintainers.) This requires an ABI bump as well as some other > > changes that affect reverse (build-) dependencies, described below. > > Can you open bug reports for the rdeps that need patches and make them block > this bug? Yes, certainly. > Also file bugs for your recommendations (e.g. ship .proto files) and > the code copy, though those are not blockers IIUC. Will do. > Please go ahead with this if you are ready to NMU the rdeps after the > transition > starts (assuming the maintainers don't do it, of course). OK, IIUC, protobuf-c 1.0.0-1 may be uploaded to unstable? -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
Robert Edmonds writes: > riemann-c-client > > > Rebuilt by hand successfully against protobuf-c 1.0.0~rc2-1 from > experimental. > > Has an unversioned build dependency on libprotobuf-c0-dev. This > needs to be updated to libprotobuf-c-dev eventually. I can switch that to libprotobuf-c-dev | libprotobuf-c0-dev in the next upload (I'd like to be able to compile the package on wheezy without changes, hence the alternative). Since I just released a new upstream version of the library, I'll be doing an upload at some point anyway, I'll try to make it so that binNMUs won't be required after. > Has a build dependency on protobuf-c-compiler and runs protoc-c > during the build. > > No protoc-c generated symbols are exported by libriemann-client0. > > The libriemann-client-dev package exports the following header files > generated by protoc-c: > > /usr/include/riemann/proto/riemann.pb-c.h > > However, I have not found any packages in the Debian archive which > utilize this file. The various riemann-c-client headers in /usr/include/riemann include proto/riemann.pb-c.h, and there's syslog-ng-mod-riemann (from syslog-ng-incubator) that uses the library, thus, the generated header too, transitively. > I would recommend that the upstream developers ship a .proto file > instead. I'd rather not ship a .proto file, if at all possible. I'll see if I can hide it completely. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
The problem with libgadu is that the embedded copy also seems to have libgadu-specific modifications applied. I've asked upstream to clarify whether these could be dropped. Marcin
Bug#755212: transition: protobuf-c
Hi Robert, On 18/07/14 22:19, Robert Edmonds wrote: > I am requesting an upload slot to upload protobuf-c 1.0.0-1 to unstable. > I am hoping to accomplish a transition to protobuf-c 1.0.0 in time for > the jessie release. (Disclaimer: I am also one of the protobuf-c > upstream maintainers.) This requires an ABI bump as well as some other > changes that affect reverse (build-) dependencies, described below. Can you open bug reports for the rdeps that need patches and make them block this bug? Also file bugs for your recommendations (e.g. ship .proto files) and the code copy, though those are not blockers IIUC. Please go ahead with this if you are ready to NMU the rdeps after the transition starts (assuming the maintainers don't do it, of course). Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello, I am requesting an upload slot to upload protobuf-c 1.0.0-1 to unstable. I am hoping to accomplish a transition to protobuf-c 1.0.0 in time for the jessie release. (Disclaimer: I am also one of the protobuf-c upstream maintainers.) This requires an ABI bump as well as some other changes that affect reverse (build-) dependencies, described below. protobuf-c 1.0.0~rc2-1 has been built successfully in experimental. There are a few minor changes queued upstream for the final 1.0.0 release which I don't expect to cause issues. Here is a proposed ben file for the transition: title = "protobuf-c"; is_affected = .build-depends ~ /libprotobuf-c0-dev|protobuf-c-compiler/ | .depends ~ /libprotobuf-c-dev|libprotobuf-c1|libprotobuf-c1-dbg|libprotobuf-c0|libprotobuf-c0-dev|protobuf-c-compiler/; is_good = .build-depends ~ /libprotobuf-c-dev/ | .depends ~ /libprotobuf-c-dev|libprotobuf-c1|libprotobuf-c1-dbg/; is_bad = .build-depends ~ /libprotobuf-c0-dev/ | .depends ~ /libprotobuf-c0|libprotobuf-c0-dev/ protobuf-c is a C implementation of Protocol Buffers, a structured data serialization format that is typically implemented in most programming languages with a code generator. In Debian, protobuf-c is split into several binary packages: * The code generator utility (/usr/bin/protoc-c) which creates .pb-c.c and .pb-c.h output files from a .proto input file. This is shipped in the protobuf-c-compiler package. Unlike other code generators that produce C code, like bison and flex, the output of protoc-c is not usable by itself. * The shared library (libprotobuf-c) which compiled .pb-c.c files must be linked against. This is shipped in the libprotobuf-c0 package (protobuf-c < 1.0.0), or the libprotobuf-c1 package (protobuf-c >= 1.0.0). * The header file (protobuf-c.h) which compiled .pb-c.h files must include. This is shipped in the libprotobuf-c0-dev package (protobuf-c < 1.0.0), or the libprotobuf-c-dev package (protobuf-c >= 1.0.0). (libprotobuf-c-dev Provides: libprotobuf-c0-dev, which smoothes the transition for packages with an unversioned build-dependency on libprotobuf-c0-dev.) In the past, protobuf-c has had issues with unannounced ABI/API changes, so for the protobuf-c 1.0.0 release we are explicitly adopting Semantic Versioning and have added version guard macros to the header file to prevent incompatible version skew between protoc-c and protobuf-c.h. We have also started versioning the symbols exported by the library. For more details, see the Versioning section in the README: https://github.com/protobuf-c/protobuf-c#versioning Because of the relationships between protoc-c, libprotobuf-c, and protobuf-c.h, and the (previously) less clear versioning situation, there are some gotchas that can occur: * Projects utilizing the output of protoc-c might ship generated copies of the .pb-c.c and .pb-c.h files in their distribution tarballs. These files should always be regenerated with the system's copy of protoc-c. Searching source packages for filenames ending in ".pb-c.c" or ".pb-c.h" can identify candidates where this may have occurred. * Projects shipping a shared library might export symbols from C files that were generated by protoc-c, which introduces a dependency on a specific major version of libprotobuf-c. Clients of such libraries cannot use these symbols with another libprotobuf-c major version. Searching the symbol tables of libraries for exported symbols whose names end in "__descriptor" or "__pack_to_buffer" can identify candidates where this has occurred. * Projects may include generated .pb-c.h files in /usr/include, which introduces a versioned dependency between clients of such a project and the protobuf-c.h header. E.g., if a project ships a .pb-c.h file in /usr/include which was generated by protoc-c from protobuf-c < 1.0.0, clients of such a project attempting to import such a header file will FTBFS when building against protobuf-c.h from protobuf-c >= 1.0.0. Searching binary packages for filenames ending in .pb-c.h under /usr/include will identify candidates where this has occurred. (If possible, I recommend instead shipping the original .proto definition file, perhaps in /usr/share, to allow clients to build the .pb-c.c and .pb-c.h files with the system's copy of protoc-c.) I've researched the packages in the Debian archive which make use of protobuf-c to some degree and detail my findings below. The summary is: Package Disposition --- collectdBinNMU possible criuBinNMU possible libgadu Sourceful changes re
