armhfentures

[John Meinel]

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
=:->
On Mar 12, 2016 05:17, "Martin Packman" <martin.packman at canonical.com>
wrote:

> There is a bug filed over Juju 2.0 not building with go 1.2 on armhf:
>
> <https://bugs.launchpad.net/juju-core/+bug/1547741>
>
> 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 golang.org/x/* 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
> golang.org/x/crypto 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:
>
> <http://reviews.vapour.ws/r/4140/>
>
> However it's possible some new code (bits Rog did?) actually needs the
> newer revision in github.com/juju/juju 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
> golang.org/x/crypto fails to build on armhf.
>
> Timeline:
>
> 2015-02-06 f7445b17d61953e333441674c2d11e91ae4559d3
> First problem rev, crypto package itself on longer builds with go 1.3
>     # golang.org/x/crypto/ocsp
>     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?
>    golang.org/x/crypto/poly1305/poly1305_arm.s:26 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
>     golang.org/x/crypto/ssh/keys.go:492: 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:
>
> http://paste.ubuntu.com/15321727/
>
> 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
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160312/ac8946c0/attachment.html>