Thread

1. -HEAD on FreeBSD 6-CURRENT build failures

   Darcy Buskermolen <darcy@wavefire.com> — 2005-01-28T18:42:40Z

   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
   
   

2. Re: -HEAD on FreeBSD 6-CURRENT build failures

   Tom Lane <tgl@sss.pgh.pa.us> — 2005-01-28T18:50:36Z

   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
   
   

3. Re: -HEAD on FreeBSD 6-CURRENT build failures

   Andrew Dunstan <andrew@dunslane.net> — 2005-01-28T20:27:22Z

   
   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
   
   

4. Re: -HEAD on FreeBSD 6-CURRENT build failures

   Tom Lane <tgl@sss.pgh.pa.us> — 2005-01-28T21:45:53Z

   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
   
   

5. Re: -HEAD on FreeBSD 6-CURRENT build failures

   Andrew Dunstan <andrew@dunslane.net> — 2005-01-28T22:01:51Z

   
   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