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
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 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
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 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
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
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
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
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
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
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
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 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 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 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 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
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 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
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
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, 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
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
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 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
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
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 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
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 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 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, 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, 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
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
33 matches
Mail list logo
