On Sep 7, 2010, at 4:54 PM, András Murányi wrote:
2010/8/29 Hans-Christoph Steiner hans@at.or.at On Sun, 2010-08-29 at 22:08 +0200, András Murányi wrote:
Ok, the problem is the backport of buildbot relies on anewer
version of dpkg, which could cause Pd-extended builds to beincompatible
with a plain Debian/lenny machine. Once Pd-extended is released, I can upgrade without worrying about it.I understand.
I'd like to keep the 128.238.56.50 machine as the mastersince
the rest are more or less "disposable". So we can wait for Pd-extended
to be released to upgrade (less than 2 weeks hopefully), we canwork
with the version that is installed now, or if you want you could install a newer version manually, then we can switch to the new Debianpackage
once Pd-extended is released.Sounds good. So you mean i shall install a new version somewhere under /var/lib/buildbot? Will it run ok as a daemon? Or shall i
build
a new version which you then install over the existing one?
Ok, I just built the package myself from source and removed the dependency on dpkg 1.15 and set it to 1.14 for lenny instead. That means 0.7.12 is now installed on debian-stable-i386.
very nice! Now we have a console view too (http://128.238.56.50:8010/console ), but i don't see if tells anything about what's happening on the different buildslaves. Maybe later we could artificially try to break things on one platform and not on the others, and see how the web views help finding the broken one. Reorganizing the builders would certainly make things less clear, so i consider it a last resort.
Well, it already found one build system issue in branches/pd-extended/ 0.42/pd/src/makefile.in, which I just fixed. :-D
Also, about the slave names, would it be possible to use the same names that are on the PdLab page? I.e. not CamelCase, but with-dashes instead :)
Sure, i will. Soon :) Now i'm at CVS polling... it goes with a script snippet, which i'm not sure about if it does what we want... could you take a look at http://128.238.56.50:8010/waterfall sometimes and see if the changes trigger the right builder? The snippet is like this:
def my_file_splitter(path): # file splitter for BRANCHNAME/PROJECT/ FILEPATH repos pieces = path.split('/') if pieces[0] == 'trunk': branch = None pieces.pop(0) # remove 'trunk' elif pieces[0] == 'branches': pieces.pop(0) # remove 'branches' # grab branch name branch = 'branches/' + pieces.pop(0) else: return None # something weird projectname = pieces.pop(0) # if projectname != 'pure-data': # return None # wrong project return (branch, '/'.join(pieces))
further explanation is here: http://buildbot.net/buildbot/docs/latest/SVNPoller.html
We have a pretty strange SVN layout for many reasons, so I think we'll have to do some little scripts to get things working. The easiest thing to start with would be just the Pd-extended branch. It seems that you can have buildbot automatically build branches as well, which is probably not something we need right now (maybe later).
I think a starting Pd-extended builder would look like this:
from buildbot.changes.svnpoller import SVNPoller c['change_source'] = SVNPoller("http://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-extended/... ")
Then it would need to "cd path/to/pd/src && ./configure && make install" or something like that.
About maintaining the 64-bit server... i'd pick it up, but as far as i know myself i'm a creative type with less perseverance... also i've never maintained chroot, but i guess it's not a big deal.
Andras
Being the server maintainer doesn't mean that no one else will help you! I will help setup things like the chroot, its pretty easy once you get over a couple hurdles.
.hc
----------------------------------------------------------------------------
Information wants to be free. -Stewart Brand