[ replying to the list, as I'm subscribed ] On Sat, Sep 05, 2026 at 10:55:33AM -0400, Hermes Jesus Rodriguez Azuaje wrote:
> Recurring failure modes in the sample: > > 1) replace to ./src/... without a go.mod at the replace target, e.g.: > github.com/alecthomas/[email protected] (replaced by ./src/.../chroma): > reading .../go.mod: no such file or directory > (seen in gh, golang-github-armon-go-metrics, > golang-github-awslabs-soci-snapshotter, …) > > 2) dh_auto_configure: > No go.mod found for <import>, unable to create go.work file > (packages still without go.mod) > > 3) dh_auto_build: > Unable to open directory _build/src/.../vN > (major-version path layout) > > 4) stricter module graph messages: > "no required module provides package …" > "module … is replaced but not required" Thanks a lot for this detailed analysis, hope you can include something similar in the bug report. > So the root cause looks like golang-1.27 (+ dh-golang assuming the old > replace/GOPATH-style workflow), not a simultaneous regression in 300 > leaf packages. I am surprised because, in my opinion, we should try hard that the number of FTBFS issues in unstable does not raise suddenly by 300 packages at once without prior notice (even if the root cause is in a single helper package). At some point I will probably end up posting a txt file with a list of packages I can't build to [email protected] and pray that at least someone else can fill the gaps. > I have not filed a bug yet; happy to if that helps. Candidates would be > src:golang-1.27 and/or src:dh-golang, with the a.tar.gz as evidence. I forgot to point out that the bugs regarding golang-1.27 alone were already reported by Tobias a few days ago, and they were only around 50 or so. So I guess it must be src:dh-golang. I leave the details to you. Thanks.
