Jim C. Nasby [EMAIL PROTECTED] writes:
And 7.3 is also failing, with a different error:
ccache gcc -traditional-cpp -g -O2 -fno-strict-aliasing -g -Wall
-Wmissing-prototypes -Wmissing-declarations -I../../../../src/include
-I/opt/local/include -c -o printtup.o printtup.c
In file included
Tom Lane wrote:
This is a considerably bigger issue for the buildfarm than it would
be for ordinary users of our distribution, since in the distro it's
only the contrib modules that you actually need to run through your
local flex.
Couldn't we just run the distprep actions (flex, bison)
Peter Eisentraut [EMAIL PROTECTED] writes:
Couldn't we just run the distprep actions (flex, bison) through contrib
as well? That wouldn't hurt anyone, I think.
No objection here (though of course it doesn't affect the buildfarm issue).
regards, tom lane
On Wed, Jul 20, 2005 at 10:32:00AM -0400, Tom Lane wrote:
In short, OS X 10.2 wasn't a supported platform when 7.2/7.3 came out,
and I don't want to retroactively try to make it so.
All I needed to hear. I'll pull those from cuckoo's config.
--
Jim C. Nasby, Database Consultant
On Sat, Jul 16, 2005 at 11:17:29PM -0400, Tom Lane wrote:
cuckoo [7.3, 7.2]: --enable-nls without OS support
This looks like pilot error; but the later branches don't fail on this
machine, so did we change something in this area?
Should I just stop using nls on 7.2 and 7.3 or does someone
Jim C. Nasby [EMAIL PROTECTED] writes:
On Sat, Jul 16, 2005 at 11:17:29PM -0400, Tom Lane wrote:
cuckoo [7.3, 7.2]: --enable-nls without OS support
This looks like pilot error; but the later branches don't fail on this
machine, so did we change something in this area?
Should I just stop
On Tue, Jul 19, 2005 at 02:29:08PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Sat, Jul 16, 2005 at 11:17:29PM -0400, Tom Lane wrote:
cuckoo [7.3, 7.2]: --enable-nls without OS support
This looks like pilot error; but the later branches don't fail on this
machine,
Jim C. Nasby wrote:
Then I guess the question is... is it more valuable to have a working
buildfarm environment for 7.2 and 7.3, or is the obnoxious failure
better to spur someone into looking at it? :) Should this maybe be made
a TODO and I'll adjust my config until someone tackles the TODO?
On Tue, Jul 19, 2005 at 03:17:49PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
Then I guess the question is... is it more valuable to have a working
buildfarm environment for 7.2 and 7.3, or is the obnoxious failure
better to spur someone into looking at it? :) Should this maybe be
(trimming cc list...)
On Tue, Jul 19, 2005 at 02:25:38PM -0500, Jim C. Nasby wrote:
OK, I'll tweak cuckoo's config accordingly then.
And now it's failing on make, at least for 7.2...
ccache gcc -O3 -pipe -traditional-cpp -g -O2 -g -Wall
-Wmissing-prototypes -Wmissing-declarations -I.
And 7.3 is also failing, with a different error:
ccache gcc -traditional-cpp -g -O2 -fno-strict-aliasing -g -Wall
-Wmissing-prototypes -Wmissing-declarations -I../../../../src/include
-I/opt/local/include -c -o printtup.o printtup.c
In file included from /usr/include/machine/param.h:30,
On Sun, 17 Jul 2005, Tom Lane wrote:
The short answer is that you should install flex 2.5.4, or else forget
about testing the 7.2 branch. I don't think anyone will be very
interested in making 7.2 work with flex 2.5.31.
Actually there are problems in the 7.3 branch as well in the cube,
First off, thanks for looking into this, Tom, and thanks to Andrew for
all the stellar work on the buildfarm, I'm glad to be a part of it.
Perhaps this will help in the diagnosis of why REL7_2_STABLE fails on
arbor (aka caribou). Please let me know if there is anything I can try
on this side, or
Tom,
thanks for this. I regularly send out private emails about what appear
to be local issues.
Tom Lane wrote:
I spent a little time today cleaning up easily-fixed problems that are
causing buildfarm failures in various back branches. Hopefully that
will result in a few more green
Kris Jurka [EMAIL PROTECTED] writes:
On Sun, 17 Jul 2005, Tom Lane wrote:
The short answer is that you should install flex 2.5.4, or else forget
about testing the 7.2 branch. I don't think anyone will be very
interested in making 7.2 work with flex 2.5.31.
Actually there are problems in the
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
potoroo [HEAD, 7.4]: lock file /tmp/.s.PGSQL.65432.lock already exists
I'm not sure if this is a problem with a stale lock file left around
from an old run, or if it happens because the machine is configured to
try to build/test
Tom Lane wrote:
I believe that if we do something like
TEMP_PORT = 5$(default_port)
check:
pg_regress ... --temp_port=$(TEMP_PORT)
then the port could be overridden without any source code hacks by
gmake TEMP_PORT=nnn check.
Works for me. Let's do it. If I understand this
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I believe that if we do something like
TEMP_PORT = 5$(default_port)
check:
pg_regress ... --temp_port=$(TEMP_PORT)
then the port could be overridden without any source code hacks by
gmake TEMP_PORT=nnn check.
Works for me.
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I believe that if we do something like
TEMP_PORT = 5$(default_port)
check:
pg_regress ... --temp_port=$(TEMP_PORT)
then the port could be overridden without any source code hacks by
gmake TEMP_PORT=nnn
I spent a little time today cleaning up easily-fixed problems that are
causing buildfarm failures in various back branches. Hopefully that
will result in a few more green entries over the new few days. While
I was looking, I noticed several machines that seem to be failing
because of local
Pete St. Onge [EMAIL PROTECTED] writes:
Perhaps this will help in the diagnosis of why REL7_2_STABLE fails on
arbor (aka caribou). Please let me know if there is anything I can try
on this side, or if there is any other info you could use.
[EMAIL PROTECTED]:~$ flex -V
flex 2.5.31
Ah. PG
On Sun, Mar 06, 2005 at 21:12:03 -0800,
Josh Berkus josh@agliodbs.com wrote:
Also, I think you should be recording the compile-time switches used on each
machine and indexing them indivdually. I'd hate to find out that, for
example, we'd broken --with-odbc and didn't know it because
Andrew,
or 2.6.x ... in fact it's almost impossible to tell what might be
installed on a Gentoo system, or how it was compiled. So I'm really not
sure how we should treat such systems.
Distribution, General OS, Kernel Version, Other Info
e.g.
SuSELinux 2.6.8-7 64-Bit
MS
Now that we've been running for a while there are a few buildfarm issues
that I need to address.
First, do we keep the right data about the members? Essentially, we
keep: operating_system, os_version, compiler, compiler_version,
architecture. For Linux, we genarlly ask for the
On Friday 04 March 2005 10:11, Andrew Dunstan wrote:
Now that we've been running for a while there are a few buildfarm issues
that I need to address.
First, do we keep the right data about the members? Essentially, we
keep: operating_system, os_version, compiler, compiler_version,
Darcy Buskermolen wrote:
On Friday 04 March 2005 10:11, Andrew Dunstan wrote:
Now that we've been running for a while there are a few buildfarm issues
that I need to address.
First, do we keep the right data about the members? Essentially, we
keep: operating_system, os_version, compiler,
@postgresql.org
Sent: Fri, 04 Mar 2005 14:28:09 -0500
Subject: Re: [HACKERS] buildfarm issues
Darcy Buskermolen wrote:
On Friday 04 March 2005 10:11, Andrew Dunstan wrote:
Now that we've been running for a while there are a few buildfarm issues
that I need to address.
First, do we
Andrew Dunstan [EMAIL PROTECTED] writes:
Also, I have no idea how portable cc -v is.
Not at all.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
28 matches
Mail list logo
