dh_auto_build parses "go list -m all" and lists the modules that still need a mapping. Those lines come in two shapes: go: a/b@v1.0.0: module lookup disabled by GOPROXY=off go: a/b@v1.0.0 requires c/d@v2.0.0: module lookup disabled by GOPROXY=off The regexp takes the first module of the line. On the second shape that is a/b, which is present and already mapped, and c/d, the module that is really missing, never shows up in the report. So the maintainer is told to map a module that needs nothing, and the one to map is not named. Please merge https://salsa.debian.org/go-team/dh-go/-/merge_requests/6 --- a/lib/Debian/Debhelper/Buildsystem/golang.pm +++ b/lib/Debian/Debhelper/Buildsystem/golang.pm @@ -1360,11 +1360,17 @@ sub build { open(my $golist, "-|", "go list -m all 2>&1") or error("Failed to run 'go list': $!"); while (<$golist>) { - # Relevant lines are formatted like this: + # Relevant lines are formatted in one of these two ways: # go: github.com/a/b@v0.2.0: module lookup disabled by GOPROXY=off - # Extract module path after 'go: ' and before '@' + # go: github.com/a/b@v0.2.0 requires github.com/c/d@v1.0.0: module + # lookup disabled by GOPROXY=off + # The module which is missing is always the last one of the line. + # In the second form, the first one is the module which requires it + # and that module is present, so reporting it sends the maintainer + # to map something which is mapped already. push(@missing_mappings, $1) - if m/^\s*go: (.+?)\@v.+: module lookup disabled by GOPROXY=off/; + if + m/(?:^\s*go: |requires )(\S+)\@v\S+: module lookup disabled by GOPROXY=off/; } close($golist); Both regexps on both shapes: line old new go: a/b@v1.0.0: ... a/b a/b go: a/b@v1 requires c/d@v2: ... a/b c/d The real line that showed it, from a dh-go build of golang-github-theupdateframework-go-tuf: go: github.com/google/go-containerregistry@v0.20.7 requires go.opentelemetry.io/auto/sdk@v1.1.0: module lookup disabled by GOPROXY=off go-containerregistry is installed and mapped. auto/sdk is the one that is missing.