Thread: So, why isn't *every* buildfarm member failing ecpg right now?
AFAICS, Peter's recent incomplete updating of error message wording should have broken every last man jack of 'em. And yet there's still some green to be seen. I think we are looking at problems in the ecpg test scaffolding. For instance, dragonfly claims a green build, but http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dragonfly&dt=2007-06-04%20043001&stg=ecpg-check shows this interesting trace: ============== running regression test queries ============== /export/home/pgfarm/gcc/HEAD/pgsql.28740/src/interfaces/ecpg/test/./tmp_check/install//export/home/pgfarm/gcc/HEAD/inst/bin/createuser -R-S -D -q regressuser1 /export/home/pgfarm/gcc/HEAD/pgsql.28740/src/interfaces/ecpg/test/./tmp_check/install//export/home/pgfarm/gcc/HEAD/inst/bin/createuser -R-S -D -q connectuser /export/home/pgfarm/gcc/HEAD/pgsql.28740/src/interfaces/ecpg/test/./tmp_check/install//export/home/pgfarm/gcc/HEAD/inst/bin/createuser -R-S -D -q connectdb testing connect/test1.pgc ... skipped testing connect/test2.pgc ... ./pg_regress: bad substitution make[1]: Leaving directory `/export/home/pgfarm/gcc/HEAD/pgsql.28740/src/interfaces/ecpg/test' which says that (a) we have a scripting bug, and (b) some other layer is failing to notice the failure. Which is two separate bugs by my count. regards, tom lane
Tom Lane wrote: > AFAICS, Peter's recent incomplete updating of error message wording > should have broken every last man jack of 'em. And yet there's still > some green to be seen. I think we are looking at problems in the ecpg > test scaffolding. Yes. The buildfarm script uses the same logic as other tests: my $ecpg_dir = "$pgsql/src/interfaces/ecpg";my @makeout = `cd $ecpg_dir && $make NO_LOCALE=1 check 2>&1`;my $status = $?>>8; The sooner we move to a more unified testing infrastructure the better. cheers andrew
On Mon, Jun 04, 2007 at 03:30:07AM -0400, Tom Lane wrote: > AFAICS, Peter's recent incomplete updating of error message wording > should have broken every last man jack of 'em. And yet there's still > some green to be seen. I think we are looking at problems in the ecpg > test scaffolding. For instance, dragonfly claims a green build, but > http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dragonfly&dt=2007-06-04%20043001&stg=ecpg-check > shows this interesting trace: > ... > testing connect/test2.pgc ... ./pg_regress: bad substitution Is it possible to find out which line is reporting this error? Looks to me like some incompatibility on the shell side. 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!
Michael Meskes wrote: > On Mon, Jun 04, 2007 at 03:30:07AM -0400, Tom Lane wrote: > >> AFAICS, Peter's recent incomplete updating of error message wording >> should have broken every last man jack of 'em. And yet there's still >> some green to be seen. I think we are looking at problems in the ecpg >> test scaffolding. For instance, dragonfly claims a green build, but >> http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dragonfly&dt=2007-06-04%20043001&stg=ecpg-check >> shows this interesting trace: >> ... >> testing connect/test2.pgc ... ./pg_regress: bad substitution >> > > Is it possible to find out which line is reporting this error? Looks to > me like some incompatibility on the shell side. > turnip_moth is also a Solaris 9 box and doesn't seem have the same issue. Kris, is there anything unusual installed on the box that would make it behave like this? cheers andrew
On Mon, 4 Jun 2007, Andrew Dunstan wrote: > turnip_moth is also a Solaris 9 box and doesn't seem have the same issue. > > Kris, is there anything unusual installed on the box that would make it > behave like this? > Not sure what's going on here. I did a manual run of the ecpg tests and it completed normally. This machine is quite out of date and it has a large mix of GNU tools with the solaris ones. Since turnip_moth is maintained by Sun I would expect it to be up to date on patches and have few non-Sun tools installed. So it could be using a different interpreter or it could be using a broken tool for which a patch has been released. I'll try doing a run with the buildfarm client later today to try and reproduce this. Kris Jurka
On Mon, 4 Jun 2007, Kris Jurka wrote:
> On Mon, 4 Jun 2007, Andrew Dunstan wrote:
>
>> turnip_moth is also a Solaris 9 box and doesn't seem have the same issue.
>>
>> Kris, is there anything unusual installed on the box that would make it
>> behave like this?
>>
>
> Not sure what's going on here. I did a manual run of the ecpg tests and it
> completed normally. This machine is quite out of date and it has a large mix
> of GNU tools with the solaris ones. Since turnip_moth is maintained by Sun I
> would expect it to be up to date on patches and have few non-Sun tools
> installed. So it could be using a different interpreter or it could be using
> a broken tool for which a patch has been released. I'll try doing a run with
> the buildfarm client later today to try and reproduce this.
>
Running ecpg's pg_regress script with -x yields:
+ cp connect/test2.c results/connect-test2.c
+ connect/test2
+ mv results/connect-test2.c results/connect-test2.c.tmp
+ cat results/connect-test2.c.tmp
+ sed -e s,^\(#line [0-9]*\) ".*/\([^/]*\)",\1 "\2",
+ rm results/connect-test2.c.tmp
+ [ yes = yes ]
./pg_regress: bad substitution
So it looks like it's bailing on this line:
if [ "$enable_threading" = yes ] && [ "${i%%/*}" = "thread" ]; then
and it doesn't like the ${i%%/*} construct. Still not sure why it happens
some places and not others.
Kris Jurka