Bug#817225: marked as done (RFS: golang-gopkg-hlandau-configurable.v1/1.0.1 [ITP] -- Go package for managing program configuration)

Your message dated Thu, 31 Mar 2016 12:47:34 +1100 with message-id <1647453.SflKaeiHQ4@deblab> and subject line Re: [pkg-go] Bug#817225: RFS: golang-gopkg-hlandau-configurable.v1/1.0.1 -- Go package for managing program configuration has caused the Debian Bug report #817225, regarding RFS:

Bug#819514: marked as done (RFS: emacs-buttercup/1.5-1 -- behaviour-driven testing for Emacs Lisp packages)

Your message dated Wed, 30 Mar 2016 18:51:00 + with message-id and subject line RE:Bug#819514: RFS: emacs-buttercup/1.5-1 -- behaviour-driven testing for Emacs Lisp packages has caused the Debian Bug report #819514,

Bug#819514: RFS: emacs-buttercup/1.5-1 -- behaviour-driven testing for Emacs Lisp packages

uploaded Cheers Fred

Bug#811073: RFS: lbfgsb/3.0-1 [ITP]

Hi >http://mentors.debian.net/debian/pool/main/l/lbfgsb/lbfgsb_3.0-2.dsc >addresses the standards-version and the dbg package. I'll have to work >on the watch file and (if needed) the build system. ok, let me know when the other points are addressed, and I'll grab it :) (please call it always

Bug#811073: RFS: lbfgsb/3.0-1 [ITP]

Hi, >I see. I was under the impression that was only to be used when files >are excluded for copyright reasons. I repackaged the upstream tarball >because it included binaries (compiled from the source, one presumes) >and some metadata - not necessarily things that are problematic in a

Bug#819514: RFS: emacs-buttercup/1.5-1 -- behaviour-driven testing for Emacs Lisp packages

control: severity -1 normal control: retitle -1 RFS: emacs-buttercup/1.5-1 -- behaviour-driven testing for Emacs Lisp packages Apologies: this is a new version, not an ITP. Changes since the last upload: * New upstream version. * Drop patch backporting a fix present in this version. *

Bug#811073: RFS: lbfgsb/3.0-1 [ITP]

On Friday 25 March 2016 18:56:40 Gianfranco Costamagna wrote: > something needs changes: > - std-version= 3.9.7 > - no watch file? > - no sane build system, why are you building the library such way? > you seem to use just two files in your library, why everything is dropped? > I don't think flags

Bug#811073: RFS: lbfgsb/3.0-1 [ITP]

On Wednesday 30 March 2016 14:27:45 Gianfranco Costamagna wrote: > HI, > > >I didn't make one since upstream's tarball (at least for the latest > >version) contains precompiled binaries, as well as a few files outside > >of any directory (a little tarbomb). It is my understanding that these >

Bug#819536: marked as done (RFS: linuxbrew-wrapper/20150804-3)

Your message dated Wed, 30 Mar 2016 17:07:45 + (UTC) with message-id <1130213414.4454919.1459357665902.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#819536: RFS: linuxbrew-wrapper/20150804-3 has caused the Debian Bug report #819536, regarding RFS: linuxbrew-wrapper/20150804-3 to be

Bug#819566: marked as done (RFS: clfft/2.10.2-1)

Your message dated Wed, 30 Mar 2016 17:07:07 + (UTC) with message-id <369919544.4431663.1459357627023.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#819566: RFS: clfft/2.10.2-1 has caused the Debian Bug report #819566, regarding RFS: clfft/2.10.2-1 to be marked as done. This means

Bug#819568: marked as done (RFS: groonga/6.0.1-1)

Your message dated Wed, 30 Mar 2016 15:51:42 + (UTC) with message-id <1033826692.4375340.1459353102190.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#819568: RFS: groonga/6.0.1-1 has caused the Debian Bug report #819568, regarding RFS: groonga/6.0.1-1 to be marked as done. This means

Bug#819568: RFS: groonga/6.0.1-1

Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "groonga" * Package name: groonga Version : 6.0.1-1 Upstream Author : Groonga Project * URL : http://groonga.org/ * License :

Bug#819566: RFS: clfft/2.10.2-1

Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "clfft" * Package name: clfft Version : 2.10.2-1 Upstream Author : Advanced Micro Devices, Inc. * URL : https://github.com/clMathLibraries/clFFT * License

Bug#811073: RFS: lbfgsb/3.0-1 [ITP]

On 30/03/16 15:27, Gianfranco Costamagna wrote: - driver*.f*: These are demonstration files for how to use the library, and are therefore not compiled. Should they be installed as example source files somewhere? a package-examples might be trivial to add now, but you are the maintainer

Bug#811073: RFS: lbfgsb/3.0-1 [ITP]

>Filex-Excluded copyright keyword might become handy. of course s/Filex/Files here https://wiki.debian.org/UscanEnhancements sorry for the typo :) G.

Bug#811073: RFS: lbfgsb/3.0-1 [ITP]

HI, >I didn't make one since upstream's tarball (at least for the latest >version) contains precompiled binaries, as well as a few files outside >of any directory (a little tarbomb). It is my understanding that these >need to be stripped out of the Debian source. Should I make a script >for that

Bug#819181: RFS: cl-asdf/3.1.7 - Another System Definition Facility

Hi, >This sounds great, but can you describe to a newbie how to convert it? >Does git-buildpackage have an option to handle this? do the change on the source, dpkg-source --commit end. or wget of the patch file (upstream or whatever) or git format-patch of the patch add-patch

Bug#819181: RFS: cl-asdf/3.1.7 - Another System Definition Facility

> no, you can add the commit as a patch, patches are applied *before* dh_clean > and removed after the build successful. > > I converted it as patch, removed the clean override, removed quilt from b-d-i. > > Success in my machine and in a real pbuilder clean environment. This sounds great, but

Bug#811073: RFS: lbfgsb/3.0-1 [ITP]

On Friday 25 March 2016 18:56:40 Gianfranco Costamagna wrote: > Hi, Hi, and thanks for the feedback! > something needs changes: > - std-version= 3.9.7 Yep, I'll update that. > - no watch file? I didn't make one since upstream's tarball (at least for the latest version) contains precompiled

Bug#819181: RFS: cl-asdf/3.1.7 - Another System Definition Facility

Hi, >Yes, definitely! I have already submitted a patch upstream which has >been merged: > >https://gitlab.common-lisp.net/asdf/asdf/commit/9b4f0d5ef957e92d1303c694027502c2a7a7ae96 > >But alas 3.1.7 is released without this change and I have to cope with >it somehow. So this is a temporary

Bug#819181: RFS: cl-asdf/3.1.7 - Another System Definition Facility

> how? I would suggest to patch the upstream make clean to not change source > files. Yes, definitely! I have already submitted a patch upstream which has been merged: https://gitlab.common-lisp.net/asdf/asdf/commit/9b4f0d5ef957e92d1303c694027502c2a7a7ae96 But alas 3.1.7 is released without

Bug#819181: RFS: cl-asdf/3.1.7 - Another System Definition Facility

Hi, >The reason is that the upstream 'make clean' deletes debian/patches >completely. So without this, I'm not able to patch anything. how? I would suggest to patch the upstream make clean to not change source files. (note: I'm *suggesting* stuff without looking at the code, I don't know

Bug#819463: RFS: python-arrayfire/3.3.20160328-1 [ITP]

On Wed, Mar 30, 2016 at 10:11:53AM +0100, Ghislain Vaillant wrote: > Indeed the policy is explicit about the naming convention of the binary > packages, but I could not find anything regarding the naming convention > for the corresponding source package. > > I recently suggested adopting the same

Bug#819181: RFS: cl-asdf/3.1.7 - Another System Definition Facility

Hi Gianfranco, thank you for taking care of this. > +override_dh_clean: > + dh_quilt_patch > + dh_clean > > > why? The reason is that the upstream 'make clean' deletes debian/patches completely. So without this, I'm not able to patch anything. > also adding quilt to b-d-i seems

Re: Problems linking hdf5, gzstream, boost_program_options due to usage of simple Makefile

Hi Jakub, On Tue, Mar 29, 2016 at 10:01:51PM +0200, Jakub Wilk wrote: > > https://github.com/johnlees/seer links to: > http://www.cs.unc.edu/Research/compgeom/gzstream/ > > AFAICT, this is not packaged for Debian. (Although we have multiple embedded > code copies[0]. Yay...) See #819532. Kind

Bug#819463: RFS: python-arrayfire/3.3.20160328-1 [ITP]

On 29/03/16 22:52, Mattia Rizzolo wrote: On Tue, Mar 29, 2016 at 05:58:28PM +0100, Ghislain Vaillant wrote: Just realized I should have probably named the source package "arrayfire-python" to reflect the name of the project on GitHub Regarding the renaming, I meant the **source** package

Bug#819536: RFS: linuxbrew-wrapper/20150804-3

Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "linuxbrew-wrapper" * Package name: linuxbrew-wrapper Version : 20150804-3 Upstream Author : homebrew * URL : http://brew.sh/linuxbrew/ * License :