Skip site navigation (1) Skip section navigation (2)

Re: -HEAD on FreeBSD 6-CURRENT build failures

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Darcy Buskermolen <darcy(at)wavefire(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: -HEAD on FreeBSD 6-CURRENT build failures
Date: 2005-01-28 20:27:22
Message-ID: 41FAA02A.90306@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

>Darcy Buskermolen <darcy(at)wavefire(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Josh BerkusDate: 2005-01-28 20:43:13
Subject: Re: [pgsql-hackers] Group-count estimation statistics
Previous:From: Matthias SchmidtDate: 2005-01-28 20:17:46
Subject: Re: Allow GRANT/REVOKE permissions to be applied to all schema objects with one command

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group