| 15 Feb 2026 |
 neobrain | Is there a list of attributes available via builtins.getFlake? Docs only mention "outputs and some metadata", and I'm wondering what metadata is included specifically | 09:59:05 |
 niko β‘οΈ | On top of inputs and outputs, you get all the metadata of every input. The common attributes are type, lastModified (and lastModifiedDate), narHash, and then there are type specific attributes like repo and owner for forge types, rev, shortRev for anything git-esque (including forge-specific types), and probably some other ones as well. I don't think there's a specific list anywhere though it's just another one of those things you have to know, or know where to look for themβ’ | 15:31:38 |
| neobrain | hmm I was trying to get the git rev from the current flake using getFlake ./., but the result of that contains no rev attribute. Though it seems doing something like this would require an impure build anyway, so not really what I'm looking for | 15:44:12 |
| neobrain | * hmm I was trying to get the git rev from the current flake using (getFlake (toString ./.)).rev, but the result of that contains no rev attribute. Though it seems doing something like this would require an impure build anyway, so not really what I'm looking for | 15:46:03 |
| neobrain | Ah, but what you're saying is that this isn't valid syntax to begin with. I only get this rev attribute for the inputs, so e.g. (getFlake (toString ./.)).inputs.nixpkgs.rev would work, but the git rev of the main flake isn't accessible | 15:48:32 |
 aloisw | IIRC this kind of attributes is omitted when the worktree is dirty. | 15:50:13 |
| neobrain | ohhhh turns out I can just get the git rev using self.dirtyRev π² | 15:54:21 |
| niko β‘οΈ | Yes, and (getFlake ./.) is the same as self pretty much | 15:59:02 |
|  parrot (he/him) changed their display name from ΟΞ±Π³Π³oΡ (he/him) to Parrot (he/him). | 16:50:28 |
|  sparogy (he/him) joined the room. | 17:36:25 |
 kuruczgy | Hi! I am debugging a build reproducability issue, would need some help.
I am running nix-build /nix/store/nl7s4ncvjkf7br9zjc86k73ph3w4jkvf-linux-6.19.0.drv --check --keep-failed, but it just completes the build, and does not flag any issues. /nix/store/vyfilqz68s0hld82n37l0s9p1nzsjcdr-linux-6.19.0-modules is the modules output of that derivation.
I am pretty convinced that there is an issue, I compared the output to the one built by GHA, there is a single bit diff, dd if=/nix/store/vyfilqz68s0hld82n37l0s9p1nzsjcdr-linux-6.19.0-modules/lib/modules/6.19.0/modules.dep.bin bs=1 skip=75086 count=20 outputs kerlel/fs/bfs/bfs.ko, which definitely seems wrong. (Note "kerlel" instead of "kernel")
In theory it could be possible that it's some input of this derivation that's already poisoned, but in this case I don't see how that could produce this result. Is there a way to tell nix to keep the build and output directories, even if it does not see a diff? Is it perhaps possible that --check is not checking the store contents directly, but some stored hash?
| 21:45:41 |
| kuruczgy | Ah yeah:
$ nix-store --verify-path /nix/store/vyfilqz68s0hld82n37l0s9p1nzsjcdr-linux-6.19.0-modules
path '/nix/store/vyfilqz68s0hld82n37l0s9p1nzsjcdr-linux-6.19.0-modules' was modified! expected hash 'sha256-9c9vmIar3f/xtbpfTVFugBRLqdCI7dS6aibpSxZRrCA=', got 'sha256-WWV4alvXbw7zgmG0yHrlnMS7W5NcxgtTjowTQkJ8dAc='
| 21:48:12 |
| kuruczgy | In this case nix-build --check not checking the actual store contents seems like quite a bit of a footgun... | 21:48:36 |
 0x4fbb09 it/its β―βΞΞ | --check not checking the store contents is fine unless you have store corruption, which would only happen if your FS/disk or RAM was fucked | 21:52:55 |
| 0x4fbb09 it/its β―βΞΞ | (you may want to run nix-store --verify --check-contents, i suspect you have more than just that corrupted?) | 21:53:26 |
| kuruczgy | Yeah in this case it's pretty clear that this is a HW fuckup.
Good point on verifying my whole store, but unfortunately I could entirely see that this is a one-off, and my non-ECC RAM HW is just working as intended... | 21:55:46 |
| kuruczgy | Anyway, is there a command to actually rebuild/repair this store path? nix-store --repair-path only talks about substituters, and nix build --rebuild/nix-build --check clearly does not detect the issue or try to replace anything. | 22:03:35 |
| kuruczgy | Though I guess it would probably be smart to rebuild anything that depends on this, so probably I want a recursive delete anyway... | 22:05:01 |
 fumnanya | couldn't you just..... nix-store --delete /nix/store/hash and rebuild your system/package? | 22:07:06 |
| kuruczgy | nix-store --delete ... refuses to delete it since some other paths depend on it, and I don't see a "delete this path and anything that depends on it recursively" option | 22:08:05 |
| fumnanya | you could probably do that with some xargs magic, see here
what does nix-store -q --referrers-closure /nix/store/vyfilqz68s0hld82n37l0s9p1nzsjcdr-linux-6.19.0-modules give?
| 22:21:27 |
| kuruczgy | Well, quite a few nixos-systems... In fact, I just realize this is my booted kernel π
$ nix why-depends /run/booted-system /nix/store/vyfilqz68s0hld82n37l0s9p1nzsjcdr-linux-6.19.0-modules
/nix/store/wmr5xisvxzqgwwcvk9nm4p5f07w0xc3v-nixos-system-cobalt-26.05
ββββ/nix/store/02qwxxfw4bs7vhlgf6k3v69lrz5vy2hz-linux-6.19.0-modules
ββββ/nix/store/vyfilqz68s0hld82n37l0s9p1nzsjcdr-linux-6.19.0-modules
| 22:24:18 |
| kuruczgy | Ok, so deletion is definitely not an option, I need some in-place replacement | 22:24:40 |
| fumnanya | hmmm you probably didn't build your own kernel though...it probably came from cache.nixos.org.....so shouldn't repair-path work then? | 22:25:16 |
| kuruczgy | I definitely did build my own kernel | 22:25:29 |
| kuruczgy | nix-store --verify --check-contents finished, it found one other bad path in the whole store, so this does not seem like a widespread corruption.
reading the Nix store...
checking path existence...
checking link hashes...
checking store hashes...
path '/nix/store/d61f7l6yyqk1n5kljzy893iv9xr6zgmh-curl-impersonate-1.4.2' was modified! expected hash 'sha256-By0RCVGwSBN4icsLsIgCtxBc7n2Od840S4p0g/zPka0=', got 'sha256-pQpattmS9VmO3ZIQUFn66az8GSmB4IvYhTTCFn6SUmo='
path '/nix/store/vyfilqz68s0hld82n37l0s9p1nzsjcdr-linux-6.19.0-modules' was modified! expected hash 'sha256-9c9vmIar3f/xtbpfTVFugBRLqdCI7dS6aibpSxZRrCA=', got 'sha256-WWV4alvXbw7zgmG0yHrlnMS7W5NcxgtTjowTQkJ8dAc='
warning: not all store errors were fixed
So I guess it's either the RAM or the SSD that's the culprit.
| 22:43:02 |
| kuruczgy | Well I just rebooted and both corruptions are gone π | 22:48:04 |
| fumnanya | oh wow....yay(?) | 22:49:21 |
| fumnanya | maybe do a memtest overnight hehe | 22:49:59 |
| 16 Feb 2026 |
| parrot (he/him) changed their display name from Parrot (he/him) to parrot (he/him). | 01:40:46 |
