During a partial archive rebuild in unstable, more than 300 Go packages
fail to build. The ~50 separate reports already filed against
src:golang-1.27 by Tobias are orthogonal. The mass FTBFS is a
regression in dh-golang / dh-go 1.66–1.67 (module-aware / go.work
upload, 2026-09-02), not in golang-1.27 itself.

Money shot (same Go 1.27.0, only dh changes):

  golang-goji 2.0.2-2
    dh-golang 1.65:  PASS
    dh-go     1.67:  FAIL  (No go.mod → go.work)

  golang-github-armon-go-metrics 0.4.1-2
    dh-golang 1.65:  PASS
    dh-go     1.67:  FAIL  (replace …/go.mod: no such file)

1.65 is the last pre-workspace upload (2026-05-30). 1.66/1.67
introduced the go.work / replace path that hard-fails these packages.

== Full A/B matrix (build-go-ab.sh, sbuild unshare/sid, fresh chroot) ==

  Package: golang-goji 2.0.2-2  (mode: no go.mod → go.work)

    Go 1.26.7 + dh-go 1.67:      FAIL  (same go.work error)
    Go 1.27.0 + dh-go 1.67:      FAIL  (same go.work error)
    Go 1.27.0 + dh-golang 1.65:  PASS

  Package: golang-github-armon-go-metrics 0.4.1-2
  (mode: replace without go.mod at target)

    Go 1.26.7 + dh-go 1.67:      FAIL  (datadog-go replace / go.mod)
    Go 1.27.0 + dh-go 1.67:      FAIL  (identical)
    Go 1.27.0 + dh-golang 1.65:  PASS

Helper used for the A/B (optional, GPL-2+):
https://salsa.debian.org/-/snippets/871
  ./build-go-ab.sh <srcpkg> <go-ver> [dh-ver]

== Recurring failure modes in the 300+ affected packages ==

Sample collected by Santiago Vila <sanvila@debian.org>; the build
logs were temporarily available at
https://people.debian.org/~sanvila/golang-tmp/a.tar.gz (358 logs).
The URL is temporary; please contact sanvila@debian.org before it
expires if a copy is needed.

  1. "replace to ./src/...: reading .../go.mod: no such file
     or directory"
       e.g. gh, golang-github-armon-go-metrics,
       golang-github-awslabs-soci-snapshotter.

  2. "No go.mod found for <import>, unable to create go.work file"
       e.g. golang-goji (A/B above).

  3. "Unable to open directory _build/src/.../vN"
     Packages using the major-version (v2, v3, ...) path layout.

  4. Stricter module-graph errors: "no required module provides
     package ..." and "module ... is replaced but not required".

These are not 300 independent leaf-package bugs. They share one
underlying cause: dh-go 1.66/1.67's auto-generated go.work / replace
graph does not match what many packaged trees provide.

== Expected ==

dh-golang / dh-go should:
  - regenerate go.work / replace directives so Go can resolve them, and
  - fall back gracefully for source trees with no go.mod,
  rather than hard-failing hundreds of packages at once.
  Alternatively keep classic dh-golang for leaf packages and ship the
  module-aware path as opt-in until the archive is ready.

== Workaround ==

Rebuild with dh-golang 1.65 (or 1.63 from trixie) restores builds for
at least golang-goji under golang-1.27. Not a long-term fix for the
archive; needs a proper fix or rollback/opt-in in src:dh-golang.

Thanks.

thanks

@ajqlee: I don't understand, wasn't dh-go supposed to be opt-in for the
transition period, as a way to test that packages will be able to build
in the future?

 From what I see in the Transition Guide [1], the dh-go dependency have
to be explicitly specified, but when I look at the example [2] it shows
that dh-golang has to be removed. However packages initially generated
with dh-make-golang do not have an explicit dependency on dh-golang, but
only on dh-sequence-golang.

[1]: https://wiki.debian.org/Teams/DebianGoTeam/ModuleAwareBuilds
[2]:
https://salsa.debian.org/go-team/packages/pocketbase/-/commit/4ddb91b866daf59b37def89e58cef52a92d1c65b

+1 -- the guide says explicit dh-go, pocketbase does that, but dh-make-golang
still emits dh-sequence-golang. Meanwhile dh-golang 1.67 in unstable broke
packages that had not opted in yet (#1146815). What should new go-team packages
use in Build-Depends today?

El dom, 6 sept 2026 a las 8:34, Nicolas Peugnet (<nicolas@club1.fr>) escribió:

Hi Nicolas,

You are right. `dh-make-golang` is out of date and still generates
legacy `dh-sequence-golang` setup instead of the new `dh-go`
buildsystem.

I noticed the same issue above when packaging
`golang-github-pocketbase-ozzo-validation-v4` with a major API version
/v4 in its XS-Go-Import-Path.
`dh-make-golang` still generates legacy build-deps uses `dh-golang`
instead of `dh-go`, and also generates legacy source, binary package
names and vcs-tags without append `-v4` API verision suffix to match
the upstream import path.

Since `dh-make-golang` is also the primary tooling for Go packaging in
Debian, having it out of date creates extra manual work and generates
outdated packaging files.

Does any dh-make-golang maintainers available to help to make it
generates modern, module-aware configurations and handles major API
version suffix correctly?

Best regards,

I'm sorry, but this does not answer my question. Wasn't the "dh-go"
package especially introduced to keep the default to "dh-golang" for the
time being, letting maintainers try the new module-aware locally by
explicitly adding a dependency to "dh-go"?

Hi Nicolas,

No. The trying period with `dh-golag 1.66~exp+` in experimental stage
already gone.

We have been in the Real-World transitioning to `dh-go` stage as
`dh-golang` will possibily goes away for forky release.

Best regards,

Hi,

It seems there is already a PR at
https://github.com/Debian/dh-make-golang/pull/325 but it is pending
review from you or others familiar with the topic.

Personally I feel it does not make sense to me to have all Go
libraries to change the source package name on every new major
version, so I find it hard to judge whether the implementation details
of it make sense or not and thus I don't think I should review it.

Hi Otto,

I understand your concern on the source package rename part. However,
this is similar to how we bump SONAME for C/C++ libraries, which also
requires going through the NEW queue for each bump.

In the Golang world, the Major API Version acts like a C/C++ SONAME.
Upstream usually maintains multiple major versions at the same time,
and they live in different import paths.

I can easily got some benifits with versioned suffix for the package in my mind:
* Multiple Version Co-Existence Possible: when go.mod contains same
module in different path or versions.
* Clear Package Naming: Matching the package name with the upstream
import path follows our naming convention and avoids confusion.
* Easier Package Queries: It makes it simple to query whether a
specific Go import path is already packaged in Debian.
* Identical Build Paths: Building with the exact same import path as
upstream ensures we can receive upstream support.
* Easier Debugging: Different path will be packaged in different
package. It makes it easier to reproduce and debug issues on both
upstream and Debian environments.
more...etc

I know it requires passing through the NEW queue for echo major
version bumps, and it matches how Debian handles library ABI
transitions.

Best regards,

Andrew Lee <ajqlee@debian.org> writes:

But only for the NEW binary package.  The Debian source package name
does not change with C/C++ soname bumps.

I agree that we should use golang-*-vX-dev consistently.  I went through
many different ideas that I thought were better until I arrived at this
(and made several confused posts about this to list many months ago..).

I'm less confident that renaming all source packages is needed or a good
use of our time...  I won't object if anyone else does it though, but I
don't envy the task.  I think renaming binary packages could be
sufficient, and adopting the new source package name style could be
opt-in going forward for new packages or API versions.

/Simon

Hi Simon,

Thank you very much for your input. Please allow me to reply to both
of your input together.

You are right. C/C++ libraries keep the same source package name while
changing binary package names. However, for Go packages, different
import paths usually come from different upstream git tags or
branches, and sometimes even in different hosts(eg: upstream rename to
their new host, or migrate to codeberg).

Here is a comparison between using `One Source Package` vs `Different
Source Packages` for handling multiple major API versions:
Fixing Bugs and Security Issues
=========================
One Source Package: Requires complex branch management and build
setup. Have to rebuilds all binary packages together in one source
package update.
Different Source Packages: Allows us to fix and update in one major
API version without touching the other.

Handling `go.mod` with Multiple Major Versions
====================================
One Source Package: Requires source package update to build multiple
Major API version binaries setup and maybe requires to symlinks to
handle upstream path name chanegs.
Different Source Packages: Works simply, just like any independent package.

Salsa Repository Management
========================
One Source Package: Needs special branch management to build multiple
different Majro API version binaries from one single source package.
Different Source Packages: Easy to maintain. We can fork the
repository and keep most files under `debian/` as they are, without
complex branching or build setup.

And I agree that making this opt-in for new major versions `Sounds Easier`. :)
However, skipping source package renames will causes problems for both
new tooling and maintainers:

Maintainer Confusion:
  It makes it much harder for maintainers to look up dependencies or
quickly check if a specific Go import path is already packaged in
Debian or not
Directory Structure:
  dh-go expects the package to provide filesystem structure to match
it's go import path when lookup modules.
Build Failures:
  If the source package does not match the major version import path,
dh-go cannot find the module root during the build.
More Maintenance:
  Keeping legacy source package names allows us to keep old hacks in
existing legacy packages, but required to add more hacks manually
across all downstream packages and hacks also takes time for
maintaining. Complex for maintaining/creating downstream packages.

Conclusion
=========
If we rename/fork source package to match the upstream go import path
and provde the same directory structure from upstream. We can simply
create different source package by fork the repo for Major API Version
bump or upstream rename/migrate to new hosts. And Module-Aware Builds
under Go Workspace with `dh-go` may work soomthly without needed to
add extra hacks anymore.

Happy hacking,
-Andrew

Am 05.09.26 um 14:01 schrieb Santiago Vila:

I think that's probably my fault, due to an error made in the control
file of dh-go.

dh-go is currently intended to be opt-in for golang packages, just like
Nicolas wrote. All packages still using dh-golang (with GOPATH) should
not be affected by this upload.

However, I've just noticed that I accidentally left the line "Provides:
dh-sequence-golang" in d/control, so that now both dh-golang and dh-go
provide that virtual package.

I suspect that all build failures which Santiago saw in the rebuild of
unstable are packages which Build-Depend on this virtual package. During
the rebuild, some of the packages got dh-go as a build dependency (and
failed), others got dh-golang.

I've just uploaded a new version of dh-go *without* the virtual package
dh-sequence-golang, so that hopefully all FTBFS bugs from Santiago's
rebuild are resolved.

Sorry for this!

I'm closing the bug report now.

Regards,
Tobias