So, why isn't *every* buildfarm member failing ecpg right now?

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