>         >                 At the moment buildbot fails with
>         >                 "exceptions.RuntimeError: Couldn't find
>         executable for
>         >                 'svn'"
>         >
>         >                 + the same for git
>         >
>         >                 I added ~buildbot/.bashrc to hopefully add
>         Fink stuff
>         >                 to buildbot's environment
>         >
>         >                 .hc
>         >
>         >
>         >                 Hmm, didn't work out, and
>         >                 net.sourceforge.buildbot.plist has sw/bin in
>         the path
>         >                 too, and svn is there, so i really don't
>         know...
>         >
>         >                 Andras
>         >
>         >
>         >         Ok, I was getting some builds from macosx104-i386,
>         but then it
>         >         disappeared, donno what happened there.
>          macosx104-powerpc
>         >         seems to be running still tho.
>         >
>         >
>         > Yea the process died somehow. I have restarted it with the
>         command:
>         >  /sw/bin/buildbot restart /Users/buildbot/macosx104-i386
>         >
>         > The output had some complaints:
>         > /sw/lib/python2.6/site-packages/twisted/persisted/sob.py:12:
>         > DeprecationWarning: the md5 module is deprecated; use
>         hashlib instead
>         >   import os, md5, sys
>         > /sw/lib/python2.6/site-packages/twisted/python/filepath.py:12:
>         > DeprecationWarning: the sha module is deprecated; use the
>         hashlib
>         > module instead
>         >   import sha
>         > /sw/lib/python2.6/site-packages/twisted/internet/_sslverify.py:5:
>         > DeprecationWarning: the md5 module is deprecated; use
>         hashlib instead
>         >   import itertools, md5
>         > Following twistd.log until startup finished..
>         > /sw/lib/python2.6/site-packages/buildbot/scripts/logwatcher.py:52:
>         > PotentialZombieWarning: spawnProcess called, but the SIGCHLD
>         handler
>         > is not installed. This probably means you have not yet
>         called
>         > reactor.run, or called reactor.run(installSignalHandler=0).
>         You will
>         > probably never see this process finish, and it may become a
>         zombie
>         > process.
>         >   env=os.environ,
>         > Removing stale
>         pidfile /Users/buildbot/macosx104-i386/twistd.pid
>         >
>         >         I worked on the pd-master/master.cfg a bit,
>         including changing
>         >         some of the names to be more consistent.  I also got
>         pure-data
>         >         building from Miller's git.
>         >
>         >         http://128.238.56.50:8010/builders/pure-data%20Linux
>         %
>         >         20debian-stable-i386/builds/6
>         >
>         >         .hc
>         >
>         >
>         > Good! I saw you stared experimenting with a builder for the
>         externals
>         > too - do i understand right that at the end we will have
>         every
>         > external built separately? I was thinking about breaking
>         them out to a
>         > separate master, but then we'd need to duplicate every slave
>         setup, so
>         > finally i think they could stay in the main master, and we
>         could have
>         > each of their have their own "category" name, which allows
>         for some
>         > selection at the web page.
>         > Also note that for the builders, you can define an array
>         with
>         > "slavenames:" instead of a single string "slavename", so you
>         can test
>         > the same builder on multiple slaves at the same time. At the
>         end they
>         > have to broken down to one slave per builder, otherwise the
>         diag
>         > output is not easy to understand.
>         >
>         > Changing descriptionDone values to past tense like
>         "compiled" may not
>         > make sense when the step fails and the output goes like
>         "compiled
>         > failed". Also there are things like "autogen" which don't
>         have a
>         > proper past tense... :)
>         > Another thing i noticed an "svn update" by itself, i think
>         we shall
>         > have the sources explicitly in master.cfg otherwise it will
>         fail where
>         > the slave got reset. Also you told before we wanted
>         "clobber" (tabula
>         > rasa) checkout not an update...
>         > I saw the "make install", "make uninstall" steps in the
>         output -
>         > having these would make much sense, fyi tests can be called
>         with
>         > Test() which has some advantages over ShellCommand() like it
>         doesn't
>         > make the whole build halt on failure.
>         > BTW switching the sources to git is easy, what we have to
>         work out is
>         > Git polling. It's built into 0.8.1 but needs to triggered
>         from git for
>         > 0.7.12. And then we have this thing with the poller to
>         explain it
>         > which builder to start upon updates... a.k.a. the cake :)
>         >
>         > Andras
>
>
>         One approach would be to use multiple PBChangeSource things
>         and have
>         commit hooks report to buildbot that they should build:
>
>
> Actually there is only one PBChangeSource needed/possible because it's
> a listener, and multiple commit hooks can communicate with it from the
> repos.
>
>         Another promising thing is loki, a web interface for easily
>         setting up
>         master/slaves:
>
>         https://fedorahosted.org/loki/
>
>
> Hm. Seems a bit young to me...
>
> I see that at the moment every factory is "under construcion" so i
> won't touch the config file for a while so that you can edit around.
> (Which makes me think about putting it in svn later...)
> http://128.238.56.50:8010/one_box_per_builder
>
> Andras

I'm actually not going to have any time to look at this for a couple
weeks, so please edit away.  

Ok, i will. I'm not very good at build building generally, and which steps certain pd sources need, but i'll experiment. I'll bug you if something fails and i really don't know why.
 
About the 'externals' collection, one idea
I had was to set up a different step for each library, then have a
common collection of steps for easy reuse.  For the Makefile-based libs
the steps could be: make, make install, make dist.  For autotools, we
could have ./configure, make, make install.  If it uses automake, then
these should also be available: make uninstall, make dist.

Perhaps that would be manageable, but it seems there might be a better
way.

Sounds good to me. If i set up that failed libs don't halt the whole build, it might be a good solution, or i'll think if there's a better one.

Andras