On Fri, Jul 15, 2005 at 08:06:15PM -0500, Kris Jurka wrote:
> On Fri, 15 Jul 2005, Marko Kreen wrote:
>
> > [buildfarm machine dragonfly]
> >
> > On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
> > > Well the buildfarm machine kudu is actually the same machine just
> > > building
>
Luke Lonergan wrote:
> Bruce,
>
> On 7/15/05 9:59 PM, "Bruce Momjian" wrote:
>
> > Actually, mine returns ')' too for the last command. I didn't copy
> > that into the email. How about the top tests? Notice I get an error on
> > the first one without the backslash. Are you OK escaping '(' b
Marko Kreen writes:
> On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
>>> Well the buildfarm machine kudu is actually the same machine just building
>>> with the Sun compiler and it works fine. It links all of libz.a into
>>> libpgcrypto.so while gcc refuses to.
>
> I googled a bit
On Sat, 16 Jul 2005, Tom Lane wrote:
> Marko Kreen writes:
> > I googled a bit and found two suggestions:
> >
> > 1. http://curl.haxx.se/mail/lib-2002-01/0092.html
> > (Use -mimpure-text on linking line)
> >
> This sure seems like a crude band-aid rather than an actual solution.
> The bug as
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The attached (new) src/test/regress/expected/geometry_9.out, intended
> only for the 7.3 stable branch, allows a clean regression pass on my
> FC4 box. I called it that to avoid conflicts with other geometry_n files
> on later branches.
I'd like to
On Sat, 16 Jul 2005, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > The attached (new) src/test/regress/expected/geometry_9.out, intended
> > only for the 7.3 stable branch, allows a clean regression pass on my
> > FC4 box. I called it that to avoid conflicts with other geom
Kris Jurka <[EMAIL PROTECTED]> writes:
> On Sat, 16 Jul 2005, Tom Lane wrote:
>> I'd like to have a more principled approach to fixing the back branches
>> than "we'll do whatever it takes to have a clean buildfarm board on the
>> set of machines that happen to have volunteered to run buildfarm on
Kris Jurka <[EMAIL PROTECTED]> writes:
> On Sat, 16 Jul 2005, Tom Lane wrote:
>> This sure seems like a crude band-aid rather than an actual solution.
>> The bug as I see it is that gcc is choosing to link libz.a rather than
>> libz.so --- why is that happening?
> The link line says -L/usr/local/l
Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> The attached (new) src/test/regress/expected/geometry_9.out, intended
>> only for the 7.3 stable branch, allows a clean regression pass on my
>> FC4 box. I called it that to avoid conflicts with other geometry_n
>> files on later bran
On Sat, 16 Jul 2005, Tom Lane wrote:
> Kris Jurka <[EMAIL PROTECTED]> writes:
>
> > The link line says -L/usr/local/lib -lz and libz.a is in /usr/local/lib
> > while libz.so is in /usr/lib.
>
> Well, that is a flat-out configuration error on the local sysadmin's
> part. I can't think of any
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Note that because of the way the buildfarm script works, this failure was
> masking the seg errno bogosity. Maybe I should reverse the test order to
> make contrib before running and regression tests.
Seems like that'd just mask a different set of fai
Kris Jurka <[EMAIL PROTECTED]> writes:
> consider what would happen if the shared library didn't exist at all and
> only a static version were available. Until this recent batch of pgcrypto
> changes everything built fine.
Well, the right answer to that really is that pgcrypto ought not try to
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
Note that because of the way the buildfarm script works, this failure was
masking the seg errno bogosity. Maybe I should reverse the test order to
make contrib before running and regression tests.
Seems like that'd just ma
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Seems like that'd just mask a different set of failures.
> Yeah. I think I'd be more concerned by core regression failures than
> contrib build failures - especially as they are often likely to have
> more far reaching consequences.
Tom Lane wrote:
Yeah. I think I'd be more concerned by core regression failures than
contrib build failures - especially as they are often likely to have
more far reaching consequences.
Agreed. I guess that the order of importance of the pieces you have is
build main (this in
I am close to completing work on this patch and will post an updated
version in a few days.
---
Michael Glaesemann wrote:
> Please find attached a patch which adds a day field to the interval
> struct so that we can treat
16 matches
Mail list logo
