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
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
--
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) th
"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 in
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,
(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. -I../../.
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
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 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 t
"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
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
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 che
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
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 r
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 bu
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 proble
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" entri
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 i
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
"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
On Sun, Mar 06, 2005 at 21:12:03 -0800,
Josh Berkus 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 nobody in the
>
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
M
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
opment
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
>
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: . For Linux, we genarlly ask for the
Distribut
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: architecture>. For Linux, we genarlly ask for the
> Distribution
26 matches
Mail list logo
