Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
(Sorry of this double posts - I'm having alias troubles on the list.) Peter Eisentraut wrote: Lamar Owen writes: Ok, I have a first set of 7.1beta3 RPMs uploading now. These RPMs pass regression on my home RedHat 6.2 machine, which has all locale environment variables disabled (/etc/sysconfig/i18n deleted and a reboot). Some thoughts: snip | -#!/usr/local/bin/perl -w | +#!/usr/bin/perl -w (and more of these for Python) I think this should be fixed to read #! /usr/bin/env perl Any comments? What assurance do you have that 'env' is in /usr/bin? Linux FHS (http://www.pathname.com/fhs/2.1/fhs-4.2.html) says that when perl is in some location other than /usr/bin, then symlinks should be provided to /usr/bin/perl. You don't have this assurance with /usr/bin/env. Maybe there are some unices that do not have perl in /usr/bin - but maybe there are unices that put 'env' into /bin instead of /usr/bin. If you follow the current FHS, /usr/bin/perl may be better -- but I'm not sure if that is entirely true of the real world of linux boxes out there. | # copy over the includes needed for SPI development. | pushd src/include | /lib/cpp -M -I. -I../backend executor/spi.h | \ | xargs -n 1| \ | grep \\W| \ | grep -v ^/| \ | grep -v spi.o | \ | grep -v spi.h | \ | sort | \ | cpio -pdu $RPM_BUILD_ROOT/usr/include/pgsql I think the standard installed set of headers is sufficient. I haven't installed the RPM yet. But I dissent unless things have changed from 7.0 in that respect. I copmile against executor/spi.h, based on the examples in the docs. Should I be using something else? (I'll have to go look at the 7.1 source, but I just wanted to register at least some comfusion, if not dissent) -- Karl DeBisschop [EMAIL PROTECTED] Learning Network/Reference http://www.infoplease.com Netsaint Plugin Developer[EMAIL PROTECTED]
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Peter Eisentraut wrote: Lamar Owen writes: Ok, I have a first set of 7.1beta3 RPMs uploading now. These RPMs pass regression on my home RedHat 6.2 machine, which has all locale environment variables disabled (/etc/sysconfig/i18n deleted and a reboot). Some thoughts: snip | -#!/usr/local/bin/perl -w | +#!/usr/bin/perl -w (and more of these for Python) I think this should be fixed to read #! /usr/bin/env perl Any comments? What assurance do you have that 'env' is in /usr/bin? Linux FHS (http://www.pathname.com/fhs/2.1/fhs-4.2.html) says that when perl is in some location other than /usr/bin, then symlinks should be provided to /usr/bin/perl. You don't have this assurance with /usr/bin/env. Maybe there are some unices that do not have perl in /usr/bin - but maybe there are unices that put 'env' into /bin instead of /usr/bin. If you follow the current FHS, /usr/bin/perl may be better -- but I'm not sure if that is entirely true of the real world of linux boxes out there. | # copy over the includes needed for SPI development. | pushd src/include | /lib/cpp -M -I. -I../backend executor/spi.h | \ | xargs -n 1| \ | grep \\W| \ | grep -v ^/| \ | grep -v spi.o | \ | grep -v spi.h | \ | sort | \ | cpio -pdu $RPM_BUILD_ROOT/usr/include/pgsql I think the standard installed set of headers is sufficient. I haven't installed the RPM yet. But I dissent unless things have changed from 7.0 in that respect. I copmile against executor/spi.h, based on the examples in the docs. Should I be using something else? (I'll have to go look at the 7.1 source, but I just wanted to register at least some comfusion, if not dissent) -- Karl DeBisschop [EMAIL PROTECTED] Learning Network Reference http://www.infoplease.com Netsaint Plugin Developer [EMAIL PROTECTED]
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Lamar Owen writes:
Likewise, Peter, I'm sure that from your point of view you have good
reasons -- I'd like to see them as well, for the same reasons as I'd
like to see Trond's.
Two points of view here:
1. The config.* files were specifically updated because the old ones did
not recognize certain Linux(!) setups correctly. This probably affects
all config.*'s before August 2000. This will simply cause the build to
fail.
2. If you use the %{configure} macro then this will be pointless because
that macro selects the host system type itself:
| %configure \
| CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
| CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
| FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \
| %{?__libtoolize:[ -f configure.in ] %{__libtoolize} --copy --force} ; \
| ./configure %{_target_platform} \\\
...
(This is subtly wrong as well, but that's something for the RPM folks to
deal with.)
So in short, don't do it.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Lamar Owen wrote: Ok, I have a first set of 7.1beta3 RPMs uploading now. ... pgaccess currently will not run unless you reconfigure to use -i in the startup. This is also being fixed in the RPMset -- there is a change necess ary in postgresql.config, I just have to do the change. In my experience, pgaccess will use the Unix socket if the hostname is left blank. Is this not the case with your RPMs? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "For I know that my redeemer liveth, and that he shall stand at the latter day upon the earth" Job 19:25
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Lamar Owen writes:
Ok, I have a first set of 7.1beta3 RPMs uploading now. These RPMs pass
regression on my home RedHat 6.2 machine, which has all locale environment
variables disabled (/etc/sysconfig/i18n deleted and a reboot).
Some thoughts:
Re: rpm-pgsql-7.1beta3.patch
| diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib
|postgresql-7.1beta3/src/Makefile.shlib
| --- postgresql-7.1beta3.orig/src/Makefile.shlib Wed Dec 6 14:37:08 2000
| +++ postgresql-7.1beta3/src/Makefile.shlib Mon Jan 15 01:50:04 2001
|@@ -160,7 +160,7 @@
|
| ifeq ($(PORTNAME), linux)
|shlib:=
|lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
| - LINK.shared = $(COMPILER) -shared -Wl,-soname,$(soname)
| + LINK.shared = $(COMPILER) -shared -Wl
| endif
This cannot possibly be right.
| diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib~
|postgresql-7.1beta3/src/Makefile.shlib~
???
| -#!/usr/local/bin/perl -w
| +#!/usr/bin/perl -w
(and more of these for Python)
I think this should be fixed to read
#! /usr/bin/env perl
Any comments?
Re: spec file
| # I hope this works
|
| %ifarch ia64
| ln -s linux_i386 src/template/linux
| %endif
It definitely won't...
| # If libtool installed, copy some files
| if [ -d /usr/share/libtool ]
| then
| cp /usr/share/libtool/config.* .
| fi
This is useless (because the config.* files are not in src/ anymore) and
(if it were fixed) not recommendable because config.{guess,sub} is not
compatible to itself, *especially* in terms of Linux recognition. You
really should use the ones PostgreSQL comes with.
| %ifarch ppc
| NEW_CFLAGS=`echo $CFLAGS|xargs -n 1|grep -v "\-O"|xargs -n 100`
| NEW_CFLAGS="$NEW_CFLAGS -O0"
This is no longer necessary.
| ./configure --enable-hba --enable-locale --with-CXX --prefix=/usr\
There is no option called '--enable-hba'. And I think you're supposed to
use %{configure}.
| %if %tkpkg
| --with-tk --with-x \
| %endif
There is no '--with-x'. '--with-tk' is the default if '--with-tcl' was
given; you should use '--without-tk' if you don't want it.
| %if %jdbc
| --with-java \
| %endif
There is no such option.
| %ifarch alpha
| --with-template=linux_alpha \
| %endif
This won't work and is not necessary.
| make COPT="$NEW_CFLAGS" DESTDIR=$RPM_BUILD_ROOT/usr all
You should set CFLAGS when you run configure. (%{configure} will do that.)
DESTDIR is only useful when you run 'make install'. And DESTDIR should
not include /usr.
| make all PGDOCS=unpacked -C doc
Not sure what this is supposed to do, but I don't think it will do what
you expect. The docs are installed automatically.
| mkdir -p $RPM_BUILD_ROOT/usr/{include/pgsql,lib,bin}
| mkdir -p $RPM_BUILD_ROOT%{_mandir}
You don't need that, the directories are made automatically.
| make DESTDIR=$RPM_BUILD_ROOT -C src install
No '-C src'.
| # copy over the includes needed for SPI development.
| pushd src/include
| /lib/cpp -M -I. -I../backend executor/spi.h | \
| xargs -n 1| \
| grep \\W| \
| grep -v ^/| \
| grep -v spi.o | \
| grep -v spi.h | \
| sort | \
| cpio -pdu $RPM_BUILD_ROOT/usr/include/pgsql
I think the standard installed set of headers is sufficient.
| %if %pgaccess
| # pgaccess installation
Pgaccess is installed automatically when you configure --with-tcl.
| # Move the PL's to the right place
| mv $RPM_BUILD_ROOT/usr/lib/pl*.so $RPM_BUILD_ROOT/usr/share/postgresql
You should not put architecture specific files into share/. I'm sure this
is in violation of FHS. (I'm amazed createlang finds it there.)
Re: sub-packages
* pg_id should be in server
* What were the last thoughts about renaming the nothing package to -clients?
* pg_upgrade won't work, so you might as well not install it. It will
probably be disabled before we release.
* You're missing pg_config in the -devel package.
These are the things I could find at first glance. ;-)
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Peter Eisentraut wrote:
Lamar Owen writes:
Ok, I have a first set of 7.1beta3 RPMs uploading now. These RPMs pass
regression on my home RedHat 6.2 machine, which has all locale environment
variables disabled (/etc/sysconfig/i18n deleted and a reboot).
Some thoughts:
Re: rpm-pgsql-7.1beta3.patch
| diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib
postgresql-7.1beta3/src/Makefile.shlib
| - LINK.shared = $(COMPILER) -shared -Wl,-soname,$(soname)
| + LINK.shared = $(COMPILER) -shared -Wl
| endif
This cannot possibly be right.
It's what you recommended a while back. See the discussions on -soname
from the libpq.so.2.1 versus libpq.so.2.0 thread awhile back.
| diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib~
postgresql-7.1beta3/src/Makefile.shlib~
???
Leftover Kedit baggage. Those are easy to forget to rm during patch
build, particularly at 2:00AM -- but there's no harm in it being there
for now. And it won't be there in -2.
| -#!/usr/local/bin/perl -w
| +#!/usr/bin/perl -w
(and more of these for Python)
I think this should be fixed to read
#! /usr/bin/env perl
No, for a RedHat or any other Linux distribution, /usr/bin is where perl
and python (or their symlinks) will always live.
Although you missed the redundant patches in the regression tree :-).
Re: spec file
| # I hope this works
|
| %ifarch ia64
| ln -s linux_i386 src/template/linux
| %endif
It definitely won't...
7.0 required it. Baggage from the previous build.
| # If libtool installed, copy some files
| if [ -d /usr/share/libtool ]
| then
| cp /usr/share/libtool/config.* .
| fi
This is useless (because the config.* files are not in src/ anymore) and
(if it were fixed) not recommendable because config.{guess,sub} is not
compatible to itself, *especially* in terms of Linux recognition. You
really should use the ones PostgreSQL comes with.
Trond can answer that one more effectively than can I, as that's his
insertion.
Of course, I've got to reorg the destination to match the source tree's
reorg.
| %ifarch ppc
| NEW_CFLAGS=`echo $CFLAGS|xargs -n 1|grep -v "\-O"|xargs -n 100`
| NEW_CFLAGS="$NEW_CFLAGS -O0"
This is no longer necessary.
Depends on the convolutions the particular build of rpm itself is
doing. This is a fix for the broken rpm setup found on Linux-PPC, as
found by Tom Lane. It would be marvelous if this would be expendable at
this juncture.
| ./configure --enable-hba --enable-locale --with-CXX --prefix=/usr\
There is no option called '--enable-hba'. And I think you're supposed to
use %{configure}.
If it works now, I'll use it. Version 7.0 and prior wouldn't work with
%{configure}.
And --enable-hba has existed at some point in time.
| %if %tkpkg
| --with-tk --with-x \
| %endif
There is no '--with-x'. '--with-tk' is the default if '--with-tcl' was
given; you should use '--without-tk' if you don't want it.
There was in the past a --with-x. So I need to change that to check for
the negation of tkpkg and use --without-tk if so.
| %if %jdbc
| --with-java \
| %endif
There is no such option.
Hmmm. I don't remember when that one got placed there
| %ifarch alpha
| --with-template=linux_alpha \
| %endif
This won't work and is not necessary.
More 7.0 and prior baggage. The patches for alpha at one point (6.5
through 7.0.3) have required this -- of course, with the need for the
alpha patches gone, the need for the special config step is also gone.
One more piece of baggage I missed.
| make COPT="$NEW_CFLAGS" DESTDIR=$RPM_BUILD_ROOT/usr all
You should set CFLAGS when you run configure. (%{configure} will do that.)
DESTDIR is only useful when you run 'make install'. And DESTDIR should
not include /usr.
Yes, if you'll notice I fixed the DESTDIR in the install. But, of
course, it's not needed (nor is it used) in the build itself. Again,
I'll use %{configure} when I verify that it works properly (if it does,
that will be a very Good Thing for all involved). But, again, you're
seeing baggage that 7.0 and prior required in order to build (well,
except DESTDIR).
| make all PGDOCS=unpacked -C doc
Not sure what this is supposed to do, but I don't think it will do what
you expect. The docs are installed automatically.
Well, they are _now_. But 7.0 and prior. again, more old baggage.
| mkdir -p $RPM_BUILD_ROOT/usr/{include/pgsql,lib,bin}
| mkdir -p $RPM_BUILD_ROOT%{_mandir}
You don't need that, the directories are made automatically.
They are _now_. But before, when the make install put things in the
'wrong' place, it was required to make the directories before doing the
copies and moves necessary.
| make DESTDIR=$RPM_BUILD_ROOT -C src install
No '-C src'.
Not anymore, at least. *sigh* There has been alot of baggage
accumulate in the spec due to 7.0 and prior's slightly brain-dead
build. I got rid of a lot of it -- but
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Lamar Owen [EMAIL PROTECTED] writes: | %ifarch ppc | NEW_CFLAGS=`echo $CFLAGS|xargs -n 1|grep -v "\-O"|xargs -n 100` | NEW_CFLAGS="$NEW_CFLAGS -O0" This is no longer necessary. Depends on the convolutions the particular build of rpm itself is doing. This is a fix for the broken rpm setup found on Linux-PPC, as found by Tom Lane. It would be marvelous if this would be expendable at this juncture. It is. 7.1 builds cleanly on PPC without any CFLAGS hackery. I think we can even survive the -fsigned-char stupidity now ;-) I think the standard installed set of headers is sufficient. Is it? It _wasn't_ sufficient for SPI development at 7.0. Have the headers and the headers install been fixed to install _all_ necessary development headers, SPI included? No, nothing's been done about that AFAIK. I'm not sure the RPMs should be taking it on themselves to solve the problem, however. regards, tom lane
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: doing. This is a fix for the broken rpm setup found on Linux-PPC, as found by Tom Lane. It would be marvelous if this would be expendable at this juncture. It is. 7.1 builds cleanly on PPC without any CFLAGS hackery. I think we can even survive the -fsigned-char stupidity now ;-) Oh, good. Makes it much cleaner. Care to test that theory? :-) I think the standard installed set of headers is sufficient. Is it? It _wasn't_ sufficient for SPI development at 7.0. Have the headers and the headers install been fixed to install _all_ necessary development headers, SPI included? No, nothing's been done about that AFAIK. I'm not sure the RPMs should be taking it on themselves to solve the problem, however. Just trying to make the postgresql-devel rpm complete, as per request. Since the folk who build from source usually still have the source tree around to do SPI development in, it's not as big of an issue for that install. Of course, if the consensus is that the RPM's simply track what the source tarball does, then that can also be arranged. But, the precedent of the RPMset fixing difficulties with the source install has already been set with the upgrading procedure. Arguments about why those wishing to do SPI development should install a full source tree aside, I'm simply providing an RPM-specific requested feature. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Tom Lane wrote: Let me know when you think the 7.1 RPM specfile is stable enough to be worth testing, and I'll try to build PPC RPMs. Ok. Should be coincident with -2. I'm planning to have a -2 out later this week. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Trond Eivind Glomsrd writes: We have a libtool tuned to work with lots of platforms, like ia64, s390 etc... this makes sure it's used. We don't use libtool. Nor does libtool care about the processor. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Peter Eisentraut [EMAIL PROTECTED] writes:
Trond Eivind Glomsrd writes:
We have a libtool tuned to work with lots of platforms, like ia64,
s390 etc... this makes sure it's used.
We don't use libtool.
Doing so would be a good thing.
Nor does libtool care about the processor.
As you can see from the actual code segment, only the
config.{guess,sub} files are copied.
--
Trond Eivind Glomsrd
Red Hat, Inc.
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Lamar Owen writes: | diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib postgresql-7.1beta3/src/Makefile.shlib | - LINK.shared = $(COMPILER) -shared -Wl,-soname,$(soname) | + LINK.shared = $(COMPILER) -shared -Wl | endif This cannot possibly be right. It's what you recommended a while back. See the discussions on -soname from the libpq.so.2.1 versus libpq.so.2.0 thread awhile back. The patch I recommended was - LDFLAGS_SL:= -Bdynamic -shared -soname $(shlib) + LDFLAGS_SL:= -Bdynamic -shared -soname +lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) but that's not what your patch does. The issue is fixed, you shouldn't patch anything. I think this should be fixed to read #! /usr/bin/env perl No, for a RedHat or any other Linux distribution, /usr/bin is where perl and python (or their symlinks) will always live. I was thinking in terms of fixing this in the source tree. There is no '--with-x'. '--with-tk' is the default if '--with-tcl' was given; you should use '--without-tk' if you don't want it. There was in the past a --with-x. But it never did anything. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Peter Eisentraut [EMAIL PROTECTED] writes:
Trond Eivind Glomsrd writes:
We don't use libtool.
Doing so would be a good thing.
Not if our code is more portable than libtool's.
And this is the case? libtool covers pretty much everything... and you
don't need to use it for every target.
Nor does libtool care about the processor.
As you can see from the actual code segment, only the
config.{guess,sub} files are copied.
But you argued that this is because your config.guess supports s390 and
ia64 (which ours does as well)
It may do so now, but I'm pretty sure it hasn't always done so... and
even if it does, it doesn't hurt.
--
Trond Eivind Glomsrd
Red Hat, Inc.
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Lamar Owen [EMAIL PROTECTED] writes: Peter Eisentraut wrote: Trond Eivind Glomsrd writes: We have a libtool tuned to work with lots of platforms, like ia64, s390 etc... this makes sure it's used. We don't use libtool. Nor does libtool care about the processor. In particular, this was and is a RedHat-made change. It does not break anything that I am aware of, and allows the distributions to do their thing as well. Note that this wasn't included in Red Hat Linux 7... it's been done since then, and I don't remember doing it myself (which of course doesn't mean I didn't do it :) - it might have been done for the S/390 port, by the people working on that. So, Trond, what sort of tunings have been performed that make the files in question need to be copied? I'm sure you have a good reason; I am just curious as to what it is. For most apps, it's just a question of configure working vs. configure failing on IA64 (there is no "tuning" as such, my choice of words wasn't too good). There may be something similar for S/390. -- Trond Eivind Glomsrd Red Hat, Inc.
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Trond Eivind Glomsrd wrote: Lamar Owen [EMAIL PROTECTED] writes: In particular, this was and is a RedHat-made change. It does not break anything that I am aware of, and allows the distributions to do their thing as well. Note that this wasn't included in Red Hat Linux 7... it's been done since then, and I don't remember doing it myself (which of course doesn't mean I didn't do it :) - it might have been done for the S/390 port, by the people working on that. A non-conditional version (the conditional is my change) was included as far back as RedHat 6.2. For most apps, it's just a question of configure working vs. configure failing on IA64 (there is no "tuning" as such, my choice of words wasn't too good). There may be something similar for S/390. Can we test both ways (after your current project is done)? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[HACKERS] RPMS for 7.1beta3 being uploaded.
Ok, I have a first set of 7.1beta3 RPMs uploading now. These RPMs pass regression on my home RedHat 6.2 machine, which has all locale environment variables disabled (/etc/sysconfig/i18n deleted and a reboot). It may take a few minutes to a few hours for the changes I uploaded to propagate to the public ftp server. NOTE: BETA RPMS ARE JUST EXACTLY THAT! These RPM's are not in a finished state -- they are for the express purpose of allowing people to test 7.1beta in an RPM setup. Upgrading from a prior version is explicitly NOT supported at this time. There ARE KNOWN packaging problems -- I am working on them. NOTE: there have been some changes in the RPM install structure. /usr/lib/pgsql is gone, replaced by /usr/share/postgresql. See the file lists from 'rpm -qlp postgresql*7.1beta3-1.i386.rpm' for more details. README.rpm-dist has not been updated for the 7.1beta3 distribution yet. To run regression tests, make sure the postgresql-test RPM is installed, then make sure that the locale environment is set properly. Regression tests may be run by first, as root, starting a postmaster: /etc/rc.d/init.d/postgresql start (if there are any errors, make sure you are not upgrading!) Then, as root: chown -R postgres.postgres /usr/share/postgresql/test/regress (yes, I know the RPMset should do this for you. It is being fixed.) Then, su to postgres and cd to /usr/share/postgresql/test/regress. Execute: ./pg_regress --schedule=parallel_schedule Any failures indicate an error somewhere -- most likely your locale settings. Look for another release this week, with things streamlined somewhat. Also, if you wish to rebuild from the source RPM, please read the comments and conditionals in the spec file BEFORE rebuilding -- you can conditionally rebuild just a few of the packages instead of having to rebuild everything. Please check all the client interfaces you are equipped to check. I need someone to work over the perl, python, tcl, and tk stuff. If someone wants to contribute built jars of the newest JDBC, I would be most grateful, as I don't have a JDK on my devel machine yet. The jars distributed are the 7.0 JDBC jars -- which are known to need some recent patches. pgaccess currently will not run unless you reconfigure to use -i in the startup. This is also being fixed in the RPMset -- there is a change necessary in postgresql.config, I just have to do the change. PL/perl is being worked on -- many thanks to Karl DeBisschop for his perserverence in this. RPMS are in at: ftp.postgresql.org/pub/dev/test-rpms and are built for RedHat 6.2/Intel ONLY. Once again, at the risk of sounding like a broken record -- these are BETA QUALITY RPMS -- BY REQUEST. Please don't make me regret not waiting until a release candidate :-). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
