Re: Biological data being used by an unpublished research paper is considered proprietary

> On Mon, 16 Sep 2013, Peter Rice wrote: > > >However, I have run into this issue before in the context of > >biological database entries and Debian so it may be worth discussing > >here. There were objections to including SwissProt entries in the > >example data for the EMBOSS package because the

Bug#724012: ITP: puppet-module-puppetlabs-firewall -- The Firewall module lets you manage firewall rules with Puppet

Package: wnpp Severity: wishlist Owner: Thomas Bechtold * Package name: puppet-module-puppetlabs-firewall Version : 0.4.2 Upstream Author : Puppet Labs * URL : http://forge.puppetlabs.com/puppetlabs/firewall * License : Apache-2.0 Programming Lang: Ruby Des

Bug#724011: ITP: puppet-module-puppetlabs-postgresql -- The PostgreSQL module allows you to easily manage postgres databases with Puppet.

Package: wnpp Severity: wishlist Owner: Thomas Bechtold * Package name: puppet-module-puppetlabs-postgresql Version : 2.5.0 Upstream Author : Puppet Labs * URL : http://forge.puppetlabs.com/puppetlabs/postgresql * License : Apache-2.0 Programming Lang: Ruby

Re: Decision on R datasets

Hi Paul, FTP team and everybody, first, let me underline that if the FTP team wants to disuss and amend its decision, I will be happy to participate. I think that the only good solution is to engage with the R community and make them change their practice of distributing data in binary format in

gngb, hey debian games team

Hi. I see gngb still doesn't work with my gamepad, so I went looking for the code I wrote a few years ago. I found my 'memory.c.diff' on the Peponas website, which I downloaded and (not surprisingly) just gives me something about "garbage" from the patch program. I honestly don't patch much, or

Re: dpkg-gensymbols -- should(n't) version where symbol was introduced remain when SONAME changes?

On Sun, 22 Sep 2013, Andreas Beckmann wrote: > > [-libfreenect.so.0.1 libfreenect0.1-]{+libfreenect.so.0.2 libfreenect0.2+} > > #MINVER#[-(optional)fn_log@Base 1:0.1.1-] > ^ > You need to change the soname in the first line of your symbols file, > otherwise what you get is t

Re: dpkg-gensymbols -- should(n't) version where symbol was introduced remain when SONAME changes?

On 2013-09-22 03:15, Yaroslav Halchenko wrote: > --- a/debian/libfreenect0.2.symbols > +++ b/debian/libfreenect0.2.symbols > @@ -1,75 +1,54 @@ > [-libfreenect.so.0.1 libfreenect0.1-]{+libfreenect.so.0.2 libfreenect0.2+} > #MINVER#[-(optional)fn_log@Base 1:0.1.1-] ^ You need

Re: Decision on R datasets

"Paul R. Tagliamonte" writes: > The real question is it less *distributable*? If its GPL and contains > things *not* in preferred form, I'd say yes, that would be less > distributable, since its a GPL violation and results in breech of > license - which means we can't distribute. I think this is

Re: Decision on R datasets

(as me, a DD, not as ftpteam) On Sat, Sep 21, 2013 at 04:59:55PM +0900, Charles Plessy wrote: > > Hello FTP team and everybody, Charles, > > In the thread that you cite, I sent another email where I asked for: > > - Time for a transition, > - Precise criteria, Law isn't precise. I think yo

dpkg-gensymbols -- should(n't) version where symbol was introduced remain when SONAME changes?

Dear library package(s) maintenance experts, I am updating libfreenect package to fresh upstream 0.2.0 (from 0.1.2). library SOVERSION changed to 0.2 and I have renamed libfreenect0.1 to libfreenect0.2 and its .symbols file. Now updating it with dpkg-gensymbols -v1:0.2.0 -plibfreenect0.2 -Odeb

Re: Decision on R datasets

(On my phone) The real question is it less *distributable*? If its GPL and contains things *not* in preferred form, I'd say yes, that would be less distributable, since its a GPL violation and results in breech of license - which means we can't distribute. My 2 cents (as a DD), Paul On Sep 21,

Re: Roll call for porters of architectures in sid and testing (Status update)

On 21-Sep-13, at 7:23 PM, Ben Hutchings wrote: I'll continue testing/software development activity on ia64 for the Jessie cycle, and more generally, until Debian drops ia64. I'm already waiting for Wayland on ia64 and other big updates. So please, keep ia64 in the bandwagon ;-) But I don't

Re: Proposed mass bug filing: Removal of automake1.4, automake1.9, automake1.10 and automake1.11

Hearing no objections to this plan I'm going to get started with these bug filings. I'm going to leave automake1.11 alone in the archive for now, as there seems to be enough compatibility problems between it and later versions that we probably need to give it more time. But automake1.4, automake1.9

Re: Roll call for porters of architectures in sid and testing (Status update)

On Sat, 2013-09-21 at 19:36 +0200, Émeric MASCHINO wrote: > Hi, > > I'm a long-time ia64 Debian user (> 10 years). I'm mostly focused on > desktop aspects (GNOME, Iceweasel, LibreOffice, Qt Creator, C++ 3D > software development) while most other ia64 users that I know are more > inclined on serve

Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing

On Fri, 20 Sep 2013, Kees Cook wrote: > This is absolutely a bug in glibc. While the spec can say "undefined", it > is, in fact, not undefined. It worked in a very specific way for over a > decade, so that's pretty well defined. ;) The fortify function has no need > to change it. FWIW +1 > > To

Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing

On Sat, 21 Sep 2013, Bastian Blank wrote: > > > > DEB_BUILD_HARDENING_FORTIFY := 0 > > > > preceding inclusion of /usr/share/hardening-includes/hardening.make > > > I would call code that hits such clear definitions too buggy to be > > > supported. > > yeah -- let's burn it!!!... oh no -- I am usi

Re: Decision on R datasets

Stephen Gran writes: > This one time, at band camp, Russ Allbery said: >> Alioth already hosts non-free packages (such as packaging repositories >> for Debian packaging for the non-free suite). I believe that the >> current understanding is that Alioth and its associated systems, such >> as the

Re: Decision on R datasets

This one time, at band camp, Russ Allbery said: > Stephen Gran writes: > > This one time, at band camp, Charles Plessy said: > > >> I therefore decided to stop uploading R packages to Debian. I use some > >> of these packages on multiple computers, and will keep on sharing my > >> work with othe

Bug#723984: ITP: r-cran-maldiquantforeign -- GNU R package providing import/export routines for MALDIquant

Package: wnpp Severity: wishlist Owner: Sebastian Gibb * Package name: r-cran-maldiquantforeign Version : 0.5.1 Upstream Author : Sebastian Gibb * URL : http://cran.r-project.org/web/packages/MALDIquantForeign/index.html * License : GPL Programming Lang: R

Re: Decision on R datasets

Stephen Gran writes: > This one time, at band camp, Charles Plessy said: >> I therefore decided to stop uploading R packages to Debian. I use some >> of these packages on multiple computers, and will keep on sharing my >> work with others on Alioth, but that is all. For any of them where I >> w

Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing

* Kees Cook [130921 17:08]: > In a theoretical sense, sure. In this particular case, why bother breaking > it when it's a trivial 1 line fix? My original approach was to fix it in > libc and do a mass bug filing. Everyone wins. If we want to reject the > undefined behavior, we should modify the co

Re: Decision on R datasets

This one time, at band camp, Charles Plessy said: > I therefore decided to stop uploading R packages to Debian. I use some of > these packages on multiple computers, and will keep on sharing my work with > others on Alioth, but that is all. For any of them where I was the sole > uploader, please

Re: packaging Postgres binary dump files

On 09/20/2013 06:18 PM, Daniel Pocock wrote: > To go the other way (from an ASCII SQL into a binary dump file) during > the package build phase, it needs to be loaded into a running PostgreSQL > server and then extracted with pg_dump. I don't think that is a great > build dependency, especially i

Re: Roll call for porters of architectures in sid and testing (Status update)

Hi, I'm a long-time ia64 Debian user (> 10 years). I'm mostly focused on desktop aspects (GNOME, Iceweasel, LibreOffice, Qt Creator, C++ 3D software development) while most other ia64 users that I know are more inclined on server use. I'm not a DD/DM, but daily update my ia64 workstation, report

Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing

On Sat, Sep 21, 2013 at 02:46:34PM +0200, Bas Wijnen wrote: > On Fri, Sep 20, 2013 at 10:12:16PM -0700, Kees Cook wrote: > > This is absolutely a bug in glibc. While the spec can say "undefined", it > > is, in fact, not undefined. It worked in a very specific way for over a > > decade, so that's pr

Bug#723942: ITP: algobox -- algorithmics introduction - French UI

Package: wnpp Severity: wishlist Owner: David Prévot * Package name: algobox Version : 0.8 Upstream Author : Pascal Brachet * URL : http://www.xm1math.net/algobox/ * License : GPL-2 Programming Lang: C++ Description : algorithmics introduction - French

Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing

On Fri, Sep 20, 2013 at 10:12:16PM -0700, Kees Cook wrote: > This is absolutely a bug in glibc. While the spec can say "undefined", it > is, in fact, not undefined. It worked in a very specific way for over a > decade, so that's pretty well defined. ;) The fortify function has no need > to change i

Bug#723934: ITP: mapnik-reference -- Parseable specifications of mapnik structures and properties

Package: wnpp Severity: wishlist Owner: "Jérémy Lal" * Package name: mapnik-reference Version : 5.0.5 Upstream Author : Mapnik Developers * URL : https://github.com/mapnik/mapnik-reference * License : http://unlicense.org/ Programming Lang

Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing

On Fri, Sep 20, 2013 at 09:04:43PM -0400, Yaroslav Halchenko wrote: > On Fri, 20 Sep 2013, Bastian Blank wrote: > > On Fri, Sep 20, 2013 at 03:05:37PM -0400, Yaroslav Halchenko wrote: > > > long story short -- reason was the combination of optimization (-O1 was > > > enough) > > > + -D_FORTIFY_SO

Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing

On Fri, Sep 20, 2013 at 10:01:36PM -0300, Henrique de Moraes Holschuh wrote: > IMHO: fix everything gcc, llvm and the static testers complain about (which > can be quite troublesome, as you must be *sure* you're actually fixing the > issue instead of making it worse by silencing the warning without

Re: Decision on R datasets

Le Wed, Sep 18, 2013 at 12:08:27AM +0200, Joerg Jaspert a écrit : > > Therefore, we shall consider these data files as preferred form of > modification if the data was captured in this format from a scientific > instrument, created manually and painstakingly by hand (this is not the > common case)