Comment 139 for bug 1267393

"Are you saying you want to use the embedded code copy? Has anyone looked at the testsuite issue to fix it? Embedded code copies should be avoided at all costs per MIR guidelines -- we are making huge concessions for the juju and lxd teams already, can someone take a look at this ftbfs and report back?"

Short version, these extended-standard library packages are in practice pretty closely tied to the golang minor version.

Debian currently has go 1.4 and the go-x-text package is from May, before the go 1.5 release:

<https://golang.org/doc/devel/release.html>

In go 1.5 the unicode package, which includes generation of various data tables, was updated to use Unicode 8.0.0 - which amongst other changes introduces the Ahom script:

<http://unicode.org/versions/Unicode8.0.0/>

This means the test in golang.org/x/text which uses the data from the standard library unicode package now finds its own data out of sync with the system golang on wily. Specifically, the new character U+11730 AHOM DIGIT ZERO should be numerically equal to 0, but is not. Obviously there are other failures as well.

There's an easy fix for wily, which is just update the package to use a current revision of golang.org/x/text for go 1.5 compatibility. I've proposed a debian/experimental branch that does that:

<http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20151019/001878.html>

(Minor wrinkle, still a test failure even with the latest code, I patched it in the packaging but presumably needs resolving upstream.)

Anyway, where this gets really fun is when we start considering backports of latest juju. None of these packages existed when trusty was released, and their current versions will generally be incompatible with go 1.2.1. We could pick out the revisions that worked for specific backport packaging, but won't have support upstream for security fixes to random older checkouts so won't really gain anything.