go version)?go version go1.12.5 linux/amd64
I have not checked yet.
go env)?GOARCH="amd64"
GOBIN=""
GOCACHE="/home/gobins/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/gobins/go"
GOPROXY="https://proxy.golang.org"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/gobins/git/capacitor/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build022726128=/tmp/go-build -gno-record-gcc-switches"
go clean --modcache
go build
Clean build with no errors
go: dmitri.shuralyov.com/service/[email protected]: unexpected status (https://proxy.golang.org/dmitri.shuralyov.com/service/change/@v/v0.0.0-20181023043359-a85b471d5412.info): 410 Gone
go: dmitri.shuralyov.com/app/[email protected]: unexpected status (https://proxy.golang.org/dmitri.shuralyov.com/app/changes/@v/v0.0.0-20180602232624-0a106ad413e3.info): 410 Gone
The build works without setting the GOPROXY to https://proxy.golang.org
Thanks for the report. CC @dmitshur.
It looks like the module proxy referenced by https://dmitri.shuralyov.com/service/change?go-get=1, https://dmitri.shuralyov.com/api/module, doesn't support looking up versions by hash -- https://dmitri.shuralyov.com/api/module/dmitri.shuralyov.com/service/change/@v/a85b471d5412.info returns 404. proxy.golang.org recently changed to require those kinds of lookups in some cases.
Sorry for the trouble. It'll probably take a bit to figure out what to do about this but we'll get it fixed as soon as we can.
It looks like the module proxy referenced by https://dmitri.shuralyov.com/service/change?go-get=1, https://dmitri.shuralyov.com/api/module, doesn't support looking up versions by hash
This is true. My understanding is that it's a valid thing for a server speaking the module proxy protocol to do, is that right? I based that on https://golang.org/cmd/go/#hdr-Module_proxy_protocol:
A Go module proxy is any web server that can respond to GET requests for URLs of a specified form. The requests have no query parameters, so even a site serving from a fixed file system (including a file:/// URL) can be a module proxy.
A site serving from a fixed file system cannot be expected to respond to arbitrary lookups of versions by hash (since hashes can be specified with various lengths, the full 40 characters or shorter).
FYI
https://proxy.golang.org/dmitri.shuralyov.com/service/change/@v/v0.0.0-20181023043359-a85b471d5412.info returns Not Found
But https://dmitri.shuralyov.com/api/module/dmitri.shuralyov.com/service/change/@v/v0.0.0-20181023043359-a85b471d5412.info actually returns Found
I've temporarily modified the module server on my website to respond to a limited subset of module queries, in commit https://github.com/shurcooL/home/commit/c1141c0e0197df42c3dbad3e8c5200dbd83ca9f9. That change makes the current proxy.golang.org work as expected on dmitri.shuralyov.com/... modules, so this issue (and #32551) should not be occurring anymore (e.g., https://proxy.golang.org/dmitri.shuralyov.com/service/change/@v/v0.0.0-20181023043359-a85b471d5412.info now returns 200 OK).
Once proxy.golang.org is updated to fully resolve this issue, I plan to remove that workaround. Hopefully this helps reduce any disruption in the meantime.
For anyone interested in being able to reproduce this issue, I've created a new test module with a single pseudo-version. Its module path is dmitri.shuralyov.com/test/modtest3:
https://dmitri.shuralyov.com/test/moduleproxy/dmitri.shuralyov.com/test/modtest3/@v/ - the static file system-based module server providing the modtest3 module
https://proxy.golang.org/dmitri.shuralyov.com/test/modtest3/@v/v0.0.0-20181023043359-a85b471d5412.info - returns 410 Gone "not found: " right now, but it should be 200 OK once this issue is fully resolved
The fix is rolled out to proxy.golang.org and Dmitri's test link is working. Thanks for your help and patience.
Thanks!
I plan to remove the temporary workaround from my site tonight, and will test that it continues to work afterwards. Edit: This is done now. I'm not seeing any problems. Please let me know if you do spot a problem.
Thanks for the quick response guys!
Most helpful comment
I've temporarily modified the module server on my website to respond to a limited subset of module queries, in commit https://github.com/shurcooL/home/commit/c1141c0e0197df42c3dbad3e8c5200dbd83ca9f9. That change makes the current proxy.golang.org work as expected on dmitri.shuralyov.com/... modules, so this issue (and #32551) should not be occurring anymore (e.g., https://proxy.golang.org/dmitri.shuralyov.com/service/change/@v/v0.0.0-20181023043359-a85b471d5412.info now returns 200 OK).
Once proxy.golang.org is updated to fully resolve this issue, I plan to remove that workaround. Hopefully this helps reduce any disruption in the meantime.
For anyone interested in being able to reproduce this issue, I've created a new test module with a single pseudo-version. Its module path is
dmitri.shuralyov.com/test/modtest3:https://dmitri.shuralyov.com/test/moduleproxy/dmitri.shuralyov.com/test/modtest3/@v/ - the static file system-based module server providing the modtest3 module
https://proxy.golang.org/dmitri.shuralyov.com/test/modtest3/@v/v0.0.0-20181023043359-a85b471d5412.info - returns 410 Gone "not found: " right now, but it should be 200 OK once this issue is fully resolved