| 8 Dec 2025 |
 Arian | url too big => server gives up? | 20:14:48 |
 Winter | is there a way to specify remote machines to use without being a trusted user? even if i have to pre-define them in /etc/nix/machines or similar | 21:56:01 |
| Winter | i ofc could do some gross hacks and negate the machine list by default | 21:56:12 |
 raitobezarius | we have a magic ban when you add too many parameters to the URL IIRC in the infra | 22:42:51 |
| raitobezarius | hm we need to look into that | 22:42:59 |
| 9 Dec 2025 |
 Sofie 🏳️⚧️ (she/her) | Does anybody know if someone has patched this but for Lix? | 08:22:57 |
| Sofie 🏳️⚧️ (she/her) | https://github.com/noamraph/nixsa | 08:22:59 |
 KFears (they/them) | In reply to @raitobezarius:matrix.org
we have a magic ban when you add too many parameters to the URL IIRC in the infra I wonder if we can improve the flow on the infra side as well, like maybe there's a way to open a templated issue without a kilometer-long URL query, or something | 10:11:29 |
 helle (just a stray cat girl) | give the user a curl post command
render a QR code with the data compressed
pre-submit at least some of the crucial data probably, but the rest templated for the user to fill in? | 10:33:05 |
 0x4fbb09 it/its ⛯✇ΘΔ | pre-submitting without consent would be bad. a lix-run pastebin of some form would work, use long enough URLs such that they can't be guessed (if the user changes their mind), let the user delete submitted pastes, then make the issue with a link to the pastebin | 10:47:21 |
| helle (just a stray cat girl) | uh, presubmitting as part of the link that is | 10:47:35 |
| helle (just a stray cat girl) | like the current link submits everything | 10:47:46 |
| helle (just a stray cat girl) | which breaks things | 10:47:49 |
| helle (just a stray cat girl) | otoh, if it is our server that breaks, "just" fix the server side of it? | 10:48:22 |
 Atemu | A while back, I found nothing in this direction and gave up because even with gross scripts, you can't get other clients that bring their own nix client (i.e. colmena, nixpkgs-review to not do remote builds by default. | 11:53:04 |
| Atemu | * | 11:53:35 |
| Sofie 🏳️⚧️ (she/her) | or nix portable? | 12:50:25 |
|  madmccrow joined the room. | 14:12:12 |
|  @emanuelm153:matrix.org left the room. | 21:17:35 |
 neobrain | Is it expected that the disk space reported by nix store gc is much higher than the actual savings I see when comparing (btrfs filesystem) df / before/after the gc run? | 23:23:42 |
| neobrain | One scenario I tested makes the former report 2.4 GiB savings when it was actually only 1 GiB, for example | 23:24:14 |
| raitobezarius | btrfs is CoW | 23:24:30 |
| raitobezarius | lix has no way to know better than summing up sizes of things being deleted | 23:24:43 |
| raitobezarius | * btrfs is CoW & compressed | 23:24:48 |
| raitobezarius | * btrfs is CoW & [inline] compressed | 23:24:53 |
| raitobezarius | but btrfs knows much better than us | 23:25:06 |
| neobrain | oh interesting. Compression makes a lot of sense. How does CoW influence this? | 23:25:46 |
| raitobezarius | if 2 inodes are CoWed and lix removes them [while they're not hardlinked], lix will count them twice but btrfs will deduce once I suppose? | 23:26:26 |
| raitobezarius | if the CoW is transparent via reflinking, maybe we could know but I don't know off my head whether this is the case | 23:27:15 |
| neobrain | That's deduplication, right? I assumed that only happened after user request | 23:27:27 |
