Debian Bug report logs - #703645
ITP: postbooks - ERP, CRM and accounting software

version graph

Package: wnpp; Maintainer for wnpp is wnpp@debian.org;

Reported by: Daniel Pocock <daniel@pocock.com.au>

Date: Thu, 21 Mar 2013 19:33:01 UTC

Owned by: bugzilla@tut.by

Severity: wishlist

Fixed in version postbooks/4.0.0-1

Done: Daniel Pocock <daniel@pocock.com.au>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#703645; Package wnpp. (Thu, 21 Mar 2013 19:33:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
New Bug report received and forwarded. Copy sent to wnpp@debian.org. (Thu, 21 Mar 2013 19:33:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: submit@bugs.debian.org
Subject: ITP: postbooks - ERP, CRM and accounting software
Date: Thu, 21 Mar 2013 20:30:40 +0100
Package: wnpp
Severity: wishlist
Owner: Daniel Pocock <daniel@pocock.com.au>

Upstream:

  http://www.xtuple.org
  https://www.xtuple.com/postbooks

License: CPAL (derived from Mozilla)
 https://www.xtuple.com/CPAL

Initial observations:

Depends on openrpt and csvimp (from the same upstream)
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338784

I've done a successful build of openrpt, csvimp and xtuple (the main
package) from SVN on a squeeze system



Here are some observations:

Fetch build dependencies:

  apt-get install qt4-qmake libqt4-dev

Checkout source:

svn co https://svn.code.sf.net/p/postbooks/code/openrpt/trunk openrpt
svn co https://svn.code.sf.net/p/postbooks/code/csvimp/trunk csvimp
svn co https://svn.code.sf.net/p/postbooks/code/xtuple/trunk xtuple

cd openrpt && qmake && make && \
  cd ../csvimp && qmake && make && \
  cd ../xtuple && qmake && make

Fetch runtime dependencies:

  apt-get install postgres libqt4-sql-psql postgresql-contrib-9.1

Do the postgres setup:

Get a copy of init.sql and a default database (e.g. demo or quickstart)
from sourceforge
  https://sourceforge.net/projects/postbooks/files/03%20PostBooks-databases/

Here I am using the default password admin from init.sql, change it for
a real setup of course:

su
su - postgres
psql -U postgres -f /tmp/init.sql postgres
createdb -U admin -W -h localhost xtuple
pg_restore -U admin -W -h localhost -d xtuple quickstart.backup -v

and then run

  xtuple/bin/xtuple

If there is an error about the database not matching the xtuple version,
download another database or if feeling brave, just edit
guiclient/version.cpp to match the database version from the error message






Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#703645; Package wnpp. (Sun, 24 Mar 2013 10:03:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Sun, 24 Mar 2013 10:03:06 GMT) Full text and rfc822 format available.

Message #10 received at 703645@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: 703645@bugs.debian.org
Subject: discussion on debian-devel
Date: Sun, 24 Mar 2013 11:00:59 +0100


Andrew Shadura has indicated that he is developing packages of PostBooks
already:

http://lists.debian.org/debian-devel/2013/03/msg00358.html

and may take ownership of this ITP bug.



Added blocking bug(s) of 703645: 338784 Request was from Daniel Pocock <daniel@pocock.com.au> to control@bugs.debian.org. (Sun, 24 Mar 2013 10:09:07 GMT) Full text and rfc822 format available.

Owner changed from Daniel Pocock <daniel@pocock.com.au> to bugzilla@tut.by. Request was from Daniel Pocock <daniel@pocock.com.au> to control@bugs.debian.org. (Wed, 15 May 2013 14:39:07 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Wed, 18 Sep 2013 14:15:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Wed, 18 Sep 2013 14:15:12 GMT) Full text and rfc822 format available.

Message #19 received at 703645@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: 703645@bugs.debian.org, 338784@bugs.debian.org, 723654@bugs.debian.org
Subject: packaging update
Date: Wed, 18 Sep 2013 16:12:54 +0200
We now have a packaging team for Postbooks and dependencies:
  
https://alioth.debian.org/projects/pkg-xtuple/

Andrew has now started uploading to Mercurial on alioth

http://anonscm.debian.org/hg/collab-maint/xtuple/

Upstream now appears to be using github as well as sourceforge:

https://github.com/xtuple





Added blocking bug(s) of 703645: 723654 Request was from Daniel Pocock <daniel@pocock.com.au> to control@bugs.debian.org. (Wed, 18 Sep 2013 14:15:21 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Wed, 18 Sep 2013 14:30:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Wed, 18 Sep 2013 14:30:04 GMT) Full text and rfc822 format available.

Message #26 received at 703645@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: 703645@bugs.debian.org
Subject: upstream support for upgrades
Date: Wed, 18 Sep 2013 16:27:40 +0200
One important issue for this package will be the database upgrade
procedure between major releases of Debian

Does upstream provide a suitable schema update mechanism that can
upgrade users who only upgrade every 2 years, or do they only support
upgrades between each of their own consecutive releases and Debian users
may have to run such upgrades back-to-back?

Alternatively, should it simply refuse to run after package upgrade and
leave the user to manage the schema manually?  Maybe README.Debian
should warn the users about the extent of support that will be provided
for their future upgrades so they can make an informed decision when
comparing it to other similar packages.





Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Wed, 18 Sep 2013 18:48:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Wed, 18 Sep 2013 18:48:07 GMT) Full text and rfc822 format available.

Message #31 received at 703645@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: 703645@bugs.debian.org, 338784@bugs.debian.org, 723654@bugs.debian.org, Andrew Shadura <andrew@shadura.me>
Subject: packaging versions
Date: Wed, 18 Sep 2013 20:46:06 +0200

Just some comments about versions for the xTuple source packages:

- I think the first commits in the git repos should be the versions
Andrew has used in production (please confirm versions for each pkg)

- we can then commit on the upstream branch the versions that I've used
in production:
   - CVSImp 0.4.7 (already committed)
   - my OpenRPT is from SVN, it has the string 3.3.4Beta2 in the version
field
   - my PostBooks (xTuple project in SVN) says v4.0.0 in the source, but
the version has been tweaked to access the v4.0.2 database

- we could potentially commit the intermediate versions if they may be
needed during schema upgrades.  We can commit them on the upstream
branch without packaging them for now.

- for new users, maybe we need to import the latest sources as well and
aim to upload that to sid after we have a chance to test it and upgrade
ourselves





Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Thu, 19 Sep 2013 12:18:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Thu, 19 Sep 2013 12:18:08 GMT) Full text and rfc822 format available.

Message #36 received at 703645@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: 703645@bugs.debian.org
Cc: Andrew Shadura <andrew@shadura.me>
Subject: packaging the database schema
Date: Thu, 19 Sep 2013 14:15:04 +0200
A database schema is required in order to run the PostBooks application

The database schema is not included in the source tarball.  Rather,
upstream distributes the schema as a separate download

They have several schemas available:

- an empty database (just the tables)

- a quickstart database (includes chart of accounts and other standard
content in the tables)

- a demo database (like quickstart, but also includes sample customers
and transaction data)

The current versions are available here:

http://sourceforge.net/projects/postbooks/files/03%20PostBooks-databases/4.1.0/

They also mention an installer but it is not clear whether their
"installer" will run as a Debian package or if it is better to just
treat the quickstart schema as a new source package and implement a
postinst script to install it.





Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Thu, 19 Sep 2013 12:45:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Thu, 19 Sep 2013 12:45:04 GMT) Full text and rfc822 format available.

Message #41 received at 703645@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: debian-devel@lists.debian.org
Cc: 703645@bugs.debian.org, Andrew Shadura <bugzilla@tut.by>
Subject: packaging Postgres binary dump files
Date: Thu, 19 Sep 2013 14:42:45 +0200

PostBooks distributes their schema as a Postgres binary dump file for
use with pg_restore

They are available for download here (not in the source tarball):

  
http://sourceforge.net/projects/postbooks/files/03%20PostBooks-databases/4.1.0/

The pg_dump documentation explains the binary format features:

   http://www.postgresql.org/docs/9.1/static/app-pgdump.html

Is this format suitable for making a source package or do we need to
load it into Postgres and then pg_dump it again as text / SQL?

I would prefer to simply distribute the original files so that people
can compare with upstream's checksums if they wish.





Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Thu, 19 Sep 2013 12:51:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Martijn van Oosterhout <kleptog@gmail.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Thu, 19 Sep 2013 12:51:05 GMT) Full text and rfc822 format available.

Message #46 received at 703645@bugs.debian.org (full text, mbox):

From: Martijn van Oosterhout <kleptog@gmail.com>
To: Debian Developers <debian-devel@lists.debian.org>
Cc: 703645@bugs.debian.org, Andrew Shadura <bugzilla@tut.by>
Subject: Re: packaging Postgres binary dump files
Date: Thu, 19 Sep 2013 14:49:37 +0200
[Message part 1 (text/plain, inline)]
On 19 September 2013 14:42, Daniel Pocock <daniel@pocock.com.au> wrote:

>
>
> PostBooks distributes their schema as a Postgres binary dump file for
> use with pg_restore
>
> They are available for download here (not in the source tarball):
>
>
> http://sourceforge.net/projects/postbooks/files/03%20PostBooks-databases/4.1.0/
>
> Is this format suitable for making a source package or do we need to
> load it into Postgres and then pg_dump it again as text / SQL?
>
> I would prefer to simply distribute the original files so that people
> can compare with upstream's checksums if they wish.
>

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 you're thinking of patching it, in which case you need to think of
something else.

Have a nice day,
-- 
Martijn van Oosterhout <kleptog@gmail.com> http://svana.org/kleptog/
[Message part 2 (text/html, inline)]

Added tag(s) pending. Request was from Anibal Monsalve Salazar <anibal@debian.org> to control@bugs.debian.org. (Thu, 19 Sep 2013 20:06:11 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Fri, 20 Sep 2013 07:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Wise <pabs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Fri, 20 Sep 2013 07:09:04 GMT) Full text and rfc822 format available.

Message #53 received at 703645@bugs.debian.org (full text, mbox):

From: Paul Wise <pabs@debian.org>
To: Daniel Pocock <daniel@pocock.com.au>
Cc: debian-devel@lists.debian.org, 703645@bugs.debian.org, Andrew Shadura <bugzilla@tut.by>
Subject: Re: packaging Postgres binary dump files
Date: Fri, 20 Sep 2013 09:07:48 +0200
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,
pabs

http://wiki.debian.org/PaulWise



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Fri, 20 Sep 2013 07:15:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Wise <pabs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Fri, 20 Sep 2013 07:15:15 GMT) Full text and rfc822 format available.

Message #58 received at 703645@bugs.debian.org (full text, mbox):

From: Paul Wise <pabs@debian.org>
To: Martijn van Oosterhout <kleptog@gmail.com>
Cc: Debian Developers <debian-devel@lists.debian.org>, 703645@bugs.debian.org, Andrew Shadura <bugzilla@tut.by>
Subject: Re: packaging Postgres binary dump files
Date: Fri, 20 Sep 2013 09:13:56 +0200
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
> you're thinking of patching it, in which case you need to think of something
> else.

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

It doesn't seem possible to treat it as a compressed tarball:

pabs@chianamo ~ $ tar zxf postbooks_empty-4.1.0.backup
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
pabs@chianamo ~ $ tar jxf postbooks_empty-4.1.0.backup
bzip2: (stdin) is not a bzip2 file.
tar: Child returned status 2
tar: Error is not recoverable: exiting now
pabs@chianamo ~ $ tar Jxf postbooks_empty-4.1.0.backup
xz: (stdin): File format not recognized
tar: Child returned status 1
tar: Error is not recoverable: exiting now

-- 
bye,
pabs

http://wiki.debian.org/PaulWise



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Fri, 20 Sep 2013 08:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Fri, 20 Sep 2013 08:03:04 GMT) Full text and rfc822 format available.

Message #63 received at 703645@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: Paul Wise <pabs@debian.org>
Cc: debian-devel@lists.debian.org, 703645@bugs.debian.org, Andrew Shadura <bugzilla@tut.by>
Subject: Re: packaging Postgres binary dump files
Date: Fri, 20 Sep 2013 09:59:40 +0200
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 more normal like compressed
> SQL?
>


Maybe they are just trying to make it easy for people to download and
start using it quickly.

My own database was created using their "quickstart" database, I've also
tried their "demo" database, both are very easy to use for anybody with
basic PostgreSQL knowledge.

They also provide an installer as another way to get started.  Neither
Andrew nor I have tried that yet and it is not in the main upstream
tarball, it is released from another repository.  We may want to provide
just the SQL and a postinst script wrapped in a Debian package rather
than packaging their whole installer.





Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Fri, 20 Sep 2013 09:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chow Loong Jin <hyperair@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Fri, 20 Sep 2013 09:03:04 GMT) Full text and rfc822 format available.

Message #68 received at 703645@bugs.debian.org (full text, mbox):

From: Chow Loong Jin <hyperair@debian.org>
To: Paul Wise <pabs@debian.org>
Cc: Daniel Pocock <daniel@pocock.com.au>, debian-devel@lists.debian.org, 703645@bugs.debian.org, Andrew Shadura <bugzilla@tut.by>
Subject: Re: packaging Postgres binary dump files
Date: Fri, 20 Sep 2013 16:59:32 +0800
[Message part 1 (text/plain, inline)]
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 switch to or add something more normal like compressed
> SQL?

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
seems much more useful than the SQL format.

You can also compress the binary format (pg_dump -Z0..9), but it still isn't as
efficient as SQL compressed with xz -9.

-- 
Kind regards,
Loong Jin
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Fri, 20 Sep 2013 09:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Federico Di Gregorio <fog@dndg.it>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Fri, 20 Sep 2013 09:15:04 GMT) Full text and rfc822 format available.

Message #73 received at 703645@bugs.debian.org (full text, mbox):

From: Federico Di Gregorio <fog@dndg.it>
To: Paul Wise <pabs@debian.org>, Daniel Pocock <daniel@pocock.com.au>, debian-devel@lists.debian.org, 703645@bugs.debian.org, Andrew Shadura <bugzilla@tut.by>
Subject: Re: packaging Postgres binary dump files
Date: Fri, 20 Sep 2013 11:05:35 +0200
[Message part 1 (text/plain, inline)]
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 reason for using the binary format? Could they be
>> > convinced to switch to or add something more normal like compressed
>> > SQL?
> 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
> seems much more useful than the SQL format.
> 
> You can also compress the binary format (pg_dump -Z0..9), but it still isn't as
> efficient as SQL compressed with xz -9.

The binary format is the preferred one for dumps because allows to
selectively restore only parts of a database. Doing the same kind of
manipulation using an SQL script requires a lot of proficiency in
sed/awk/perl and regular expressions. Yes the format is binary but given
that the tools to manipulate it are completely free and already
available in Debian why distribute a less useful version of the same data?

federico

-- 
Federico Di Gregorio                         federico.digregorio@dndg.it
                           Don't dream it. Be it. -- Dr. Frank'n'further

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Fri, 20 Sep 2013 09:57:04 GMT) Full text and rfc822 format available.

Message #76 received at 703645@bugs.debian.org (full text, mbox):

From: Christoph Berg <myon@debian.org>
To: Paul Wise <pabs@debian.org>
Cc: Martijn van Oosterhout <kleptog@gmail.com>, Debian Developers <debian-devel@lists.debian.org>, 703645@bugs.debian.org, Andrew Shadura <bugzilla@tut.by>
Subject: Re: packaging Postgres binary dump files
Date: Fri, 20 Sep 2013 11:53:11 +0200
[Message part 1 (text/plain, inline)]
Re: Paul Wise 2013-09-20 <CAKTje6H+3YuHOo3Tr39yuCubjdZD08XOcVUu=02TvTtX9x1OZw@mail.gmail.com>
> 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 will just give you the listing of what's inside the dump
file, not the actual contents.

> It doesn't seem possible to treat it as a compressed tarball:
> 
> pabs@chianamo ~ $ tar zxf postbooks_empty-4.1.0.backup

That'd be "pg_restore postbooks_empty-4.1.0.backup".

(Note that there is also a "tar" format that "pg_dump -Ft" will
create, but that format is crap because it needs to create a tempfile
somewhere first. These "binary" or "custom" dumps that "pg_dump -Fc"
creates are much more flexible to use because you can stream them when
writing, while at the same time getting a TOC for random read access
later.)

Christoph
-- 
cb@df7cb.de | http://www.df7cb.de/
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Fri, 20 Sep 2013 10:24:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Wise <pabs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Fri, 20 Sep 2013 10:24:04 GMT) Full text and rfc822 format available.

Message #81 received at 703645@bugs.debian.org (full text, mbox):

From: Paul Wise <pabs@debian.org>
To: Paul Wise <pabs@debian.org>, Daniel Pocock <daniel@pocock.com.au>, debian-devel@lists.debian.org, 703645@bugs.debian.org, Andrew Shadura <bugzilla@tut.by>
Subject: Re: packaging Postgres binary dump files
Date: Fri, 20 Sep 2013 12:20:38 +0200
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
> seems much more useful than the SQL format.

In this case we are talking about installation and upgrades,
presumably selective restoration etc aren't needed here.

> You can also compress the binary format (pg_dump -Z0..9), but it still isn't as
> efficient as SQL compressed with xz -9.

It is more efficient than SQL but less efficient than even lzop -1, I
guess there is not much compression.

It is also impossible to patch the binary format unlike SQL.

Anyway, this is getting off-topic. As long as the ftpteam are made
aware of the format's properties everything should be fine.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Fri, 20 Sep 2013 12:06:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Fri, 20 Sep 2013 12:06:08 GMT) Full text and rfc822 format available.

Message #86 received at 703645@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: 703645@bugs.debian.org
Subject: now linking against shared libs
Date: Fri, 20 Sep 2013 14:04:16 +0200
The latest push in postbooks.git links to the shared libs of openrpt

I've tested and it appears to be running fine


$ ldd bin/xtuple
    linux-vdso.so.1 (0x00007fffac969000)
    libwrtembed.so.1 => /usr/lib/x86_64-linux-gnu/libwrtembed.so.1
(0x00007fcc7a97a000)
    libcommon.so.1 => /usr/lib/x86_64-linux-gnu/libcommon.so.1
(0x00007fcc7a70a000)
    librenderer.so.1 => /usr/lib/x86_64-linux-gnu/librenderer.so.1
(0x00007fcc7a47a000)
    libdmtx.so.0 => /usr/lib/x86_64-linux-gnu/libdmtx.so.0
(0x00007fcc7a266000)
    libMetaSQL.so.1 => /usr/lib/x86_64-linux-gnu/libMetaSQL.so.1
(0x00007fcc79ff7000)
    libQtDesignerComponents.so.4 =>
/usr/lib/x86_64-linux-gnu/libQtDesignerComponents.so.4 (0x00007fcc79b59000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fcc79942000)
    libQtHelp.so.4 => /usr/lib/x86_64-linux-gnu/libQtHelp.so.4
(0x00007fcc796ba000)
    libQtWebKit.so.4 => /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4
(0x00007fcc77b7e000)
    libQtScript.so.4 => /usr/lib/x86_64-linux-gnu/libQtScript.so.4
(0x00007fcc776da000)
    libQtScriptTools.so.4 =>
/usr/lib/x86_64-linux-gnu/libQtScriptTools.so.4 (0x00007fcc7741d000)
    libQtSql.so.4 => /usr/lib/x86_64-linux-gnu/libQtSql.so.4
(0x00007fcc771dc000)
    libQtXmlPatterns.so.4 =>
/usr/lib/x86_64-linux-gnu/libQtXmlPatterns.so.4 (0x00007fcc76b95000)
    libQtXml.so.4 => /usr/lib/x86_64-linux-gnu/libQtXml.so.4
(0x00007fcc76952000)
    libQtGui.so.4 => /usr/lib/x86_64-linux-gnu/libQtGui.so.4
(0x00007fcc75c9a000)
    libQtNetwork.so.4 => /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4
(0x00007fcc7595a000)
    libQtCore.so.4 => /usr/lib/x86_64-linux-gnu/libQtCore.so.4
(0x00007fcc75486000)
    libQtDesigner.so.4 => /usr/lib/x86_64-linux-gnu/libQtDesigner.so.4
(0x00007fcc74d2e000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fcc74b12000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007fcc7480b000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcc7450c000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007fcc742f6000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcc73f4a000)
    libQtCLucene.so.4 => /usr/lib/x86_64-linux-gnu/libQtCLucene.so.4
(0x00007fcc73c35000)
    libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
(0x00007fcc7398a000)
    libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1
(0x00007fcc73780000)
    libgstapp-0.10.so.0 => /usr/lib/x86_64-linux-gnu/libgstapp-0.10.so.0
(0x00007fcc73573000)
    libgstinterfaces-0.10.so.0 =>
/usr/lib/x86_64-linux-gnu/libgstinterfaces-0.10.so.0 (0x00007fcc73361000)
    libgstpbutils-0.10.so.0 =>
/usr/lib/x86_64-linux-gnu/libgstpbutils-0.10.so.0 (0x00007fcc7313b000)
    libgstvideo-0.10.so.0 =>
/usr/lib/x86_64-linux-gnu/libgstvideo-0.10.so.0 (0x00007fcc72f1e000)
    libgstbase-0.10.so.0 =>
/usr/lib/x86_64-linux-gnu/libgstbase-0.10.so.0 (0x00007fcc72cc9000)
    libgstreamer-0.10.so.0 =>
/usr/lib/x86_64-linux-gnu/libgstreamer-0.10.so.0 (0x00007fcc729e0000)
    libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
(0x00007fcc72790000)
    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x00007fcc72491000)
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
(0x00007fcc72155000)
    libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
(0x00007fcc71f1a000)
    libaudio.so.2 => /usr/lib/x86_64-linux-gnu/libaudio.so.2
(0x00007fcc71cff000)
    libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0
(0x00007fcc71ad8000)
    libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6
(0x00007fcc71839000)
    libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007fcc71631000)
    libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6
(0x00007fcc71416000)
    libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6
(0x00007fcc71204000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcc70fff000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fcc70df7000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fcc7ad45000)
    liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0
(0x00007fcc70b79000)
    libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0
(0x00007fcc70975000)
    libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2
(0x00007fcc70813000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6
(0x00007fcc7060a000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fcc703cc000)
    libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1
(0x00007fcc701ac000)
    libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
(0x00007fcc6ff81000)
    libXt.so.6 => /usr/lib/x86_64-linux-gnu/libXt.so.6 (0x00007fcc6fd1a000)
    libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6
(0x00007fcc6fb17000)
    libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fcc6f911000)
    liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fcc6f6ee000)
    libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
(0x00007fcc6f4e8000)




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Fri, 20 Sep 2013 16:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Fri, 20 Sep 2013 16:21:05 GMT) Full text and rfc822 format available.

Message #91 received at 703645@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: Paul Tagliamonte <paultag@debian.org>
Cc: debian-devel@lists.debian.org, 703645@bugs.debian.org
Subject: Re: packaging Postgres binary dump files
Date: Fri, 20 Sep 2013 18:18:32 +0200
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 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".
>>> I mean, not really, right?
>>>
>>> If I want to use a .so, I want the ELF, but I want to modify it in C
>>>
>>>
>>> This just means we ship the prefered form for use (this binary kruft)
>>> but ship the preferred form for modification in the source.
>> The rules file could apply changes if required, pg_restore | something |
>> pg_dump again.
>>
>> The current version of the postbooks-schema-* packages are now in
>> collab-maint git. They simply install these files to
>> /usr/share/postbooks-schema but make no attempt to load them into PostgreSQL
>>
>> In this case, it is a client-server solution.  There is no guarantee the
>> client code (package: postbooks) runs on the same host as the database
>> (packages postgresql and postbooks-schema-quickstart).  Maybe the user
>> even has some Windows clients too.  So we have no easy way to
>> synchronize changes to the client package and the database.
>>
>> If somebody wants to create any indexes in the database, details can go
>> in README.Debian.  The administrator can then choose how to use it.
>>
>> However, if the package is formally rejected by the FTP masters then I
>> will be happy to change it to ASCII SQL if required.
> Please include the source / preferred form for modification in the
> source, and create this postgres thing from that.

I've now re-created the git repos on alioth and created a new version of
the orig.tar.gz that includes both the file downloaded from upstream and
an ASCII SQL

Only the SQL is shipped in the binary package.

The file from upstream is not distributed in the binary package for now
and we do not try to regenerate it either.  The conversion between this
format and ASCII is one way with the pg_restore command.  We convert the
file from binary to SQL during the creation of the orig.tar.gz (it is a
repackaged upstream tarball in effect).

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 if we want to support things like chroot
builds.

There are two downsides to this approach:
- user doesn't get the benefit of the pg_restore features for selective
restore
- the usage instructions are very slightly different from what upstream
describes, in particular, the SQL is zipped and has to be piped through
zcat when using it




Reply sent to Daniel Pocock <daniel@pocock.com.au>:
You have taken responsibility. (Sat, 21 Sep 2013 04:03:46 GMT) Full text and rfc822 format available.

Notification sent to Daniel Pocock <daniel@pocock.com.au>:
Bug acknowledged by developer. (Sat, 21 Sep 2013 04:03:46 GMT) Full text and rfc822 format available.

Message #96 received at 703645-close@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: 703645-close@bugs.debian.org
Subject: Bug#703645: fixed in postbooks 4.0.0-1
Date: Sat, 21 Sep 2013 04:00:23 +0000
Source: postbooks
Source-Version: 4.0.0-1

We believe that the bug you reported is fixed in the latest version of
postbooks, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 703645@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Daniel Pocock <daniel@pocock.com.au> (supplier of updated postbooks package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 19 Sep 2013 18:33:39 +0200
Source: postbooks
Binary: postbooks
Architecture: source amd64
Version: 4.0.0-1
Distribution: unstable
Urgency: low
Maintainer: Debian xTuple Maintainers <pkg-xtuple-maintainers@lists.alioth.debian.org>
Changed-By: Daniel Pocock <daniel@pocock.com.au>
Description: 
 postbooks  - multi-user accounting / CRM / ERP suite (GUI)
Closes: 703645
Changes: 
 postbooks (4.0.0-1) unstable; urgency=low
 .
   * Initial release. (Closes: #703645)
Checksums-Sha1: 
 a1f61a379470d8003521d21c4317e1d66f584641 1977 postbooks_4.0.0-1.dsc
 73c3b23b9997c043c143908107337ad458d93fed 2692556 postbooks_4.0.0.orig.tar.bz2
 32b1fefe906e25f1448d9f896b8fe6ee90d1f248 14131 postbooks_4.0.0-1.debian.tar.gz
 683d55aba5611da3b9d5e4a834be480581a55b6b 10739514 postbooks_4.0.0-1_amd64.deb
Checksums-Sha256: 
 3e2db6dce836db47cd03f58a197a4811249167f4d09d4df388267407667bc14a 1977 postbooks_4.0.0-1.dsc
 4d8fc7366fa9fd16fd4cc5173c87ccc6f883eb99e3d28df9761512975fb5dffd 2692556 postbooks_4.0.0.orig.tar.bz2
 b476e11226f794ceeaeab684e581b90bb7f66c79d6ca985a4c822ce484274710 14131 postbooks_4.0.0-1.debian.tar.gz
 c3048c4bd8648bca07fb0e1832bb2cb3881cd463871d896ee8d87509f8971fc2 10739514 postbooks_4.0.0-1_amd64.deb
Files: 
 f63a0d89355924df7f38a5a06da37231 1977 misc optional postbooks_4.0.0-1.dsc
 f79bb953a79aca073cc60f799c942d15 2692556 misc optional postbooks_4.0.0.orig.tar.bz2
 1929a0f3c97143500c55fe15b6f741ea 14131 misc optional postbooks_4.0.0-1.debian.tar.gz
 c24737dd20b9738ce7eb423a54607029 10739514 misc optional postbooks_4.0.0-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJSO1F7AAoJEOm1uwJp1aqD/wUQALW1DOptWgYOy0/Wv9/jZ3lw
tUAv7T0ZutqTY3GqGX0jrNEa3AmJzXPWpZarvdGfEi+s3jPcsGzSx32/jiUhYKDE
I8UiPvLJoa+W+gs6TYfBu1lfiPunIitQbPmK9IsMJ6uGJozmAoJdy/7BKXi2k8qu
wmavS/9zQ2GtJyV6u7X3fKZKfBjJbYR6XEZOMSqisIbdXazQh1OapBInyo6xL/jp
Tkqh04rcXSu5vcxRK75cV73x/Jc1vos6O5PTJ6Bz1+mNk/3IPWRV81IQwigBgwGo
asYDm+b0o6GwzGGZZ1hsVWLwFZSltJJMFFIfWSrtFew09hNMRgY6FQIJCVw9Lpy5
ln9W3LpVDdPj7zgjXBFe0L7PdYS78TFIsgjM9UsKbJ2yi69xF1KCbGaTP10MyV0B
NRBpbyZF4q5X8pTnXREn95cH4xS8/TGUr/rnkGwXYoJvth2nrVwR4LTmbd3+19Qz
h19LktZTYndoz7l45gQJYBloNhLAkTFmAILc8I8dUZ93+qUesuXGRp0W82hdDf2y
klF0B+Dz2LfvFrSG3q5JZRMgEp+r4CnxfC4MrPMjXEgkgUqjColCJwn8J3rMkyu2
cceZcUcwgElkl+8H6ZGR+ZTXsT8Q0Wj4Lo/tMRbSwMIMoHIZ/kk7rK+ot03qXyPF
VkGNVS5AMhHOXxXxZIsT
=SkL6
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Sat, 21 Sep 2013 18:42:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bernd Zeimetz <bernd@bzed.de>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Sat, 21 Sep 2013 18:42:04 GMT) Full text and rfc822 format available.

Message #101 received at 703645@bugs.debian.org (full text, mbox):

From: Bernd Zeimetz <bernd@bzed.de>
To: Daniel Pocock <daniel@pocock.com.au>
Cc: Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org, 703645@bugs.debian.org
Subject: Re: packaging Postgres binary dump files
Date: Sat, 21 Sep 2013 20:40:11 +0200
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 if we want to support things like chroot
> builds.

I don't think you should distribute the files in the binary format at all as
you'd have to require a pg_restore which is able to restore the files from
pg_dump in the version you've used to package it - so while it might be possible
that the ascii version just works well for older postgres versions, you might
end up with needed pg_restore form 9.x just becuase you dumped it with it.


-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, bugzilla@tut.by:
Bug#703645; Package wnpp. (Sun, 22 Sep 2013 10:24:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joerg Jaspert <joerg@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, bugzilla@tut.by. (Sun, 22 Sep 2013 10:24:05 GMT) Full text and rfc822 format available.

Message #106 received at 703645@bugs.debian.org (full text, mbox):

From: Joerg Jaspert <joerg@debian.org>
To: Daniel Pocock <daniel@pocock.com.au>
Cc: Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org, 703645@bugs.debian.org
Subject: Re: packaging Postgres binary dump files
Date: Sun, 22 Sep 2013 12:20:33 +0200
On 13340 March 1977, Daniel Pocock wrote:
>>> However, if the package is formally rejected by the FTP masters then I
>>> will be happy to change it to ASCII SQL if required.
>> Please include the source / preferred form for modification in the
>> source, and create this postgres thing from that.

> I've now re-created the git repos on alioth and created a new version of
> the orig.tar.gz that includes both the file downloaded from upstream and
> an ASCII SQL
> Only the SQL is shipped in the binary package.

I think this is similar to other cases that came up in the past. The
preferred form for modification isn't what is shipped and probably best
to use / used by default from upstream and it's not easy to regenerate
it at build time. The preferred form of modification is a running
database and SQL commands issued to it with whatever interface.

So what you should ship in the source is the file from upstream plus the
SQL to generate it. Ideally you would now build-depend on a running
postgres server, but everyone could understand the armada of black
helicopters that buildd admins will send your way for this.  I would
even lend a chainsaw or two :)

So this falls under the: "Not easy to regenerate" category. Which means
that, ohwell, ship the upstream file - or one you generated yourself
from the SQL, and don't rebuild it on buildds.
BUT *you* *must* make entirely sure that what is shipped corresponds with
the source AKA the SQL file. (And document it in README.source please)
And double bonus points if there is an easy accessible way of getting
from SQL to binary file, say debian/rules rebuild or so. With the
implication that the user has to have a postgres ready for it to load and
dump from. Or so.

-- 
bye, Joerg
Marge, it takes two to lie. One to lie and one to listen.



Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Mon, 21 Oct 2013 07:30:46 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 05:09:46 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.