One last detail: from go-1.10 onward, we will need to turn all CGO input to propagated inputs, otherwise referrers won't be able to build. -- Pierre Neidhardt https://ambrevar.xyz/ Attachment: signat
Actually I think I'll have to patch golua. According to https://golang.org/cmd/cgo/, CGO flags cannot be customized from command line. -- Pierre Neidhardt https://ambrevar.xyz/ Attachment: signature.
I've been studying the situation: From https://golang.org/doc/go1.10#build: From https://golang.org/doc/go1.11: My understanding is that we cannot rely on the /pkg/ folder anymore, since Go 1.12 won'
Okay, I think you should go ahead and push these changes now, assuming the packages still build afterwards. Okay, I see. I won't be working on this soon, if ever. I don't understand enough about how
In my patchset, there are 2 kinds of fixes: - Disabling tests because Go 1.11 test policies are stricter and some lax code from before does not pass anymore. For this issue, upstream should fix the
It's a matter of taste :) Yes, we should, but that problem is not related to packages not building with Go 1.11 because they need to be updated upstream, right? Even if our go-build-system was update
Sure, but isn't this too much a hassle (and more pollution added to the package namespace) for a temporary workaround? Shouldn't we focus on fixing the cache bug in the build system instead? -- Pierr
Yeah, I don't think there is any notion of backwards compatibility there. Maybe you could take a look at how we handle packaging for both Python 3 and Python 2? There, we have package variants for bo
Hmm, actually it seems that go1.9 is not able to build a package against dependencies built with go1.11. For Demlo, that would mean that I need to add the 1.9 specialization to 10 packages, but this
Oh, cool, I did not know about the #:go key! Great, I'll udpate the patchset then! -- Pierre Neidhardt https://ambrevar.xyz/ Attachment: signature.asc Description: PGP signature
The default Go is defined in ((guix build-system go) default-go). Updates can be tested with this diff: diff --git a/guix/build-system/go.scm b/guix/build-system/go.scm index cf9116327..80894677f 100
Hm, quel dommage! If most of the Go packages are ready for Go 1.11, we could make it the dfeault and then use Go 1.9 for the packages that are lagging behind. Or vice versa. In general, we should try
Actually bug 32919 matters, it breaks Demlo and all packages that depend on packages that need special compilation flags (e.g. -tags "xyz"). Concretely, say A depends on B and B must be built with "-
Also, if we move to go 1.11, should we remove go 1.9? Considering there is the slowdown mentioned in https://bugs.gnu.org/32919, maybe it would be smarter to keep 1.9 around? -- Pierre Neidhardt http
I see you've fixed this on November 1st. I'll test Syncthing with go 1.11. If it works, do you think it's safe to move to 1.11 for the default? -- Pierre Neidhardt https://ambrevar.xyz/ Attachment: s
That was my first clue as well! :) But looking at other downloaders, only url-fetch has some x509 provisions. I'm not too sure about its mechanics however. For instance, there is this snippet: --8<-
Hello! Pierre Neidhardt <address@hidden> skribis: [...] As long as ‘hash-algo’ and ‘hash’ are true, it does define a fixed-output derivation, so the builder should indeed have network access.
There is also <https://bugs.gnu.org/32919> but IMO it's not a blocker considering that Go 1.9 is no longer supported upstream. Yes :) Attachment: signature.asc Description: PGP signature
Is it _only_ inefficient because of issue 32949 or is there another reason? OK, if Gábor's clue happens to be the right one, it should not be too hard. I'll look into it later. I think you meant Go