Bug#742175: marked as done (RFS: osgearth/2.5.0+dfsg-1)

Your message dated Fri, 21 Mar 2014 04:36:22 + with message-id and subject line closing RFS: osgearth/2.5.0+dfsg-1 has caused the Debian Bug report #742175, regarding RFS: osgearth/2.5.0+dfsg-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is no

Bug#742173: marked as done (RFS: geos/3.4.2-4)

Your message dated Fri, 21 Mar 2014 04:36:16 + with message-id and subject line closing RFS: geos/3.4.2-4 has caused the Debian Bug report #742173, regarding RFS: geos/3.4.2-4 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is n

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

On 2014-03-21 00:00, Christian Kastner wrote: > On 2014-03-20 23:21, Jakub Wilk wrote: > A) using symbols.common + symbols.$arch > B) using symbols.common + symbols.arch, using (arch= ) tags > C) using symbols + (c++|regex) tags Missed an obvious one: D) using symbols + (c++|arch=) tags -- To

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

On 2014-03-20 23:21, Jakub Wilk wrote: > For example, symbol names for a f(size_t) function are: > _Z1fj on i386, > _Z1fm on amd64. > > After unmangling it becomes: > f(unsigned int) on i386, > f(unsigned long) on amd64. Well, after researching a bit, the only somewhat manageable solutions I can

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

On 2014-03-20 23:21, Jakub Wilk wrote: > * Christian Kastner , 2014-03-20, 22:49: >> This is problematic. First, you need to demangle the symbols in there >> with c++filt (for examples, your package FTBFS on my host without this). > > I haven't looked into details of this particular package, but i

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

* Christian Kastner , 2014-03-20, 22:49: This is problematic. First, you need to demangle the symbols in there with c++filt (for examples, your package FTBFS on my host without this). I haven't looked into details of this particular package, but in general unmangling rarely helps curing FTBFS

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

On 2013-11-14 00:32, Bryan Conrad wrote: > I am looking for a sponsor for my package "libpoly2tri" I'm not a DD so I cannot sponsor your package, but hoping that you are still interested in contributing to Debian (despite the long time passed since your ITP) I'd like to offer some feedback. debi

Bug#742077: RFS: vcmi/0.95-1 [ITP]

* Johannes Schauer , 2014-03-19, 06:31: [I don't intend to sponsor this package. Sorry!] dont worry, I'm happy for any help that can improve my packaging! :) All right… :-P I wouldn't repack the .orig.tar just to remove debian/. If you're using the "3.0 (quilt)" format, dpkg-source removes u

Bug#741501: RFS: libb2/0.96-1 [ITP]

Hi, On 2014-03-13 05:57, Robert Ransom wrote: > I am looking for a sponsor for my package "libb2": I'm not a DD so I can't sponsor your package, but here is a quick review: Building There is one troublesome aspect of the upstream code: AFAICT, CPU-specific optimizations such as MMX, S

Re: DEP8 tests using the built package source

Stephen Kitt writes ("Re: DEP8 tests using the built package source"): > (Hi Ian, I'm adding you to the discussion since I'm talking about changes to > DEP8. I've snipped the exchanges but I hope you can get the gist of it > without needing to spend time looking anything else up!) Hi. Sorry about

Re: DEP8 tests using the built package source

* Stephen Kitt , 2014-03-19, 23:25: FTR, we explicitly make use of that for our toolchain packages: gcc, binutils, linux, and eglibc have a "bin/true" test with "needs build" to ensure that whenever we update one piece, the others are still buildable and their tests succeed (which run at build

Re: pbuilder --autocleanaptcache ???

On 20/03/14 14:27, Andreas Tille wrote: > Hi, > > I tried to clean up only those debs from pbuilder apt cache which are > outdated and not used any more. Since --autocleanaptcache only results > in printing the help page I did some research and the only hint on the > weg is this quite old bug in

Re: library linking, missing libB.so

Hi On 3/20/14, Nico Schlömer wrote: > I'm building a package for a library A that depends on another > library, libB.so (from its dev-version). When installing library A, > the package libb is installed, containing libB.so.7.2 and libB.so.7. > When linking an executable against libA.so, the linke

pbuilder --autocleanaptcache ???

Hi, I tried to clean up only those debs from pbuilder apt cache which are outdated and not used any more. Since --autocleanaptcache only results in printing the help page I did some research and the only hint on the weg is this quite old bug in Ubuntu: https://bugs.launchpad.net/ubuntu/+sourc

Re: library linking, missing libB.so

Le 20/03/2014 14:06, Nico Schlömer a écrit : >> which must depend on libB-dev. > > libB-dev is indeed not explicitly listed as a dependency of libA-dev, > mostly because I was under the impression that ${shlibs:Depends} takes > care of this, cf. . Is >

Re: DEP8 tests using the built package source

On Wed, Mar 19, 2014 at 11:47:02AM +0100, Jakub Wilk wrote: > I hope that ci.debian.net is configured in such a way it uses binary > packages from the archive. It is. -- Antonio Terceiro signature.asc Description: Digital signature

Re: library linking, missing libB.so

> which must depend on libB-dev. libB-dev is indeed not explicitly listed as a dependency of libA-dev, mostly because I was under the impression that ${shlibs:Depends} takes care of this, cf. . Is that not the case? Cheers, Nico On Thu, Mar 20, 201

Re: library linking, missing libB.so

Le 20/03/2014 13:22, Nico Schlömer a écrit : > Hi all, > > I'm building a package for a library A that depends on another > library, libB.so (from its dev-version). When installing library A, > the package libb is installed, containing libB.so.7.2 and libB.so.7. > When linking an executable agains

Re: DEP8 tests using the built package source

* Martin Pitt , 2014-03-20, 11:17: autopkgtest calls dpkg-buildpackage to do the actual package build, so for adding this to autopkgtest explicitly, we could add a flag for that and call dpkg-buildpackage --target. If by "a flag" you meant "a new restriction", then it sounds good to me. :) I

library linking, missing libB.so

Hi all, I'm building a package for a library A that depends on another library, libB.so (from its dev-version). When installing library A, the package libb is installed, containing libB.so.7.2 and libB.so.7. When linking an executable against libA.so, the linker rightfully complains about a missin

Bug#742185: RFS: qgis/2.2.0-1

Package: sponsorship-requests Severity: normal Dear mentors, As part of the SpatiaLite transition I am looking for a sponsor for my package "qgis" https://release.debian.org/transitions/html/libspatialite5.html https://release.debian.org/transitions/html/librasterlite2.html Please refer to the

Re: public extension linked with libpython* vs. -Wl,-no-undefined

> Actually, you usually don't get these kind of warnings for Python extension > modules. The warning is emitted only if a module has SONAME, and it > typically doesn't. > > You might want to get rid of SONAMEs That indeed was the problem. Thanks! It's a CMake/SWIG build, and I now added a patch to

Re: DEP8 tests using the built package source

* Martin Pitt , 2014-03-20, 07:51: I'm happy to add a stanza to its documentation to avoid it for packages which take a nontrivial amount of time to build; does that sound like an acceptable compromise? It does indeed, with Jakub's idea of copying only the required code to $ADTTMP too. Done n

Re: DEP8 tests using the built package source

Jakub Wilk [2014-03-19 11:52 +0100]: > >autopkgtest calls dpkg-buildpackage to do the actual package > >build, so for adding this to autopkgtest explicitly, we could add > >a flag for that and call dpkg-buildpackage --target. > > If by "a flag" you meant "a new restriction", then it sounds good to

Re: Bug#742173: Please commit your changes to VCS

Hi Andreas, > I guess you forgot to `git push` ... I did, sorry for my oversight. The branch on git.d.o is update to date now. Kind Regards, Bas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org A

Bug#742173: Please commit your changes to VCS

Hi Bas, I guess you forgot to `git push` ... Kind regards Andreas. PS: Please CC me if you did. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://li

Bug#742175: RFS: osgearth/2.5.0+dfsg-1

Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "osgearth" Package name: osgearth Version : 2.5.0+dfsg-1 Upstream Author : Glenn Waldron URL : http://osgearth.org/ License : LGPL-3 Section : dev

Bug#742173: RFS: geos/3.4.2-4

Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "geos" Package name: geos Version : 3.4.2-4 Upstream Author : GEOS Developers URL : http://trac.osgeo.org/geos/ License : LGPL-2.1+ Section : scie

Re: DEP8 tests using the built package source

Hi Stephen, On Wed, Mar 19, 2014 at 11:54:03PM +0100, Stephen Kitt wrote: > ... Thanks for the clarification / sharing your opinion. > > Moreover I observed another issue with autopkgtest which is quite > > astonishing to me: In bug #741274 it was reported that the autopkgtest > > would fail an

Re: DEP8 tests using the built package source

Stephen Kitt [2014-03-19 23:54 +0100]: > On Wed, 19 Mar 2014 13:49:52 +0100, Andreas Tille wrote: > > On Wed, Mar 19, 2014 at 11:47:02AM +0100, Jakub Wilk wrote: > > > Long answer: > > > > > > You can declare that a test needs to be run from a built source > > > tree. Then the test runner will bu