| 16 Jun 2026 |
|  Sapii/Saperson joined the room. | 00:36:59 |
|  andiandi 🐈 changed their display name from andiandi 🐈 to andiandi 🐈 @ HadR ☎️ 2634@DECT. | 13:51:32 |
| andiandi 🐈 changed their display name from andiandi 🐈 @ HadR ☎️ 2634@DECT to andiandi 🐈 🏰 HadR ☎️ 2634@DECT. | 13:53:11 |
| 17 Jun 2026 |
|  Jean 💕 changed their profile picture. | 14:21:35 |
|  c2fc2f joined the room. | 16:14:04 |
|  Spider joined the room. | 17:03:03 |
| 18 Jun 2026 |
|  @arrowd:kde.org joined the room. | 08:29:21 |
| @arrowd:kde.org | Eelco Hi, I see you merged a PR in https://github.com/NixOS/patchelf
Could you also please take a look at https://github.com/NixOS/patchelf/pull/638 and https://github.com/NixOS/patchelf/pull/636 ? These should be fairly simple to review. | 08:31:08 |
|  Biswa96 joined the room. | 17:28:52 |
|  whispers [& it/fae] changed their display name from whispers [& it/fae] to meow meow. | 18:46:22 |
| whispers [& it/fae] changed their display name from meow meow to whispers [& it/fae]. | 19:11:58 |
| 19 Jun 2026 |
| andiandi 🐈 changed their display name from andiandi 🐈 🏰 HadR ☎️ 2634@DECT to andiandi 🐈 @ 🏰 HadR ☎️ 2634. | 07:55:39 |
|  Krysteq joined the room. | 11:57:29 |
| 20 Jun 2026 |
 pveierland | Is it intentional that xz files are created as a single compressed block from nix? | 08:54:05 |
| pveierland | * | 08:54:33 |
| pveierland | * | 08:55:32 |
| pveierland | I'd guess it could relate to determinism and avoiding additional parameters. | 09:01:02 |
| pveierland | * | 09:03:08 |
 flokli | FileHash is not verified at all, and some people looked into using multi-block for various usecases. | 09:06:47 |
| flokli | In the end the conclusion was that xz isn't really worth it, which is why we're now with zstd. | 09:07:11 |
| pveierland | Is zstd in use on cache.nixos.org now? Does it support ranged reads? | 09:08:12 |
| flokli | zstd is in use. Don't know if it allows ranged reads. | 09:08:53 |
| pveierland | Do you know why it was chosen over brotli? | 09:09:40 |
| flokli | No | 09:09:57 |
| flokli | Ideally all the compression parts would be a content-encoding concern, so range requests wouldn't need to be complicated at all. That's what snix-nar-bridge does, it sends Compression: none and relies on libcurl to request zstd-compressed. That of course not realistic for the c.n.o situation, where we currently serve from the bucket "directly", as it would be even more costly than it already is. | 09:11:57 |
| flokli | If you're ok with the current caveats, you're welcome to use nixos.snix.store for the mynixos usecase as a fetch-through version. Gives you c.n.o with Compression: none and zstd content encoding. | 09:14:56 |
| pveierland | Interesting, thank you 👍 I'll have a look. Do you know ~coverage/content available compared to c.n.o? | 09:17:03 |
| pveierland | Found the stats 👍 | 09:18:21 |
| flokli | We have "everything" in c.n.o. the first request from anyone to the Narinfo url is "slow" though, as it needs to ingest the NAR | 09:18:47 |
| pveierland | Ah, so it's just a lazy cache with better interface? | 09:19:24 |
