Yes, my advice would definitely be to not worry about fixing this. I hope to have 1.6 in trusty (-updates BTW, not backports) within a week - just need to get some time from the over subscribed people who can make it happen. Cheers, mwh <div class="gmail_quote">On 12/03/2016 7:08 pm, "John Meinel" <<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Especially for platforms that aren't amd64, I think we want newer go compilers. I would imagine the architecture support has gotten better as they've introduced more architectures. And I'd be especially cautious rolling back a crypto branch as they tend to fix security issues. I don't know the time line for getting 1.6 into Trusty backports but I'd like us to move towards go 1.6 across the board for Juju 2.0 if it's available. (AFAIK it's available everywhere but ppc32) John =:-> <div class="gmail_quote">On Mar 12, 2016 05:17, "Martin Packman" <<a href="mailto:martin.packman@canonical.com" target="_blank">martin.packman@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There is a bug filed over Juju 2.0 not building with go 1.2 on armhf: <<a href="https://bugs.launchpad.net/juju-core/+bug/1547741" rel="noreferrer" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1547741</a>> I believe I understand all the moving parts here, but it's a little fiddly and we're going to have to make a choice about how we plan to build 2.0, so wanted some input. The bug comes from the <a href="http://golang.org/x/*" rel="noreferrer" target="_blank">golang.org/x/*</a> projects being closely tied to the core go project, and not generally attempting cross version compatibility. So, when a new go version is released, the x/* packages quickly pick up new functionality. In this case, the <a href="http://golang.org/x/crypto" rel="noreferrer" target="_blank">golang.org/x/crypto</a> package both introduces some new arm assembly code that will not build on go 1.3 or earlier, and has also started using some new apis from the standard library. It looks safe to roll back to a version from before the incompatible changes, and I've proposed that here: <<a href="http://reviews.vapour.ws/r/4140/" rel="noreferrer" target="_blank">http://reviews.vapour.ws/r/4140/</a>> However it's possible some new code (bits Rog did?) actually needs the newer revision in <a href="http://github.com/juju/juju" rel="noreferrer" target="_blank">github.com/juju/juju</a> directly. Anyway, the bigger question is, do we want keep building Juju 2.0 with go 1.2 at all? We have work ongoing to get go 1.6 back into trusty, using a consistent toolchain vastly simplifies what we have to test and support. There is a wrinkle over supplying jujud binaries for precise agents (I don't think anyone is concerned about the juju client on precise), but it's possible we can just use the trusty build as-is? Mostly for my own future reference, some specifics over why <a href="http://golang.org/x/crypto" rel="noreferrer" target="_blank">golang.org/x/crypto</a> fails to build on armhf. Timeline: 2015-02-06 f7445b17d61953e333441674c2d11e91ae4559d3 First problem rev, crypto package itself on longer builds with go 1.3 # <a href="http://golang.org/x/crypto/ocsp" rel="noreferrer" target="_blank">golang.org/x/crypto/ocsp</a> ocsp/ocsp.go:482: undefined: crypto.Signer This doesn't affect juju which has no dependency on that particular package. 2015-05-14 e3f150b4372fce47109dbd8fef5f03cd2af08700 Last working rev for go 1.2 2015-05-14 4d48e5fa3d62b5e6e71260571bf76c767198ca02 Introduction of arm assembly, new code can't be built due to syntax error? <a href="http://golang.org/x/crypto/poly1305/poly1305_arm.s:26" rel="noreferrer" target="_blank">golang.org/x/crypto/poly1305/poly1305_arm.s:26</a> syntax error, last name: R9 2015-06-11 f6a608df624ae17d57958a8a294c66da81730577 Attempt to fix arm assembly compile on go 1.3, doesn't help the above issue. 2015-09-24 e74b0352e547e3830f8471e7ae9609239c52606f Additional breakage due to use of new crypto.Signer api <a href="http://golang.org/x/crypto/ssh/keys.go:492" rel="noreferrer" target="_blank">golang.org/x/crypto/ssh/keys.go:492</a>: undefined: crypto.Signer It would be possible to address the assembly compilation by correcting the build flags to continue using the fallback on older go versions, with a patch something like: <a href="http://paste.ubuntu.com/15321727/" rel="noreferrer" target="_blank">http://paste.ubuntu.com/15321727/</a> However as tip of the project now doesn't work due to later incompatibile changes, that doesn't get us anywhere useful. Martin -- Juju-dev mailing list <a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a> 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> </blockquote></div> -- Juju-dev mailing list <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a> 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> </blockquote></div>