Thread: beta3
Are we doing beta3 soon? I thought we were going to do it yesterday, though it seems like we have a few packaging problems to iron out first. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Are we doing beta3 soon? I thought we were going to do it yesterday,
> though it seems like we have a few packaging problems to iron out first.
The packaging problems need to be solved before we can build a release
candidate --- but I don't see why they should hold up beta3. beta2 has
the same problems, so beta3 wouldn't be a regression.
I don't have any pending work that ought to go in beta3, but I think
Thomas is sitting on some datetime patches ... probably should wait
for him.
regards, tom lane
Tom Lane writes: > The packaging problems need to be solved before we can build a release > candidate --- but I don't see why they should hold up beta3. beta2 has > the same problems, so beta3 wouldn't be a regression. Considering the history of how-do-we-get-the-docs-in-the-tarball problem, I'd like to see at least one beta where this works before shipping a release candidate. Otherwise I'll have no confidence at all that we're not going to ship the final release with last year's docs and no man pages. -- Peter Eisentraut peter_e@gmx.net
Okay, how do we want to address/fix/test this? On Sun, 18 Nov 2001, Peter Eisentraut wrote: > Tom Lane writes: > > > The packaging problems need to be solved before we can build a release > > candidate --- but I don't see why they should hold up beta3. beta2 has > > the same problems, so beta3 wouldn't be a regression. > > Considering the history of how-do-we-get-the-docs-in-the-tarball problem, > I'd like to see at least one beta where this works before shipping a > release candidate. Otherwise I'll have no confidence at all that we're > not going to ship the final release with last year's docs and no man > pages. > > -- > Peter Eisentraut peter_e@gmx.net > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html >
Marc G. Fournier writes: > Okay, how do we want to address/fix/test this? Assuming that we don't want to make sweeping changes to the overall procedure, I suggest this: 1. The postgres.tar.gz and man.tar.gz documentation tarballs required for a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The new file system location of this directory needs to be determined. 2. Some postgres.tar.gz and man.tar.gz files need to be put there. 3. The currently commented out portion in the mk-release script needs to be altered to pick up these files. (I also suggest 'set -e' in this script so it doesn't ignore errors.) 4. The HTML-doc-build cron job needs to be reinstated on postgresql.org and put its output file at the new location. 5. When I'm done with the new manpages I'll upload them to the appropriate location. I think the answer to #1 is /var/spool/ftp or something. For #2, use the postgres.tar.gz files that Bruce currently builds, and use the old man.tar.gz file from 7.1. I suggest when #3 is done we can ship a beta3. For #4, I don't know who wants to do it. If it's me then it might take a few days. #5 is well under way. When #4 and #5 are done we can ship rc1 or beta4, depending on the other issues. -- Peter Eisentraut peter_e@gmx.net
On Mon, 19 Nov 2001, Peter Eisentraut wrote: > Marc G. Fournier writes: > > > Okay, how do we want to address/fix/test this? > > Assuming that we don't want to make sweeping changes to the overall > procedure, I suggest this: > > 1. The postgres.tar.gz and man.tar.gz documentation tarballs required for > a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The new > file system location of this directory needs to be determined. Should simply be ~ftp/pub/dev/doc > 2. Some postgres.tar.gz and man.tar.gz files need to be put there. > > 3. The currently commented out portion in the mk-release script needs > to be altered to pick up these files. > > (I also suggest 'set -e' in this script so it doesn't ignore errors.) Okay, just added 'set -e', commented out, to the script ... actually, just uncommented it, for, even without the docs, it probably shouldn't be ignored, eh? :) > 4. The HTML-doc-build cron job needs to be reinstated on > postgresql.org and put its output file at the new location. > > 5. When I'm done with the new manpages I'll upload them to the > appropriate location. > > I think the answer to #1 is /var/spool/ftp or something. For #2, use the > postgres.tar.gz files that Bruce currently builds, and use the old > man.tar.gz file from 7.1. > > I suggest when #3 is done we can ship a beta3. Okay, will bundle up Beta3 in the morning then ... > For #4, I don't know who wants to do it. If it's me then it might > take a few days. #5 is well under way. When #4 and #5 are done we > can ship rc1 or beta4, depending on the other issues. Would #4 be these, from thomas old cron jobs: # Run at 3:05 local time (EST5EDT?) every day5 3 * * * $HOME/CURRENT/docbuild |& tee $HOME/CURRENT/docbuild.log # Twice a day during beta 2000-03-28 25 11 * * * $HOME/CURRENT/docbuild |& tee $HOME/CURRENT/docbuild.log
On Tue, 20 Nov 2001, Christopher Kings-Lynne wrote: > > > > -----Original Message----- > > From: pgsql-hackers-owner@postgresql.org > > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Peter Eisentraut > > Sent: Monday, 19 November 2001 10:40 PM > > To: Marc G. Fournier > > Cc: Tom Lane; Bruce Momjian; PostgreSQL-development; Thomas Lockhart > > Subject: Re: [HACKERS] beta3 > > > > > > Marc G. Fournier writes: > > > > > Okay, how do we want to address/fix/test this? > > > > Assuming that we don't want to make sweeping changes to the overall > > procedure, I suggest this: > > > > 1. The postgres.tar.gz and man.tar.gz documentation tarballs required for > > a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The new > > file system location of this directory needs to be determined. > > > > 2. Some postgres.tar.gz and man.tar.gz files need to be put there. > > Just a thought: Doesn't everyone have bzip2 these days? Many large > projects come bz2-only even these days. Is there a good reason to stick > with the extra-large tar.gz format? Cause not everyone has bzip2 ... Solaris comes with gzip, doesn't come with bzip ... not sure how many other OS, but even FreeBSD requiresyou to compile bzip from ports, it isn't part of hte operating system ...
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Peter Eisentraut > Sent: Monday, 19 November 2001 10:40 PM > To: Marc G. Fournier > Cc: Tom Lane; Bruce Momjian; PostgreSQL-development; Thomas Lockhart > Subject: Re: [HACKERS] beta3 > > > Marc G. Fournier writes: > > > Okay, how do we want to address/fix/test this? > > Assuming that we don't want to make sweeping changes to the overall > procedure, I suggest this: > > 1. The postgres.tar.gz and man.tar.gz documentation tarballs required for > a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The new > file system location of this directory needs to be determined. > > 2. Some postgres.tar.gz and man.tar.gz files need to be put there. Just a thought: Doesn't everyone have bzip2 these days? Many large projects come bz2-only even these days. Is there a good reason to stick with the extra-large tar.gz format? Chris
> Cause not everyone has bzip2 ... Solaris comes with gzip, doesn't come > with bzip ... not sure how many other OS, but even FreeBSD requiresyou to > compile bzip from ports, it isn't part of hte operating system ... FreeBSD 4.4 has it as part of the OS... For example, the entire KDE project is bz2, and people use it on Solaris. But anyway, fair enough - I guess it's an extra step that would inhibit the use of Postgres. Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Cause not everyone has bzip2 ... Why not have both, so the user can choose? Many other things on the net do just that. That way, I can choose bz2 for a quick download, or use gz if I am using an inferior OS :) While we're on the subject, how about digitally signing the releases as well? An MD5 checksum is fine, but certainly won't protect against trojans and other maliciousness that a pgp signature could prevent. Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200111191132 -----BEGIN PGP SIGNATURE----- Comment: http://www.turnstep.com/pgp.html iQA/AwUBO/nc+7ybkGcUlkrIEQLBPgCeM6CXgV0W7WjJBwGhiVj6u8hjPJ8An3Os fP8flAAcciNI6FfOPyXKsD1B =00M7 -----END PGP SIGNATURE-----
On Lun 19 Nov 2001 22:49, you wrote:
> On Tue, 20 Nov 2001, Christopher Kings-Lynne wrote:
> > > -----Original Message-----
> > > From: pgsql-hackers-owner@postgresql.org
> > > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Peter
> > > Eisentraut Sent: Monday, 19 November 2001 10:40 PM
> > > To: Marc G. Fournier
> > > Cc: Tom Lane; Bruce Momjian; PostgreSQL-development; Thomas Lockhart
> > > Subject: Re: [HACKERS] beta3
> > >
> > > Marc G. Fournier writes:
> > > > Okay, how do we want to address/fix/test this?
> > >
> > > Assuming that we don't want to make sweeping changes to the overall
> > > procedure, I suggest this:
> > >
> > > 1. The postgres.tar.gz and man.tar.gz documentation tarballs required
> > > for a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The
> > > new file system location of this directory needs to be determined.
> > >
> > > 2. Some postgres.tar.gz and man.tar.gz files need to be put there.
> >
> > Just a thought: Doesn't everyone have bzip2 these days? Many large
> > projects come bz2-only even these days. Is there a good reason to stick
> > with the extra-large tar.gz format?
>
> Cause not everyone has bzip2 ... Solaris comes with gzip, doesn't come
> with bzip ... not sure how many other OS, but even FreeBSD requiresyou to
> compile bzip from ports, it isn't part of hte operating system ...
Go to www.sunfreeware.com and get bzip2 for Solaris.
I even recompiled the new tar with support for bzip2! :-)
Saludos... :-)
P.D.: bzip2 is slow, but you can get a real small package with it, even
though PostgreSQL isn't that big, if we compare it with KDE or Mozilla.
--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica Universidad Nacional
del Litoral
-----------------------------------------------------------------
Martín Marqués <martin@bugs.unl.edu.ar> writes:
> P.D.: bzip2 is slow, but you can get a real small package with it, even
> though PostgreSQL isn't that big, if we compare it with KDE or Mozilla.
As an experiment, I zipped my current PG source tree with both. (This
isn't an exact test of the distribution size, because I didn't bother
to get rid of the CVS control files, but it's pretty close.)
Original tar file: 37089280 bytes
gzip -9: 8183182 bytes
bzip2: 6762638 bytes
or slightly less than a 20% savings for bzip over gzip. That's useful,
but not exactly compelling. A comparison of unzip runtime also seems
relevant:
$ time gunzip pgsql.tar.gz
real 0m5.48s
user 0m4.46s
sys 0m0.62s
$ time bunzip2 pgsql.tar.bz2
real 0m27.77s
user 0m26.50s
sys 0m0.92s
If I'd downloaded this thing over a decent DSL or cable modem line,
bzip2 would actually be a net loss in total download + uncompress time.
<editorial>
The reason bzip is still an also-ran is that it's not enough better
than gzip to have persuaded people to switch over. My bet is that
bzip will always be an also-ran, and that gzip will remain the de
facto standard until something comes along that's really significantly
better, like a factor of 2 better. I've watched this sort of game
play out before, and I know you don't take over the world with a 20%
improvement over the existing standard. At least not without other
compelling reasons, like speed (oops) or patent freedom (no win there
either).
</editorial>
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > If I'd downloaded this thing over a decent DSL or cable modem > line, bzip2 would actually be a net loss in total > download + uncompress time. I think the download time is a lot more important to people than the uncompression time. A savings of nearly 1.5 Megs is significant, no matter what type of line you are on. If we can shave off 1.5M for a 56K user, why not? My runtime tests were also different: bzip -9: 8.959 real bzip -1: 7.473 real gzip -9: 1.491 real That's not much of a difference, and (IMO) is more than offset by the smaller download size. Bandwidth should be a more important factor: after all, the next few steps (tar, configure, make) are going to make the unzipping seem fast in comparison. :) I'm not advocating *replacing* gzip with bzip2, but I do think we should make it an option. It should not be that much trouble. Digital signatures, on the other hand, are a lot more trouble but are much more important than the gzip/bzip2 issue.... Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200111201606 -----BEGIN PGP SIGNATURE----- Comment: http://www.turnstep.com/pgp.html iQA/AwUBO/rG+LybkGcUlkrIEQJO8wCdGlZgyQUTYwLUMTrSwcmmnUx0nlYAn37H I6W1G8h+7jQIIiBTuHQeKQB7 =PtZi -----END PGP SIGNATURE-----
"Greg Sabino Mullane" <greg@turnstep.com> writes: > > If I'd downloaded this thing over a decent DSL or cable modem > > line, bzip2 would actually be a net loss in total > > download + uncompress time. > > I think the download time is a lot more important to people than > the uncompression time. A savings of nearly 1.5 Megs is > significant, no matter what type of line you are on. And for CD space (I'd love bzipped binaries), ftp space, etc (not only for mirrors, but for distributions shipping postgresql and mirrors thereeof. -- Trond Eivind Glomsrød Red Hat, Inc.
On Mar 20 Nov 2001 12:16, Tom Lane wrote:
>
> As an experiment, I zipped my current PG source tree with both. (This
> isn't an exact test of the distribution size, because I didn't bother
> to get rid of the CVS control files, but it's pretty close.)
>
> Original tar file: 37089280 bytes
> gzip -9: 8183182 bytes
> bzip2: 6762638 bytes
>
> or slightly less than a 20% savings for bzip over gzip. That's useful,
> but not exactly compelling. A comparison of unzip runtime also seems
> relevant:
>
> $ time gunzip pgsql.tar.gz
>
> real 0m5.48s
> user 0m4.46s
> sys 0m0.62s
>
> $ time bunzip2 pgsql.tar.bz2
>
> real 0m27.77s
> user 0m26.50s
> sys 0m0.92s
>
> If I'd downloaded this thing over a decent DSL or cable modem line,
> bzip2 would actually be a net loss in total download + uncompress time.
That would be if I have a decent DSL or cable modem. We have a dedicated line
of 756 kb, but we also have 3000 users. Maybe postgreSQL isn't that big, but
Mozilla or KDE are, and waiting for la large download isn't what I recommend
for an internet experience. :-)
> <editorial>
> The reason bzip is still an also-ran is that it's not enough better
> than gzip to have persuaded people to switch over. My bet is that
> bzip will always be an also-ran, and that gzip will remain the de
> facto standard until something comes along that's really significantly
> better, like a factor of 2 better. I've watched this sort of game
> play out before, and I know you don't take over the world with a 20%
> improvement over the existing standard. At least not without other
> compelling reasons, like speed (oops) or patent freedom (no win there
> either).
> </editorial>
I think it comes to what CPU I'm using. If I'm on an old Pentium, I may not
be happy seeing unbzip2 grabbing all my CPU, but if I'm on a last generation
PIV of, lets say 1000Mhz, I may not feel it.
Saludos... :-)
--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica Universidad Nacional
del Litoral
-----------------------------------------------------------------
On 20 Nov 2001, Trond Eivind [iso-8859-1] Glomsr�d wrote: > "Greg Sabino Mullane" <greg@turnstep.com> writes: > > > > If I'd downloaded this thing over a decent DSL or cable modem > > > line, bzip2 would actually be a net loss in total > > > download + uncompress time. > > > > I think the download time is a lot more important to people than > > the uncompression time. A savings of nearly 1.5 Megs is > > significant, no matter what type of line you are on. > > And for CD space (I'd love bzipped binaries), ftp space, etc (not only > for mirrors, but for distributions shipping postgresql and mirrors > thereeof. Huh? You are advocating adding to the ftp space required? *raised eyebrow*
Okay, tried today what you suggested, about set -e and all that ... take a look at ~pgsql/bin/mk-beta, to see if maybe I missed something ... but, trying to do the packaging, I'm getting an error about 'build.xml'? /usr/bin/tar cf postgresql-opt-7.2b3.tar postgresql-7.2b3/src/backend/utils/mb postgresql-7.2b3/contrib/retep postgresql-7.2b3/build.xmlpostgresql-7.2b3/src/tools postgresql-7.2b3/src/corba postgresql-7.2b3/src/data postgresql-7.2b3/src/tutorialpostgresql-7.2b3/src/bin/pgaccess postgresql-7.2b3/src/bin/pgtclsh postgresql-7.2b3/src/bin/pg_encodingpostgresql-7.2b3/src/interfaces/odbc postgresql-7.2b3/src/interfaces/libpq++ postgresql-7.2b3/src/interfaces/libpgtclpostgresql-7.2b3/src/interfaces/perl5 postgresql-7.2b3/src/interfaces/python postgresql-7.2b3/src/interfaces/jdbcpostgresql-7.2b3/src/pl/plperl postgresql-7.2b3/src/pl/tcl /usr/bin/tar: can't add file postgresql-7.2b3/build.xml : No such file or directory gmake: *** [postgresql-opt-7.2b3.tar] Error 1 gmake: *** Deleting file `postgresql-opt-7.2b3.tar' % Looking in the wrong directory? %find . -name build.xml -print ./contrib/retep/build.xml ./src/interfaces/jdbc/build.xml % On Mon, 19 Nov 2001, Peter Eisentraut wrote: > Marc G. Fournier writes: > > > Okay, how do we want to address/fix/test this? > > Assuming that we don't want to make sweeping changes to the overall > procedure, I suggest this: > > 1. The postgres.tar.gz and man.tar.gz documentation tarballs required for > a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The new > file system location of this directory needs to be determined. > > 2. Some postgres.tar.gz and man.tar.gz files need to be put there. > > 3. The currently commented out portion in the mk-release script needs > to be altered to pick up these files. > > (I also suggest 'set -e' in this script so it doesn't ignore errors.) > > 4. The HTML-doc-build cron job needs to be reinstated on postgresql.org > and put its output file at the new location. > > 5. When I'm done with the new manpages I'll upload them to the > appropriate location. > > I think the answer to #1 is /var/spool/ftp or something. For #2, use the > postgres.tar.gz files that Bruce currently builds, and use the old > man.tar.gz file from 7.1. > > I suggest when #3 is done we can ship a beta3. > > For #4, I don't know who wants to do it. If it's me then it might take a > few days. #5 is well under way. When #4 and #5 are done we can ship rc1 > or beta4, depending on the other issues. > > -- > Peter Eisentraut peter_e@gmx.net > >
> > Okay, tried today what you suggested, about set -e and all that ... take a > look at ~pgsql/bin/mk-beta, to see if maybe I missed something ... but, > trying to do the packaging, I'm getting an error about 'build.xml'? > > /usr/bin/tar cf postgresql-opt-7.2b3.tar postgresql-7.2b3/src/backend/utils/mb postgresql-7.2b3/contrib/retep postgresql-7.2b3/build.xmlpostgresql-7.2b3/src/tools postgresql-7.2b3/src/corba postgresql-7.2b3/src/data postgresql-7.2b3/src/tutorialpostgresql-7.2b3/src/bin/pgaccess postgresql-7.2b3/src/bin/pgtclsh postgresql-7.2b3/src/bin/pg_encodingpostgresql-7.2b3/src/interfaces/odbc postgresql-7.2b3/src/interfaces/libpq++ postgresql-7.2b3/src/interfaces/libpgtclpostgresql-7.2b3/src/interfaces/perl5 postgresql-7.2b3/src/interfaces/python postgresql-7.2b3/src/interfaces/jdbcpostgresql-7.2b3/src/pl/plperl postgresql-7.2b3/src/pl/tcl > /usr/bin/tar: can't add file postgresql-7.2b3/build.xml : No such file or directory > gmake: *** [postgresql-opt-7.2b3.tar] Error 1 > gmake: *** Deleting file `postgresql-opt-7.2b3.tar' > % > > Looking in the wrong directory? > > %find . -name build.xml -print > ./contrib/retep/build.xml > ./src/interfaces/jdbc/build.xml > % OK, patch applied. There was a space where there should have been a slash. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 Index: GNUmakefile.in =================================================================== RCS file: /cvsroot/pgsql/GNUmakefile.in,v retrieving revision 1.19 diff -c -r1.19 GNUmakefile.in *** GNUmakefile.in 2001/09/17 23:00:27 1.19 --- GNUmakefile.in 2001/11/21 05:40:51 *************** *** 65,71 **** $(distdir).tar: distdir $(TAR) chf $@ $(distdir) ! opt_files := src/backend/utils/mb contrib/retep build.xml \ src/tools src/corba src/data src/tutorial \ $(addprefix src/bin/, pgaccess pgtclsh pg_encoding) \ $(addprefix src/interfaces/, odbc libpq++ libpgtcl perl5 python jdbc) \ --- 65,71 ---- $(distdir).tar: distdir $(TAR) chf $@ $(distdir) ! opt_files := src/backend/utils/mb contrib/retep/build.xml \ src/tools src/corba src/data src/tutorial \ $(addprefix src/bin/, pgaccess pgtclsh pg_encoding) \ $(addprefix src/interfaces/, odbc libpq++ libpgtcl perl5 python jdbc) \
> >
> > Okay, tried today what you suggested, about set -e and all that ... take a
> > look at ~pgsql/bin/mk-beta, to see if maybe I missed something ... but,
> > trying to do the packaging, I'm getting an error about 'build.xml'?
> >
> > /usr/bin/tar cf postgresql-opt-7.2b3.tar postgresql-7.2b3/src/backend/utils/mb postgresql-7.2b3/contrib/retep
postgresql-7.2b3/build.xmlpostgresql-7.2b3/src/tools postgresql-7.2b3/src/corba postgresql-7.2b3/src/data
postgresql-7.2b3/src/tutorialpostgresql-7.2b3/src/bin/pgaccess postgresql-7.2b3/src/bin/pgtclsh
postgresql-7.2b3/src/bin/pg_encodingpostgresql-7.2b3/src/interfaces/odbc postgresql-7.2b3/src/interfaces/libpq++
postgresql-7.2b3/src/interfaces/libpgtclpostgresql-7.2b3/src/interfaces/perl5 postgresql-7.2b3/src/interfaces/python
postgresql-7.2b3/src/interfaces/jdbcpostgresql-7.2b3/src/pl/plperl postgresql-7.2b3/src/pl/tcl
> > /usr/bin/tar: can't add file postgresql-7.2b3/build.xml : No such file or directory
> > gmake: *** [postgresql-opt-7.2b3.tar] Error 1
> > gmake: *** Deleting file `postgresql-opt-7.2b3.tar'
> > %
> >
> > Looking in the wrong directory?
> >
> > %find . -name build.xml -print
> > ./contrib/retep/build.xml
> > ./src/interfaces/jdbc/build.xml
> > %
>
> OK, patch applied. There was a space where there should have been a
> slash.
OK, I found another problem:
gzip -f --best postgresql-base-7.2b3.tar /usr/bin/tar cf postgresql-docs-7.2b3.tar
postgresql-7.2b3/doc/postgres.tar.gzpostgresql-7.2b3/doc/src
^^^^^^^^^^^^^^^^^^^ postgresql-7.2b3/doc/TODO.detail postgresql-7.2b3/doc/internals.ps /usr/bin/tar:
can'tadd file postgresql-7.2b3/doc/postgres.tar.gz : No
^^^^^^^^^^^^^^^^^^^
such file or directory
The problem is this line in pgsql/GNUmakefile.in:
docs_files := doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps
Why is doc/postgres.tar.gz used. It normally is in doc/src, and why
only that doc tarball.
And again, there is that intenrals.ps file that doesn't really belong
there, I think.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
> OK, I found another problem: > > gzip -f --best postgresql-base-7.2b3.tar > /usr/bin/tar cf postgresql-docs-7.2b3.tar > postgresql-7.2b3/doc/postgres.tar.gz postgresql-7.2b3/doc/src > > ^^^^^^^^^^^^^^^^^^^ > postgresql-7.2b3/doc/TODO.detail postgresql-7.2b3/doc/internals.ps > /usr/bin/tar: can't add file postgresql-7.2b3/doc/postgres.tar.gz : No > > ^^^^^^^^^^^^^^^^^^^ > > such file or directory > > The problem is this line in pgsql/GNUmakefile.in: > > docs_files := doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps > > Why is doc/postgres.tar.gz used. It normally is in doc/src, and why > only that doc tarball. OK, I updated this to point to doc/src. Marc, I have a doc/postgres.tar.gz here that you can use to make the tarball. It is now at ftp://candle.pha.pa.us/pub/postgresql. > And again, there is that intenrals.ps file that doesn't really belong > there, I think. Tom agrees so I will move it to the web site. Shame we don't have the source, which was originally TeX. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
"Marc G. Fournier" <scrappy@hub.org> writes: > On 20 Nov 2001, Trond Eivind [iso-8859-1] Glomsrød wrote: > > > "Greg Sabino Mullane" <greg@turnstep.com> writes: > > > > > > If I'd downloaded this thing over a decent DSL or cable modem > > > > line, bzip2 would actually be a net loss in total > > > > download + uncompress time. > > > > > > I think the download time is a lot more important to people than > > > the uncompression time. A savings of nearly 1.5 Megs is > > > significant, no matter what type of line you are on. > > > > And for CD space (I'd love bzipped binaries), ftp space, etc (not only > > for mirrors, but for distributions shipping postgresql and mirrors > > thereeof. > > Huh? You are advocating adding to the ftp space required? *raised > eyebrow* Replace gz with bz2, and you'll save :) - also, bzipped files will allow others who only ship one instance (like us - we only need one tarball for the SRPM), and these will save space. -- Trond Eivind Glomsrød Red Hat, Inc.
On Wed, Nov 21, 2001 at 10:30:54AM -0500, Bruce Momjian wrote: > > > And again, there is that intenrals.ps file that doesn't really belong > > there, I think. > > Tom agrees so I will move it to the web site. Shame we don't have the > source, which was originally TeX. > Digging in the archives, I find that the author of this doc offered the source: > Date: Wed, 13 Jan 1999 06:04:15 +0000 > From: Clark Evans <clark.evans@manhattanproject.com> > Subject: Re: [HACKERS] Re: EXCEPT/INTERSECT for v6.4 > > Thomas, > > The documentation Stefan wrote for his Master's thesis > is great stuff. Perhaps some of could be incorporated? > > Stefan Simkovics wrote: > > > I also included the text of my Master's Thesis. (a postscript > > > version). I hope that you find something of it useful and would be > > > happy if parts of it find their way into the PostgreSQL documentation > > > project (If so, tell me, then I send the sources of the document!) If we can track down his current email address, perhaps he still has it? I'm copying this to his @ag.or.at address, since the mailer there still recognizes it. Let's see if Stefan's around. ;-) Ross (musing if he could find the source docs to his Ph.D. thesis ... and if so, if they'd be readable) -- Ross Reedstrom, Ph.D. reedstrm@rice.edu Executive Director phone: 713-348-6166 Gulf Coast Consortium for Bioinformatics fax: 713-348-6182 Rice University MS-39 Houston, TX 77005
> > Stefan Simkovics wrote: > > > > I also included the text of my Master's Thesis. (a postscript > > > > version). I hope that you find something of it useful and would be > > > > happy if parts of it find their way into the PostgreSQL documentation > > > > project (If so, tell me, then I send the sources of the document!) > > > If we can track down his current email address, perhaps he still has it? > I'm copying this to his @ag.or.at address, since the mailer there still > recognizes it. Let's see if Stefan's around. ;-) > > Ross (musing if he could find the source docs to his Ph.D. thesis ... and > if so, if they'd be readable) The thesis was in LaTeX. I think Thomas may have copy, but I am not sure. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Hi! > > Could you please let me know the reason you're looking for it? > (I'm just curious :-)) That's an excellent question. We moved the Postscript file out of the main CVS into the web page CVS because it wasn't really source code. Of course, if we had the LaTeX, it would be documentation source code. However, we have no intention of modifying it, so am not sure what value the LaTeX would be to us. Guys, why did we want the source, exactly? I think just putting the Postscript on the web site is enough. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Hi! > > As you can see, the address is still valid :-) > Could you please let me know exactly , who is looking for what? > > Then I can send you a LaTeX/PDF/PS Version of my thesis. I think we wanted the Latex source. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Guys, why did we want the source, exactly?
I just said that source for the document would be appropriate to keep
in CVS whereas the PS output was not. I'm not sure that we really want
the document, though, since we're not using it as actual documentation
(ie, it's not being updated to reflect changes in the system).
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Guys, why did we want the source, exactly? > > I just said that source for the document would be appropriate to keep > in CVS whereas the PS output was not. I'm not sure that we really want > the document, though, since we're not using it as actual documentation > (ie, it's not being updated to reflect changes in the system). Yea, that was my reading too. I will convert the PS to PDF and add it to the web site. I think that's the way to go. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, Nov 21, 2001 at 01:36:15PM -0500, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Guys, why did we want the source, exactly? > > I just said that source for the document would be appropriate to keep > in CVS whereas the PS output was not. I'm not sure that we really want > the document, though, since we're not using it as actual documentation > (ie, it's not being updated to reflect changes in the system). Perhaps because it _can't_ be updated, without the source? A number of people have commented on how it's a good write up of internals of query processing. Unfortunately, it's circa v. 6.3, and starting to show it's age. If the source were available, pulling out sections and updating them is at least a possibility. Otherwise, it's just a historical document: interesting, but fading. Stefan, could you see your way to putting it under an Open Content license of some sort, so it could be used in this way? Ross
OK, here is where I think we are on beta3 packaging. Last night, I fixed the error Marc was seeing in the build. I have also put my HTML version of the docs at: ftp://candle.pha.pa.us/pub/postgresql/postgres-docs.tar.gz. If that is copied to doc/src and mk-beta is run, it should work fine. Also, can the beta directory be removed from the snapshot tar file? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
"Marc G. Fournier" <scrappy@hub.org> writes:
> Also, its reporting that internals.ps is missing ...
Looks like Bruce forgot to remove the reference in the toplevel
GNUmakefile.in.
regards, tom lane
> On Wed, 21 Nov 2001, Bruce Momjian wrote: > > > OK, here is where I think we are on beta3 packaging. > > > > Last night, I fixed the error Marc was seeing in the build. I have also > > put my HTML version of the docs at: > > > > ftp://candle.pha.pa.us/pub/postgresql/postgres-docs.tar.gz. > > > > If that is copied to doc/src and mk-beta is run, it should work fine. > > Okay, we have a ~ftp/pub/doc/current, but no src ... what is the > difference between current and src? I meant copy into pgsql/doc/src or wherever directory tree you are using to make the beta. Does that make sense? > Also, its reporting that internals.ps is missing ... OK, sorry, fixed. Please rerun configure to get the new code. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, 21 Nov 2001, Bruce Momjian wrote: > OK, here is where I think we are on beta3 packaging. > > Last night, I fixed the error Marc was seeing in the build. I have also > put my HTML version of the docs at: > > ftp://candle.pha.pa.us/pub/postgresql/postgres-docs.tar.gz. > > If that is copied to doc/src and mk-beta is run, it should work fine. Okay, we have a ~ftp/pub/doc/current, but no src ... what is the difference between current and src? Also, its reporting that internals.ps is missing ...
> "Marc G. Fournier" <scrappy@hub.org> writes: > > Also, its reporting that internals.ps is missing ... > > Looks like Bruce forgot to remove the reference in the toplevel > GNUmakefile.in. Yea, I removed it only from GNUmakefile the first time. Got it now. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > Okay, how do we want to address/fix/test this? > > On Sun, 18 Nov 2001, Peter Eisentraut wrote: > > > Tom Lane writes: > > > > > The packaging problems need to be solved before we can build a release > > > candidate --- but I don't see why they should hold up beta3. beta2 has > > > the same problems, so beta3 wouldn't be a regression. > > > > Considering the history of how-do-we-get-the-docs-in-the-tarball problem, > > I'd like to see at least one beta where this works before shipping a > > release candidate. Otherwise I'll have no confidence at all that we're > > not going to ship the final release with last year's docs and no man > > pages. The best we can do at this point is to package my HTML files for beta3 and see if we can test this for RC1. At least the tar.gz file itself will be added by the script, just not built on the same machine. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian writes: > > The problem is this line in pgsql/GNUmakefile.in: > > > > docs_files := doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps > > > > Why is doc/postgres.tar.gz used. It normally is in doc/src, and why > > only that doc tarball. > > OK, I updated this to point to doc/src. Nooooooooooooooooooooooooooooo! -- Peter Eisentraut peter_e@gmx.net
Bruce Momjian writes: > OK, I found another problem: > > gzip -f --best postgresql-base-7.2b3.tar > /usr/bin/tar cf postgresql-docs-7.2b3.tar > postgresql-7.2b3/doc/postgres.tar.gz postgresql-7.2b3/doc/src > > ^^^^^^^^^^^^^^^^^^^ > postgresql-7.2b3/doc/TODO.detail postgresql-7.2b3/doc/internals.ps > /usr/bin/tar: can't add file postgresql-7.2b3/doc/postgres.tar.gz : No > > ^^^^^^^^^^^^^^^^^^^ > > such file or directory Well, I sent you the list with items 1 through 5 and if you process them in a different order then all bets are off. > > The problem is this line in pgsql/GNUmakefile.in: > > docs_files := doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps > > Why is doc/postgres.tar.gz used. It normally is in doc/src, and why > only that doc tarball. No, this is correct. > > And again, there is that intenrals.ps file that doesn't really belong > there, I think. > > -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
>> OK, I updated this to point to doc/src.
> Nooooooooooooooooooooooooooooo!
If it's wrong, please fix it.
*Somebody's* got to take responsibility for making the doc build process
work again on postgresql.org. I don't have the foggiest idea what's wrong
or where to look. You and Marc (and Thomas, except he's gone for awhile)
are the only candidate fixers in sight.
regards, tom lane
> Bruce Momjian writes: > > > > The problem is this line in pgsql/GNUmakefile.in: > > > > > > docs_files := doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps > > > > > > Why is doc/postgres.tar.gz used. It normally is in doc/src, and why > > > only that doc tarball. > > > > OK, I updated this to point to doc/src. > > Nooooooooooooooooooooooooooooo! OK, I put it back. I don't know how this is supposed to work. Marc, if you put the postgresql.tar.gz in /doc instead of doc/src as I said before, it should work. Again, I am just trying to jump start this thing so we can get on to beta3. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, 21 Nov 2001, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > >> OK, I updated this to point to doc/src. > > > Nooooooooooooooooooooooooooooo! > > If it's wrong, please fix it. > > *Somebody's* got to take responsibility for making the doc build process > work again on postgresql.org. I don't have the foggiest idea what's wrong > or where to look. You and Marc (and Thomas, except he's gone for awhile) > are the only candidate fixers in sight. and, right now, I don't know what is "broken" that needs to be fixed ... Peter, my fingers are at y our disposal, what haven't I installed yet? :(
On Wed, 21 Nov 2001, Bruce Momjian wrote: > > > > Okay, how do we want to address/fix/test this? > > > > On Sun, 18 Nov 2001, Peter Eisentraut wrote: > > > > > Tom Lane writes: > > > > > > > The packaging problems need to be solved before we can build a release > > > > candidate --- but I don't see why they should hold up beta3. beta2 has > > > > the same problems, so beta3 wouldn't be a regression. > > > > > > Considering the history of how-do-we-get-the-docs-in-the-tarball problem, > > > I'd like to see at least one beta where this works before shipping a > > > release candidate. Otherwise I'll have no confidence at all that we're > > > not going to ship the final release with last year's docs and no man > > > pages. > > The best we can do at this point is to package my HTML files for beta3 > and see if we can test this for RC1. At least the tar.gz file itself > will be added by the script, just not built on the same machine. Is there a reason why it can't be built on the same machine, by the script that builds the package itself? Is there something remaining missing on the server that prevents this from happening?
> > The best we can do at this point is to package my HTML files for beta3 > > and see if we can test this for RC1. At least the tar.gz file itself > > will be added by the script, just not built on the same machine. > > Is there a reason why it can't be built on the same machine, by the script > that builds the package itself? Is there something remaining missing on > the server that prevents this from happening? Uh, I don't know. It needs the SGML tools stuff. Is that working? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Peter and I are discussing this off list and will let y'all know once we get it working again ... once we do, beta3 will come out ... On Wed, 21 Nov 2001, Bruce Momjian wrote: > > > The best we can do at this point is to package my HTML files for beta3 > > > and see if we can test this for RC1. At least the tar.gz file itself > > > will be added by the script, just not built on the same machine. > > > > Is there a reason why it can't be built on the same machine, by the script > > that builds the package itself? Is there something remaining missing on > > the server that prevents this from happening? > > Uh, I don't know. It needs the SGML tools stuff. Is that working? > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 >
Is he awake? It is Thu Nov 22 03:50:21 GMT 2001. --------------------------------------------------------------------------- > > Peter and I are discussing this off list and will let y'all know once we > get it working again ... once we do, beta3 will come out ... > > On Wed, 21 Nov 2001, Bruce Momjian wrote: > > > > > The best we can do at this point is to package my HTML files for beta3 > > > > and see if we can test this for RC1. At least the tar.gz file itself > > > > will be added by the script, just not built on the same machine. > > > > > > Is there a reason why it can't be built on the same machine, by the script > > > that builds the package itself? Is there something remaining missing on > > > the server that prevents this from happening? > > > > Uh, I don't know. It needs the SGML tools stuff. Is that working? > > > > -- > > Bruce Momjian | http://candle.pha.pa.us > > pgman@candle.pha.pa.us | (610) 853-3000 > > + If your life is a hard drive, | 830 Blythe Avenue > > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, Nov 20, 2001 at 10:16:57AM -0500, Tom Lane wrote: > Original tar file: 37089280 bytes > gzip -9: 8183182 bytes > bzip2: 6762638 bytes maybe 1.420.544 it's not a big difference for you, but here in italy there's still a lot of people using 33.6/55Kb telephone line modem. so, this difference means, downloading at 3kb/s, seven minutes... also: a) cpu utilization has no cost... band cost a lot; b) if i have to download 5 files, and i can avoid 1 MB of download for each one... thanks for your time, andrea gelmini
Hi! As you can see, the address is still valid :-) Could you please let me know exactly , who is looking for what? Then I can send you a LaTeX/PDF/PS Version of my thesis. best regards Stefan Simkovics > > > Stefan Simkovics wrote: > > > > > I also included the text of my Master's Thesis. (a postscript > > > > > version). I hope that you find something of it useful and would be > > > > > happy if parts of it find their way into the PostgreSQL documentation > > > > > project (If so, tell me, then I send the sources of the document!) > > > > > > If we can track down his current email address, perhaps he still has it? > > I'm copying this to his @ag.or.at address, since the mailer there still > > recognizes it. Let's see if Stefan's around. ;-) > > > > Ross (musing if he could find the source docs to his Ph.D. thesis ... and > > if so, if they'd be readable) > > The thesis was in LaTeX. I think Thomas may have copy, but I am not sure. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > -- ===================================================================== DI Stefan Simkovics KPNQwest Austria GmbH A-1150 Wien, Diefenbachgasse 35 Tel.: +43 (1) 899 33 - 162, Fax: +43 (1) 899 33 - 10 162 Mob.: +43 (0) 664 818 91 41, e-Mail: stefan.simkovics@kpnqwest.com http://www.kpnqwest.at, http://www.kpnqwest.com
Hi! Could you please let me know the reason you're looking for it? (I'm just curious :-)) best regards Stefan > > Hi! > > > > As you can see, the address is still valid :-) > > Could you please let me know exactly , who is looking for what? > > > > Then I can send you a LaTeX/PDF/PS Version of my thesis. > > I think we wanted the Latex source. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > -- ===================================================================== DI Stefan Simkovics KPNQwest Austria GmbH A-1150 Wien, Diefenbachgasse 35 Tel.: +43 (1) 899 33 - 162, Fax: +43 (1) 899 33 - 10 162 Mob.: +43 (0) 664 818 91 41, e-Mail: stefan.simkovics@kpnqwest.com http://www.kpnqwest.at, http://www.kpnqwest.com
Tom Lane wrote: > <editorial> > The reason bzip is still an also-ran is that it's not enough better > than gzip to have persuaded people to switch over. My bet is that > bzip will always be an also-ran, and that gzip will remain the de > facto standard until something comes along that's really significantly > better, like a factor of 2 better. I've watched this sort of game > play out before, and I know you don't take over the world with a 20% > improvement over the existing standard. At least not without other > compelling reasons, like speed (oops) or patent freedom (no win there > either). > </editorial> While agree in principle with your view on bzip2, I think there is a strong reason why you should use it, 20% That 20% is quite valuable. Just by switching to bzip2, the hosting companies can deliver 20% more downloads with the same equipment and bandwidth cost. The people with slow connections can get it 20% faster. Will bzip2 become the standard? Probably not in general use, but for downloadable tarballs it is rapidly becoming the standard. Those who pay for bandwidth (server or client) welcome any improvement possible. I would switch the argument around, time how long it takes to do: ncftpget postgresql-xxxx.tar.gz tar xpzvf postgresql-xxxx.tar.gz cd postgresql-xxxx ./configure --option make make install vs ncftpget postgresql-xxxx.tar.bz2 bunzip2 -c postgresql-xxxx.tar.bz2 | tar xpzv cd postgresql-xxxx ./configure --option make make install The total time involved is almost identical, plus or minus a few seconds, but on slow connections: users get postgresql faster and have to tie up a phone line for a shorter amount of time. The hosting company can serve 20% less bandwidth. The archive takes up 20% less space on the mirrors. The archine takes up 20% less space on server backups. I don't think there is a compelling reason to keep a gzipped version.
On Vie 23 Nov 2001 13:10, mlw wrote:
>
> While agree in principle with your view on bzip2, I think there is a strong
> reason why you should use it, 20%
>
> That 20% is quite valuable. Just by switching to bzip2, the hosting
> companies can deliver 20% more downloads with the same equipment and
> bandwidth cost. The people with slow connections can get it 20% faster.
>
> Will bzip2 become the standard? Probably not in general use, but for
> downloadable tarballs it is rapidly becoming the standard. Those who pay
> for bandwidth (server or client) welcome any improvement possible.
>
> I would switch the argument around, time how long it takes to do:
>
> ncftpget postgresql-xxxx.tar.gz
> tar xpzvf postgresql-xxxx.tar.gz
> cd postgresql-xxxx
> ./configure --option
> make
> make install
>
> vs
>
> ncftpget postgresql-xxxx.tar.bz2
> bunzip2 -c postgresql-xxxx.tar.bz2 | tar xpzv
New versions of tar would do this:
tar xpjvf postgresql-xxxx.tar.gz
It comes with bzip2 support.
Saludos... :-)
--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica Universidad Nacional
del Litoral
-----------------------------------------------------------------
...
> Perhaps because it _can't_ be updated, without the source? A number of
> people have commented on how it's a good write up of internals of query
> processing. Unfortunately, it's circa v. 6.3, and starting to show it's
> age. If the source were available, pulling out sections and updating them
> is at least a possibility. Otherwise, it's just a historical document:
> interesting, but fading.
> Stefan, could you see your way to putting it under an Open Content
> license of some sort, so it could be used in this way?
Stefan already authorized us to use it anyway that we see fit, but we
*do* need to preserve the attribution for himself and his academic
advisor and institution.
Some/much of the source is commented out in cvs source code (latex
markup and all) in the repository afaicr (don't have my laptop fired up
at the moment) because I was worried about losing it otherwise. Since
then, I've of course lost the original sources afaict.
- Thomas