<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Apr 11, 2016 at 12:55 AM Curtis Hovey-Canonical <<a href="mailto:curtis@canonical.com">curtis@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ladies and Gentlemen, We build with Go 1.6 everywhere.<br>
<br>
Take a moment to consider the implications, because that means we do<br>
not use Go 1.2, 1.3, or 1.5. Juju 1.x and 2.x for Windows, OS X, and<br>
Linux (precise, trusty, wily, xenial, and centos7) are built with Go 1.6.<br></blockquote><div><br></div><div>Great news! Thank you, and Michael.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There was concern about how to support precise if the code grew 1.2<br>
incompatibilities. Michael Hudson-Doyle's fabulous package was trivial<br>
to backport to precise. We don't need to create a new process to support<br>
precise. The golang-1.6 packages was also easy to copy to wily. since<br>
the Go 1.5 unit tests are less reliable than the Go 1.6 unit tests, the<br>
hour spent setting up wily to build with golang-1.6 will pay for itself<br>
in a day.<br>
<br>
Some unit tests combinations are still using Go 1.2 because the tests<br>
assume OS features because of the Golang version instead of checking<br>
the OS:<br>
<br>
1. The Makefile rules for installing deps are very stale. Precise unit<br>
tests will fail when forced to use Go 1.6 because they cannot<br>
start mongo:<br>
    error command line: unknown option sslOnNormalPorts<br>
But we see that actual deployments of precise built with Go 1.6 work.</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Centos and Windows unit test are still Go 1.2 because many lxd<br>
related tests fail when run with Go 1.6.<br>
<br>
The git-merge-juju job is using the xenial daily image to gate merges.<br>
The released image it too stale to do an unattended dist-upgrade<br></blockquote><div><br></div><div><br></div><div>Are precise, CentOS, and/or Windows voting? I'd like to merge some changes that would mean the Azure provider no longer compiles with Go 1.2. If we still have 1.2 testers, and they're voting, then I still can't merge without breaking CI.</div><div><br></div><div>Cheers,</div><div>Andrew</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The unit test runs for xenial-amd64, xenial-arm64, xenial-s390x,<br>
xenial-ppc64el, wily-amd64, trusty-amd64, trusty-i386, and<br>
trusty-ppc64el will use the golang (1.6) or golang-1.6 (1.6) packages.<br>
The go1.2 trusty unit tests amd64, arm64, i386, and ppc64el are gone.<br>
<br>
Ubuntu source packages prefer the golang-1.6 package, and fallback to<br>
golang (>= 1.2). We needed a new builder because Go 1.6 needs more<br>
memory. We saw errors like this with 2G of memory<br>
    golang-1.6/pkg/tool/linux_amd64/link: running gcc failed:<br>
    fork/exec /usr/bin/gcc: cannot allocate memory<br>
Centos is created using the same Go package as trusty. Windows is<br>
cross compiled as 64 bit for agent and 32 bit for clients. OS X is<br>
natively compiled using Go 1.6 on CI's OS X host.<br>
<br>
We also got word is was safe to upgrade our arm64 host to xenial. This<br>
is done. The ppc64el hosts were also upgraded this week. We are<br>
expanding tests for arm64 and ppc64el<br>
<br>
--<br>
Curtis Hovey<br>
Canonical Cloud Development and Operations<br>
<a href="http://launchpad.net/~sinzui" rel="noreferrer" target="_blank">http://launchpad.net/~sinzui</a><br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</blockquote></div></div>