dh-go (1.69) [PTS] [DDPO]

OK: VCS matches the version in the archive

Git: https://salsa.debian.org/go-team/dh-go.git
JSON
Enter a full Vcs-* header, supported schemes are: Vcs-Bzr, Vcs-Cvs, Vcs-Darcs, Vcs-Git, Vcs-Hg, Vcs-Mtn, Vcs-Svn.
For Vcs-Git append -b branch to select the branch name; append [subdir] if the debian/ directory is not in the repository root.
The next upload will reset the information from the source package headers.
Branch: debian/sid
Path: debian/changelog
Repo size: 339968
Browser: https://salsa.debian.org/go-team/dh-go
Last scan: 2026-10-11 02:03:34+00
Next scan: 2026-10-17 08:48:00+00
CI pipeline status: success

Debian changelog in Git:

dh-go (1.69) unstable; urgency=medium

  [ Dr. Tobias Quathamer ]
  * Check that XS-Go-Import-Path is equal to module path from go.mod
  * Do not remove dh_dwz from build sequence in compat >= 14
  * Revert "Move setup of golang build environment into pre_building_step()"
    Thanks to Juan Manuel Mendez Rey <juan.mendezr@proton.me> (Closes: #1149945)
  * Update example to use debhelper v14
  * Run perltidy
  * Strip comments from go.mod (Closes: #1149022)
  * Use debhelper v14

  [ Juan Manuel Méndez Rey ]
  * Keep symlinks when copying sources.
    Three file tests follow the link they are given, so symlinks to directories
    and dangling symlinks are silently dropped:
      - the DH_GOLANG_INSTALL_EXTRA walk in configure uses -f, which is false
        for a directory and for a broken link;
      - the main source walk in configure uses -e, which is false for a broken
        link;
      - install uses -d before the branch that recreates a symlink, so a link
        to a directory returns early, and File::Find does not descend into it
        either, so the subtree goes too.
    Test suites ship both kinds deliberately. The first of the three is
    https://bugs.debian.org/842755, reported in 2016 and still open.
  * Follow requirements of modules installed under another path
  * Follow requirements of every module in go.work
    _create_go_work_file only walked the requirements of the main module
    (DH_GOPKG). A multi-module repository whose root module requires nothing,
    such as github.com/GoogleCloudPlatform/opentelemetry-operations-go, lists
    its submodules in go.work but their requirements were never followed, so
    modules they need (for example the requirements of grpc-gateway/v2) were
    neither replaced nor stubbed and target expansion failed with "module
    lookup disabled by GOPROXY=off".
    Seed the walk with the requirements of every module written as a use
    directive as well.
  * Sequence: fix inverted compat guard around dh_dwz removal.
    The guard removes dh_dwz at compat >= 14, where debhelper does not run it
    anyway, and leaves it in the sequence at compat 13, where it does run and
    fails on Go binaries with 'Unknown debugging section .debug_addr'.
    (Closes: #1148172)
  * Write a go directive into generated minimal go.mod files
  * Create go.work from the raw build packages, not from go list
    _create_go_work_file() expanded DH_GOLANG_BUILDPKG with get_targets(),
    which shells out to `go list`. That cannot work there: the workspace
    `go list` needs is the file being written, so any pattern ends up
    contributing nothing and the resulting go.work has no use directive.
    A multi-module package that passes bare module paths to
    dh_auto_configure and "module/..." patterns to dh_auto_build hits this
    whenever the workspace is missing at build time, which is what
    dh_golang_autopkgtest arranges: it disables override_dh_auto_configure
    and injects one that only copies the installed sources. The build then
    fails with "matched no packages" for every pattern, followed by "go: no
    modules were found in the current workspace".
    Strip a trailing /... from each entry instead and let the existing loop
    locate the go.mod files; for bare paths the result is unchanged.

 -- Dr. Tobias Quathamer <toddy@debian.org>  Mon, 05 Oct 2026 17:07:15 +0200

This branch is even with tag debian/1.69