Package: wnpp
Severity: wishlist
Owner: Gioele Barabucci
* Package name: ruby-filepath
Version : 0.6
Upstream Author : Gioele Barabucci
* URL : https://rubygems.org/gems/filepath
* License : CC0
Programming Lang: Ruby
Description : Small gem to manipul
On Fri, Sep 20, 2013 at 03:05:37PM -0400, Yaroslav Halchenko wrote:
> + -D_FORTIFY_SOURCE=2 to fall into the "undefined" darkness of C standard(s)
> in s*printf() functions (man 3 sprintf, search for undefined or NOTES).
>
> Original report
> https://sourceware.org/bugzilla/show_bug.cgi?id=7075
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_SOURCE=2 to fall into the "undefined" darkness of C
> > standard(s)
> > in s
On Fri, 20 Sep 2013, Yaroslav Halchenko wrote:
> On "your" code you could look for some (no multiline or more complex
> expressions, no snprintf) hits in sprintf with following grep
> grep -re 'sprintf(\s*\(\w\+\)\s*,[^,]\+,\s*\1\>' *
> unfortunately codesearch.d.n seems to not have support for
On Fri, 20 Sep 2013, Daniel Pocock wrote:
> On 20/09/13 22:09, Bastian Blank wrote:
> > I would call code that hits such clear definitions too buggy to be
> > supported.
>
> and what if many more existing packages are found to have similar issues?
IMHO: fix everything gcc, llvm and the static tes
On Sat, Sep 21, 2013 at 12:00:57AM +0200, Adam Borowski wrote:
> > So basically a variation of the old problem of calling memcpy when one
> > meant to use memmove. I'm actually surprised that type of call to sprintf
> > ever worked reliably with optimization, even without _FORTIFY_SOURCE.
> > But,
On Sat, Sep 21, 2013 at 04:29:30AM +0600, Andrey Rahmatullin wrote:
> On Sat, Sep 21, 2013 at 12:00:57AM +0200, Adam Borowski wrote:
> > > So basically a variation of the old problem of calling memcpy when one
> > > meant to use memmove. I'm actually surprised that type of call to sprintf
> > > ev
Just to share with fellow developers, in particular those who maintain
scientific software projects which still quite often come without
thorough unittests batteries.
Within NeuroDebian we have been preparing a package of AFNI (which now could
soon be uploaded to Debian proper) which, unfortunatel
On Fri, Sep 20, 2013 at 01:08:00PM -0700, Russ Allbery wrote:
> So basically a variation of the old problem of calling memcpy when one
> meant to use memmove. I'm actually surprised that type of call to sprintf
> ever worked reliably with optimization, even without _FORTIFY_SOURCE.
> But, like mem
On 20/09/13 22:09, Bastian Blank wrote:
> I would call code that hits such clear definitions too buggy to be
> supported.
>
and what if many more existing packages are found to have similar issues?
http://debile.debian.net/sources/
One of my packages has some nice colours:
http://debile.d
Excerpts from Thomas Goirand's message of 2013-09-19 23:52:38 -0700:
> Package: wnpp
> Severity: wishlist
> Owner: Thomas Goirand
>
> * Package name: python-diskimage-builder
> Version : 0.0.2
> Upstream Author : OpenStack Development Mailing List
>
> * URL : https:/
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_SOURCE=2 to fall into the "undefined" darkness of C standard(s)
> in s*printf() functions (man 3 sprintf, search for undefined or
On Fri, 20 Sep 2013, Russ Allbery wrote:
> Yaroslav Halchenko writes:
> > long story short -- reason was the combination of optimization (-O1 was
> > enough) + -D_FORTIFY_SOURCE=2 to fall into the "undefined" darkness of C
> > standard(s) in s*printf() functions (man 3 sprintf, search for undefin
Yaroslav Halchenko writes:
> long story short -- reason was the combination of optimization (-O1 was
> enough) + -D_FORTIFY_SOURCE=2 to fall into the "undefined" darkness of C
> standard(s) in s*printf() functions (man 3 sprintf, search for undefined
> or NOTES).
So basically a variation of the
On Fri, Sep 20, 2013 at 11:19:24AM -0400, Federico Sologuren wrote:
> i have a HP Visualize B2000 that i managed to install last night from iso
> distribution that i found after a lot of looking. at this point only
> terminal is working. will keep reading to get debian up and running.
>
> i would
On 20/09/13 17:07, Paul Tagliamonte wrote:
> On Fri, Sep 20, 2013 at 05:04:50PM +0200, Daniel Pocock wrote:
>> On 20/09/13 15:49, Paul Tagliamonte wrote:
>>> On Fri, Sep 20, 2013 at 02:47:39PM +0100, Jonathan Dowland wrote:
On Fri, Sep 20, 2013 at 12:20:38PM +0200, Paul Wise wrote:
> It is
i have a HP Visualize B2000 that i managed to install last night from iso
distribution that i found after a lot of looking. at this point only
terminal is working. will keep reading to get debian up and running.
i would like to get involved. will need some additional information on what
is needed
On Fri, Sep 20, 2013 at 05:04:50PM +0200, Daniel Pocock wrote:
> On 20/09/13 15:49, Paul Tagliamonte wrote:
> > On Fri, Sep 20, 2013 at 02:47:39PM +0100, Jonathan Dowland wrote:
> >> On Fri, Sep 20, 2013 at 12:20:38PM +0200, Paul Wise wrote:
> >>> It is also impossible to patch the binary format un
On 20/09/13 15:49, Paul Tagliamonte wrote:
> On Fri, Sep 20, 2013 at 02:47:39PM +0100, Jonathan Dowland wrote:
>> On Fri, Sep 20, 2013 at 12:20:38PM +0200, Paul Wise wrote:
>>> It is also impossible to patch the binary format unlike SQL.
>> Interesting. For the first time, I've realised there can b
On Fri, Sep 20, 2013 at 02:47:39PM +0100, Jonathan Dowland wrote:
> On Fri, Sep 20, 2013 at 12:20:38PM +0200, Paul Wise wrote:
> > It is also impossible to patch the binary format unlike SQL.
>
> Interesting. For the first time, I've realised there can be a clash between
> "preferred form for modi
On Fri, Sep 20, 2013 at 12:20:38PM +0200, Paul Wise wrote:
> It is also impossible to patch the binary format unlike SQL.
Interesting. For the first time, I've realised there can be a clash between
"preferred form for modification" and "preferred form for use".
--
To UNSUBSCRIBE, email to debia
On Thu, Sep 19, 2013 at 08:10:07PM -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 20 Sep 2013, Faheem Mitha wrote:
> > So, I suppose anyone using the software needs to download it. I'll
> > provide a script to download the data, but if I want to build a
> > Debian package containing that data,
On Fri, Sep 20, 2013 at 10:59 AM, Chow Loong Jin wrote:
> Just speaking for myself here, but I find that the binary format is more
> flexible in that pg_restore can selectively restore things, generate DROP
> statements, restoring things in parallel and such. All in all, the binary
> format
Package: wnpp
Severity: wishlist
Owner: Jerome Benoit
* Package name: mpfrc++
Version : 2013-09-02
Upstream Author : Pavel Holoborodko
* URL : http://www.holoborodko.com/pavel/mpfr
* License : GPL
Programming Lang: C++
Description : C++ wrapper for the
I have not been involved before in the porting effort but may be interested if
there is a need. I have a few alpha platforms and ia64. Could someone describe
or point me to a Web page that describes what is involved? I have a c
programming background for a lot of years and am now a java software
Re: Paul Wise 2013-09-20
> The format doesn't appear to be very efficient, the plain SQL commands
> are much smaller:
>
> pabs@wagner:~$ pg_restore -l postbooks_empty-4.1.0.backup > foo.sql
> pabs@wagner:~$ ls -Ssh
> total 5.6M
> 5.3M postbooks_empty-4.1.0.backup 344K foo.sql
pg_restore -l wil
FWIW, I am a porter of the Alpha architecture in the following ways:
- run a buildd
- kernel support
- work with upstreams for toolchain support
- general porting work including filing bugs and patches
I doubt if I will continue that for the life cycle of Jessie given that
many of the former
On 20/09/2013 10:59, Chow Loong Jin wrote:
> On Fri, Sep 20, 2013 at 09:07:48AM +0200, Paul Wise wrote:
>> > On Thu, Sep 19, 2013 at 2:42 PM, Daniel Pocock wrote:
>> >
>>> > > PostBooks distributes their schema as a Postgres binary dump file for
>>> > > use with pg_restore
>> >
>> > What is their
On Fri, Sep 20, 2013 at 09:07:48AM +0200, Paul Wise wrote:
> On Thu, Sep 19, 2013 at 2:42 PM, Daniel Pocock wrote:
>
> > PostBooks distributes their schema as a Postgres binary dump file for
> > use with pg_restore
>
> What is their reason for using the binary format? Could they be
> convinced to
Hi,
I am an active tester (not always porter) for the following architectures and I
intend
to continue this for the lifetime of the jessie release:
i386, amd64, armel
- test most base packages on this architecture (every day tasks)
- test arch-related things
- test lots of ipv6 related issues
On 20/09/13 09:07, Paul Wise wrote:
> On Thu, Sep 19, 2013 at 2:42 PM, Daniel Pocock wrote:
>
>> PostBooks distributes their schema as a Postgres binary dump file for
>> use with pg_restore
> What is their reason for using the binary format? Could they be
> convinced to switch to or add something m
On Thu, Sep 19, 2013 at 2:49 PM, Martijn van Oosterhout wrote:
> FWIW, you can convert the file to text using pg_restore, you don't actually
> need a running database server. It's really just a compressed tarball and
> should be treated as such. That is, I think it can be included as-is. Unless
>
On Thu, Sep 19, 2013 at 2:42 PM, Daniel Pocock wrote:
> PostBooks distributes their schema as a Postgres binary dump file for
> use with pg_restore
What is their reason for using the binary format? Could they be
convinced to switch to or add something more normal like compressed
SQL?
--
bye,
pa
33 matches
Mail list logo
