armhfentures

[Michael Hudson-Doyle]

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
On 12/03/2016 7:08 pm, "John Meinel" <john at arbash-meinel.com> wrote:

> 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
>>
>
> --
> 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/20160313/6c5549fb/attachment.html>