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