Thread: Buildfarm failure on ecpg/test/pgtypeslib
Platypus just started failing... http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2010:05:01 Rest of the farm is looking pretty green, though, so I'm not sure what to make of it... but http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2009:05:01 is the first run it failed on, and several files changed in ecpg/test: Files changed this run pgsql/src/interfaces/ecpg/ChangeLog 1.320 pgsql/src/interfaces/ecpg/include/pgtypes_numeric.h 1.16 pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.c 1.2 pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.stdout 1.2 pgsql/src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc 1.2 pgsql/src/interfaces/ecpg/pgtypeslib/numeric.c 1.29 Also, it looks like "Files changed since last sucess" maybe isn't working right? Or does it intentionally exclude files already listed in "changed since last run"? -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim C. Nasby wrote: > Platypus just started failing... > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2010:05:01 > > Rest of the farm is looking pretty green, though, so I'm not sure what > to make of it... but > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2009:05:01 > is the first run it failed on, and several files changed in ecpg/test: > > Files changed this run > > pgsql/src/interfaces/ecpg/ChangeLog 1.320 > pgsql/src/interfaces/ecpg/include/pgtypes_numeric.h 1.16 > pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.c 1.2 > pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.stdout 1.2 > pgsql/src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc 1.2 > pgsql/src/interfaces/ecpg/pgtypeslib/numeric.c 1.29 > > Also, it looks like "Files changed since last sucess" maybe isn't > working right? Or does it intentionally exclude files already listed in > "changed since last run"? > Jim, can you upgrade your version of the script to the latest in CVS? http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/~checkout~/pgbuildfarm/client-code/run_build.pl?rev=1.64&content-type=text/plain It has a feature that blows away the ccache directory on failure, so that we don't have a failure that might be caused by ccache persisting. After that, remove the actual cache.( I notice that you are using ccache but don't seem to have a cache directory set - that can be a problem, too. It's best to have a cache per branch) Alternatively, just turn off use of ccache in your config file - probably commenting out this line would suffice: 'CC' => 'ccache gcc -O3 -pipe' And see if that fixes the problem. cheers andrew
On Wed, Aug 09, 2006 at 12:17:44PM -0400, Andrew Dunstan wrote: > Jim C. Nasby wrote: > >Platypus just started failing... > >http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2010:05:01 > > > >Rest of the farm is looking pretty green, though, so I'm not sure what > >to make of it... but > >http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2009:05:01 > >is the first run it failed on, and several files changed in ecpg/test: > > > >Files changed this run > > > >pgsql/src/interfaces/ecpg/ChangeLog 1.320 > >pgsql/src/interfaces/ecpg/include/pgtypes_numeric.h 1.16 > >pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.c 1.2 > >pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.stdout 1.2 > >pgsql/src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc 1.2 > >pgsql/src/interfaces/ecpg/pgtypeslib/numeric.c 1.29 > > > >Also, it looks like "Files changed since last sucess" maybe isn't > >working right? Or does it intentionally exclude files already listed in > >"changed since last run"? > > > > Jim, can you upgrade your version of the script to the latest in CVS? > > http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/~checkout~/pgbuildfarm/client-code/run_build.pl?rev=1.64&content-type=text/plain > > It has a feature that blows away the ccache directory on failure, so > that we don't have a failure that might be caused by ccache persisting. Doesn't seem to be working; the cache still had data after http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2019:59:17. > After that, remove the actual cache.( I notice that you are using ccache > but don't seem to have a cache directory set - that can be a problem, > too. It's best to have a cache per branch) That seems kinda bunk, since ccache is normally used in a system-wide setting. > Alternatively, just turn off use of ccache in your config file - > probably commenting out this line would suffice: > > 'CC' => 'ccache gcc -O3 -pipe' > > > And see if that fixes the problem. Nope, no dice... -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim C. Nasby wrote: > On Wed, Aug 09, 2006 at 12:17:44PM -0400, Andrew Dunstan wrote: > >> Jim C. Nasby wrote: >> >>> Platypus just started failing... >>> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2010:05:01 >>> >>> Rest of the farm is looking pretty green, though, so I'm not sure what >>> to make of it... but >>> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2009:05:01 >>> is the first run it failed on, and several files changed in ecpg/test: >>> >>> Files changed this run >>> >>> pgsql/src/interfaces/ecpg/ChangeLog 1.320 >>> pgsql/src/interfaces/ecpg/include/pgtypes_numeric.h 1.16 >>> pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.c 1.2 >>> pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.stdout 1.2 >>> pgsql/src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc 1.2 >>> pgsql/src/interfaces/ecpg/pgtypeslib/numeric.c 1.29 >>> >>> Also, it looks like "Files changed since last sucess" maybe isn't >>> working right? Or does it intentionally exclude files already listed in >>> "changed since last run"? >>> >>> >> Jim, can you upgrade your version of the script to the latest in CVS? >> >> http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/~checkout~/pgbuildfarm/client-code/run_build.pl?rev=1.64&content-type=text/plain >> >> It has a feature that blows away the ccache directory on failure, so >> that we don't have a failure that might be caused by ccache persisting. >> > > Doesn't seem to be working; the cache still had data after > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2019:59:17. > *ahem* you loaded 1.62 (the latest release), not 1.64 (cvs tip) like I asked. > >> After that, remove the actual cache.( I notice that you are using ccache >> but don't seem to have a cache directory set - that can be a problem, >> too. It's best to have a cache per branch) >> > > That seems kinda bunk, since ccache is normally used in a system-wide > setting. > Not on my boxes! ;-) ccache is only used if explicitly invoked in my world. >> Alternatively, just turn off use of ccache in your config file - >> probably commenting out this line would suffice: >> >> 'CC' => 'ccache gcc -O3 -pipe' >> >> >> And see if that fixes the problem. >> > > Nope, no dice... > At any rate, do please try to blow the cache away manually and rerun. btw, your config file also looks slightly out of date - a modern one will set up a per branch cache, which is both safer and more effective. cheers andrew
> Jim C. Nasby wrote: >> Platypus just started failing... >> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2010:05:01 gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing-g -I./../../include -I../../../../../src/interfaces/libpq -I../../include -I../../../../../src/include-L../../../../../src/port -L/usr/local/lib -Wl,-R'/home/buildfarm/buildfarm/HEAD/inst/lib' -L../../ecpglib-L../../pgtypeslib -L../../../libpq num_test2.c -lpgport -lintl -lssl -lcrypto -lz -lreadline -lcrypt -lm -lpgtypes -lecpg -lpq -o num_test2 /tmp/buildfarm/ccwtFkAf.o(.text+0x259): In function `main': /home/buildfarm/buildfarm/HEAD/pgsql.67800/src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc:102: undefined reference to`PGTYPESdecimal_new' /tmp/buildfarm/ccwtFkAf.o(.text+0x292):/home/buildfarm/buildfarm/HEAD/pgsql.67800/src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc:118: undefinedreference to `PGTYPESdecimal_free' gmake[5]: *** [num_test2] Error 1 I note that both those functions exist in ecpg's pgtypeslib in HEAD but not in 8.1. I'm betting you have an older pgtypeslib.so in /usr/local/lib and that the poorly-chosen order of -L flags in the above command is the problem. Basically the bug here is that src/interfaces/ecpg/test/Makefile.regress does override LDFLAGS += -L../../ecpglib -L../../pgtypeslib -L../../../libpq which is guaranteed to create the wrong ordering of -L switches compared to anything coming from "configure --with-libraries". We need all the -L switches for inside-the-build-tree directories to come before all the ones for other places. pg_xs.mk does this by the simple expedient of including PG_LIBS before LDFLAGS on the link command line; Makefile.shlib has a more complex approach involving surgery on LDFLAGS itself; but one way or the other you need to be careful. regards, tom lane
On Wed, Aug 09, 2006 at 05:11:37PM -0400, Tom Lane wrote: > > Jim C. Nasby wrote: > >> Platypus just started failing... > >> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2010:05:01 > > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing-g -I./../../include -I../../../../../src/interfaces/libpq -I../../include -I../../../../../src/include-L../../../../../src/port -L/usr/local/lib -Wl,-R'/home/buildfarm/buildfarm/HEAD/inst/lib' -L../../ecpglib-L../../pgtypeslib -L../../../libpq num_test2.c -lpgport -lintl -lssl -lcrypto -lz -lreadline -lcrypt -lm -lpgtypes -lecpg -lpq -o num_test2 > /tmp/buildfarm/ccwtFkAf.o(.text+0x259): In function `main': > /home/buildfarm/buildfarm/HEAD/pgsql.67800/src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc:102: undefined reference to`PGTYPESdecimal_new' > /tmp/buildfarm/ccwtFkAf.o(.text+0x292):/home/buildfarm/buildfarm/HEAD/pgsql.67800/src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc:118: undefinedreference to `PGTYPESdecimal_free' > gmake[5]: *** [num_test2] Error 1 > > I note that both those functions exist in ecpg's pgtypeslib in HEAD > but not in 8.1. I'm betting you have an older pgtypeslib.so in > /usr/local/lib and that the poorly-chosen order of -L flags in the > above command is the problem. > > Basically the bug here is that src/interfaces/ecpg/test/Makefile.regress > does > > override LDFLAGS += -L../../ecpglib -L../../pgtypeslib -L../../../libpq > > which is guaranteed to create the wrong ordering of -L switches compared > to anything coming from "configure --with-libraries". We need all the > -L switches for inside-the-build-tree directories to come before all the > ones for other places. pg_xs.mk does this by the simple expedient of > including PG_LIBS before LDFLAGS on the link command line; > Makefile.shlib has a more complex approach involving surgery on LDFLAGS > itself; but one way or the other you need to be careful. Makes sense, since the machine has an install of 8.1 out of FreeBSD ports. So... do we want something like override LDFLAGS := $(LDFLAGS_NO_L) -L../../ecpglib -L../../pgtypeslib -L../../../libpq ? -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> So... do we want something like
> override LDFLAGS := $(LDFLAGS_NO_L) -L../../ecpglib -L../../pgtypeslib
> -L../../../libpq
I suppose Michael and Joachim are in bed, so I'll try committing this.
If they don't like it they can fix it in the morning ...
regards, tom lane
On Wed, Aug 09, 2006 at 06:39:07PM -0400, Tom Lane wrote: > "Jim C. Nasby" <jnasby@pervasive.com> writes: > > So... do we want something like > > override LDFLAGS := $(LDFLAGS_NO_L) -L../../ecpglib -L../../pgtypeslib > > -L../../../libpq > > I suppose Michael and Joachim are in bed, so I'll try committing this. > If they don't like it they can fix it in the morning ... It just made it past contrib installcheck, so probably fixed. BTW, what time does the anonymous-cvs rsync normally finish? Right now my build starts at 5 after, but I suspect that's the worst possible time for it... -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> BTW, what time does the anonymous-cvs rsync normally finish? Right now
> my build starts at 5 after, but I suspect that's the worst possible time
> for it...
Marc recently said it starts at 19 after, so somewhere near half past is
probably the optimal time. (I'd suggest picking a random time near half
past, else all the buildfarm members will gang up on the server at once
...)
regards, tom lane
Tom Lane wrote: > "Jim C. Nasby" <jnasby@pervasive.com> writes: >> BTW, what time does the anonymous-cvs rsync normally finish? Right now >> my build starts at 5 after, but I suspect that's the worst possible time >> for it... > > Marc recently said it starts at 19 after, so somewhere near half past is > probably the optimal time. (I'd suggest picking a random time near half > past, else all the buildfarm members will gang up on the server at once > ...) > is this also true of the cvsup server? cheers andrew
andrew@dunslane.net wrote: > is this also true of the cvsup server? No, I think cvsup is served directly from the write-CVS. I've gotten patches via CVSup that were just committed. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Wed, Aug 09, 2006 at 06:39:07PM -0400, Tom Lane wrote: > I suppose Michael and Joachim are in bed, so I'll try committing this. > If they don't like it they can fix it in the morning ... Right we were. :-) Thanks Tom. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Oh, I didn't realize there was a CVSup server. I think it'd be good to promote that over CVS, as it's (supposedly) much easier on the hosting machine. Andrew, is there a way to get the buildfarm to use cvsup instead of cvs? Does the script just call cvs via the shell? On Aug 9, 2006, at 10:08 PM, Alvaro Herrera wrote: > andrew@dunslane.net wrote: > >> is this also true of the cvsup server? > > No, I think cvsup is served directly from the write-CVS. I've gotten > patches via CVSup that were just committed. > > -- > Alvaro Herrera http:// > www.CommandPrompt.com/ > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > > ---------------------------(end of > broadcast)--------------------------- > TIP 6: explain analyze is your friend > -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim Nasby wrote: > Oh, I didn't realize there was a CVSup server. I think it'd be good > to promote that over CVS, as it's (supposedly) much easier on the > hosting machine. > > Andrew, is there a way to get the buildfarm to use cvsup instead of > cvs? Does the script just call cvs via the shell? > You can call cvs directly against your csvup repo copy if it's on the same machine, or set up a pserver against the repo copy. The buildfarm howto at http://pgfoundry.org/docman/view.php/1000040/4/PGBuildFarm-HOWTO.txt has some extra details. Buildfarm just calls your cvs client. cheers andrew