On 09/10/2012 02:44 PM, Tom Lane wrote:
I wrote:
And the answer is ... it's a gmake bug. Apparently introduced in 3.82.
http://savannah.gnu.org/bugs/?30653
https://bugzilla.redhat.com/show_bug.cgi?id=835424
So I think .NOTPARALLEL is just masking the true problem, but
nonetheless it's a proble
I wrote:
> And the answer is ... it's a gmake bug. Apparently introduced in 3.82.
> http://savannah.gnu.org/bugs/?30653
> https://bugzilla.redhat.com/show_bug.cgi?id=835424
> So I think .NOTPARALLEL is just masking the true problem, but
> nonetheless it's a problem. And given that the bug report
On 09/09/2012 05:00 PM, Tom Lane wrote:
Peter Eisentraut writes:
But then the answer could be, if you want to use parallel make, use a
version that's not broken.
That's not a terribly practical answer for people who use the "make"
supplied by their OS vendor, which is approximately 99.9% of p
Peter Eisentraut writes:
> But then the answer could be, if you want to use parallel make, use a
> version that's not broken.
That's not a terribly practical answer for people who use the "make"
supplied by their OS vendor, which is approximately 99.9% of people.
It's even less practical for pack
Peter Eisentraut writes:
> On Sun, 2012-09-09 at 14:05 -0400, Tom Lane wrote:
>> So I think .NOTPARALLEL is just masking the true problem, but
>> nonetheless it's a problem. And given that the bug report on savannah
>> has been ignored for two years, we should not hold our breath for a fix
>> to
On Sun, 2012-09-09 at 14:57 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 09/09/2012 02:05 PM, Tom Lane wrote:
> >> And the answer is ... it's a gmake bug.
>
> > Thanks for pursuing this. Whether or not it masks the underlying
> > problem, it's still something we should do, no? In fact,
On Sun, 2012-09-09 at 14:05 -0400, Tom Lane wrote:
> And the answer is ... it's a gmake bug. Apparently introduced in 3.82.
>
> http://savannah.gnu.org/bugs/?30653
> https://bugzilla.redhat.com/show_bug.cgi?id=835424
>
> So I think .NOTPARALLEL is just masking the true problem, but
> nonetheless
Andrew Dunstan writes:
> On 09/09/2012 02:05 PM, Tom Lane wrote:
>> And the answer is ... it's a gmake bug.
> Thanks for pursuing this. Whether or not it masks the underlying
> problem, it's still something we should do, no? In fact, it seems to me
> like this makes it even less worth trying to
On 09/09/2012 02:05 PM, Tom Lane wrote:
And the answer is ... it's a gmake bug. Apparently introduced in 3.82.
http://savannah.gnu.org/bugs/?30653
https://bugzilla.redhat.com/show_bug.cgi?id=835424
So I think .NOTPARALLEL is just masking the true problem, but
nonetheless it's a problem. And
And the answer is ... it's a gmake bug. Apparently introduced in 3.82.
http://savannah.gnu.org/bugs/?30653
https://bugzilla.redhat.com/show_bug.cgi?id=835424
So I think .NOTPARALLEL is just masking the true problem, but
nonetheless it's a problem. And given that the bug report on savannah
has b
Andrew Dunstan writes:
> On 09/09/2012 11:31 AM, Tom Lane wrote:
>> I assume we need this for all active branches, if the buildfarm is
>> going to be stressing it?
> I can restrict it to only modern branches. Didn't we supposedly improve
> support for this during the 9.1 cycle? That seems like a
On 09/09/2012 11:31 AM, Tom Lane wrote:
Yeah. I am going to add a config parameter to the buildfarm to allow
parallelism for the "make" and "make contrib" stages, but I'm not going
to release it until this is fixed.
Well, why don't we stick .NOTPARALLEL in there for the moment, and then
if Pete
Andrew Dunstan writes:
> On 09/09/2012 03:29 AM, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> On Sat, 2012-09-08 at 19:54 -0400, Tom Lane wrote:
Anyway, what I notice is that I get different types of failures, but
they are all under ecpg/. What I think we need to do is insert
.
On 09/09/2012 03:29 AM, Tom Lane wrote:
Peter Eisentraut writes:
On Sat, 2012-09-08 at 19:54 -0400, Tom Lane wrote:
Anyway, what I notice is that I get different types of failures, but
they are all under ecpg/. What I think we need to do is insert
.NOTPARALLEL in ecpg/Makefile,
I'd hate tha
Peter Eisentraut writes:
> On Sat, 2012-09-08 at 19:54 -0400, Tom Lane wrote:
>> Anyway, what I notice is that I get different types of failures, but
>> they are all under ecpg/. What I think we need to do is insert
>> .NOTPARALLEL in ecpg/Makefile,
> I'd hate that, because the ecpg build is one
On Sat, 2012-09-08 at 19:54 -0400, Tom Lane wrote:
> Anyway, what I notice is that I get different types of failures, but
> they are all under ecpg/. What I think we need to do is insert
> .NOTPARALLEL in ecpg/Makefile,
I'd hate that, because the ecpg build is one of the slowest parts of the
buil
On 09/08/2012 07:54 PM, Tom Lane wrote:
Andrew Dunstan writes:
I have just repeated this on an absolutely fresh up to date F17 machine,
with no symlink stuff in play.
Steps to recreate:
CC="ccache gcc" ../postgres/configure --enable-depend --enable-debug
--enable-cassert --with-perl
Andrew Dunstan writes:
> I have just repeated this on an absolutely fresh up to date F17 machine,
> with no symlink stuff in play.
> Steps to recreate:
> CC="ccache gcc" ../postgres/configure --enable-depend --enable-debug
> --enable-cassert --with-perl --with-python --with-tcl --with-l
On 09/08/2012 04:52 PM, Andrew Dunstan wrote:
On 09/08/2012 04:46 PM, Tom Lane wrote:
Andrew Dunstan writes:
Scratch that theory, that was just a transient. If anything it looks
like it is related to system load. When almost nothing was running on
the machine it worked fine. When I started u
On 09/08/2012 04:46 PM, Tom Lane wrote:
Andrew Dunstan writes:
Scratch that theory, that was just a transient. If anything it looks
like it is related to system load. When almost nothing was running on
the machine it worked fine. When I started up a Browser and an MUA the
problem occurred. Thi
On 09/08/2012 04:54 PM, Tom Lane wrote:
Andrew Dunstan writes:
And it's the stock Fedora build of make.
Which Fedora branch exactly?
The package version I was trying to reproduce with here is
make-3.82-8.fc16.x86_64.
Same:
$ rpm -q make
make-3.82-8.fc16.x86_64
cheers
andrew
--
Andrew Dunstan writes:
> And it's the stock Fedora build of make.
Which Fedora branch exactly?
The package version I was trying to reproduce with here is
make-3.82-8.fc16.x86_64.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
Andrew Dunstan writes:
> Scratch that theory, that was just a transient. If anything it looks
> like it is related to system load. When almost nothing was running on
> the machine it worked fine. When I started up a Browser and an MUA the
> problem occurred. This VM has 4 CPUs and 4Gb of memory
On 09/08/2012 11:06 AM, Tom Lane wrote:
Andrew Dunstan writes:
This seems totally stupid, but it happens when the path to the current
directory includes a cross-device symlink. If I cd following the link,
then this effect doesn't happen. Weird.
Huh. So maybe a gmake bug, or maybe there's som
Andrew Dunstan writes:
> This seems totally stupid, but it happens when the path to the current
> directory includes a cross-device symlink. If I cd following the link,
> then this effect doesn't happen. Weird.
Huh. So maybe a gmake bug, or maybe there's something wrong with our
make rules for
On 09/07/2012 10:46 PM, Andrew Dunstan wrote:
On 09/07/2012 09:55 PM, Andrew Dunstan wrote:
On 09/07/2012 08:43 PM, Tom Lane wrote:
Andrew Dunstan writes:
Well, it looks like it's always failing on ecpg, with preproc.h not
being made in the right order. Here is the last bit of a make log
s
On 09/07/2012 09:55 PM, Andrew Dunstan wrote:
On 09/07/2012 08:43 PM, Tom Lane wrote:
Andrew Dunstan writes:
Well, it looks like it's always failing on ecpg, with preproc.h not
being made in the right order. Here is the last bit of a make log
starting from when it starts on ecpg. This is pre
On 09/07/2012 08:43 PM, Tom Lane wrote:
Andrew Dunstan writes:
Well, it looks like it's always failing on ecpg, with preproc.h not
being made in the right order. Here is the last bit of a make log
starting from when it starts on ecpg. This is pretty repeatable.
Hmph. I can't reproduce it at
Andrew Dunstan writes:
> Well, it looks like it's always failing on ecpg, with preproc.h not
> being made in the right order. Here is the last bit of a make log
> starting from when it starts on ecpg. This is pretty repeatable.
Hmph. I can't reproduce it at all on my Fedora 16 box. What versi
On 09/04/2012 08:51 PM, Andrew Dunstan wrote:
On 09/04/2012 08:37 PM, Tom Lane wrote:
Andrew Dunstan writes:
Frankly, I have had enough failures of parallel make that I think doing
this would generate a significant number of non-repeatable failures (I
had one just the other day that took thr
On 09/04/2012 08:37 PM, Tom Lane wrote:
Andrew Dunstan writes:
Frankly, I have had enough failures of parallel make that I think doing
this would generate a significant number of non-repeatable failures (I
had one just the other day that took three invocations of make to get
right). So I'm not
Andrew Dunstan writes:
> Frankly, I have had enough failures of parallel make that I think doing
> this would generate a significant number of non-repeatable failures (I
> had one just the other day that took three invocations of make to get
> right). So I'm not sure doing this would advance us
On Sep 4, 2012 6:06 PM, "Andrew Dunstan" wrote:
>
>
> Frankly, I have had enough failures of parallel make that I think doing
this would generate a significant number of non-repeatable failures (I had
one just the other day that took three invocations of make to get right).
So I'm not sure doing t
On 09/04/2012 05:49 PM, Peter Eisentraut wrote:
On 9/1/12 12:12 PM, Robert Creager wrote:
I change the build-farm.conf file to have the following make line:
make => 'make -j 8', # or gmake if required. can include path if
necessary.
2 pass, 4 fail. Is this a build configuration you want
Excerpts from Peter Eisentraut's message of mar sep 04 18:49:46 -0300 2012:
> On 9/1/12 12:12 PM, Robert Creager wrote:
> >
> > I change the build-farm.conf file to have the following make line:
> >
> > make => 'make -j 8', # or gmake if required. can include path if
> > necessary.
> >
> > 2
On 9/1/12 12:12 PM, Robert Creager wrote:
>
> I change the build-farm.conf file to have the following make line:
>
> make => 'make -j 8', # or gmake if required. can include path if
> necessary.
>
> 2 pass, 4 fail. Is this a build configuration you want to pursue?
Sure that would be useful
Excerpts from Robert Creager's message of sáb sep 01 12:12:51 -0400 2012:
>
> I change the build-farm.conf file to have the following make line:
>
> make => 'make -j 8', # or gmake if required. can include path if
> necessary.
>
> 2 pass, 4 fail. Is this a build configuration you want to p
I change the build-farm.conf file to have the following make line:
make => 'make -j 8', # or gmake if required. can include path if necessary.
2 pass, 4 fail. Is this a build configuration you want to pursue? I can
either create a new machine, or change one of my existing machines. Makes
On 04/20/2011 09:54 AM, Kevin Grittner wrote:
Andrew Dunstan wrote:
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2011-04-20%2010%3A17%3A02&stg=isolation-check
On a cursory scan, that looks like a successful run of the right
test suite. Was there anything in particular I
Andrew Dunstan wrote:
>
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2011-04-20%2010%3A17%3A02&stg=isolation-check
On a cursory scan, that looks like a successful run of the right
test suite. Was there anything in particular I should be checking
there?
> I'll include thi
On 04/19/2011 11:53 AM, Kevin Grittner wrote:
Andrew Dunstan wrote:
I think the best thing might be to add a new step which runs the
isolation check or installcheck. It would only need a small amount
of perl code adde3d to the client to accomplish, and nothing on
the server side.
Since I'm
Excerpts from Kevin Grittner's message of mar abr 19 12:53:07 -0300 2011:
> Since I'm unskilled at perl and have never looked at the buildfarm
> scripts, could someone with the appropriate skills and knowledge add
> this for me? In bash, when I'm in the normal base directory for a
> build from so
Andrew Dunstan wrote:
> I think the best thing might be to add a new step which runs the
> isolation check or installcheck. It would only need a small amount
> of perl code adde3d to the client to accomplish, and nothing on
> the server side.
Since I'm unskilled at perl and have never looked
On 04/19/2011 11:16 AM, Kevin Grittner wrote:
I'm not sure what the right thing is to do here.
Heikki added a new testing methodology under src/test/isolation
which allows intermingling a series of statements on multiple
connections in desired permutations. (By default each test defined
for i
I'm not sure what the right thing is to do here.
Heikki added a new testing methodology under src/test/isolation
which allows intermingling a series of statements on multiple
connections in desired permutations. (By default each test defined
for it runs all permutations of how the statement sequ
It took a little longer than expected, due to a slightly clagged network
between the old and new servers, but the database migration is complete
and the server is back up and running.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Greg Sabino Mullane wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> > I mentioned earlier that buildfarm member jaguar (that's the one that
> > builds with CLOBBER_CACHE_ALWAYS) was showing suspicious intermittent
> > failures.
>
> Tom, this brings up another question: is
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> I mentioned earlier that buildfarm member jaguar (that's the one that
> builds with CLOBBER_CACHE_ALWAYS) was showing suspicious intermittent
> failures.
Tom, this brings up another question: is there any flag, environment,
forced resource li
On Tue, 2 Oct 2007, Gregory Stark wrote:
> (we don't seem to have a recent icc ia32 build farm member).
Sorry about that, my buildfarm member (mongoose) is down with hardware
problems, and probably will be for the forseeable future. For some
reason, it suddenly decided to stop recognizing its RA
Gregory Stark <[EMAIL PROTECTED]> writes:
> And given the consistency and the fact that the other icc machines
> didn't show the same problems it sounds like it's something about that
> machine, not a software problem.
Well, we haven't *got* any other icc-on-ia64 machines AFAICS, so it
could easil
Gregory Stark <[EMAIL PROTECTED]> writes:
> dugong (icc on ia64) has been failing the contrib installcheck consistently
> since 6 days ago with errors like:
> ERROR: could not fsync segment 0 of relation 1663/40960/41403: No such file
> or directory
Yeah, I already asked Sergey about this but I
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> dugong (icc on ia64) has been failing the contrib installcheck consistently
> since 6 days ago with errors like:
>
> ERROR: could not fsync segment 0 of relation 1663/40960/41403: No such file
> or directory
>
> I checked a cvs diff between the two t
dugong (icc on ia64) has been failing the contrib installcheck consistently
since 6 days ago with errors like:
ERROR: could not fsync segment 0 of relation 1663/40960/41403: No such file or
directory
I checked a cvs diff between the two timestamps and that's precisely when the
self-adjusting b
Alvaro Herrera wrote:
How do you create the copy of the repo to build? One idea would be to
explicitely skip files that appear on .cvsignore (and maybe croak about
them).
We are supposed to croak - see
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbuildfarm/client-code/run_build.pl.d
Andrew Dunstan wrote:
>
>
> Michael Meskes wrote:
>> The backend has:
>>
>> $(srcdir)/gram.c: $(srcdir)/parse.h ;
>>
>> $(srcdir)/parse.h: gram.y
>>
>> So except for the different naming it's the same. However, we haven't
>> had that problem with the backend so far, or did we?
>>
>> What do I fail
Michael Meskes wrote:
The backend has:
$(srcdir)/gram.c: $(srcdir)/parse.h ;
$(srcdir)/parse.h: gram.y
So except for the different naming it's the same. However, we haven't
had that problem with the backend so far, or did we?
What do I fail to see?
We have had problems in the past. If
On Thu, Aug 16, 2007 at 08:24:14AM -0700, Darcy Buskermolen wrote:
> This is something I do not recall doing, however it's possible. though this
> does make me ask why are the build dependencies in the Makefile are not
> properly setup to tell that the .y needs to be rebuilt (which I would assum
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Darcy Buskermolen wrote:
This sort of thing is usually a
symptom of somebody having run a build in the repo directly, a thing
that buildfarm owners have been repeatedly advised not to do.
This is something I do not recall doing
Andrew Dunstan wrote:
>
>
> Darcy Buskermolen wrote:
>>> This sort of thing is usually a
>>> symptom of somebody having run a build in the repo directly, a thing
>>> that buildfarm owners have been repeatedly advised not to do.
>>>
>>
>> This is something I do not recall doing, however it's po
On Thursday 16 August 2007 04:29:41 Andrew Dunstan wrote:
> Michael Meskes wrote:
> > Hi,
> >
> > we have two build farm members failing to make since I committed teh
> > ecpg changes: echidna and herring.
> >
> > It looks like they are still using an old preproc.c although they
> > checked out the
Darcy Buskermolen wrote:
This sort of thing is usually a
symptom of somebody having run a build in the repo directly, a thing
that buildfarm owners have been repeatedly advised not to do.
This is something I do not recall doing, however it's possible. though this
does make me ask why a
Michael Meskes wrote:
Hi,
we have two build farm members failing to make since I committed teh
ecpg changes: echidna and herring.
It looks like they are still using an old preproc.c although they
checked out the new preproc.y. I have no idea how this is supposed to
work so could someone pleas
Hi,
we have two build farm members failing to make since I committed teh
ecpg changes: echidna and herring.
It looks like they are still using an old preproc.c although they
checked out the new preproc.y. I have no idea how this is supposed to
work so could someone please enlighten me?
Michael
-
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Mon, Oct 03, 2005 at 05:19:43PM +0200, Gaetano Mendola wrote:
>>> What version of Python have you got on that thing? It seems to be
>>> emitting still another spelling of the encoding error message :-(
>>
>> $ python -V
>> Python 2.2.3
> The attached
On Mon, Oct 03, 2005 at 05:19:43PM +0200, Gaetano Mendola wrote:
> Tom Lane wrote:
> > Gaetano Mendola <[EMAIL PROTECTED]> writes:
> >> I'm the administrator of that machine and PLCheck is failing.
> >> Is there anything I can do to fix it ?
> >
> > What version of Python have you got on that thin
Tom Lane wrote:
> Gaetano Mendola <[EMAIL PROTECTED]> writes:
>> I'm the administrator of that machine and PLCheck is failing.
>> Is there anything I can do to fix it ?
>
> What version of Python have you got on that thing? It seems to be
> emitting still another spelling of the encoding error me
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> I'm the administrator of that machine and PLCheck is failing.
> Is there anything I can do to fix it ?
What version of Python have you got on that thing? It seems to be
emitting still another spelling of the encoding error message :-(
Hi all,
I'm the administrator of that machine and PLCheck is failing.
Is there anything I can do to fix it ?
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 6: explain analyze is your friend
Dave Cramer <[EMAIL PROTECTED]> writes:
> It appears to be getting the wrong address for tsearch()
I applied a patch for that earlier today. It seems that in OS X 10.4
the compiler generates a function with the same name as the shared
library, ie tsearch() for libtsearch ... and it doesn't tell y
It appears to be getting the wrong address for tsearch()
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x011b
0x9009a7c8 in tsearch ()
However if I set a break point for tsearch, I get
br tsearch
Breakpoint 5 at 0xe08c64: file t
Just a thought. You could also run the regression test automatically after a
successful build?
"Andrew Dunstan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
>
> Jean-Michel POURE wrote:
>
> >Le Vendredi 21 Novembre 2003 19:47, Tom Lane a écrit :
> >
> >
> >>I think the main value
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
directories for most of the machines, meaning you can CVS update once
and telnet in to compile for each platform.
As Peter pointed out, these machin
Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
> >directories for most of the machines, meaning you can CVS update once
> >and telnet in to compile for each platform.
> >
> >
> >
>
> As Peter pointed out, these machines are fi
Bruce Momjian wrote:
FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
directories for most of the machines, meaning you can CVS update once
and telnet in to compile for each platform.
As Peter pointed out, these machines are firewalled. But presumably one could upload a snaps
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
> > directories for most of the machines, meaning you can CVS update once
> > and telnet in to compile for each platform.
>
> Except that you can't open connections to the out
Bruce Momjian writes:
> FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
> directories for most of the machines, meaning you can CVS update once
> and telnet in to compile for each platform.
Except that you can't open connections to the outside from these machines.
--
Peter E
Would it be reasonable to promote users testing daily snapshots with
popular applications? I'm guessing there's not many applications that
have automated test frameworks, but any that do would theoretically
provide another good test of PGSQL changes.
May I quote Joel on Software here?
http://www.j
On Wed, Nov 19, 2003 at 04:34:27PM +0100, Peter Eisentraut wrote:
> Hence the open-source community approach. Closed-source development teams
> can do all the above, with great effort. But by throwing out the code and
> have real people test them on real systems with real applications, you can
>
FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
directories for most of the machines, meaning you can CVS update once
and telnet in to compile for each platform.
---
Andrew Dunstan wrote:
> Tom Lane wrote
Le Lundi 24 Novembre 2003 16:38, Andreas Pflug a Ãcrit :
> And a tiny correction: The farm member for win32 is my machine, and it's
> operated manually :-)
Some GNU/Linux farm animals are living in my garage running on very old 50
euros machines ... Ancient farming :-)
By the way, we would love
Andrew Dunstan wrote:
Jean-Michel POURE wrote:
Le Vendredi 21 Novembre 2003 19:47, Tom Lane a Ãcrit :
I think the main value of a build farm is that we'd get nearly
immediate
feedback about the majority of simple porting problems. Your previous
arguments that it wouldn't smoke everything o
Jean-Michel POURE wrote:
Le Vendredi 21 Novembre 2003 19:47, Tom Lane a Ãcrit :
I think the main value of a build farm is that we'd get nearly immediate
feedback about the majority of simple porting problems. Your previous
arguments that it wouldn't smoke everything out are certainly valid -
Le Vendredi 21 Novembre 2003 19:47, Tom Lane a Ãcrit :
> I think the main value of a build farm is that we'd get nearly immediate
> feedback about the majority of simple porting problems. ÂYour previous
> arguments that it wouldn't smoke everything out are certainly valid ---
> but we wouldn't aban
Tom Lane wrote:
I think the main value of a build farm is that we'd get nearly immediate
feedback about the majority of simple porting problems. Your previous
arguments that it wouldn't smoke everything out are certainly valid ---
but we wouldn't abandon the regression tests just because they don
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Andrew Dunstan writes:
>> Maybe it wouldn't be of great value to PostgreSQL. And maybe it would. I
>> have an open mind about it. I don't think incompleteness is an argument
>> against it, though.
> If you want to do it, by all means go for it. I'm s
Peter Eisentraut wrote:
Andrew Dunstan writes:
Essentially what I have is something like this pseudocode:
cvs update
Be sure check past branches as well.
check if there really was an update and if not exit
OK.
configure; get config.log
Ideally, you'd try all possible
Andrew Dunstan writes:
> Essentially what I have is something like this pseudocode:
>
> cvs update
Be sure check past branches as well.
> check if there really was an update and if not exit
OK.
> configure; get config.log
Ideally, you'd try all possible option combinations for configure
Peter Eisentraut wrote:
The Samba build daemon suite is pretty good. We have a couple of those
hosts in our office in fact. (I think they're building PostgreSQL
regularly as well.) A tip: You might find that adopting the source code
of the Samba suite to PostgreSQL is harder than writing a new
Andrew Dunstan writes:
> Maybe it wouldn't be of great value to PostgreSQL. And maybe it would. I
> have an open mind about it. I don't think incompleteness is an argument
> against it, though.
If you want to do it, by all means go for it. I'm sure it would give
everyone a fuzzy feeling to see t
Peter Eisentraut wrote:
Andrew Dunstan writes:
"Useful" is probably subjective. That list would at least be a good
place to start, though. What combinations of variables do you think we
would need?
First of all, I don't necessarily think that a large list of CPU/operation
system combinati
Andrew Dunstan writes:
> "Useful" is probably subjective. That list would at least be a good
> place to start, though. What combinations of variables do you think we
> would need?
First of all, I don't necessarily think that a large list of CPU/operation
system combinations is going to help much.
Peter Eisentraut wrote:
Andrew Dunstan writes:
If there's general interest I'll try to cook something up. (This kind of
stuff is right up my alley). I'd prefer some automated display of
results, though. A simple CGI script should be all that's required for
that.
The real problem will be
Andrew Dunstan writes:
> If there's general interest I'll try to cook something up. (This kind of
> stuff is right up my alley). I'd prefer some automated display of
> results, though. A simple CGI script should be all that's required for
> that.
The real problem will be to find enough machines s
Robert Treat wrote:
> > >Check the archives on this, as its been hashed out already once at least
> > >... I think the big issue/problem is that nobody seems able (or wants) to
> > >come up with a script that could be setup in cron on machines to do this
> > >... something simple that would dump th
On Tue, 2003-11-18 at 14:36, Andrew Dunstan wrote:
> Marc G. Fournier wrote:
>
> >On Tue, 18 Nov 2003, Andrew Dunstan wrote:
> >
> >
> >
> >>Maybe some sort of automated distributed build farm would be a good
> >>idea. Check out http://build.samba.org/about.html to see how samba does
> >>it (muc
Marc G. Fournier wrote:
On Tue, 18 Nov 2003, Andrew Dunstan wrote:
Maybe some sort of automated distributed build farm would be a good
idea. Check out http://build.samba.org/about.html to see how samba does
it (much lighter than the Mozilla tinderbox approach).
We wouldn't need to be as intens
96 matches
Mail list logo
