Bug#729374: marked as done (RFS: spiped/1.3.1-1 [ITP] -- create secure pipes between socket addresses)

2013-11-13 Thread Debian Bug Tracking System
Your message dated Thu, 14 Nov 2013 04:27:17 + with message-id and subject line closing RFS: spiped/1.3.1-1 [ITP] -- create secure pipes between socket addresses has caused the Debian Bug report #729374, regarding RFS: spiped/1.3.1-1 [ITP] -- create secure pipes between socket addresses to b

Bug#729534: RFS: libpoly2tri/0.3.3-1 [ITP]

2013-11-13 Thread Bryan Conrad
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libpoly2tri" * Package name: libpoly2tri Version : 0.3.3-1 Upstream Author : Mason Green * URL : http://code.google.com/p/poly2tri/ * License : BSD

Re: RE:Help running tests in python-biom-format

2013-11-13 Thread Tim Booth
Hi Andreas, I second that - the tests run fine if I do: cd python-biom-format-1.2.0/python-code env PYTHONPATH=../build/lib.linux-x86_64-2.7/biom nosetests Also, if I have python-biom-format installed then the commands work fine and I can do: cd ~ ; python -c 'import biom.sparsemat' But within

Re: Bug#728716: RFS: xchroot/2.3.3-3 [ITP] -- extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots

2013-11-13 Thread Gergely Nagy
Elmar Stellnberger writes: > Am 12.11.2013 10:24, schrieb Andrew Shadura: >> Hello, >> >> On 12 November 2013 10:22, Elmar Stellnberger wrote: >>> O.K. That is actually what is to be done next. >>> There are some people whom I know and who I am going to consult. >>> It will at last be necessary

Bug#729359: RFS: mtink/1.0.16-8 [QA] -- Status monitor tool for Epson inkjet printers

2013-11-13 Thread Graham Inggs
> Isn't it (easily) possible to fix these spelling errors, or are they > false positives? If you stick to the overrides, please document why in > the override file. Well, they occur in non-English messages so I would say false positives, but perhaps the best solution is for me to ask in the rele

Bug#729374: RFS: spiped/1.3.1-1 [ITP] -- create secure pipes between socket addresses

2013-11-13 Thread Peter Pentchev
On Wed, Nov 13, 2013 at 08:50:42AM +0100, Vincent Bernat wrote: > ❦ 12 novembre 2013 15:12 CET, Peter Pentchev  : > > > I am looking for a sponsor for my new package "spiped". This is > > the first version uploaded to the Debian archive; the corresponding > > ITP bug is #699310. > > > > * Packag

Re: New upstream source tarball introduces a new shared library

2013-11-13 Thread 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 wrote: > ❦ 13 novembre 2013 09:21 CET, Tom Lee : > > > Can I assume you're inter

Re: New upstream source tarball introduces a new shared library

2013-11-13 Thread Vincent Bernat
❦ 13 novembre 2013 09:21 CET, Tom Lee  : > 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) signature.asc De

Re: New upstream source tarball introduces a new shared library

2013-11-13 Thread 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 wrote: > ❦ 13 nov

Re: New upstream source tarball introduces a new shared library

2013-11-13 Thread Vincent Bernat
❦ 13 novembre 2013 09:04 CET, 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

Re: New upstream source tarball introduces a new shared library

2013-11-13 Thread 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