problem with RH7.3 Pg7.3.4 binaries

Andrew Dunstan wrote:

I know building RPMs can be a major pain, but ISTM that builds should be
published that don't break on vanilla installations. I'm prepared to
help with fixing this if necessary. For now I've upgraded to 7.3.3 (the
RPMs for this don't suffer the same problem on RH7.3).

Sorry, that's my fault, not Lamar's. I built the 7.3 RPMs for him.
Unfortunately I don't have a plain vanilla installation available -- I
had forgotten that I upgraded ssl to something non-standard :(

Perhaps if you have a vanilla 7.3 machine available, you could build new
7.3 RPMs from the source RPM and give them to Lamar for distribution?

Joe

On Monday 04 August 2003 11:53, Joe Conway wrote:

Andrew Dunstan wrote:

I know building RPMs can be a major pain, but ISTM that builds should be
published that don't break on vanilla installations. I'm prepared to
help with fixing this if necessary. For now I've upgraded to 7.3.3 (the
RPMs for this don't suffer the same problem on RH7.3).

Sorry, that's my fault, not Lamar's. I built the 7.3 RPMs for him.
Unfortunately I don't have a plain vanilla installation available -- I
had forgotten that I upgraded ssl to something non-standard :(

Perhaps if you have a vanilla 7.3 machine available, you could build new
7.3 RPMs from the source RPM and give them to Lamar for distribution?

Until vanilla-built RH7.3 RPMs are available, I've removed them from the FTP
site. I don't have an RH7.3 installation readily available for building.

Joe, the RHAS binaries won't have this problem, right?

To prevent this in the future, I'm going to state that anyone who wants to
build RPMs for distribution needs to do so with a fully up to date vanilla
installation of the target OS. Since I do this myself for whatever RPMs I'm
personally building, it was an easy assumption to make that everyone would do
this. My apologies.

A minor rant: I seem to vacillate between providing only one set of RPMs
versus providing whatever sets people can build for me. There is a definite
tradeoff between having lots of sets available and having only good sets
available. While I do my best to ensure only good sets are available, I am
not able to test every set that is built. That is one reason I've not begun
GPG-signing my RPMs -- if you want certified RPMs build them yourself. It
isn't that hard. And when people are so impatient for RPMsets, then complain
that the set didn't work -- well, it isn't the most encouraging thing in the
world. You want guaranteed RPMs that will install on your machine the day of
the release? You have three choices: build them yourself, pay someone to
build them, or wait until the official set is available. My rate for
building RPMs under those conditions is $100 per hour. (and I have been paid
that rate before.) But the official set will only get uploaded once I've had
the time to build it and test it.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute

Lamar Owen wrote:

Joe, the RHAS binaries won't have this problem, right?

I don't think so -- the server I built those on is very much vanilla
RHAS. But then this raises a question in my mind -- is vanilla a fully
updated vanilla or "off the original CDs" vanilla?

To prevent this in the future, I'm going to state that anyone who wants to
build RPMs for distribution needs to do so with a fully up to date vanilla
installation of the target OS. Since I do this myself for whatever RPMs I'm
personally building, it was an easy assumption to make that everyone would do
this. My apologies.

Sorry -- I'll be more cognizant of that in the future.

Joe

On Monday 04 August 2003 13:00, Joe Conway wrote:

I don't think so -- the server I built those on is very much vanilla
RHAS. But then this raises a question in my mind -- is vanilla a fully
updated vanilla or "off the original CDs" vanilla?

I've thus far used the definition that it is a fully-updated install, using
the OS vendor's update packages that are dependencies of PostgreSQL.
Updating to, say, a later KDE, or GNUcash, or whatnot is OK. But core
libraries that PostgreSQL uses need to stay vanilla-updated.

Sorry -- I'll be more cognizant of that in the future.

Hey, don't worry about it. I should have checked: that IS my responsibility.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute

Lamar Owen wrote:

On Monday 04 August 2003 13:00, Joe Conway wrote:

I don't think so -- the server I built those on is very much vanilla
RHAS. But then this raises a question in my mind -- is vanilla a fully
updated vanilla or "off the original CDs" vanilla?

I've thus far used the definition that it is a fully-updated install, using
the OS vendor's update packages that are dependencies of PostgreSQL.
Updating to, say, a later KDE, or GNUcash, or whatnot is OK. But core
libraries that PostgreSQL uses need to stay vanilla-updated.

I'll have to check, but I'd guess that the RHAS I built on was pretty
close to "off the original CDs", i.e. not updated. I'll let you know.

Joe

I agree with the definition of "vanilla install" below.

I can't use the machine I was upgrading to build, unfortunately. Its a
production machine I am prepping, (and is missing stuff the build
process needs even if I wanted to monkey with it), which is precisely
why I wanted to install from RPMs rather than just saying "screw it" and
installing from a source tarball.

I will see if I can get the old machine currently mouldering away in my
attic to run 7.3 and build with it, maybe some time this week. (It's
time like these you appreciate having lots of bandwidth to download ISOs).

andrew

Lamar Owen wrote:

Joe Conway wrote:

Lamar Owen wrote:

I've thus far used the definition that it is a fully-updated install,
using the OS vendor's update packages that are dependencies of
PostgreSQL. Updating to, say, a later KDE, or GNUcash, or whatnot is
OK. But core libraries that PostgreSQL uses need to stay
vanilla-updated.

I'll have to check, but I'd guess that the RHAS I built on was pretty
close to "off the original CDs", i.e. not updated. I'll let you know.

I just checked, and the RHAS that I built the RPMs on is pretty close to
original, other than kernel and some driver updates. I'll let you decide
whether to pull them or not, but they don't meet your "fully-updated
install" criterion.

Joe

On Monday 04 August 2003 13:57, Joe Conway wrote:

I just checked, and the RHAS that I built the RPMs on is pretty close to
original, other than kernel and some driver updates. I'll let you decide
whether to pull them or not, but they don't meet your "fully-updated
install" criterion.

Hmmm... Tough call, but I think I'll leave them be, since they will install on
a fully-updated installation. Although I can't imagine an RHAS install not
updated, but that's a different topic.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute

Hi there,

I have a RedHat 7.3 machine that can build the 7.3.4 RPMs if required -
it only contains RPMs from the vanilla CD or from updates.redhat.com.
I've just done a test build and everything seems OK except that the C
compiler is passed the -mcpu=i686 flag - I'm guessing I need to somehow
change this to i386 so it will binaries will run on actual i386
machines? Can someone point me in the right direction?

Cheers,

Mark.

---

Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England

Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446

This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.

Mark Cave-Ayland said:

Hi there,

I have a RedHat 7.3 machine that can build the 7.3.4 RPMs if required -
it only contains RPMs from the vanilla CD or from updates.redhat.com.
I've just done a test build and everything seems OK except that the C
compiler is passed the -mcpu=i686 flag - I'm guessing I need to somehow
change this to i386 so it will binaries will run on actual i386
machines? Can someone point me in the right direction?

The -mcpu flag doesn't do what you seems to think it does.
It still generates i386 compatible code, but favours i686 processor
timings etc.

Cheers,

Mark.

Magnus

Hi Magnus,

Thanks for that. I always believed that the mcpu flag could enable a C
compiler to generate code that could use the extra instructions on the
newer CPUs - perhaps one day I'll get around to reading the
documentation ;)

Anyway, I've posted the compiled RH 7.3 postgresql-7.3.4 RPMs at
http://www.webbased.co.uk/mca/pgsql/. Andrew, if you are satisfied that
these work correctly on your RH7.3 install, there is no problem with
Lamar placing copies of them on the postgresql website for people to
download.

Cheers,

Mark.

---

Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England

Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446

This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.

Will check later today.

Extract from man gcc:

-mcpu=cpu-type
Tune to cpu-type everything applicable about the generated code,
except for the ABI and the set of available instructions. The
choices for cpu-type are i386, i486, i586, i686, pentium,
pentium-
mmx, pentiumpro, pentium2, pentium3, pentium4, k6, k6-2, k6-3,
athlon, athlon-tbird, athlon-4, athlon-xp and athlon-mp.

While picking a specific cpu-type will schedule things appropri-
ately for that particular chip, the compiler will not generate
any
code that does not run on the i386 without the -march=cpu-type
option being used. i586 is equivalent to pentium and i686 is
equivalent to pentiumpro. k6 and athlon are the AMD chips as
opposed to the Intel ones.

cheers

andrew

----- Original Message -----
From: "Mark Cave-Ayland" <m.cave-ayland@webbased.co.uk>
To: <mag@fbab.net>
Cc: "'Joe Conway'" <mail@joeconway.com>; "'Andrew Dunstan'"
<andrew@dunslane.net>; "'Lamar Owen'" <lowen@pari.edu>; "'Postgresql
Hackers'" <pgsql-hackers@postgresql.org>
Sent: Tuesday, August 05, 2003 6:28 AM
Subject: Re: [HACKERS] problem with RH7.3 Pg7.3.4 binaries

On Tuesday 05 August 2003 08:14, Andrew Dunstan wrote:

Will check later today.

When you do, let me know, so that I can post them.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute

Seems to be OK. See below.

BTW, for those interested, following up a note from Joe Conway I
discovered yesterday the Right Way (tm) to build RPMs (nothing Pg
specific in this). Basically, you set up some rpm macros like this in
~/.rpmmacros:
%_topdir %(echo ${HOME}/rpm)
%_tmppath %{_topdir}/tmp
%packager Your Name <yourusername@your.org>
and a directory tree something like this under your homedir:
rpm
rpm/BUILD
rpm/RPMS
rpm/RPMS/i386
rpm/RPMS/i586
rpm/RPMS/noarch
rpm/SOURCES
rpm/SPECS
rpm/SRPMS
rpm/tmp
adjusting the subdirs of RPMS appropriately.

now you can run
rpmbuild -ba postgresql-7.3.4-1PGDG.src.rpm

and everything builds nicely (assuming your have the right stuff
installed). No need to build as root (building as root is Evil) nor to
install the source rpm before building.

Now having rescued the boat anchor \b\b\b\b\b\b\b old P1 box from the
attic I need to find a new use for it .....

cheers

andrew
-------------------------

[root@face pgsql]# rpm -Fhv postgresql-*.rpm
Preparing... ###########################################
[100%]
1:postgresql-docs ###########################################
[ 12%]
2:postgresql-jdbc ###########################################
[ 25%]
3:postgresql-libs ###########################################
[ 37%]
4:postgresql ###########################################
[ 50%]
5:postgresql-contrib ###########################################
[ 62%]
6:postgresql-devel ###########################################
[ 75%]
7:postgresql-server ###########################################
[ 87%]
8:postgresql-pl ###########################################
[100%]
[root@face pgsql]# /etc/init.d/postgresql stop
[ OK ]
[root@face pgsql]# /etc/init.d/postgresql start
Starting postgresql service: [ OK ]
[root@face pgsql]# su - facedba -c "psql face"
Welcome to psql 7.3.4, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

face=# select version();
version
-----------------------------------------------------------------
PostgreSQL 7.3.4 on i386-redhat-linux-gnu, compiled by GCC 2.96
(1 row)

face=# \q
[root@face pgsql]#
-------------------------------------------------------
Lamar Owen wrote:

BTW, the init file has this:

# chkconfig: - 85 15

I would modestly suggest changing this to something like 81 19. The
reason - these are the same settinga as httpd, and I normally want Pg
started up before the web server and shut down after the web server.

andrew

Andrew Dunstan wrote: