Thread: -HEAD on FreeBSD 6-CURRENT build failures
There looks to be an issue with gram.y as seen in the following 2 FreeBSD6 boxen: http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&dt=2005-01-28%2018:33:43 http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=echidna&dt=2005-01-28%2018:30:01 -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com
Darcy Buskermolen <darcy@wavefire.com> writes: > There looks to be an issue with gram.y as seen in the following 2 FreeBSD6 > boxen: > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&dt=2005-01-28%2018:33:43 > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=echidna&dt=2005-01-28%2018:30:01 The "issue" is that your make is broken: it's failed to regenerate gram.c from the recently updated gram.y. The impression I have gained from watching the build farm is that ccache is seriously unreliable --- the machines using it often show transient build failures that look like failure to update derived files. regards, tom lane
Tom Lane wrote: >Darcy Buskermolen <darcy@wavefire.com> writes: > > >>There looks to be an issue with gram.y as seen in the following 2 FreeBSD6 >>boxen: >> >> > > > >>http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&dt=2005-01-28%2018:33:43 >>http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=echidna&dt=2005-01-28%2018:30:01 >> >> > >The "issue" is that your make is broken: it's failed to regenerate >gram.c from the recently updated gram.y. > >The impression I have gained from watching the build farm is that ccache >is seriously unreliable --- the machines using it often show transient >build failures that look like failure to update derived files. > > > > The way buildfarm works is that it should always run on a clean set of CVS files - i.e. there should no gram.c. We don't even bot6her with clean, distclean, maintainer-clean and friends - we simply copy the source directory tree for each run. The fact that Darcy's builds don't show a call to bison indicates to me that his source dir ( /buildfarm/pg-buildfarm/HEAD/pgsql ) might not be clean for some reason that is not clear to me. Darcy, please blow that directory tree away and see if the situation recovers. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> The way buildfarm works is that it should always run on a clean set of
> CVS files - i.e. there should no gram.c. We don't even bot6her with
> clean, distclean, maintainer-clean and friends - we simply copy the
> source directory tree for each run. The fact that Darcy's builds don't
> show a call to bison indicates to me that his source dir (
> /buildfarm/pg-buildfarm/HEAD/pgsql ) might not be clean for some reason
> that is not clear to me.
Hmm, source directory used for a build and then not maintainer-clean'd
perhaps?
If you do the copy without -p then the copy would tend to lose the
timestamps that would show that the gram.c file is out of date.
I suppose "cp -p" would be a bad idea because of permissions issues,
but you could consider replacing the cp with "tar cf - | tar xf -"
to preserve timestamps better.
regards, tom lane
Tom Lane wrote: >Andrew Dunstan <andrew@dunslane.net> writes: > > >>The way buildfarm works is that it should always run on a clean set of >>CVS files - i.e. there should no gram.c. We don't even bot6her with >>clean, distclean, maintainer-clean and friends - we simply copy the >>source directory tree for each run. The fact that Darcy's builds don't >>show a call to bison indicates to me that his source dir ( >>/buildfarm/pg-buildfarm/HEAD/pgsql ) might not be clean for some reason >>that is not clear to me. >> >> > >Hmm, source directory used for a build and then not maintainer-clean'd >perhaps? > > That would do it. Basically the user should not touch anything inside <buildroot>, any more that they should touch anything in <datadir>/base. >If you do the copy without -p then the copy would tend to lose the >timestamps that would show that the gram.c file is out of date. >I suppose "cp -p" would be a bad idea because of permissions issues, >but you could consider replacing the cp with "tar cf - | tar xf -" >to preserve timestamps better. > > > > If we needed to, yes. rsync also works very nicely on stuff like this - and I have been using it in my day job for such a purpose. But I think the answer in this case is "don't do that." Darcy has cleaned out his source directory and all now seems well. cheers andrew