On Sun, Jul 12, 2026 at 3:26 PM Nilesh Patra <[email protected]> wrote: > > "DefaultGODBUG" is found. > Got it. I've written a check and it emits the following for hugo: > > W: hugo: binary-contains-defaultgodebug-options > asynctimerchan=1,containermaxprocs=0,cryptocustomrand=1 ... [/usr/bin/hugo] > be a bit better, please suggest if something else would sound better.
I would suggest to use `go-binary-contains-godebug-overrides` instead of `defaultgodebug-options` to avoid confusion. The phrase "defaultgodebug" makes it sound like a standard go default, which is not what upstream intends. Other distributions and upstreams have switched to module-aware builds. So all the go binary should builds with the go version line inside go.mod file to set a correct behaves in the built binary. > Not sure how useful the individual options are, I wonder if it makes sense to > not emit them at all. I wrote a simple script for show the behavior from different go versions: https://salsa.debian.org/helmutg/godebug-analysis/-/blob/main/version-check-DefaultGODEBUG.output?ref_type=heads > > My personal feeling is that lintian should emit a warning if DefaultGODEBUG > > is detected in a binary. > > I'm worried if this will annoy maintainers. As a downstream maintainer, > unless someone tries a patch > to explicitly use DefaultGODEBUG, I am not sure what they can do about it, as > this could be coming > directly off upstream. > > Do you have suggestions to fix this if found in a downstream package? > > I tried digging around for a way to fix this for hugo for instance but don't > find anything obvious. OTOH, more > verbose compilation suggests these come from compiler itself. If one runs > > `go version -m /usr/bin/hey` or `go version -m /usr/bin/certinfo` these > options are everywhere. Your concern is right on the spot. These settings show up everywhere because Debian still uses `GO111MODULES=off` for building packages. This forces the Go compiler to ignore the go version line inside go.mod, causing it to automatically inject these unexpected and insecure backward-compatibility level (default to go 1.16) settings into the final binary. Maintainers cannot fix this in their individual packages right now. Since this is caused by our Debian packaging build style rather than an upstream choice, Lintian should audit and provide warning about these specific unexpected vaule to avoid the binary behaves different from upstream expected. Fortunately, Toddy has uploaded a fixed version of dh-golang 1.66 to Experimental, which sets `GO111MODULES=on` by default. Please consider pulling dh-golang 1.66 into your test environments and sharing your results. And this is a major change in Go ecosystem in Debian. We need more people to test their packages with the new dh-golang from Experimental and spot any bugs early. Best regards, -- -Andrew
