Thread

1. build farm failures

   Michael Meskes <meskes@postgresql.org> — 2007-08-16T09:11:51Z

   Hi,
   
   we have two build farm members failing to make since I committed teh
   ecpg changes: echidna and herring.
   
   It looks like they are still using an old preproc.c although they
   checked out the new preproc.y. I have no idea how this is supposed to
   work so could someone please enlighten me?
   
   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!
   
   

2. Re: build farm failures

   Andrew Dunstan <andrew@dunslane.net> — 2007-08-16T11:29:41Z

   
   Michael Meskes wrote:
   > Hi,
   >
   > we have two build farm members failing to make since I committed teh
   > ecpg changes: echidna and herring.
   >
   > It looks like they are still using an old preproc.c although they
   > checked out the new preproc.y. I have no idea how this is supposed to
   > work so could someone please enlighten me?
   >
   >   
   
   Yes it looks like that. But the buildfarm client doesn't actually build 
   in the repo normally - it builds in a temp copy which is removed at the 
   end of the run, precisely to avoid this kind of problem, so I'm a bit 
   mystified how it can happen. In fact we go to some lengths to ensure 
   that there are no extraneous files, but this one might not get caught by 
   that because it is is in .cvsignore. This sort of thing is usually a 
   symptom of somebody having run a build in the repo directly, a thing 
   that buildfarm owners have been repeatedly advised not to do.
   
   Anyway, the simple solution is to ask Darcy to blow away the repo (these 
   buildfarm clients share a single cvs checkout) so that the buildfarm 
   client will get a fresh checkout next time it's run.
   
   cheers
   
   andrew
   
   

3. Re: build farm failures

   Darcy Buskermolen <darcy@ok-connect.com> — 2007-08-16T15:24:14Z

   On Thursday 16 August 2007 04:29:41 Andrew Dunstan wrote:
   > Michael Meskes wrote:
   > > Hi,
   > >
   > > we have two build farm members failing to make since I committed teh
   > > ecpg changes: echidna and herring.
   > >
   > > It looks like they are still using an old preproc.c although they
   > > checked out the new preproc.y. I have no idea how this is supposed to
   > > work so could someone please enlighten me?
   >
   > Yes it looks like that. But the buildfarm client doesn't actually build
   > in the repo normally - it builds in a temp copy which is removed at the
   > end of the run, precisely to avoid this kind of problem, so I'm a bit
   > mystified how it can happen. In fact we go to some lengths to ensure
   > that there are no extraneous files, but this one might not get caught by
   > that because it is is in .cvsignore. This sort of thing is usually a
   > symptom of somebody having run a build in the repo directly, a thing
   > that buildfarm owners have been repeatedly advised not to do.
   
   This is something I do not recall doing, however it's possible.  though this 
   does make me ask why are the build dependencies in the Makefile are not 
   properly setup to tell that the .y needs to be rebuilt (which I would assume 
   would make this problem also go away)
   
   >
   > Anyway, the simple solution is to ask Darcy to blow away the repo (these
   > buildfarm clients share a single cvs checkout) so that the buildfarm
   > client will get a fresh checkout next time it's run.
   
   Let me go nuke the tree, and we'll try again....
   
   >
   > cheers
   >
   > andrew
   >
   > ---------------------------(end of broadcast)---------------------------
   > TIP 5: don't forget to increase your free space map settings
   
   
   
   

4. Re: build farm failures

   Andrew Dunstan <andrew@dunslane.net> — 2007-08-16T16:12:02Z

   
   Darcy Buskermolen wrote:
   >> This sort of thing is usually a
   >> symptom of somebody having run a build in the repo directly, a thing
   >> that buildfarm owners have been repeatedly advised not to do.
   >>     
   >
   > This is something I do not recall doing, however it's possible.  though this 
   > does make me ask why are the build dependencies in the Makefile are not 
   > properly setup to tell that the .y needs to be rebuilt (which I would assume 
   > would make this problem also go away)
   >
   >   
   
   Thje way cvs works is that it gives the file the date it has in the 
   repository, so if your preproc.c is newer than the preproc.y, make will 
   detect that and not rebuild it.  If Michael's checkin occurs between the 
   time the repo is updated and the time bison gets run on the original 
   file this will happen. But if you never ever build in the repo then it 
   won't, because buildfarm only ever builds in a copy (unless you're 
   building with vpath, in which case it cleans up the generated files).
   
   cheers
   
   andrew
   
   

5. Re: build farm failures

   Alvaro Herrera <alvherre@commandprompt.com> — 2007-08-16T16:37:54Z

   Andrew Dunstan wrote:
   >
   >
   > Darcy Buskermolen wrote:
   >>> This sort of thing is usually a
   >>> symptom of somebody having run a build in the repo directly, a thing
   >>> that buildfarm owners have been repeatedly advised not to do.
   >>>     
   >>
   >> This is something I do not recall doing, however it's possible.  though 
   >> this does make me ask why are the build dependencies in the Makefile are 
   >> not properly setup to tell that the .y needs to be rebuilt (which I would 
   >> assume would make this problem also go away)
   >
   > Thje way cvs works is that it gives the file the date it has in the 
   > repository, so if your preproc.c is newer than the preproc.y, make will 
   > detect that and not rebuild it.  If Michael's checkin occurs between the 
   > time the repo is updated and the time bison gets run on the original file 
   > this will happen. But if you never ever build in the repo then it won't, 
   > because buildfarm only ever builds in a copy (unless you're building with 
   > vpath, in which case it cleans up the generated files).
   
   Hum, so why not clean up the files when not in vpath as well?
   
       find . -name .cvsignore | while read line
       do
           dir=$(dirname $line)
           cd $dir
           rm -fv `cat .cvsignore`
           cd $OLDPWD
       done
   
   -- 
   Alvaro Herrera                                http://www.CommandPrompt.com/
   PostgreSQL Replication, Consulting, Custom Development, 24x7 support
   
   

6. Re: build farm failures

   Andrew Dunstan <andrew@dunslane.net> — 2007-08-16T16:57:10Z

   
   Alvaro Herrera wrote:
   > Andrew Dunstan wrote:
   >   
   >> Darcy Buskermolen wrote:
   >>     
   >>>> This sort of thing is usually a
   >>>> symptom of somebody having run a build in the repo directly, a thing
   >>>> that buildfarm owners have been repeatedly advised not to do.
   >>>>     
   >>>>         
   >>> This is something I do not recall doing, however it's possible.  though 
   >>> this does make me ask why are the build dependencies in the Makefile are 
   >>> not properly setup to tell that the .y needs to be rebuilt (which I would 
   >>> assume would make this problem also go away)
   >>>       
   >> Thje way cvs works is that it gives the file the date it has in the 
   >> repository, so if your preproc.c is newer than the preproc.y, make will 
   >> detect that and not rebuild it.  If Michael's checkin occurs between the 
   >> time the repo is updated and the time bison gets run on the original file 
   >> this will happen. But if you never ever build in the repo then it won't, 
   >> because buildfarm only ever builds in a copy (unless you're building with 
   >> vpath, in which case it cleans up the generated files).
   >>     
   >
   > Hum, so why not clean up the files when not in vpath as well?
   >
   >     find . -name .cvsignore | while read line
   >     do
   >         dir=$(dirname $line)
   >         cd $dir
   >         rm -fv `cat .cvsignore`
   >         cd $OLDPWD
   >     done
   >
   >   
   
   Because they are not supposed to be there in the first place! If the 
   buildfarm owner builds in the repo that is pilot error.
   
   And, btw,  buildfarm is not a shell script. We use File::Find to do this 
   sort of thing.
   
   cheers
   
   andrew
   
   

7. Re: build farm failures

   Michael Meskes <meskes@postgresql.org> — 2007-08-16T17:48:30Z

   On Thu, Aug 16, 2007 at 08:24:14AM -0700, Darcy Buskermolen wrote:
   > This is something I do not recall doing, however it's possible.  though this 
   > does make me ask why are the build dependencies in the Makefile are not 
   > properly setup to tell that the .y needs to be rebuilt (which I would assume 
   > would make this problem also go away)
   
   Frankly I have no idea. The dependencies are the same as with the
   backend's gram.y file:
   
   $(srcdir)/preproc.c: $(srcdir)/preproc.h ;
   
   $(srcdir)/preproc.h: preproc.y
   
   The backend has:
   
   $(srcdir)/gram.c: $(srcdir)/parse.h ;
   
   $(srcdir)/parse.h: gram.y
   
   So except for the different naming it's the same. However, we haven't
   had that problem with the backend so far, or did we?
   
   What do I fail to see?
   
   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!
   
   

8. Re: build farm failures

   Andrew Dunstan <andrew@dunslane.net> — 2007-08-16T17:58:20Z

   
   Michael Meskes wrote:
   > The backend has:
   >
   > $(srcdir)/gram.c: $(srcdir)/parse.h ;
   >
   > $(srcdir)/parse.h: gram.y
   >
   > So except for the different naming it's the same. However, we haven't
   > had that problem with the backend so far, or did we?
   >
   > What do I fail to see?
   >
   >   
   
   We have had problems in the past. If the user builds at a point in time 
   after the .y file is checked in then the generated file is newer and if 
   it's not removed will never be regenerated, even if they do a subsequent 
   cvs update.
   
   cheers
   
   andrew
   
   

9. Re: build farm failures

   Alvaro Herrera <alvherre@commandprompt.com> — 2007-08-16T20:04:57Z

   Andrew Dunstan wrote:
   >
   >
   > Michael Meskes wrote:
   >> The backend has:
   >>
   >> $(srcdir)/gram.c: $(srcdir)/parse.h ;
   >>
   >> $(srcdir)/parse.h: gram.y
   >>
   >> So except for the different naming it's the same. However, we haven't
   >> had that problem with the backend so far, or did we?
   >>
   >> What do I fail to see?
   >
   > We have had problems in the past. If the user builds at a point in time 
   > after the .y file is checked in then the generated file is newer and if 
   > it's not removed will never be regenerated, even if they do a subsequent 
   > cvs update.
   
   How do you create the copy of the repo to build?  One idea would be to
   explicitely skip files that appear on .cvsignore (and maybe croak about
   them).
   
   -- 
   Alvaro Herrera                                http://www.CommandPrompt.com/
   The PostgreSQL Company - Command Prompt, Inc.
   
   

10. Re: build farm failures

    Andrew Dunstan <andrew@dunslane.net> — 2007-08-16T20:22:36Z

    
    Alvaro Herrera wrote:
    >
    >
    > How do you create the copy of the repo to build?  One idea would be to
    > explicitely skip files that appear on .cvsignore (and maybe croak about
    > them).
    >
    >   
    
    
    We are supposed to croak - see 
    http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbuildfarm/client-code/run_build.pl.diff?r1=1.69&r2=1.70
    
    And these machines run the version after that. So either the code is 
    buggy or my explanation is of what happened is :-)
    
    cheers
    
    andrew