Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: go get fails for module from fossil repo #42323

Closed
clagraff opened this issue Nov 1, 2020 · 2 comments
Closed

cmd/go: go get fails for module from fossil repo #42323

clagraff opened this issue Nov 1, 2020 · 2 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@clagraff
Copy link
Contributor

clagraff commented Nov 1, 2020

I am trying to use a self-hosted Fossil repository for one of my packages, https://scm.lagraff.me/openfray/tui
I receive an error (shown below) from go get as it fails to find the latest revision of the module.

The source of the error appears to be in the fossilParseStat (vcs.go L570) function, where it is expecting a line to start with uuid: so it can extract the hash of the desired revision.

However, since Fossil Check-in [8ad5e469] (May 2020) the desired line from fossil info has been changed from starting with uuid: to hash:, and therefore an error occurs because it cannot find any matching lines.

The code in fossilParseStat should be updated at either look for hash:, or possibly both to maintain backwards compatibility with older versions of fossil running in the wild.

What version of Go are you using (go version)?

$ go version
go version go1.15.3 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/clagraff/.cache/go-build"
GOENV="/home/clagraff/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/clagraff/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/clagraff/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/clagraff/Source/goroot/src/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-build930617405=/tmp/go-build -gno-record-gcc-switches"

What did you do?

$ go get scm.lagraff.me/openfray/tui@latest
go: finding scm.lagraff.me/openfray/tui latest
go get scm.lagraff.me/openfray/tui@latest: unexpected response from fossil info: "hash:         4687434da95e770216c0fb2e48b9cd21480c0bec 2020-11-01 16:52:23 UTC\nparent:       2ca114f848bf0bd8befc84dea4ee7c236ea6e51c 2020-11-01 16:42:39 UTC\ntags:         trunk, latest\ncomment:      Fix readme package change (user: clagraff)\n"

What did you expect to see?

$ go get scm.lagraff.me/openfray/tui@latest
# No error output

What did you see instead?

Received the following error from the go get:

go get scm.lagraff.me/openfray/tui@latest: unexpected response from fossil info: "hash:         4687434da95e770216c0fb2e48b9cd21480c0bec 2020-11-01 16:52:23 UTC\nparent:       2ca114f848bf0bd8befc84dea4ee7c236ea6e51c 2020-11-01 16:42:39 UTC\ntags:         trunk, latest\ncomment:      Fix readme package change (user: clagraff)\n"
clagraff added a commit to clagraff/go that referenced this issue Nov 1, 2020
…sh prefix

A recent update of the Fossil SCM application changes the line prefix when the fossil info command is used.
Instead of the revision hash starting with "uuid:", it has been changed to "hash:".

Fossil check-in introducing this change: https://fossil-scm.org/home/info/8ad5e4690854a81a

To support both older and new versions of fossil, fossilParseStat will now check for either version of the prefix
when attempting to find the line containing the hash of the desired revision.

Fixed golang#42323
clagraff added a commit to clagraff/go that referenced this issue Nov 1, 2020
…sh prefix

A recent update of the Fossil SCM application changes the line prefix when the fossil info command is used.
Instead of the revision hash starting with "uuid:", it has been changed to "hash:".

Fossil check-in introducing this change: https://fossil-scm.org/home/info/8ad5e4690854a81a

To support both older and new versions of fossil, fossilParseStat will now check for either version of the prefix
when attempting to find the line containing the hash of the desired revision.

Fixes golang#42323
@gopherbot
Copy link

Change https://golang.org/cl/267080 mentions this issue: cmd/go/internal/modfetch/codehost: add support for new fossil info hash prefix

@bcmills bcmills added this to the Go1.16 milestone Nov 2, 2020
@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 2, 2020
clagraff added a commit to clagraff/go that referenced this issue Nov 2, 2020
…sh prefix

A recent update of the Fossil SCM application changes the line prefix when the fossil info command is used.
Instead of the revision hash starting with "uuid:", it has been changed to "hash:".

Fossil check-in introducing this change: https://fossil-scm.org/home/info/8ad5e4690854a81a

To support both older and new versions of fossil, fossilParseStat will now check for either version of the prefix
when attempting to find the line containing the hash of the desired revision.

Fixes golang#42323
clagraff added a commit to clagraff/go that referenced this issue Nov 2, 2020
…sh prefix

A recent update of the Fossil SCM application changes the line prefix when the fossil info command is used.
Instead of the revision hash starting with "uuid:", it has been changed to "hash:".

Fossil check-in introducing this change: https://fossil-scm.org/home/info/8ad5e4690854a81a

To support both older and new versions of fossil, fossilParseStat will now check for either version of the prefix
when attempting to find the line containing the hash of the desired revision.

Fixes golang#42323
clagraff added a commit to clagraff/go that referenced this issue Nov 3, 2020
…sh prefix

A recent update of the Fossil SCM application changes the line prefix when the fossil info command is used.
Instead of the revision hash starting with "uuid:", it has been changed to "hash:".

Fossil check-in introducing this change: https://fossil-scm.org/home/info/8ad5e4690854a81a

To support both older and new versions of fossil, fossilParseStat will now check for either version of the prefix
when attempting to find the line containing the hash of the desired revision.

Fixes golang#42323
@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Nov 4, 2020
@gopherbot
Copy link

Change https://golang.org/cl/267884 mentions this issue: cmd/go: set FOSSIL_HOME in TestScript/mod_get_fossil

gopherbot pushed a commit that referenced this issue Nov 9, 2020
Without HOME or FOSSIL_HOME set, this test fails for me when run with
fossil 2.12.1.

Also verify that the 'go get' command produces an executable, which
helps to verify that the files extracted by fossil are not corrupted.

Updates #42323

Change-Id: Ie6f5d2eab6a6338e997a4f85591195e5bd9a0d37
Reviewed-on: https://go-review.googlesource.com/c/go/+/267884
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
@golang golang locked and limited conversation to collaborators Nov 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants