Bug#819615: RFS: spin/6.4.5-1 [ITP] -- formal software verification tool

[Tom Lee]

Cheers for the review Mattia! I'll look into all of this. A few comments:

On Sun, May 15, 2016 at 9:19 AM, Mattia Rizzolo  wrote:

> ...
> * d/patches/01_makefile_fixes.patch:
>   + Probably use += instead of ?= in the first CFLAGS?
>   + I'd rather use install(1) instead of cp(1)
>   + Really forward at least the DESTDIR/INSTALL change
>

Yes, thanks for reminding me -- do intend to follow up with upstream. I'm
curious if this makefile was perhaps written for some crusty old version of
make that doesn't do well with the "optional assignment" syntax used for
DESTDIR/INSTALL. I had similar questions about the use of cp vs. install.
I'll see if upstream has any strong attachment to any of this.


> * d/patches/02_manpage_fixes.patch:
>   + what's blocking you from forwarding this patch?
>

Nothing at all, it just hasn't been done yet.


> * d/rules:
>   + get rid of all those useless comments
>   + DPKG_EXPORT_BUILDFLAGS and the inclusion of buildflags.mk is
> useless, please read debhelper(7)
>   + trailing whitespace at line 22
>   + what's wrong with using --sourcedirectory on the dh(1) call instead
> of overriding everything like that?
>

Oh much better idea, didn't know I could do that.


>   + I'd avoid that "INSTALL=install -D" by patching correctly the
> makefile to default INSTALL on install(1) instead of cp(1) (as I
> said above)
>

Sure.

Thanks again!

Bug#819615: RFS: spin/6.4.5-1 [ITP] -- formal software verification tool

[Tom Lee]

Still looking for a sponsor for the spin verification tool. I added a
spin-dbg binary package to the mix earlier today:

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

Builds fine in pbuilder, is lint clean, etc. Appreciate reviews too!

-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#819615: RFS: spin/6.4.5-1 [ITP] -- formal software verification tool

[Tom Lee]

Great, got it -- thanks Paul. Uploading to mentors again now.

On Wed, Mar 30, 2016 at 11:59 PM, Paul Wise <p...@debian.org> wrote:

> On Thu, Mar 31, 2016 at 2:47 PM, Tom Lee wrote:
>
> > N.B. no watchfile is present due to the naming strategy of the upstream
> tarball:
> > uscan interprets the version number as "645" when the release is
> actually "6.4.5".
> > if there's a way to teach uscan how to figure this out, I'm all ears!
>
> I think you want the uversionmangle option.
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#819615: RFS: spin/6.4.5-1 [ITP] -- formal software verification tool

[Tom Lee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the "spin" package:

* Package name: spin
  Version : 6.4.5
  Upstream Author : Gerard J. Holzmann 
* URL : http://spinroot.com
* License : BSD-3-clause
  Section : devel

It builds those binary packages:

   spin - formal software verification tool

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

https://mentors.debian.net/package/spin

N.B. no watchfile is present due to the naming strategy of the upstream tarball:
uscan interprets the version number as "645" when the release is actually 
"6.4.5".
if there's a way to teach uscan how to figure this out, I'm all ears!

One can also download the package with dget using this command:

 dget -x http://mentors.debian.net/debian/pool/main/s/spin/spin_6.4.5-1.dsc

More information about spin can be obtained from http://spinroot.com

Cheers,
Tom

Re: not installed and installed , where they store?

[Tom Lee]

Try this too if virtualbox is the specific package you're interested in:

$ grep -A 3 ^Package: virtualbox\$ /var/lib/dpkg/status
Package: virtualbox
Status: install ok installed
Priority: optional
Section: contrib/misc


On Sat, May 9, 2015 at 9:44 PM, Johannes Schauer jo...@debian.org wrote:

 Hi,

 Quoting Mohsen Pahlevanzadeh (2015-05-10 05:53:17)
 When i use : grep ^Status: /var/lib/dpkg/status ,
 Unfortunately , i only get Status: install ok installed

 how sure are you of that? Did you just look at the first few hundred or
 did you
 really find all unique values? Try:

 grep ^Status: /var/lib/dpkg/status | sort | uniq -c

 cheers, josch




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

Re: not installed and installed , where they store?

[Tom Lee]

Hey Mohsen,

The short answer is /var/lib/dpkg/status.

There might be easier ways, but strace can give you some hints wrt where to
look if you're patient:

$ strace dpkg -l virtualbox 21 | grep open | grep O_RDONLY | grep -v
ENOENT
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
open(/lib/x86_64-linux-gnu/libselinux.so.1, O_RDONLY|O_CLOEXEC) = 3
open(/lib/x86_64-linux-gnu/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
open(/lib/x86_64-linux-gnu/libpcre.so.3, O_RDONLY|O_CLOEXEC) = 3
open(/lib/x86_64-linux-gnu/libdl.so.2, O_RDONLY|O_CLOEXEC) = 3
open(/lib/x86_64-linux-gnu/libpthread.so.0, O_RDONLY|O_CLOEXEC) = 3
open(/proc/filesystems, O_RDONLY) = 3
open(/usr/lib/locale/locale-archive, O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, /etc/dpkg/dpkg.cfg.d,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open(/etc/dpkg/dpkg.cfg, O_RDONLY)= 3
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
open(/lib/x86_64-linux-gnu/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
open(/usr/lib/locale/locale-archive, O_RDONLY|O_CLOEXEC) = 3
open(/var/lib/dpkg/arch, O_RDONLY)= 3
open(/var/lib/dpkg/status, O_RDONLY)  = 3
open(/usr/share/locale/locale.alias, O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, /var/lib/dpkg/updates/,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open(/var/lib/dpkg/triggers/File, O_RDONLY) = 3
open(/var/lib/dpkg/triggers/Unincorp, O_RDONLY) = 3
open(/proc/meminfo, O_RDONLY|O_CLOEXEC) = 4
open(/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache, O_RDONLY) = 4

In the middle of all that noise you'll notice it's opening
/var/lib/dpkg/status. If you run head /var/lib/dpkg/status you should get
an idea of what's going on.

Cheers,
Tom

On Sat, May 9, 2015 at 7:41 PM, Mohsen Pahlevanzadeh 
moh...@pahlevanzadeh.org wrote:

  Dear Mentors,

 Suppose :

 ///
 root@debian:/home/mohsen# dpkg -l virtualbox
 Desired=Unknown/Install/Remove/Purge/Hold
 |
 Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
 |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
 ||/ Name   Version  Architecture Description

 +++-==---=
 un  virtualbox none   none   (no description available)

 ///

 My query means not installed and installed !(ii)

 When dpkg read it, dpkg read from where?


 --Regards
 Mohsen


  -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with
 a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/554ec53c.9090...@pahlevanzadeh.org




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

Re: Shared library binary package, SONAME changes and file conflicts

[Tom Lee]

https://github.com/redis/hiredis/issues/327 -- sounds like upstream's
on-board. Thanks for your help Andrey!

On Wed, May 6, 2015 at 5:50 AM, Andrey Rahmatullin w...@debian.org wrote:

 On Tue, May 05, 2015 at 10:43:57PM -0700, Tom Lee wrote:
  After reading a little more about shared lib naming  SONAME, I think I
  understand. So instead of the current libhiredis.so.0 symlink we want a
  libhiredis.so.0.13 symlink  the real name of the shared lib would be
  something like libhiredis.so.0.13.1? That would certainly make life
 easier.
 You don't need to invent a real name, just removing the symlink would be
 enough.

  I'm happy to make the case upstream, but is it sane to work around this
 in
  the packaging while that gets figured out?
 I think so.

 --
 WBR, wRAR




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

Shared library binary package, SONAME changes and file conflicts

[Tom Lee]

Silly question, but I need a quick sanity-check:

hiredis upstream has bumped their SONAME from 0.10 to 0.13. From what I
understand, this means the libhiredis0.10 binary package needs to be
renamed to libhiredis0.13.

By and large that's an easy  mostly mechanical change, but both
libhiredis0.10 and libhiredis0.13 want to install the libhiredis.so.0
symlink (each pointing to one of libhiredis.so.0.{10,13}).

I *think* what I want to do based on
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces is
to add the following to debian/control for libhiredis0.13:

Replaces: libhiredis0.10
Breaks: libhiredis0.10

If I'm reading correctly, when users upgrade from libhiredis0.10 to
libhiredis0.13, this should replace the libhiredis.so.0 symlink in
libhiredis0.10 with the symlink pointing to libhiredis0.13. So long as 0.13
is a good citizen  contains no backward-incompatible changes from 0.10
(which I have yet to verify), I feel like everything should continue to
work fine.

Is this the right way to handle the situation, or is there a better way to
do this?

Cheers,
Tom

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

Access to mips64el system wanted to fix a bug in the capnproto package

[Tom Lee]

I'm looking at bug 743402 which involves an upstream bug on mips64el arch
for the capnproto source package causing tests to fail:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743402

Upstream has a good theory on what's going down (MIPS does things
differently to most architectures with the quiet/signalled flag on NaN
values) and is eager to fix the bug, but doesn't have access to the
appropriate hardware to work on a fix.

Does the Debian project have hardware/VMs set aside to help
packagers/upstream maintainers diagnose this sort of thing? I don't think
it's appropriate for me to simply skip the test on the packaging side
because the test is indicating pretty clearly things may not work as
expected on the affected architecture.

Thought I'd check here before bothering debian-mips{,el} in case there's a
well-known way to tackle this sort of thing -- happy to ask there if it's
more appropriate.

Thanks!
Tom


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

Re: Access to mips64el system wanted to fix a bug in the capnproto package

[Tom Lee]

Thanks for the detailed response Stephen, all great stuff to know. Yunqiang
Su has already been kind enough to offer up a porterbox since I sent my
earlier email. :)

Am I right in understanding a porterbox is basically just a chrooted
environment available for remote access on a temporary basis?


On Sat, Apr 19, 2014 at 2:33 PM, Stephen Kitt sk...@debian.org wrote:

 Hi Tom,

 On Sat, 19 Apr 2014 13:29:48 -0700, Tom Lee deb...@tomlee.co wrote:
  Does the Debian project have hardware/VMs set aside to help
  packagers/upstream maintainers diagnose this sort of thing? I don't think
  it's appropriate for me to simply skip the test on the packaging side
  because the test is indicating pretty clearly things may not work as
  expected on the affected architecture.

 Generally speaking, yes, for official Debian architectures; see
 https://db.debian.org/machines.cgi for the available machines (look for
 public in the right-hand column) and
 https://dsa.debian.org/doc/guest-account/ for the procedure to gain
 access.

 This won't help with mips64el, but you could just ask your bug reporter
 ;-).
 See the thread starting at
 https://lists.debian.org/debian-devel/2013/10/msg00704.html for details of
 the mips64el machine which is available via YunQiang Su.

 For this kind of problem another possibility is the GNU Compile Farm, which
 also includes a mips64el system; see http://gcc.gnu.org/wiki/CompileFarmfor
 details.

 Regards,

 Stephen




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

Re: New upstream source tarball introduces a new shared library

[Tom Lee]

Yes it is -- all the libraries built by the source package have the same
version numbers.

It wasn't too much trouble to split out libkj, so I did that. I can either
leave it that way or fold it back into the libcapnp binary package. Any
strong feelings either way with this?

I should note that the source package also builds *another*, third shared
object (libcapnpc) used by the capnpc compiler that I've opted to roll into
the libcapnp package for now. At some point it may make sense to split the
compiler + runtime libraries up too.

The relevant changes for libkj  libcapnpc are here:

https://github.com/thomaslee/capnproto-debian/commit/2a8ae2fa288970ee0ba666c5958fed23bbd971f0
https://github.com/thomaslee/capnproto-debian/commit/a54d2cb076f39be88e927d1c02147228469a27cc

Full repo here:

https://github.com/thomaslee/capnproto-debian

Cheers,
Tom


On Tue, Nov 12, 2013 at 11:46 PM, Vincent Bernat ber...@debian.org wrote:

  ❦ 13 novembre 2013 05:30 CET, Tom Lee deb...@tomlee.co :

  I work on the packaging for capnproto.
 
  Upstream has provided a new source tarball that introduces a new shared
  library (libkj). Theoretically, this shared library is stand-alone 
 could
  be used independently, but it is likely only interesting to users of
  capnproto in the short term.
 
  In the developer's words:
 
  It can exist independently, and some day it might be marketed as a
  separate library.  For now, though, it is bundled with Cap'n Proto and
 used
  only by Cap'n Proto users.  Unless Debian mandates breaking these out or
 we
  actually see some demand for KJ being separate, I don't think we need to
  divide the package yet.
 
  I *think* I should extract libkj as a separate binary package  am
  currently proceeding under that assumption, but thought I'd ask here RE:
  whether I'm correct. Do I really need to split out libkj at this time?

 No, you don't. Is the versioning the same?
 --
 10.0 times 0.1 is hardly ever 1.0.
 - The Elements of Programming Style (Kernighan  Plauger)




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

Re: New upstream source tarball introduces a new shared library

[Tom Lee]

Cool -- I'll roll kj back into the libcapnp package  push this out to
mentors.debian.net.

Can I assume you're interested in sponsoring capnproto_0.3.0-1 Vincent, or
should I open an RFS?

Thanks for the feedback.

Cheers,
Tom


On Wed, Nov 13, 2013 at 12:12 AM, Vincent Bernat ber...@debian.org wrote:

  ❦ 13 novembre 2013 09:04 CET, Tom Lee deb...@tomlee.co :

  Yes it is -- all the libraries built by the source package have the same
  version numbers.
 
  It wasn't too much trouble to split out libkj, so I did that. I can
 either
  leave it that way or fold it back into the libcapnp binary package. Any
  strong feelings either way with this?

 By not installing libkj in a separate package, you avoid one binary
 package which translates to saving space and memory all around the
 world. This is somewhat similar to what happens with GTK: libgtk-3-0
 contains both libgtk-3 and libgdk-3.
 --
 printk(KERN_WARNING Multi-volume CD somehow got mounted.\n);
 2.2.16 /usr/src/linux/fs/isofs/inode.c




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

Re: New upstream source tarball introduces a new shared library

[Tom Lee]

For your review, Vincent:

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

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

Thanks again.


On Wed, Nov 13, 2013 at 12:29 AM, Vincent Bernat ber...@debian.org wrote:

  ❦ 13 novembre 2013 09:21 CET, Tom Lee deb...@tomlee.co :

  Can I assume you're interested in sponsoring capnproto_0.3.0-1 Vincent,
 or
  should I open an RFS?

 Yes, mail me directly so I don't forget.
 --
 Program defensively.
 - The Elements of Programming Style (Kernighan  Plauger)




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

New upstream source tarball introduces a new shared library

[Tom Lee]

Hi folks,

I work on the packaging for capnproto.

Upstream has provided a new source tarball that introduces a new shared
library (libkj). Theoretically, this shared library is stand-alone  could
be used independently, but it is likely only interesting to users of
capnproto in the short term.

In the developer's words:

It can exist independently, and some day it might be marketed as a
separate library.  For now, though, it is bundled with Cap'n Proto and used
only by Cap'n Proto users.  Unless Debian mandates breaking these out or we
actually see some demand for KJ being separate, I don't think we need to
divide the package yet.

I *think* I should extract libkj as a separate binary package  am
currently proceeding under that assumption, but thought I'd ask here RE:
whether I'm correct. Do I really need to split out libkj at this time?

Thanks!

Tom

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

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

[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 ber...@debian.org wrote:

  ❦ 20 août 2013 10:24 CEST, Tom Lee deb...@tomlee.co :

  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 http://twitter.com/tglee

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

[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 ber...@debian.org wrote:

  ❦ 21 août 2013 09:02 CEST, Tom Lee deb...@tomlee.co :

  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 http://twitter.com/tglee

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

[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 ber...@debian.org wrote:

  ❦ 21 août 2013 18:19 CEST, Kenton Varda tempo...@gmail.com :

  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 http://twitter.com/tglee

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

[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 ber...@debian.org wrote:

  ❦ 20 août 2013 06:48 CEST, Tom Lee deb...@tomlee.co :

  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 http://twitter.com/tglee

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

[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 deb...@tomlee.co 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 ber...@debian.orgwrote:

  ❦ 20 août 2013 06:48 CEST, Tom Lee deb...@tomlee.co :

  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 http://twitter.com/tglee




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

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

[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

[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 ber...@debian.org wrote:

  ❦ 19 août 2013 01:34 CEST, Tom Lee deb...@tomlee.co :

  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 http://twitter.com/tglee

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

[Tom Lee]

On Mon, Aug 19, 2013 at 12:28 AM, Vincent Bernat ber...@debian.org 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 http://twitter.com/tglee

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

[Tom Lee]

On Mon, Aug 19, 2013 at 1:47 AM, Vincent Bernat ber...@debian.org wrote:

  ❦ 19 août 2013 09:56 CEST, Tom Lee deb...@tomlee.co :

   - 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 http://twitter.com/tglee

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

[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 ber...@debian.org wrote:

  ❦ 19 août 2013 11:46 CEST, Tom Lee deb...@tomlee.co :

  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 http://twitter.com/tglee

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

[Tom Lee]

Hi Vincent,

Thanks for the review! Questions  comments below:

On Sun, Aug 18, 2013 at 9:27 AM, Vincent Bernat ber...@debian.org 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::Arraykj::StringTree,
kj::StringPtr)@Base 0.2.0
 (c++)kj::StringTree::StringTree(kj::Arraykj::StringTree,
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:

 snip


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-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKwFPQ-EoLBdF-F3PeUgRf=j4p6e+7j-neotcm1pd8xuppn...@mail.gmail.com

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

[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 ber...@debian.org wrote:
  ❦ 18 août 2013 20:29 CEST, Vincent Bernat ber...@debian.org :

 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-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cakwfpq8bjxe_dvtarkzfsbsamkaxc3+dxtsxwhqesy9u6mc...@mail.gmail.com

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

[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 unfinished ...
[pid 13045] readlink(/proc/self/exe,  unfinished ...
[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 unfinished ...
[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 deb...@tomlee.co 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 ber...@debian.org wrote:
  ❦ 18 août 2013 20:29 CEST, Vincent Bernat ber...@debian.org :

 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-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKwFPQ-VKMksS67Nsdq3RKkDfZ=k4adtjf-+4njvjf0tr6s...@mail.gmail.com

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

[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 ber...@debian.org wrote:
  ❦ 18 août 2013 22:53 CEST, Tom Lee deb...@tomlee.co :

 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 unfinished 
 ...
 [pid 13045] readlink(/proc/self/exe,  unfinished ...
 [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 unfinished 
 ...
 [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-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cakwfpq8azx1xzqbdjotyhcf63eruk4u8y_zixtvo91jhoxm...@mail.gmail.com

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

[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 tempo...@gmail.com
* 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-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cakwfpq85fwy2733jgyfvtp4a9nufaivxqayrvzbi2a30lem...@mail.gmail.com

Bug#719286: Please upload hiredis 0.11.0-3?

[Tom Lee]

On Sun, Aug 11, 2013 at 3:37 AM, Alessandro Ghedini gh...@debian.orgwrote:

 owner 719286 gh...@debian.org
 tags 719286 pending
 kthxbye

 [ also CCing the RFS bug ]

 On sab, ago 10, 2013 at 09:32:29 -0700, Tom Lee wrote:
  Hey Alessandro,

 Hi,

  Not sure if this is the right email address to contact you on, but I've
  forwarded my upload request for hiredis on to debian-mentors.

 My canonical Debian contact would be gh...@debian.org but this other
 address is
 fine as well (also, I'm not subscribed to debian-mentors). Sorry if you
 had to
 waste your time for the inactive email address thing.


Oh no problem at all. No time wasted. I'll be sure to use this email
address in the future.


   https://mentors.debian.net/package/hiredis
 
  No response from them yet, but if you're out there I figure you may want
 to
  know so there's no duplication of effort here.

 I've looked into the package and it mostly looks good. In the other email
 you
 mentioned that this is supposed to fix bug #717611 but there's no mention
 of it
 in the changelog. Usually, when an entry in the changelog fixes a bug
 filed in
 the BTS, you should also mention the bug number so that a) people reading
 the
 changelog can trace the fix back to the bug report and b) when the bug
 number
 is listed in the changelog (with a special syntax), the original report
 is
 automatically closed when the package is uploaded (so that you don't have
 to do
 it manually). See [0] for more info.


D'oh, I remember wondering about that when I was editing the change log.
Meant to check on that!

I've updated the changelog manually. I've also modified the timestamp to
reflect the time at which it was edited, not sure if that's necessary.


 If you use the git-dch/gbp-dch script in the git-buildpackage package to
 generate the changelog, you can also add a special meta-tag in the git
 commit
 listing the bugs fixed by that commit, and they will automatically show up
 in
 the changelog with the correct syntax when git-dch is run. Have a look at
 the
 META TAGS section in the git-dch/gbp-dch(1) man page.


Sure, I'll keep a note of that for next time.


 A final suggestion: you should not create the debian/* tags in the git
 repository before the package is uploaded, otherwise (as in this case) you
 may
 have to delete the tag if you need to make any modifications suggested by a
 sponsor.


This occurred to me after I had created  pushed the tag. :) I'll delete it
now  wait for your a-OK before I tag it again.


 (also, there's no need to upload to mentors.debian.net a fixed package,
 git is
 fine for me).


Great -- thanks! I only uploaded to mentors.debian.net because I hadn't
heard anything back from you. Now that I have your canonical
@debian.comaddress, I'll use that :)

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

Bug#719286: RFS: hiredis/0.11.0-3

[Tom Lee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package hiredis

* Package name: hiredis
  Version : 0.11.0-3
  Upstream Author : Salvatore Sanfilippo anti...@gmail.com
* URL : http://github.com/redis/hiredis
* License : BSD
  Section : libs

It builds those binary packages:

  libhiredis-dbg - minimalistic C client library for Redis (debug)
  libhiredis-dev - minimalistic C client library for Redis (development files)
  libhiredis0.10 - minimalistic C client library for Redis

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

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

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

  dget -x 
http://mentors.debian.net/debian/pool/main/h/hiredis/hiredis_0.11.0-3.dsc
More information about redis can be obtained from http://redis.io/

Changes since the last upload:

  * Fix incorrect --cflags  --libs in pkg-config file

Cheers,
Tom



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