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 a newer
> version of
> dpkg, which could cause Pd-extended builds to be incompatible
> 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 master since
> 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 can work
> 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 Debian package
> 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/0.42/pd")

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