On Wed, 2017-02-01 at 10:40 +0000, Robbie Gemmell wrote: > On 18 January 2017 at 11:05, Robbie Gemmell <[email protected] > > wrote: > > On 18 January 2017 at 01:21, Alan Conway <[email protected]> > > wrote: > > > On Tue, 2017-01-17 at 14:20 -0500, Alan Conway wrote: > > > > On Wed, 2017-01-11 at 10:54 -0500, Andrew Stitcher wrote: > > > > > On Wed, 2017-01-11 at 12:32 +0000, Robbie Gemmell wrote: > > > > > > ... > > > > > > Running it again on the 14.04.4 instance, node ubuntu-2, it > > > > > > failed > > > > > > as > > > > > > before (seemingly using Go 1.6, vs 1.6.2 on the 16.04.1 > > > > > > instance, > > > > > > which was node H12) > > > > > > > > > > I only disabled the PHP binding build, so any problems with > > > > > the go > > > > > bindings on Ubuntu 1404 were not addressed. > > > > > > > > > > We can't simply disable the go bindings as they are in active > > > > > development, so someone with a clue will have to actually > > > > > understand > > > > > what the problem is (not me!). > > > > > > > > > > > > > I'll look into this. > > > > > > > > > > The problem seems to be specific to certain go versions. I've > > > done some > > > work to make the code build with golang and gcc Go compilers, > > > that may > > > or may not address the failure for go 1.6. If not I'll have to > > > get an > > > older compiler and figure it out. > > > > > > > Two builds resulting from your commits failed, on different nodes. > > One > > instance was 14.4.4, the other 14.4.5, both using go 1.6. > > > > Robbie > > I looked/googled into this a bit given the intent to release > imminently. > > The issue seems to be with use of the -race option during the tests, > which it appears didn't work in some versions of Go in Ubuntu: > https://bugs.launchpad.net/bugs/1487010 > https://bugs.launchpad.net/bugs/1496503 > > From bindings/go/CMakeLists.txt, it appears the build is currently > using -race if the go version doesn't match 'gccgo'. > > It would seem we could do various things: > 1. Decide its fine as-is, anyone affected can [maybe?] fix their > installation to work, CI will continue to sporadically fail (we could > identify all the working nodes and pin them). > 2. Figure out a way to detect this situation automatically and not > set > -race when it wont work. > 3. Add a manual flag to control whether -race is used, perhaps > default > it to false to get builds working (or again for CI, pin the working > nodes). > 4. Remove use of -race entirely. > 5. Other?
Thanks Robbie. I don't want to stop running -race tests entirely, but until we can auto-identify a safe setting for them, I can make them optional default-off and enable manually in my tests. Will do that now... --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
