Kashyap5d ago
Michael Stapelberg 🐧🐹😺

New blog post 🥳

Stamp It! All Programs Must Report Their Version

> […]
>
> In this article, I’ll explain how 3 simple steps (Stamp it! Plumb it! Report it!) are sufficient to save you hours of delays and stress during incident response.

Read more: https://michael.stapelberg.ch/posts/2026-04-05-stamp-it-all-programs-must-report-their-version/

#nix #golang #linux

Apr 5 at 5:04pmWeb
Show threadMichael Stapelberg 🐧🐹😺6d ago

Aside from the article itself, there’s also a repository to illustrate the technique at https://github.com/stapelberg/stampit, a README where we can collect language ecosystem build stamping status, and an agent SKILL.md to audit your fleet! :)

And of course, I researched **the Nix full picture diagram** (see attached) for this article 🤯

#nix #nixos

Show threadMichael Stapelberg 🐧🐹😺6d ago

There’s probably some mistakes in there, because I am somewhat pressed for time and this rabbit hole turned out *very deep*.

Please do send corrections (with references, ideally) if something seems wrong! Thanks!🙏

Show threadequinox6d ago

@zekjur I made the FRR library executable (no I didn't get confused there) just so it can report its version. Sadly, this broke at some point due to some changes in GCC re. assumptions about stack alignment (assumes 0/16, but it's 8/16 on x86_64 now), need to push a fix for that…

I invite FRR users to try running libfrr.so, maybe your version still works 😉

Show threadAtemu6d ago

@zekjur

Honestly, we should have that in the go builder by default.

Perhaps even stdenv. We could then have a standard fakegit hook that returns the rev for the common rev checking commands which would work for any build process that does git integration via execve.
Rev info for regular nixpkgs packages with non-flake input srcs would need to be locked along with version and src hash on update; ideally automatically and into a plain JSON file.

Show threadMichael Stapelberg 🐧🐹😺6d ago

@Atemu Are you involved with the Go builder in Nix? :)

Having the workaround enabled by default until a cleaner fix lands (I spotted https://go-review.googlesource.com/c/go/+/762920 earlier today) sounds great to me!

Show threadNiklas Korz6d ago
@zekjur @Atemu You can find involved maintainers in https://github.com/NixOS/nixpkgs/commits/master/pkgs/build-support/go but to save you the roundtrip: @katexochen
History for pkgs/build-support/go - NixOS/nixpkgs

Nix Packages collection & NixOS. Contribute to NixOS/nixpkgs development by creating an account on GitHub.

GitHub
Show threadPaul Meyer5d ago
@niklaskorz @zekjur @Atemu Yes, I read the article, hadn't had a chance to look at the code yet.
Show threadPaul Meyer22h ago
@niklaskorz @zekjur @Atemu I like the proposal of Daniel: https://github.com/golang/go/issues/77020#issuecomment-4195228859
Let's wait and see if we can actually get that as part of 1.27? Then we wouldn't need to implement a temporary workaround in nixpkgs.
proposal: cmd/go: add -buildversion build flag · Issue #77020 · golang/go

Background I yearn for the day debug.BuildInfo.Main.Version is all a binary needs to know its own version. buildInfo, ok := debug.ReadBuildInfo() if !ok { panic("can't retrieve version: this binary...

GitHub
Show threadzhenech6d ago

@zekjur in Git, you can mark files as export-subst [1] and thus place the describe output in git-archive generated tarballs (like the ones GitHub offers) via "$Format:%(describe)$" or similar. Putting that into the VERSION file makes `git describe || cat VERSION` do the right thing in 99.999%[2] of the cases.

[1] https://git-scm.com/docs/git-archive/2.29.0#ATTRIBUTES
[2] not scientifically proven

Git - git-archive Documentation