Sender | Message | Time |
---|---|---|
8 Oct 2024 | ||
@jade_:matrix.org | In reply to @waltmck:matrix.org not only that, there cannot really exist one without it being a giant pain in the neck. maintaining date based dependencies is a pain in the neck, and it is unclear how one would even "properly" schedule one in step with nixpkgs and in step with our own release schedule since nixpkgs takes a while to get new versions of lix. the correct way for this to be handled is if something like our overlay is upstreamed into nixpkgs itself. | 01:34:16 |
uep | FWIW, this is mildly annoying too.. (but not worth the effort)
| 01:57:57 |
uep | I don't really know why the nix attribute it pulls in isn't the one overlayed to lix, but.. whatever | 01:59:05 |
@jade_:matrix.org | In reply to @uep:matrix.orgit's because of something more depressing | 02:06:18 |
@jade_:matrix.org | https://github.com/NixOS/nixpkgs/pull/313497 | 02:06:44 |
@jade_:matrix.org | this is the fix, it just needs flake support ripped out and the merge button pressec | 02:06:55 |
@jade_:matrix.org | * this is the fix, it just needs flake support ripped out and the merge button pressed | 02:06:56 |
@jade_:matrix.org | the thing it is replacing has no flake support and the flake support in the replacement isn't quite good enough by some peoples' estimation | 02:07:30 |
uep | sigh | 02:23:53 |
@jade_:matrix.org | like. they're right | 02:23:59 |
uep | I'm all for user-friendly convenience commands, but isn't this "just use the repl" ? | 02:24:17 |
@jade_:matrix.org | but this means that the flake support should be removed and we should ship that as a second change that is actually reviewable | 02:24:20 |
uep | yah | 02:24:34 |
ext0l | for the record i use https://github.com/NixOS/nixpkgs/issues/97855#issuecomment-1075818028 for nixos-option flake compat | 03:48:13 |
Lily Foster | In reply to @ext0l:matrix.orgi do downright criminal stuff like NIX_PATH=nixpkgs/nixos=/path/to/cursed/nixos/entrypoint/shim:nixpkgs=/path/to/normal/nixpkgs with nixos entrypoint shim https://github.com/lilyinstarlight/foosteros/blob/ae4b316dbd297d23dbd13a078b15797805109f9c/nixos.nix | 04:46:39 |
Lily Foster | (https://github.com/lilyinstarlight/foosteros/blob/ae4b316dbd297d23dbd13a078b15797805109f9c/config/base.nix#L114 and https://github.com/lilyinstarlight/foosteros/blob/ae4b316dbd297d23dbd13a078b15797805109f9c/config/base.nix#L173 for where i'm setting NIX_PATH. but uh i'm sorry in advance to anyfew clicking those links that most of my config is overengineered, inscrutible rubbish) | 04:57:00 |
Lily Foster | * (https://github.com/lilyinstarlight/foosteros/blob/ae4b316dbd297d23dbd13a078b15797805109f9c/config/base.nix#L114 and https://github.com/lilyinstarlight/foosteros/blob/ae4b316dbd297d23dbd13a078b15797805109f9c/config/base.nix#L173 for where i'm setting NIX_PATH. but uh i'm sorry in advance to anyfew clicking those links that most of my config is overengineered, inscrutable rubbish) | 04:57:23 |
ext0l | In reply to @lily:lily.flowersyou're right, that is criminal | 05:46:46 |
benjamin | I think I have a misunderstanding of either what a closure is or how buildInputs works | 22:18:08 |
benjamin | my previous understanding was that anything in buildInputs becomes part of the output path's closure, which is the thing that shows up with nix path-info --recursive (or nix copy ) | 22:18:28 |
benjamin | but I'm currently looking at the mesa package in nixpkgs, where libxshmfence is part of buildInputs , but not listed in nix path-info --recursive | 22:18:58 |
Lily Foster | runtime closure is done via reference scanning after building ("build closure" is distinct) | 22:19:19 |
benjamin | ah that makes sense | 22:19:33 |
benjamin | so libxshmfence isn't included because none of the libraries/binaries built by the mesa package actually link it | 22:20:02 |
benjamin | so libxshmfence isn't included because none of the libraries/binaries built by the mesa package actually link it? | 22:20:10 |
Lily Foster | (as in it looks for any of the input store path hashes in the output store path and writes those references down and that makes up the runtime closure) | 22:20:15 |
Lily Foster | In reply to @benjamin:computer.surgeryyeah, if you were to grep for the hash part of the store path in whichever mesa output you're inspecting, it would be absent | 22:20:56 |
Lily Foster | In reply to @benjamin:computer.surgery* yeah, if you were to grep for the hash part of the libxshmfence store path in whichever mesa output you're inspecting, it would be absent | 22:21:10 |
Lily Foster | (but also note that derivations can have multiple outputs, so you may only be inspecting one of the outputs and the reference could still exist in another) | 22:21:26 |
raitobezarius | And as you can expect, if you apply any transformation that's not the identity to that path which is reversed at runtime, it's also absent | 22:21:26 |