Lix | 1120 Members | |
| Lix user channel. Feel free to discuss on-topic issues here and give each other help. For matrix.to links to the rest of the Lix channels, see: https://wiki.lix.systems/books/lix-organisation/page/matrix-rooms | 302 Servers |
| Sender | Message | Time |
|---|---|---|
| 30 Jan 2026 | ||
| once per line yes | 01:12:23 | |
| it appends | 01:12:24 | |
| 01:12:33 | |
| Winter i dont know if your woes with systemd units building moved forward somehow but | 01:17:50 | |
| we merged https://git.lix.systems/lix-project/lix/commit/56988d860593a5fd8153d02a0ca5469508378626 and there's more to come | 01:17:54 | |
| if those doesn't fix your problem, i think it may reside somewhere else | 01:18:03 | |
| (though i slightly doubt that you are that much running into drv overheads) | 01:18:14 | |
| 07:53:57 | ||
| So, how did u extract initrd files? | 08:34:30 | |
| I need to get a service file from one | 08:34:36 | |
| nvm figured it out | 08:42:35 | |
| I found something that is messed up with flakes:
It shows that The log outputs will say something like
Notice that this looks like a store path made from a store path. It seems to be, as both store paths exist. But if you write something like:
you will get:
Since I rely on | 15:57:38 | |
| * I found something that is weird:
It shows that The log outputs will say something like
Notice that this looks like a store path made from a store path. It seems to be, as both store paths exist. But if you write something like:
you will get:
Since I rely on | 15:57:51 | |
| Noticed this from a bug report on my library https://github.com/RossSmyth/press/issues/20 | 15:58:05 | |
| * I found something that is weird:
It shows that The log outputs will say something like
Notice that this looks like a store path made from a store path. It seems to be, as both store paths exist. But if you write something like:
you will get:
Since I rely on | 16:01:52 | |
Definitely something flakey because running it without flakes it acts as expected (finalAttrs.src == $src) | 16:18:08 | |
| 16:18:56 | ||
| aloisw: you are super strong at rootcausing this sort of things ^, if you have some time (and desire), that'd be awesome ^ My bet is that this seems normal and is a stdenv machinery thing but not sure | 19:50:05 | |
| I can't reproduce it using the old cli, I'll try flakes but I doubt it'll affect anything. FWIW this is the derivation I'm trying
and the output is
| 19:59:20 | |
| I tried both with nixpkgs pinned in my config and with nixpkgs that's pinned in your repo | 19:59:39 | |
| My lix commit is 7068cbf | 20:00:04 | |
| 20:22:31 | ||
| 20:23:18 | ||
| 20:24:14 | ||
| 20:24:51 | ||
| 20:25:50 | ||
| 20:26:19 | ||
| 22:28:13 | ||
| 31 Jan 2026 | ||
The problem is that src (and consequently, also finalAttrs.src and something) are not strings, but paths. Similar to string interpolation, builtins.derivation will always copy paths to the store, even if they already happen to point into the store. So all of $src, $something and ${finalAttrs.src} will point at the double-hash path (no idea how you got something else for the latter, did a builtins.toString sneak in somehow?). On the other hand, you determine the name of the unpacked source using your stripHash function (https://github.com/RossSmyth/press/blob/d3eb2b2deee2116609f938b08fc86a48850b99c4/src/buildTypstDocument.nix#L18-L23), which calls builtins.baseNameOf which operates on the original path. | 06:00:42 | |
| Anyone at Fosdem and would like to meet up? | 10:11:01 | |