Created attachment 698055 [details] ebuild that fails I wrote a small go-module ebuild for Authelia that works for 4.25.0 but no for 4.27.4 (attached), with no other changes to anything but GO_SUM variable generated by get-ego-vendor. From the looks of the error, it looks like go-module is perhaps having issues dealing with URL encoding of the downloaded file?
Created attachment 698058 [details] ebuild result
I'm working on getting a couple of Smallstep CA ebuilds together and believe this issue is still affecting portage commit "4dbd...3bc9 master". When assigning a deps files (created via command: ```GOMODCACHE="${PWD}"/go-mod go mod download -modcacherw && XZ_OPT='-T0 -9' tar -acf ${PN}-${PV}-deps.tar.xz go-mod``` ), or assigning values to `EGO_SUM` both resulting in similar (if not identitical) issues arising. - With defining deps.tar.xz The path of "/go-mod" in the deps file is unpack at ${WORKDIR}. This results in the go-proxy link and/or processing in not finding any dep modules. - With defining EGO_SUM and deps.tar.xz: 2. The internal path to go-proxy and the URI for the local file in the proxy escaping is creating the wrong paths and resulting in `go mod verify` bailing out after the first failure. Example error: go: github.com/Azure/azure-sdk-for-go/sdk/azidentity@v1.8.1: reading file:///var/tmp/portage/app-crypt/step-cli-0.28.3/temp/go-proxy/github.com/%21azure/azure-sdk-for-go/sdk/azidentity/@v/v1.8.1.mod: no such file or directory If you override `src_unpack` and softlink `${WORKDIR}/go-mod -> ${T}/go-proxy`, a look inside `${T}/go-proxy` show the following path is actually available: ```${T}/go-proxy/github.com/!azure/azure-sdk-for-go/sdk/azidentity@v1.8.2/go.mod``` So not sure if things changed and `go-module.eclass` needs updating or is just sorta borked?
