DragonFly support in Go

[Brad Fitzpatrick]

On Fri, Jan 17, 2014 at 11:07 AM, John Marino <dragonflybsd at marino.st>wrote:

> On 1/17/2014 20:04, Justin Sherrill wrote:
> > On Fri, Jan 17, 2014 at 1:45 PM, Brad Fitzpatrick <bradfitz at golang.org
> > <mailto:bradfitz at golang.org>> wrote:
> >
> >
> >     But the Go 1.2 you have already in ports might be sufficient to
> >     build the builder worker and start the process.  Even the plan9 and
> >     solaris ports started with months of red failure on our dashboard.
> >
> >
> > The best long-term solution is to have a DragonFly system doing
> > bleeding-edge Go builds in a loop, correct?  Even if it builds in
> > (d)ports, that won't catch possible problems until the port itself is
> > updated, and I'm assuming the purpose of this is to serve as a sort of
> > tinderbox/warning system.
> >
> > If I can scare up a separate machine to do it, I'd be happy to build it.
> >  I've been meaning to do something with Go, but like any project,
> > without a clear work target it's been hard to get started.
>
> Justin,
> Rather than look for a separate machine, I suggest we add these to
> pkgbox64 and pkgbox32 official servers.  Then you can tend them there.
>
> I doubt it's a loop though, it is probably triggered.  Maybe even as
> often as every new commit.


Yes, every commit.

The builder program monitors the build master for work.  When the master
sees new commits, it notifies each worker to do a new build and report the
results/output.

The build worker (that you will run) will just run all.bash.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20140117/1db2b5d4/attachment-0012.html>