get_targets() calls "go list -e". With -e, a pattern that matches no package
comes back as if it were a package name. The code drops only the pattern
built from DH_GOPKG, so any other pattern from DH_GOLANG_BUILDPKG stays in
the list of targets.

The build step opens every target as a directory under the build directory,
so it stops here:

  dh_auto_build: error: Unable to open directory
  _build/src/github.com/theupdateframework/go-tuf/v0/... No such file or directory

That path is a pattern, not a directory. The message does not say that one of
the patterns in DH_GOLANG_BUILDPKG matched nothing, and that is the real
problem. I hit this while porting golang-github-theupdateframework-go-tuf to
dh-go. The module in that pattern was not in go.work yet, which was my
mistake in debian/rules, but the message took a long time to understand.

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
@@ -1282,9 +1282,19 @@ sub get_targets {
     );
     my @targets = split(/\n/, $output);

-    # Ensure that the pattern "$ENV{DH_GOPKG}/..." with three
-    # literal dots is not included in the targets.
-    @targets = grep { !m{$ENV{DH_GOPKG}/\.\.\.} } @targets;
+    # With "go list -e", a pattern which matches no package comes back as
+    # if it were a package. Such a target is not a package. Later steps
+    # open every target as a directory of the build directory, so the
+    # build stops with "Unable to open directory", which does not say
+    # which pattern is wrong. Drop those targets and name them instead.
+    my @unresolved = grep { m{/\.\.\.} } @targets;
+    if (@unresolved) {
+        warning("These build patterns match no package:");
+        foreach my $pattern (sort uniq(@unresolved)) {
+            warning("   - $pattern");
+        }
+    }
+    @targets = grep { !m{/\.\.\.} } @targets;

     # Remove all targets that are matched by one of the regular expressions
     # in DH_GOLANG_EXCLUDES.

A warning keeps the current behaviour of going on with the targets that did
resolve. An error would be fine by me as well, and it would catch the case
where a package silently stops building part of itself.