DragonFly support in Go
bradfitz at golang.org
Fri Jan 17 11:13:15 PST 2014
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.
> 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
The build worker (that you will run) will just run all.bash.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users