Bug#806754: RFS: gmp-ecm/6.4.4+ds-5 [FTBFS fix]

Package: sponsorship-requests Severity: normal Dear Mentors: I am looking for a sponsor for the package gmp-ecm [1] that I am maintaining on behalf of the Debian Science-Team. This version fix the FTBFS issue #806619 that pointed that the gmp-ecm package did not

Bug#790412: RFS: circus/0.12.0-1

On 11/09/2015 08:51 AM, David Douard wrote: > On 11/06/2015 04:30 PM, Gianfranco Costamagna wrote: >> Hi, >> > Hi, I've (at last) reuploaded a version of circus (0.12.1) on mentors. I've disabled the tests, as suggested by Gianfranco, in order to have a package. I'll try to figure out how to

How to find out why debuild -S dislikes dpkg-source --commit ?

Hi, after a few weeks of other leisures i came back to Debian packaging for a new upstream release of my software. Currently i feel plain stupid because i fail to install a patch which shall silence a few lintian warnings about the man pages. I unpacked the upstream tarball, moved it to the

Re: .symbols or shlibs file

> * Herbert Parentes Fortes Neto , 2015-11-29, 16:12: > >I removed the 'override_dh_makeshlibs' and now 'dpkg-gensymbols' is > >warning that: > > I certainly didn't advocate removing this override. A little rush of mine. > > The override passed -X options to dh_makeshlibs.

Re: Copyright of composite Makefile.in files

Vincent Bernat writes: > ❦ 30 novembre 2015 10:41 +0100, Ferenc Wagner  : > >> Makefile.in files distributed in an upstream tarball often have several >> copyright notices: the FSF copyleft at the top added by Automake and >> later those carried over from other

Re: Copyright of composite Makefile.in files

Alex Vong writes: > I am not a mentor, the following is just my opinions: I'm afraid that if you answer a question on debian-mentors, you're a mentor by definition. :) > I don't know how Makefile.in is being handled in particular, but I > think in general, if one file

Re: general question about quilt patch handling

Hi, > For example, if 3.patch has not been forwarded upstream yet, then I > would definitely modify it (instead of creating a new patch). I've modified 3.patch - in the course of the modification one line has been deleted (perl "use" statement) as it's not needed anymore. Therefore some

Problem with buid in AMD64

Hi mentors, My package doesnt build in amd64 http://paste.debian.net/hidden/7253bf53/, I want to know, if I need add -fPIC flag only amd64 or in any arch in the configure? Thanks! -- Daniel Echeverry http://wiki.debian.org/DanielEcheverry Linux user: #477840 Debian user Software libre

Re: Problem with buid in AMD64

On Mon, Nov 30, 2015 at 05:51:12PM -0500, Daniel Echeverry wrote: > My package doesnt build in amd64 > http://paste.debian.net/hidden/7253bf53/, I want to know, if I need > add -fPIC flag only amd64 or in any arch in the configure? All shared libraries should be compiled with -fPIC. -- WBR,

Bug#806773: RFS: normaliz/3.0.0+ds-3 [FTBFS fix]

Package: sponsorship-requests Severity: normal Dear Mentors: I am looking for a sponsor for the package normaliz [1] that I am maintaining on behalf of the Debian Science-Team. This version fix the FTBFS issue #806769 that pointed random emitting of `Bus error'

Copyright of composite Makefile.in files

Dear mentors, Makefile.in files distributed in an upstream tarball often have several copyright notices: the FSF copyleft at the top added by Automake and later those carried over from other macro packages included into Makefile.am (for example: include doxygen.am). The result is like this: #

Re: Copyright of composite Makefile.in files

❦ 30 novembre 2015 10:41 +0100, Ferenc Wagner  : > Makefile.in files distributed in an upstream tarball often have several > copyright notices: the FSF copyleft at the top added by Automake and > later those carried over from other macro packages included into > Makefile.am (for

Re: Copyright of composite Makefile.in files

Hi, I am not a mentor, the following is just my opinions: I think if possible, Makefile.in should not be included in tarball, since dh_autoreconf will re-generate it at build-time anyway. But I think it is fine to keep it if the upstream tarball provides it since it does not worth repacking the