On Sep 16, 2010, at 12:21 PM, András Murányi wrote:
> 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 theSIGCHLD
handler > is not installed. This probably means you have not yet called > reactor.run, or calledreactor.run(installSignalHandler=0).
You will > probably never see this process finish, and it maybecome 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 alsogot
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 forthe
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 everyslave
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", soyou
can test > the same builder on multiple slaves at the same time. Atthe
end they > have to broken down to one slave per builder, otherwisethe
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 itwill
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 becalled
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.
I'll still be on email, so I can contribute here and there. Yeah, I was also thinking that the libs wouldn't stop the whole build.
.hc
----------------------------------------------------------------------------
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman