Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-21 Thread Tom Lee 
Oh right -- sorry, I misunderstood what you were saying wrt collapsing
those log entries :) I'll update the git repo.

Thanks very much for all your help getting this on NEW, Vincent. Hopefully
it's smooth sailing from here!


On Wed, Aug 21, 2013 at 10:30 AM, Vincent Bernat  wrote:

>  ❦ 21 août 2013 18:19 CEST, Kenton Varda  :
>
> > I do have experience with sonames, actually, from protobufs.  My
> experience
> > was:
> >
> > - We never did two releases that had the same binary interface.
> > - We occasionally forgot to bump the soname, leading to problems.
> [...]
>
> OK, fair enough for me.
>
> Tom, I am sorry to be picky but I have changed the changelog entry to
> just contain "Initial release (Closes: #719782)". We don't care for
> changes that did happen before the package is released in Debian. Be
> sure to update the changelog entry in your git repository too.
>
> There is no other problem with the packages for me, so I have uploaded
> it.
> --
> Debian package sponsoring guidelines:
>  http://vincent.bernat.im/en/debian-package-sponsoring.html
>



-- 
*Tom Lee */ http://tomlee.co / @tglee

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-21 Thread Vincent Bernat 
 ❦ 21 août 2013 18:19 CEST, Kenton Varda  :

> I do have experience with sonames, actually, from protobufs.  My experience
> was:
>
> - We never did two releases that had the same binary interface.
> - We occasionally forgot to bump the soname, leading to problems.
[...]

OK, fair enough for me.

Tom, I am sorry to be picky but I have changed the changelog entry to
just contain "Initial release (Closes: #719782)". We don't care for
changes that did happen before the package is released in Debian. Be
sure to update the changelog entry in your git repository too.

There is no other problem with the packages for me, so I have uploaded
it.
-- 
Debian package sponsoring guidelines:
 http://vincent.bernat.im/en/debian-package-sponsoring.html


signature.asc
Description: PGP signature

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-21 Thread Kenton Varda 
I do have experience with sonames, actually, from protobufs.  My experience
was:

- We never did two releases that had the same binary interface.
- We occasionally forgot to bump the soname, leading to problems.

The nature of C++ is that binary compatibility between versions is nearly
impossible to maintain, unless you design your interface in a very careful
and limiting way.  You want people to be able to allocate objects on the
stack, but that means that if the size of the object changes, the ABI has
changed.  And then there's inline methods, templates, etc., all of which
Cap'n Proto uses extensively.  Moreover, Cap'n Proto is a library where
nearly every module has a public API.  If it, say, had one main public
interface wrapping a large implementation, the ABI would be more manageable.

So, I set the flag on libtool to have it just use the whole version number
as the soname.  That way at least there's no chance of accidents leading to
subtle bugs.

It happens to be true that 0.2.0 -> 0.2.1 did not change the binary
interface, because no headers were modified.  However, I expect this to be
pretty rare.

Perhaps a strategy for reducing trouble with dependencies would be to only
update dependencies to the latest Cap'n Proto release a few weeks after
such a release takes place, since the chance of a subsequent point release
falls off with time.

And, yeah, we're pretty early in development and I'm not even aware of
anyone using Cap'n Proto in real projects yet, so for the moment dependency
churn isn't a big deal.  Later on, there will be more dependencies, but
there will also be fewer releases.

-Kenton

On Wed, Aug 21, 2013 at 12:02 AM, Tom Lee  wrote:

> Changelog squashed.
>
> CCing Kenton RE: the SONAME suggestion.
>
> I suspect that because capnproto is relatively young the frequent SONAME
> breakages might be warranted -- I'm happy to work with that for now so long
> as it's not in breach of the DPM, though I agree this may be an issue for
> reverse dependencies.
>
> Kenton, not sure how much you've had to deal with this in the past -- any
> thoughts here? Relevant docs:
>
> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
>
> "The SONAME and binary package name need not, and indeed normally should
> not, change if new interfaces are added but none are removed or changed,
> since this will not break binaries linked against the old shared library.
> Correct versioning of dependencies on the newer shared library by binaries
> that use the new interfaces is handled via the symbols or shlibs system."
>
> This is complicated by the use of C++, which would place restrictions on
> things like virtual functions being added & removed. The KDE guys have
> documented some of this stuff:
>
> http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
>
>
>
> On Tue, Aug 20, 2013 at 6:27 AM, Vincent Bernat  wrote:
>
>>  ❦ 20 août 2013 10:24 CEST, Tom Lee  :
>>
>> > Done -- 0.2.1-1 was just uploaded to mentors:
>> >
>> > http://mentors.debian.net/package/capnproto
>>
>> Please, squash the changelog into one entry. This is a matter of taste,
>> but this avoids forgetting to include all the appropriate changelog
>> entries into .changes.
>>
>> Also, I notice that for a small change, the ABI is changing. This will
>> be a bit difficult for reverse-dependencies if there are frequent
>> releases. Maybe the SO name should be handled differently by upstream to
>> avoid unnecessary ABI version dump.
>> --
>> Don't just echo the code with comments - make every comment count.
>> - The Elements of Programming Style (Kernighan & Plauger)
>>
>
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee 
>
>

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-21 Thread Tom Lee 
Sorry, Debian Policy Manual :)

By the way, just uploaded the changelog modification to mentors, should
appear shortly. Nearly forgot to upload it.


On Wed, Aug 21, 2013 at 12:12 AM, Vincent Bernat  wrote:

>  ❦ 21 août 2013 09:02 CEST, Tom Lee  :
>
> > Changelog squashed.
> >
> > CCing Kenton RE: the SONAME suggestion.
> >
> > I suspect that because capnproto is relatively young the frequent SONAME
> > breakages might be warranted -- I'm happy to work with that for now so
> long
> > as it's not in breach of the DPM, though I agree this may be an issue for
> > reverse dependencies.
>
> Sorry, what is DPM?
> --
> Debian package sponsoring guidelines:
>  http://vincent.bernat.im/en/debian-package-sponsoring.html
>



-- 
*Tom Lee */ http://tomlee.co / @tglee

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-21 Thread Vincent Bernat 
 ❦ 21 août 2013 09:02 CEST, Tom Lee  :

> Changelog squashed.
>
> CCing Kenton RE: the SONAME suggestion.
>
> I suspect that because capnproto is relatively young the frequent SONAME
> breakages might be warranted -- I'm happy to work with that for now so long
> as it's not in breach of the DPM, though I agree this may be an issue for
> reverse dependencies.

Sorry, what is DPM?
-- 
Debian package sponsoring guidelines:
 http://vincent.bernat.im/en/debian-package-sponsoring.html


signature.asc
Description: PGP signature

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-21 Thread Tom Lee 
Changelog squashed.

CCing Kenton RE: the SONAME suggestion.

I suspect that because capnproto is relatively young the frequent SONAME
breakages might be warranted -- I'm happy to work with that for now so long
as it's not in breach of the DPM, though I agree this may be an issue for
reverse dependencies.

Kenton, not sure how much you've had to deal with this in the past -- any
thoughts here? Relevant docs:

http://www.debian.org/doc/debian-policy/ch-sharedlibs.html

"The SONAME and binary package name need not, and indeed normally should
not, change if new interfaces are added but none are removed or changed,
since this will not break binaries linked against the old shared library.
Correct versioning of dependencies on the newer shared library by binaries
that use the new interfaces is handled via the symbols or shlibs system."

This is complicated by the use of C++, which would place restrictions on
things like virtual functions being added & removed. The KDE guys have
documented some of this stuff:

http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++



On Tue, Aug 20, 2013 at 6:27 AM, Vincent Bernat  wrote:

>  ❦ 20 août 2013 10:24 CEST, Tom Lee  :
>
> > Done -- 0.2.1-1 was just uploaded to mentors:
> >
> > http://mentors.debian.net/package/capnproto
>
> Please, squash the changelog into one entry. This is a matter of taste,
> but this avoids forgetting to include all the appropriate changelog
> entries into .changes.
>
> Also, I notice that for a small change, the ABI is changing. This will
> be a bit difficult for reverse-dependencies if there are frequent
> releases. Maybe the SO name should be handled differently by upstream to
> avoid unnecessary ABI version dump.
> --
> Don't just echo the code with comments - make every comment count.
> - The Elements of Programming Style (Kernighan & Plauger)
>



-- 
*Tom Lee */ http://tomlee.co / @tglee

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-20 Thread Vincent Bernat 
 ❦ 20 août 2013 10:24 CEST, Tom Lee  :

> Done -- 0.2.1-1 was just uploaded to mentors:
>
> http://mentors.debian.net/package/capnproto

Please, squash the changelog into one entry. This is a matter of taste,
but this avoids forgetting to include all the appropriate changelog
entries into .changes.

Also, I notice that for a small change, the ABI is changing. This will
be a bit difficult for reverse-dependencies if there are frequent
releases. Maybe the SO name should be handled differently by upstream to
avoid unnecessary ABI version dump.
-- 
Don't just echo the code with comments - make every comment count.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-20 Thread Tom Lee 
Oops, just noticed I missed the leading upper-case 'T' for the capnproto
package. Fixed & pushing to mentors.d.n now.

Cheers,
Tom


On Tue, Aug 20, 2013 at 1:24 AM, Tom Lee  wrote:

> Done -- 0.2.1-1 was just uploaded to mentors:
>
> http://mentors.debian.net/package/capnproto
>
> Cheers,
> Tom
>
>
> On Mon, Aug 19, 2013 at 11:57 PM, Vincent Bernat wrote:
>
>>  ❦ 20 août 2013 06:48 CEST, Tom Lee  :
>>
>> > Alright, latest build of this package is up on mentors.debian.net:
>> >
>> > http://mentors.debian.net/package/capnproto
>> >
>> > Noticed that my watch file has detected a new point release Kenton put
>> out
>> > earlier today to work around that GCC compiler bug.
>> >
>> > Should I upgrade to the new release now? Or is it okay to follow up
>> with a
>> > 0.2.1-1 build once 0.2.0-1 lands in unstable?
>>
>> Please, upgrade now as it can take up to a month to land in unstable.
>> --
>> Don't comment bad code - rewrite it.
>> - The Elements of Programming Style (Kernighan & Plauger)
>>
>
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee 
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-20 Thread Tom Lee 
Done -- 0.2.1-1 was just uploaded to mentors:

http://mentors.debian.net/package/capnproto

Cheers,
Tom


On Mon, Aug 19, 2013 at 11:57 PM, Vincent Bernat  wrote:

>  ❦ 20 août 2013 06:48 CEST, Tom Lee  :
>
> > Alright, latest build of this package is up on mentors.debian.net:
> >
> > http://mentors.debian.net/package/capnproto
> >
> > Noticed that my watch file has detected a new point release Kenton put
> out
> > earlier today to work around that GCC compiler bug.
> >
> > Should I upgrade to the new release now? Or is it okay to follow up with
> a
> > 0.2.1-1 build once 0.2.0-1 lands in unstable?
>
> Please, upgrade now as it can take up to a month to land in unstable.
> --
> Don't comment bad code - rewrite it.
> - The Elements of Programming Style (Kernighan & Plauger)
>



-- 
*Tom Lee */ http://tomlee.co / @tglee

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-20 Thread Vincent Bernat 
 ❦ 20 août 2013 06:48 CEST, Tom Lee  :

> Alright, latest build of this package is up on mentors.debian.net:
>
> http://mentors.debian.net/package/capnproto
>
> Noticed that my watch file has detected a new point release Kenton put out
> earlier today to work around that GCC compiler bug.
>
> Should I upgrade to the new release now? Or is it okay to follow up with a
> 0.2.1-1 build once 0.2.0-1 lands in unstable?

Please, upgrade now as it can take up to a month to land in unstable.
-- 
Don't comment bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-19 Thread Tom Lee 
Alright, latest build of this package is up on mentors.debian.net:

http://mentors.debian.net/package/capnproto

Noticed that my watch file has detected a new point release Kenton put out
earlier today to work around that GCC compiler bug.

Should I upgrade to the new release now? Or is it okay to follow up with a
0.2.1-1 build once 0.2.0-1 lands in unstable?

Cheers,
Tom


On Mon, Aug 19, 2013 at 3:12 AM, Vincent Bernat  wrote:

>  ❦ 19 août 2013 11:46 CEST, Tom Lee  :
>
> >> The easiest way is to use Lintian (I use it with -viI).
> >>
> >>
> > Odd, I don't see any warnings:
> >
> > tom@desktop:~/Source$ lintian -viI capnproto_0.2.0-1.dsc
> > N: Using profile debian/main.
> > N: Setting up lab in /tmp/temp-lintian-lab-q9W0nEVK6F ...
> > N: Unpacking packages in group capnproto/0.2.0-1
> > N: 
> > N: Processing source package capnproto (version 0.2.0-1, arch source) ...
> >
> > I also see what looks like hardening-related CXXFLAGS during the build.
> > Stuff like this:
> >
> > -D_FORTIFY_SOURCE=2 -I./src -I./src  -g -O2 -fPIE -fstack-protector
> > --param=ssp-buffer-size=4 -Wformat -Werror=format-security
> >
> > The warning appears on mentors.debian.net:
> > http://mentors.debian.net/package/capnproto
> >
> > Maybe related to this bug:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673112#10
> >
> > Based on this bug & assuming you can see the _FORTIFY_SOURCE etc. during
> > your build I'd be inclined to add another override for this -- what do
> you
> > think?
> >
> > Weird I can't reproduce it locally.
>
> Try with "hardening-check" then:
> /usr/bin/capnp:
>  Position Independent Executable: yes
>  Stack protected: yes
>  Fortify Source functions: no, only unprotected functions found!
>  Read-only relocations: yes
>  Immediate binding: yes
>
> The unprotected functions are getcwd() and memcpy().
>
> In the bug you pointed, it seems that memcpy() can be left unprotected
> when it is used in replacement of strcpy(). Maybe there is no other
> issue with getcwd(). Since there is no use of other commonly protected
> functions like *printf(), this should be a false positive. Therefore,
> yes, add a lintian override.
>
> >> Well, you shouldn't get this warning. Maybe it was here because you were
> >> build-depending on python-support?
> >>
> >
> > Doesn't seem that way. From the control file:
> >
> > Build-Depends: debhelper (>= 8.0.0), gcc (>= 4.7),
> >  python-all (>= 2.6), dpkg-dev (>= 1.16.1.1), docbook-xsl, docbook-xml,
> >  xsltproc, autotools-dev
> >
> > Removed --with python2 from debian/rules and I see this near the end of
> the
> > build:
> >
> > ...
> >dh_install
> >dh_installdocs
> >dh_installchangelogs
> >dh_installman
> >dh_pysupport
> > dh_pysupport: This program is deprecated, you should use dh_python2
> > instead. Migration guide: http://deb.li/dhs2p
>
> Oh, OK. Just ignore this warning. dh_pysupport is just called because
> you are using compat 8 and it is installed.
> --
> Make your program read from top to bottom.
> - The Elements of Programming Style (Kernighan & Plauger)
>



-- 
*Tom Lee */ http://tomlee.co / @tglee

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-19 Thread Vincent Bernat 
 ❦ 19 août 2013 11:46 CEST, Tom Lee  :

>> The easiest way is to use Lintian (I use it with -viI).
>>
>>
> Odd, I don't see any warnings:
>
> tom@desktop:~/Source$ lintian -viI capnproto_0.2.0-1.dsc
> N: Using profile debian/main.
> N: Setting up lab in /tmp/temp-lintian-lab-q9W0nEVK6F ...
> N: Unpacking packages in group capnproto/0.2.0-1
> N: 
> N: Processing source package capnproto (version 0.2.0-1, arch source) ...
>
> I also see what looks like hardening-related CXXFLAGS during the build.
> Stuff like this:
>
> -D_FORTIFY_SOURCE=2 -I./src -I./src  -g -O2 -fPIE -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security
>
> The warning appears on mentors.debian.net:
> http://mentors.debian.net/package/capnproto
>
> Maybe related to this bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673112#10
>
> Based on this bug & assuming you can see the _FORTIFY_SOURCE etc. during
> your build I'd be inclined to add another override for this -- what do you
> think?
>
> Weird I can't reproduce it locally.

Try with "hardening-check" then:
/usr/bin/capnp:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

The unprotected functions are getcwd() and memcpy().

In the bug you pointed, it seems that memcpy() can be left unprotected
when it is used in replacement of strcpy(). Maybe there is no other
issue with getcwd(). Since there is no use of other commonly protected
functions like *printf(), this should be a false positive. Therefore,
yes, add a lintian override.

>> Well, you shouldn't get this warning. Maybe it was here because you were
>> build-depending on python-support?
>>
>
> Doesn't seem that way. From the control file:
>
> Build-Depends: debhelper (>= 8.0.0), gcc (>= 4.7),
>  python-all (>= 2.6), dpkg-dev (>= 1.16.1.1), docbook-xsl, docbook-xml,
>  xsltproc, autotools-dev
>
> Removed --with python2 from debian/rules and I see this near the end of the
> build:
>
> ...
>dh_install
>dh_installdocs
>dh_installchangelogs
>dh_installman
>dh_pysupport
> dh_pysupport: This program is deprecated, you should use dh_python2
> instead. Migration guide: http://deb.li/dhs2p

Oh, OK. Just ignore this warning. dh_pysupport is just called because
you are using compat 8 and it is installed.
-- 
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-19 Thread Tom Lee 
On Mon, Aug 19, 2013 at 1:47 AM, Vincent Bernat  wrote:

>  ❦ 19 août 2013 09:56 CEST, Tom Lee  :
>
> >>  - The hardening stuff does not seem to work correctly. Maybe you could
> >>just try with debhelper 9 and debian/compat to 9 to have them apply
> >>automatically.
> >>
> >>
> > Happy to try compat 9, but what can I do to verify that the hardening
> stuff
> > has been fixed? I mean, what's telling you that it's not working
> correctly?
> > Maybe I need to go reading more documentation.
>
> The easiest way is to use Lintian (I use it with -viI).
>
>
Odd, I don't see any warnings:

tom@desktop:~/Source$ lintian -viI capnproto_0.2.0-1.dsc
N: Using profile debian/main.
N: Setting up lab in /tmp/temp-lintian-lab-q9W0nEVK6F ...
N: Unpacking packages in group capnproto/0.2.0-1
N: 
N: Processing source package capnproto (version 0.2.0-1, arch source) ...

I also see what looks like hardening-related CXXFLAGS during the build.
Stuff like this:

-D_FORTIFY_SOURCE=2 -I./src -I./src  -g -O2 -fPIE -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security

The warning appears on mentors.debian.net:
http://mentors.debian.net/package/capnproto

Maybe related to this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673112#10

Based on this bug & assuming you can see the _FORTIFY_SOURCE etc. during
your build I'd be inclined to add another override for this -- what do you
think?

Weird I can't reproduce it locally.


> >>  - You use --with python2. I don't see any Python files in the resulting
> >>packages. Therefore, you don't need to use dh_python2. I suppose
> >>Python is only used in tests. Just keep it as a Build-Depends.
> >>
> >>
> > I can do that, but without it I think I was getting a warning about
> > python-support being deprecated & I should use --with python2 to "fix"
> it.
> > I'll try it again tomorrow to be sure, but is that safe enough to ignore?
> > Easy enough either way.
>
> Well, you shouldn't get this warning. Maybe it was here because you were
> build-depending on python-support?
>

Doesn't seem that way. From the control file:

Build-Depends: debhelper (>= 8.0.0), gcc (>= 4.7),
 python-all (>= 2.6), dpkg-dev (>= 1.16.1.1), docbook-xsl, docbook-xml,
 xsltproc, autotools-dev

Removed --with python2 from debian/rules and I see this near the end of the
build:

...
   dh_install
   dh_installdocs
   dh_installchangelogs
   dh_installman
   dh_pysupport
dh_pysupport: This program is deprecated, you should use dh_python2
instead. Migration guide: http://deb.li/dhs2p
   dh_lintian
   dh_perl
   dh_link
   dh_compress
   dh_fixperms
   dh_strip
   dh_makeshlibs
...

Adding --with python2 back in makes the warning go away. I'm not really
sure I understand why the Python debhelper stuff is being invoked at all,
so I'm happy to go with whatever you feel is best here.

Cheers,
Tom


> --
> if (user_specified)
> /* Didn't work, but the user is convinced this is the
>  * place. */
> 2.4.0-test2 /usr/src/linux/drivers/parport/parport_pc.c
>



-- 
*Tom Lee */ http://tomlee.co / @tglee

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-19 Thread Vincent Bernat 
 ❦ 19 août 2013 09:56 CEST, Tom Lee  :

>>  - The hardening stuff does not seem to work correctly. Maybe you could
>>just try with debhelper 9 and debian/compat to 9 to have them apply
>>automatically.
>>
>>
> Happy to try compat 9, but what can I do to verify that the hardening stuff
> has been fixed? I mean, what's telling you that it's not working correctly?
> Maybe I need to go reading more documentation.

The easiest way is to use Lintian (I use it with -viI).

>>  - You use --with python2. I don't see any Python files in the resulting
>>packages. Therefore, you don't need to use dh_python2. I suppose
>>Python is only used in tests. Just keep it as a Build-Depends.
>>
>>
> I can do that, but without it I think I was getting a warning about
> python-support being deprecated & I should use --with python2 to "fix" it.
> I'll try it again tomorrow to be sure, but is that safe enough to ignore?
> Easy enough either way.

Well, you shouldn't get this warning. Maybe it was here because you were
build-depending on python-support?
-- 
if (user_specified)
/* Didn't work, but the user is convinced this is the
 * place. */
2.4.0-test2 /usr/src/linux/drivers/parport/parport_pc.c


signature.asc
Description: PGP signature

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-19 Thread Tom Lee 
On Mon, Aug 19, 2013 at 12:28 AM, Vincent Bernat  wrote:

> OK, it works for me too.
>
>
Great!


> > I've also explicitly removed the .symbols file as I found the Policy
> Manual
> > explicitly talks about C++ libraries in the last paragraph of section
> 8.6 (
> >
> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-depends
> > ):
>
> Please add a lintian override for this:
> libcapnp-0.2.0: no-symbols-control-file usr/lib/libcapnp-0.2.0.so
>
>
Will do.


> > Last of all, I've just built & uploaded a new build of 0.2.0-1 with the
> > changes you suggested in your original review, plus the changes discussed
> > in this email:
> >
> >
> http://mentors.debian.net/debian/pool/main/c/capnproto/capnproto_0.2.0-1.dsc
> >
> > Thanks! Please let me know if I can do anything else to move this
> forward.
>
> So, a few other comments:
>
>  - Remove the comments at the top of debian/rules, they clutter it and
>they do not match the content (since you are using the tiny debhelper
>set). Don't even keep the DH_VERBOSE stuff
>
>
Likewise.


>  - The hardening stuff does not seem to work correctly. Maybe you could
>just try with debhelper 9 and debian/compat to 9 to have them apply
>automatically.
>
>
Happy to try compat 9, but what can I do to verify that the hardening stuff
has been fixed? I mean, what's telling you that it's not working correctly?
Maybe I need to go reading more documentation.


>  - Use DEP3 (http://dep.debian.net/deps/dep3/) to describe the patchs
>that you add (with Author, Description and Forwarded fields).

 - You ship the .la file and empty the dependency_libs field. I think
>that you can just not ship it at all. There was a release goal to
>remove them. Since you don't have any reverse dependency, it is
>better to not ship it.
>
>
Ah I see -- I'll omit the .la.


>  - You use --with python2. I don't see any Python files in the resulting
>packages. Therefore, you don't need to use dh_python2. I suppose
>Python is only used in tests. Just keep it as a Build-Depends.
>
>
I can do that, but without it I think I was getting a warning about
python-support being deprecated & I should use --with python2 to "fix" it.
I'll try it again tomorrow to be sure, but is that safe enough to ignore?
Easy enough either way.


>  - In debian/control, don't start the short description with a capital
>for capnproto.
>
>
Shall do.

Should be able to push a new build of this package tomorrow. Thanks again!

-- 
*Tom Lee */ http://tomlee.co / @tglee

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-19 Thread Vincent Bernat 
 ❦ 19 août 2013 07:57 CEST, Tom Lee  :

> Also incorporated part of an upstream patch for another potential,
> seemingly unrelated memory corruption issue that didn't quite make the
> 0.2.0 release.
>
> Let me know if you still can't build from source with these two changes in
> place.

OK, it works for me too.

> I've also explicitly removed the .symbols file as I found the Policy Manual
> explicitly talks about C++ libraries in the last paragraph of section 8.6 (
> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-depends
> ):

Please add a lintian override for this:
libcapnp-0.2.0: no-symbols-control-file usr/lib/libcapnp-0.2.0.so

> Last of all, I've just built & uploaded a new build of 0.2.0-1 with the
> changes you suggested in your original review, plus the changes discussed
> in this email:
>
> http://mentors.debian.net/debian/pool/main/c/capnproto/capnproto_0.2.0-1.dsc
>
> Thanks! Please let me know if I can do anything else to move this forward.

So, a few other comments:

 - Remove the comments at the top of debian/rules, they clutter it and
   they do not match the content (since you are using the tiny debhelper
   set). Don't even keep the DH_VERBOSE stuff

 - The hardening stuff does not seem to work correctly. Maybe you could
   just try with debhelper 9 and debian/compat to 9 to have them apply
   automatically.

 - Use DEP3 (http://dep.debian.net/deps/dep3/) to describe the patchs
   that you add (with Author, Description and Forwarded fields).

 - You ship the .la file and empty the dependency_libs field. I think
   that you can just not ship it at all. There was a release goal to
   remove them. Since you don't have any reverse dependency, it is
   better to not ship it.

 - You use --with python2. I don't see any Python files in the resulting
   packages. Therefore, you don't need to use dh_python2. I suppose
   Python is only used in tests. Just keep it as a Build-Depends.

 - In debian/control, don't start the short description with a capital
   for capnproto.

Everything else seems OK.
-- 
 /*
  * Hash table gook..
  */
2.4.0-test2 /usr/src/linux/fs/buffer.c


signature.asc
Description: PGP signature

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-18 Thread Tom Lee 
Compiler issue doesn't appear to be a Debian bug. Kenton just filed
upstream, logging it here for posterity:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58192

Again, the capnproto package now builds with the -DNDEBUG flag which
enables some inlining that happens to work around this bug.


On Sun, Aug 18, 2013 at 11:14 PM, Vincent Bernat  wrote:

>  ❦ 19 août 2013 01:34 CEST, Tom Lee  :
>
> > I'm thinking maybe I rip out the symbols file all together for now --
> > it sounds like the tooling isn't there for it yet. What do you think?
>
> Yes, just remove it.
> --
> Watch out for off-by-one errors.
> - The Elements of Programming Style (Kernighan & Plauger)
>



-- 
*Tom Lee */ http://tomlee.co / @tglee

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-18 Thread Vincent Bernat 
 ❦ 19 août 2013 01:34 CEST, Tom Lee  :

> I'm thinking maybe I rip out the symbols file all together for now --
> it sounds like the tooling isn't there for it yet. What do you think?

Yes, just remove it.
-- 
Watch out for off-by-one errors.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-18 Thread Tom Lee 
Kenton (upstream maintainer) has narrowed this down to a compiler bug that
only occurs during a build without the -DNDEBUG flag set. Typically the
NDEBUG flag is set if CXXFLAGS are left unspecified, but the Debian build
scripts obviously meddle with those a little. To work around this, I've
explicitly added the -DNDEBUG flag in via DEB_CXXFLAGS_MAINT_APPEND.

Unclear whether this is an upstream issue in GCC or a bug in Debian/Ubuntu
patches. Kenton reproduced this with Ubuntu's patches against 4.8, so
evidence seems to hint at upstream -- though Ubuntu is probably using many
of the Debian patches too, I guess.

Also incorporated part of an upstream patch for another potential,
seemingly unrelated memory corruption issue that didn't quite make the
0.2.0 release.

Let me know if you still can't build from source with these two changes in
place.

I've also explicitly removed the .symbols file as I found the Policy Manual
explicitly talks about C++ libraries in the last paragraph of section 8.6 (
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-depends
):

"symbols files are therefore recommended for most shared library packages
since they provide more accurate dependencies. For most C libraries, the
additional detail required by symbols files is not too difficult to
maintain. However, maintaining exhaustive symbols information for a C++
library can be quite onerous, so shlibs files may be more appropriate for
most C++ libraries."

I've already got a shlibs file in place for libcapnp-0.2.0, so I think
that's enough.

Last of all, I've just built & uploaded a new build of 0.2.0-1 with the
changes you suggested in your original review, plus the changes discussed
in this email:

http://mentors.debian.net/debian/pool/main/c/capnproto/capnproto_0.2.0-1.dsc

Thanks! Please let me know if I can do anything else to move this forward.

-- 
Tom Lee / http://tomlee.co / @tglee

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-18 Thread Tom Lee 
Oh nice -- I didn't realize that pbuilder/cowbuilder actually created
chroots and all that, thought they were just an alternative to things
like debuild & gbp. Really should RTFM eh? :)

I'm working with the upstream maintainer to address the crash.

I notice that even if I disable the tests all together, the build's
failing because of issues with the symbols file (presumably g++
version changes generating different symbols or something). That wiki
page you linked me to earlier RE: C++ symbols files led me to this
interesting blog post:

http://www.eyrie.org/~eagle/journal/2012-02/001.html

Russ explains in more detail, but the interesting points:

"I wanted to give a final update of my experiment with adding symbols
files to C++ library packages.

In the end, I reverted the changes and have gone back to not providing
a symbols file, and instead just using shlibs. <...>

But there are also tool issues. The biggest that I ran into is that
symbols appear and disappear in the export list with different
versions of the compiler, <...>

<...> but I think that the level of work and remaining fragility
doesn't make sense for a lot of C++ libraries, at least right now
without more direct support in dpkg-gensymbols and other tool
improvements. <...>"

I'm thinking maybe I rip out the symbols file all together for now --
it sounds like the tooling isn't there for it yet. What do you think?

Cheers,
Tom

On Sun, Aug 18, 2013 at 2:04 PM, Vincent Bernat  wrote:
>  ❦ 18 août 2013 22:53 CEST, Tom Lee  :
>
>> Ah, the Debug.Log hang seems like it might relate to a missing
>> /proc/self/exe symlink -- probably because I didn't mount the /proc
>> filesystem. Here's the relevant bit of strace output:
>>
>> [pid  7463] write(3, "[   OK ] Exception.Exception"..., 143 > ...>
>> [pid 13045] readlink("/proc/self/exe",  
>> [pid  7463] <... write resumed> )   = 143
>> [pid 13045] <... readlink resumed> 0x7fff11d94460, 512) = -1 ENOENT
>> (No such file or directory)
>> [pid  7463] read(0, "[ RUN  ] Debug.Log\n", 8192) = 23
>> [pid  7463] write(1, "[ RUN  ] Debug.Log\n", 23[ RUN  ] Debug.Log
>> ) = 23
>> [pid 13045] futex(0x2baa75e0, FUTEX_WAIT_PRIVATE, 2, NULL > ...>
>> [pid  7463] write(3, "[ RUN  ] Debug.Log\n", 23) = 23
>> [pid  7463] read(0,
>>
>> The last two futex(...) & read(...) calls wait around forever.
>>
>> Might be a silly question, but I'm guessing it's standard practice to
>> mount /proc when doing these chrooted builds?
>>
>> And assuming the build servers are using a chroot, can I also assume
>> they will mount procfs on /proc prior to executing a build?
>>
>> Either way, I'm going to mount /proc in my chroot & try again.
>
> Yes, you can count on /proc being present. And you should really try
> pbuilder or cowbuilder. This is just a matter of doing:
>
>  cowbuilder --create
>  cowbuilder --update
>  cowbuilder --build your.dsc
> --
> panic("Oh boy, that early out of memory?");
> 2.2.16 /usr/src/linux/arch/mips/mm/init.c



-- 
Tom Lee / http://tomlee.co / @tglee


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-18 Thread Vincent Bernat 
 ❦ 18 août 2013 22:53 CEST, Tom Lee  :

> Ah, the Debug.Log hang seems like it might relate to a missing
> /proc/self/exe symlink -- probably because I didn't mount the /proc
> filesystem. Here's the relevant bit of strace output:
>
> [pid  7463] write(3, "[   OK ] Exception.Exception"..., 143  ...>
> [pid 13045] readlink("/proc/self/exe",  
> [pid  7463] <... write resumed> )   = 143
> [pid 13045] <... readlink resumed> 0x7fff11d94460, 512) = -1 ENOENT
> (No such file or directory)
> [pid  7463] read(0, "[ RUN  ] Debug.Log\n", 8192) = 23
> [pid  7463] write(1, "[ RUN  ] Debug.Log\n", 23[ RUN  ] Debug.Log
> ) = 23
> [pid 13045] futex(0x2baa75e0, FUTEX_WAIT_PRIVATE, 2, NULL 
> [pid  7463] write(3, "[ RUN  ] Debug.Log\n", 23) = 23
> [pid  7463] read(0,
>
> The last two futex(...) & read(...) calls wait around forever.
>
> Might be a silly question, but I'm guessing it's standard practice to
> mount /proc when doing these chrooted builds?
>
> And assuming the build servers are using a chroot, can I also assume
> they will mount procfs on /proc prior to executing a build?
>
> Either way, I'm going to mount /proc in my chroot & try again.

Yes, you can count on /proc being present. And you should really try
pbuilder or cowbuilder. This is just a matter of doing:

 cowbuilder --create
 cowbuilder --update
 cowbuilder --build your.dsc
-- 
panic("Oh boy, that early out of memory?");
2.2.16 /usr/src/linux/arch/mips/mm/init.c


signature.asc
Description: PGP signature

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-18 Thread Tom Lee 
Ah, the Debug.Log hang seems like it might relate to a missing
/proc/self/exe symlink -- probably because I didn't mount the /proc
filesystem. Here's the relevant bit of strace output:

[pid  7463] write(3, "[   OK ] Exception.Exception"..., 143 
[pid 13045] readlink("/proc/self/exe",  
[pid  7463] <... write resumed> )   = 143
[pid 13045] <... readlink resumed> 0x7fff11d94460, 512) = -1 ENOENT
(No such file or directory)
[pid  7463] read(0, "[ RUN  ] Debug.Log\n", 8192) = 23
[pid  7463] write(1, "[ RUN  ] Debug.Log\n", 23[ RUN  ] Debug.Log
) = 23
[pid 13045] futex(0x2baa75e0, FUTEX_WAIT_PRIVATE, 2, NULL 
[pid  7463] write(3, "[ RUN  ] Debug.Log\n", 23) = 23
[pid  7463] read(0,

The last two futex(...) & read(...) calls wait around forever.

Might be a silly question, but I'm guessing it's standard practice to
mount /proc when doing these chrooted builds?

And assuming the build servers are using a chroot, can I also assume
they will mount procfs on /proc prior to executing a build?

Either way, I'm going to mount /proc in my chroot & try again.


On Sun, Aug 18, 2013 at 1:30 PM, Tom Lee  wrote:
> Interesting, I'm seeing the Debug.Log tests hang when building in a
> wheezy chroot.
>
> I'll play around with this a little more & try to reproduce in sid
> with pbuilder. I'll follow up when I have more info.
>
> Thanks for trying this out!
>
> On Sun, Aug 18, 2013 at 1:14 PM, Vincent Bernat  wrote:
>>  ❦ 18 août 2013 20:29 CEST, Vincent Bernat  :
>>
 Weird -- I'll try that out myself & see if I can figure out what's
 going wrong.
>>>
>>> I'll try again at home, I am on my laptop currently with limited
>>> Internet access. Did you use something like pbuilder/cowbuilder?  If
>>> not, you should. But I don't see how this could lead to such a
>>> backtrace.
>>
>> Same problem at home. I am building on AMD64. Please try in a sid
>> pbuilder if you didn't.
>> --
>> Use data arrays to avoid repetitive control sequences.
>> - The Elements of Programming Style (Kernighan & Plauger)
>
>
>
> --
> Tom Lee / http://tomlee.co / @tglee



-- 
Tom Lee / http://tomlee.co / @tglee


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-18 Thread Tom Lee 
Interesting, I'm seeing the Debug.Log tests hang when building in a
wheezy chroot.

I'll play around with this a little more & try to reproduce in sid
with pbuilder. I'll follow up when I have more info.

Thanks for trying this out!

On Sun, Aug 18, 2013 at 1:14 PM, Vincent Bernat  wrote:
>  ❦ 18 août 2013 20:29 CEST, Vincent Bernat  :
>
>>> Weird -- I'll try that out myself & see if I can figure out what's
>>> going wrong.
>>
>> I'll try again at home, I am on my laptop currently with limited
>> Internet access. Did you use something like pbuilder/cowbuilder?  If
>> not, you should. But I don't see how this could lead to such a
>> backtrace.
>
> Same problem at home. I am building on AMD64. Please try in a sid
> pbuilder if you didn't.
> --
> Use data arrays to avoid repetitive control sequences.
> - The Elements of Programming Style (Kernighan & Plauger)



-- 
Tom Lee / http://tomlee.co / @tglee


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-18 Thread Vincent Bernat 
 ❦ 18 août 2013 20:29 CEST, Vincent Bernat  :

>> Weird -- I'll try that out myself & see if I can figure out what's
>> going wrong.
>
> I'll try again at home, I am on my laptop currently with limited
> Internet access. Did you use something like pbuilder/cowbuilder?  If
> not, you should. But I don't see how this could lead to such a
> backtrace.

Same problem at home. I am building on AMD64. Please try in a sid
pbuilder if you didn't.
-- 
Use data arrays to avoid repetitive control sequences.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-18 Thread Vincent Bernat 
 ❦ 18 août 2013 20:17 CEST, Tom Lee  :

>> Glad to see you are working on this package.
>>
>> debian/control: why do you depend explicitely on such a version of GCC?
>> The README states gcc 4.7+ but your version excludes GCC as in Wheezy.
>>
>
> I chose to use the version that I built with (though in retrospect I
> don't think I should've had that tilde in there), thinking that if
> it's in testing now it should be readily available on unstable, but I
> didn't think about wheezy.
>
> I've updated the Build-Depends to look like this:
>
> Build-Depends: debhelper (>= 8.0.0), gcc (>= 4.7.0~) ...

Since gcc version is something like 4.7.5-2, you can either go for (>=
4.7) or (>= 4.7.0-3~). The second form is needed only if you need at
least this precise version as released in Debian. The ~ is here to
accomodate backports. You should use the first form, I think: the
required version of gcc does not depend on the packaging.

>> capnproto-doc.docs, capnproto-doc.install, capnproto.install have some
>> odd contents. For .install, it would be the first time I see a directory
>> without a wildcard in it. Maybe this works but this seems unusual to me.
>>
>
> Hm. I don't create a separate -doc package -- is this necessary for
> landing this package? If not, I'd be inclined to remove the *-doc.*
> files all together.

OK, I didn't look carefully enough. I assumed there was a package with
documentations. You don't have to have such a package if the
documentation is not shared between packages or is small.

> I actually got the directory-without-a-wildcard thing from the protobuf 
> package:
>
>   tom@desktop:~/Source/protobuf-2.4.1$ cat debian/protobuf-compiler.install
>   usr/bin
>
> Seems to work fine, but I can change it if it's at odds with the usual
> style.

OK, I didn't know this was possible. If it works, keep it.

>> In C++, the symbols file will change depending on the
>> architecture. Therefore, you should use demangled names by using
>> c++filt. See:  https://wiki.debian.org/UsingSymbolsFiles
>>
>
> I followed the instructions on the wiki page, but there still seems to
> be some mangled names in the symbols file, e.g. the first few lines
> here:
[...]

Unfortunately¸ this C++ voodoo is a bit magic for me. We can pass the
package as is and wait for builders to build for all archs and see what
the symbols on other archs look like.

>> I am unable to compile the package on a clean chroot. The unittests
>> fail:
>>
>> 
>>
>
> Weird -- I'll try that out myself & see if I can figure out what's
> going wrong.

I'll try again at home, I am on my laptop currently with limited
Internet access. Did you use something like pbuilder/cowbuilder?  If
not, you should. But I don't see how this could lead to such a
backtrace.
-- 
printk("What? oldfid != cii->c_fid. Call 911.\n");
2.4.3 linux/fs/coda/cnode.c


signature.asc
Description: PGP signature

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-18 Thread Tom Lee 
Hi Vincent,

Thanks for the review! Questions & comments below:

On Sun, Aug 18, 2013 at 9:27 AM, Vincent Bernat  wrote:
> Hi Tom!
>
> Glad to see you are working on this package.
>
> debian/control: why do you depend explicitely on such a version of GCC?
> The README states gcc 4.7+ but your version excludes GCC as in Wheezy.
>

I chose to use the version that I built with (though in retrospect I
don't think I should've had that tilde in there), thinking that if
it's in testing now it should be readily available on unstable, but I
didn't think about wheezy.

I've updated the Build-Depends to look like this:

Build-Depends: debhelper (>= 8.0.0), gcc (>= 4.7.0~) ...

> debian/copyright: just to let you know that it is usually easier to use
> the same license for debian/* than for the package. For example, this
> would allow upstream to pick your eventual patches without having having
> a license conflict. But this is not a necessity.
>

Ah, of course -- I've changed it to 2-clause BSD.

> capnproto-doc.docs, capnproto-doc.install, capnproto.install have some
> odd contents. For .install, it would be the first time I see a directory
> without a wildcard in it. Maybe this works but this seems unusual to me.
>

Hm. I don't create a separate -doc package -- is this necessary for
landing this package? If not, I'd be inclined to remove the *-doc.*
files all together.

FWIW, the only docs available in the upstream package is a brief
README (at least in the latest release tarball) & the only docs
available for this package atm is the manpage I wrote for the capnp
command.

I actually got the directory-without-a-wildcard thing from the protobuf package:

  tom@desktop:~/Source/protobuf-2.4.1$ cat debian/protobuf-compiler.install
  usr/bin

Seems to work fine, but I can change it if it's at odds with the usual style.

> README.source content is bogus too, remove it.
>

Done.

> In debian/rules, remove the comments saying this is a sample. This is no
> longer a sample.
>

Also done.

> In C++, the symbols file will change depending on the
> architecture. Therefore, you should use demangled names by using
> c++filt. See:  https://wiki.debian.org/UsingSymbolsFiles
>

I followed the instructions on the wiki page, but there still seems to
be some mangled names in the symbols file, e.g. the first few lines
here:

 
(c++)"_ZN2kj10StringTree6concatIJNS_8ArrayPtrIKcEES0_NS_10FixedArrayIcLm1EES0_DpOT_@Base"
0.2.0
 (c++)"_ZN2kj10StringTree6concatIJNS_8ArrayPtrIKcEES4_S0_EEES0_DpOT_@Base" 0.2.0
 (c++)"kj::StringTree::StringTree(kj::Array&&,
kj::StringPtr)@Base" 0.2.0
 (c++)"kj::StringTree::StringTree(kj::Array&&,
kj::StringPtr)@Base" 0.2.0

Is that a problem? I've got to head out for a while, but I'll have a
read through the rest of that documentation later today & see if
there's anything enlightening in there.

> I am unable to compile the package on a clean chroot. The unittests
> fail:
>
> 
>

Weird -- I'll try that out myself & see if I can figure out what's going wrong.

Cheers,
Tom

-- 
Tom Lee / http://tomlee.co / @tglee


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-18 Thread Vincent Bernat 
 ❦ 18 août 2013 07:45 CEST, Tom Lee  :

> I am looking for a sponsor for my package "capnproto":
>
> * Package name: capnproto
>   Version : 0.2.0-1
>   Upstream Author : Kenton Varda 
> * URL : http://capnproto.org
> * License : BSD-2-clause
>   Section : devel

Hi Tom!

Glad to see you are working on this package.

debian/control: why do you depend explicitely on such a version of GCC?
The README states gcc 4.7+ but your version excludes GCC as in Wheezy.

debian/copyright: just to let you know that it is usually easier to use
the same license for debian/* than for the package. For example, this
would allow upstream to pick your eventual patches without having having
a license conflict. But this is not a necessity.

capnproto-doc.docs, capnproto-doc.install, capnproto.install have some
odd contents. For .install, it would be the first time I see a directory
without a wildcard in it. Maybe this works but this seems unusual to me.

README.source content is bogus too, remove it.

In debian/rules, remove the comments saying this is a sample. This is no
longer a sample.

In C++, the symbols file will change depending on the
architecture. Therefore, you should use demangled names by using
c++filt. See:  https://wiki.debian.org/UsingSymbolsFiles

I am unable to compile the package on a clean chroot. The unittests
fail:

src/capnp/encoding-test.c++:37: Failure
Value of: reader.size()
  Actual: 1348
Expected: expected.size()
Which is: 4
src/capnp/encoding-test.c++:37: Failure
Value of: reader.size()
  Actual: 1348
Expected: expected.size()
Which is: 4
src/capnp/encoding-test.c++:37: Failure
Value of: reader.size()
  Actual: 4068
Expected: expected.size()
Which is: 4
src/capnp/encoding-test.c++:37: Failure
Value of: reader.size()
  Actual: 4068
Expected: expected.size()
Which is: 4
src/capnp/encoding-test.c++:37: Failure
Value of: reader.size()
  Actual: 4068
Expected: expected.size()
Which is: 4
src/capnp/encoding-test.c++:37: Failure
Value of: reader.size()
  Actual: 4068
Expected: expected.size()
Which is: 4
*** Error in `/tmp/buildd/capnproto-0.2.0/.libs/lt-capnp-test': malloc(): 
memory corruption (fast): 0x2acd6240 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x7aa26)[0x2c2eda26]
/lib/x86_64-linux-gnu/libc.so.6(+0x7cca5)[0x2c2efca5]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x63)[0x2c2f1093]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_Znwm+0x1d)[0x2babae3d]
/tmp/buildd/capnproto-0.2.0/.libs/libcapnp-0.2.0.so(_ZN2kj1_17HeapArrayDisposer12allocateImplEmmmPFvPvES4_+0x24)[0x2b795404]
/tmp/buildd/capnproto-0.2.0/.libs/libcapnp-0.2.0.so(_ZN2kj10heapStringEm+0x23)[0x2b795f03]
/tmp/buildd/capnproto-0.2.0/.libs/lt-capnp-test(_ZN2kj1_6concatIINS_8ArrayPtrIKcENS_6StringEDpOT_+0x15)[0x2ab09985]
/tmp/buildd/capnproto-0.2.0/.libs/libcapnp-0.2.0.so(_ZN2kj1_5Debug5FaultC1IJRA56_KcEEEPS4_iNS_9Exception6NatureEiS7_S7_DpOT_+0x5a)[0x2b79d72a]
/tmp/buildd/capnproto-0.2.0/.libs/libcapnp-0.2.0.so(_ZN5capnp1_11WireHelpers22getWritableListPointerEPNS0_11WirePointerEPNS_4wordEPNS0_14SegmentBuilderENS0_9FieldSizeEPKS4_+0x275)[0x2b7b6d95]
/tmp/buildd/capnproto-0.2.0/.libs/libcapnp-0.2.0.so(_ZN5capnp1_13StructBuilder12getListFieldEjNS0_9FieldSizeEPKNS_4wordE+0x2d)[0x2b7b193d]
/tmp/buildd/capnproto-0.2.0/.libs/lt-capnp-test(+0x117f20)[0x2abc2f20]
/tmp/buildd/capnproto-0.2.0/.libs/lt-capnp-test(+0x110b90)[0x2a90]
/tmp/buildd/capnproto-0.2.0/gtest/lib/.libs/libgtest.so.0(_ZN7testing8internal35HandleExceptionsInMethodIfSupportedINS_4TestEvEET0_PT_MS4_FS3_vEPKc+0x33)[0x2b3351f3]
/tmp/buildd/capnproto-0.2.0/gtest/lib/.libs/libgtest.so.0(_ZN7testing4Test3RunEv+0xb7)[0x2b32d5d7]
/tmp/buildd/capnproto-0.2.0/gtest/lib/.libs/libgtest.so.0(_ZN7testing8TestInfo3RunEv+0x9e)[0x2b32d67e]
/tmp/buildd/capnproto-0.2.0/gtest/lib/.libs/libgtest.so.0(_ZN7testing8TestCase3RunEv+0xa5)[0x2b32d785]
/tmp/buildd/capnproto-0.2.0/gtest/lib/.libs/libgtest.so.0(_ZN7testing8internal12UnitTestImpl11RunAllTestsEv+0x238)[0x2b32da28]
/tmp/buildd/capnproto-0.2.0/gtest/lib/.libs/libgtest.so.0(_ZN7testing8UnitTest3RunEv+0x37)[0x2b32dcb7]
/tmp/buildd/capnproto-0.2.0/gtest/lib/.libs/libgtest_main.so.0(main+0x39)[0x2b546969]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2c294995]
/tmp/buildd/capnproto-0.2.0/.libs/lt-capnp-test(+0x2c1be)[0x2aad71be]
=== Memory map: 
2aaab000-2acb3000 r-xp  fe:06 406462 
/tmp/buildd/capnproto-0.2.0/.libs/lt-capnp-test
2acb3000-2acb7000 rw-p  00:00 0
2acb8000-2adbf000 rw-p  00:00 0
2aeb3000-2aec1000 r--p 00208000 fe:06 406462 
/tmp/buildd/capnproto-0.2.0/.libs/lt-capnp-test
2aec1000-2aec2000 rw-p 00216000 fe:06 406462 
/tmp/buildd/capnproto-0.2.0/.libs/lt-capnp-test
2aec2000-2aee3000 r-xp  fe:06 136324 
/lib

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format

2013-08-17 Thread Tom Lee 
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "capnproto":

* Package name: capnproto
  Version : 0.2.0-1
  Upstream Author : Kenton Varda 
* URL : http://capnproto.org
* License : BSD-2-clause
  Section : devel

It builds those binary packages:

  capnproto - Tool for working with the Cap'n Proto data interchange format
  libcapnp-0.2.0 - Cap'n Proto C++ library
  libcapnp-dev - Cap'n Proto C++ library (development files)

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/capnproto

Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/c/capnproto/capnproto_0.2.0-1.dsc

More information about Cap'n Proto can be obtained from http://capnproto.org.

Changes since the last upload:

* Initial release (Closes: #719782)

Regards,
Tom Lee

-- 
Tom Lee / http://tomlee.co / @tglee


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org