7.1 RPMs

Thomas Lockhart wrote:

Hi Lamar. What are the plans for RPMs? Do we have an "integrated RPM"
which will work with Mandrake, or should I keep carrying along my
patches to make the spec file work for now?

I haven't addressed that as yet. Is it safe to assume that -ffast-math
should be Considered Harmful in the RPM_OPT_FLAGS? Is -ffast-math
_ever_ a Good Thing for our routines? I can easily enough strip out
-ffast-math from the flags for all cases (xarg -n 1 grep -v
ffast-math|xargs is your friend....).

While I don't plan on following the Mandrake Way WRT repackaging our
tarball with bzip2, the source RPM should use whatever compression for
the man pages that the buildrootpolicy for that distribution supplies.

How are you planning on packaging the hardcopy docs? They are not yet
available, but will be Real Soon Now :(

In the postgresql-docs subpackage, along with the SGML source. The html
built docs made from the SGML source is still going into the main
tarball, as they are nice and browseable in their standard location.

If I release a -1 RPM without the hardcopy, I can release a -2 with....

I have a couple of patches from Trond to integrate, and a decision to
make regarding the contribs: should all the contrib tree go into one big
RPM (860KB or so),or should each contrib directory get its own RPM
(reminiscent of the PM3 binary RPM monster)? One patch from Trond has
been duplicated by Karl: which patch allows building as non-root again.

There's also a question about the Python client -- it would be good if
someone who has downloaded one of the RC RPM's could test that, as I'm
not a snake charmer. :-)

Also, I need either a standard way to build the java stuff (meaning my
own JDK that is reasonably standard by consensus -- kaffe ships with
RedHat 7.0 -- isthat an acceptable JDK-substitute?) or someone needs to
package 7.1 JDBC jars for my packaging pleasure. I'm running low enough
on disk space on my devel machines (one of which is a notebook) to make
my own JDK a second choice.

Oliver, what are doing with the JDBC client?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Fri, 13 Apr 2001, Peter Eisentraut wrote:

Lamar Owen writes:

In the postgresql-docs subpackage, along with the SGML source.

Why would you want to ship the source?

For those with SGML tools and viewers, who might like to build hardcopy of
their own. Frankly, it was an easy thing to do; had been done; and I saw no
real reason to stop doing it. I _does_ take up a little space, however.

The SGML source had been distributed as part of the main RPM, prior to 7.1.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen writes:

In the postgresql-docs subpackage, along with the SGML source.

Why would you want to ship the source?

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

I haven't addressed that as yet. Is it safe to assume that -ffast-math
should be Considered Harmful in the RPM_OPT_FLAGS? Is -ffast-math
_ever_ a Good Thing for our routines? I can easily enough strip out
-ffast-math from the flags for all cases (xarg -n 1 grep -v
ffast-math|xargs is your friend....).

I believe that there is no room for -ffast-math in PostgreSQL. The
compiler man page says that the option allows the compiler to generate
code which does not conform to IEEE math standards, and istm that we
might consider that as affecting our predictability and portability. The
man page also warns against using -ffast-math and -O together, but I
can't tell if that is a warning to users or a "note to myself" for the
compiler maintainers.

While I don't plan on following the Mandrake Way WRT repackaging our
tarball with bzip2, the source RPM should use whatever compression for
the man pages that the buildrootpolicy for that distribution supplies.

Certainly so for the tarball. However the tarballs are delivered is how
we should use them imho. Why is it an issue for the man pages? They are
uncompressed in our source tarball (? haven't checked) and if we have
them uncompressed in the RPM build area then they get compressed by RPM
somewhere between installation and RPM packaging, right?

How are you planning on packaging the hardcopy docs? They are not yet
available, but will be Real Soon Now :(

In the postgresql-docs subpackage, along with the SGML source. The html
built docs made from the SGML source is still going into the main
tarball, as they are nice and browseable in their standard location.
If I release a -1 RPM without the hardcopy, I can release a -2 with....

Great.

There's also a question about the Python client -- it would be good if
someone who has downloaded one of the RC RPM's could test that, as I'm
not a snake charmer. :-)

Not sure about the python stuff, and I don't recall doing anything in
the past on that topic.

Also, I need either a standard way to build the java stuff (meaning my
own JDK that is reasonably standard by consensus -- kaffe ships with
RedHat 7.0 -- isthat an acceptable JDK-substitute?) or someone needs to
package 7.1 JDBC jars for my packaging pleasure. I'm running low enough
on disk space on my devel machines (one of which is a notebook) to make
my own JDK a second choice.

In the past I have found that kaffe did not handle enough java code for
my needs, but that was not for the JDBC driver. I am currently using
jikes for my projects, and it produces *nice* code in my experience.

- Thomas

Thomas Lockhart wrote:

I believe that there is no room for -ffast-math in PostgreSQL. The

I have placed code in the spec to strip out ffast-math from the CFLAGS.
I have not as yet followed Peter's advice on exporting CFLAGS and
leaving COPT -- but that's not to say that I won't.

While I don't plan on following the Mandrake Way WRT repackaging our
tarball with bzip2, the source RPM should use whatever compression for
the man pages that the buildrootpolicy for that distribution supplies.

Certainly so for the tarball. However the tarballs are delivered is how
we should use them imho.

Exactly.

them uncompressed in the RPM build area then they get compressed by RPM
somewhere between installation and RPM packaging, right?

Right. Each distributor can use its own buildrootpolicy -- which
handles man page compression, executable stripping, and the like. Not an
issue -- but Mandrake historically bzip2's them.

Not sure about the python stuff, and I don't recall doing anything in
the past on that topic.

I thought you did up the current build way ... but I could be mistaken.
I need to see if the python interface makefile Does the Right Thing now
WRT RPM_BUILD_ROOT/DESTDIR processing. The main make stuff now acts
sanely inthe presence of RPM_BUILD_ROOT -- well, except the perl
interface, but that's a special case.

In the past I have found that kaffe did not handle enough java code for
my needs, but that was not for the JDBC driver. I am currently using
jikes for my projects, and it produces *nice* code in my experience.

Jikes is open source, right? I know it is available for Red Hat (ships
with it on one of the applications CD's,IIRC.) How does a Jikes-built
JDBC sound to people? Ormaybe I don't understand the Java Way well
enough to decide. Gotta learn it a little....
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

In the past I have found that kaffe did not handle enough java code for
my needs, but that was not for the JDBC driver. I am currently using
jikes for my projects, and it produces *nice* code in my experience.

Jikes is open source, right? I know it is available for Red Hat (ships
with it on one of the applications CD's,IIRC.) How does a Jikes-built
JDBC sound to people? Ormaybe I don't understand the Java Way well
enough to decide. Gotta learn it a little....

Jikes is an excellent compiler, but it needs a set of classes to
compile against from a JDK.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

Do we need to start thinking about an RPM mailing list? Seems there is
lots of traffic.

-- 
  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

If someone wants to come up with an idea for name, i think that the whole
Win camp could be seperated also ...

pgsql-windows and pgsql-rpm ?

as far as newsgroups are concerned, they would both fall under ports:

comp.databases.postgresql.ports.linux.rpm
comp.databases.postgresql.ports.windows

I'm willing to create, as long as ppl are willing to use *shrug*

On Sat, 14 Apr 2001, Bruce Momjian wrote:

Do we need to start thinking about an RPM mailing list? Seems there is
lots of traffic.

--
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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

The Hermit Hacker wrote:

If someone wants to come up with an idea for name, i think that the whole
Win camp could be seperated also ...

pgsql-windows and pgsql-rpm ?

as far as newsgroups are concerned, they would both fall under ports:

If that's what you want to do. Although, I'd recommend pgsql-cygwin,
lest someone erroneously think we directly support Win32.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

The Hermit Hacker <scrappy@hub.org> writes:

If someone wants to come up with an idea for name, i think that the whole
Win camp could be seperated also ...

pgsql-windows and pgsql-rpm ?

A windows list seems like a good idea. But I'm not sure that a separate
list for RPMs is a good idea. In the first place, it's fuzzy: is it
to be used just for RPM packaging discussion, or is it going to draw
off --- for example --- all bug reports from people who happen to have
installed from RPM instead of source? I suppose the former is intended,
but it's not going to be clear to people. I think we've already got too
many lists with fuzzy boundaries. In the second place, the RPM
packaging discussion is quite sporadic; I think the traffic would be nil
except at times when Lamar is working on new RPMs.

regards, tom lane

On Sat, 14 Apr 2001, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

If someone wants to come up with an idea for name, i think that the whole
Win camp could be seperated also ...

pgsql-windows and pgsql-rpm ?

A windows list seems like a good idea. But I'm not sure that a
separate list for RPMs is a good idea. In the first place, it's
fuzzy: is it to be used just for RPM packaging discussion, or is it
going to draw off --- for example --- all bug reports from people who
happen to have installed from RPM instead of source? I suppose the
former is intended, but it's not going to be clear to people. I think
we've already got too many lists with fuzzy boundaries. In the second
place, the RPM packaging discussion is quite sporadic; I think the
traffic would be nil except at times when Lamar is working on new
RPMs.

That's why I wasn't sure how to classify the RPM one ...

I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable?

Bruce Momjian writes:

Do we need to start thinking about an RPM mailing list? Seems there is
lots of traffic.

The traffic naturally peaks around release time, and this time especially
because yours truly messed up the whole build system that the packagers
were so careful to work around. I trust that in a few weeks we'll enter a
new quiet period. My vote is that technical packaging discussions should
go on -hackers just like a makefile discussion.

OK, it was just an idea.

-- 
  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

The Hermit Hacker <scrappy@hub.org> writes:

I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable?

Yes, that's probably better than pgsql-windows ...

regards, tom lane

Bruce Momjian writes:

Do we need to start thinking about an RPM mailing list? Seems there is
lots of traffic.

The traffic naturally peaks around release time, and this time especially
because yours truly messed up the whole build system that the packagers
were so careful to work around. I trust that in a few weeks we'll enter a
new quiet period. My vote is that technical packaging discussions should
go on -hackers just like a makefile discussion.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

On Sat, 14 Apr 2001, Peter Eisentraut wrote:

Bruce Momjian writes:

Do we need to start thinking about an RPM mailing list? Seems there is
lots of traffic.

The traffic naturally peaks around release time, and this time
especially because yours truly messed up the whole build system that
the packagers were so careful to work around. I trust that in a few
weeks we'll enter a new quiet period. My vote is that technical
packaging discussions should go on -hackers just like a makefile
discussion.

Why not a "pgsql-build", or something like that, list? Where build/make
file discussions can take place? Vs server issues? I'd really like to
find some way of reducing traffic on -hackers like we did with -interfaces
... if we can come up with a good list for it ...

pgsql-build (or a better name?) could be for RPM discussions, just as easy
as Makefile/Configure discussions ...

The Hermit Hacker writes:

I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable?

We have pgsql-ports, which isn't seeing too much traffic as it is. Seems
like the cygwin people hang out there anyway.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

On Sat, 14 Apr 2001, The Hermit Hacker wrote:

On Sat, 14 Apr 2001, Peter Eisentraut wrote:

Bruce Momjian writes:

Do we need to start thinking about an RPM mailing list? Seems there is
lots of traffic.

The traffic naturally peaks around release time, and this time
especially because yours truly messed up the whole build system that
the packagers were so careful to work around. I trust that in a few
weeks we'll enter a new quiet period. My vote is that technical
packaging discussions should go on -hackers just like a makefile
discussion.

Why not a "pgsql-build", or something like that, list? Where build/make
file discussions can take place? Vs server issues? I'd really like to
find some way of reducing traffic on -hackers like we did with -interfaces
... if we can come up with a good list for it ...

pgsql-build (or a better name?) could be for RPM discussions, just as easy
as Makefile/Configure discussions ...

How 'bout pgsql-hackers-rpm. Because the make/config stuff can impact
so many different parts of PostgreSQL, that stuff should probably remain
on hackers.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

The Hermit Hacker <scrappy@hub.org> writes:

I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable?

Yes, that's probably better than pgsql-windows ...

But then again, the comment this is more properly done on ports makes
sense.

-- 
  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

On Sat, 14 Apr 2001, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable?

Yes, that's probably better than pgsql-windows ...

Done ...