Package: dh-go
Version: 1.68
Severity: important
_get_go_module_dependencies in Debian/Debhelper/Buildsystem/golang.pm takes the
first non-space token of every line inside a "require (" block:
if (m/^\s*(\S+)/ and $inside_require_directive) {
push(@dependencies, $1);
}
A comment on a line of its own is a normal thing to find there, and it yields
"//" as a module name. _create_go_work_file then reaches its loop over
dependencies that are "actually present", where
my $filepath = $this->get_buildpath("src/$module");
next if not -e $filepath;
collapses "src///" to the build directory's own src/, which exists, so the line
is written:
replace // => ./src///
Go then refuses to parse the whole workspace:
go: errors parsing go.work:
_build/go.work:1631: usage: replace module/path [v1.2.3] => other/module
v1.4
Skipping comment lines in that loop fixes it:
next if m{^\s*//};
Still present in debian/sid at commit 260d81a4525e (2026-09-20), which is newer
than 1.68. I looked for an existing report first: #1146815 and #1145862 are both
about go.work and both closed, but neither is this.
Three separate go.mod files triggered this in one build of syft: upstream's own
go.mod, one of the go.mod fixtures the golang cataloger uses in its testdata,
and howett.net/plist from golang-howett-plist-dev. A trailing comment on a
require line is handled correctly; only a comment on its own line is affected.
The testdata one is worth a second look: dh-go parses every go.mod it finds
under the build tree, so a fixture that is deliberately malformed, and never
built, can still stop the package from building.
