Hi Simon, It’s a temporary workaround before we can switch to module-awareness builds in Debian.
You can see more details on my short talk at mini debconf Hamburg or another talk with more details at debconf26 if I eventually get visa approved. :) Best regards, -Andrew Simon Josefsson <[email protected]>於 2026年6月24日週三，12:06寫道： > All, > > Is the DEB_GOMINCOMPAT interface documented? Could someone share > knowledge around this? > > It seems for some packages (e.g., torchwood, sigsum-go) the defaults > makes the Go compiler mis-compile code. Setting DEB_GOMINCOMPAT to, > say, 1.24 makes Debian's go compiler produce correct code. > > Wisdom from mw on irc: > > I found out that in go 1.22 there was an optimization intruduced for > httpmux which basically lets http.Servemux.HandleFunc read strings > looking like this: "POST /add-checkpoint" as typed pair of <method>, > <path>. When compiling with go build, the version in go.mod will > enable this optimization based on go 1.24.0. > > In the debian case, that doesn't get picked up and the go compiler > falls back to the pre-optimized behavior. Which means the http routes > will look as the literal string "POST /add-checkpoint", and therefore > 404. > > Adding export DEB_GOMINCOMPAT := 1.24 to debian/rules resolved this. > > As far as I can tell, this does not only affect library or test code but > also binaries. It seems bad that Debian's Go compiler ends up in a > pre-1.22 code generator mode somehow. > > Does anyone have a good explanation of the actual problem here? With > trade-offs how to solve it? > > Is the best way forward really to sprinkle DEB_GOMINCOMPAT:=1.24 into > our debian/rules? I'm confirmed it modify how both torchwood and > sigsum-go behaves. I've seen some debian/rules starting to use this > already (e.g., golang-opentelemetry-collector). > > Another solution would be to pick the Go version from go.mod, but I'm > not convinced it is a good idea. > > /Simon >
