| 9 Mar 2026 |
| @jannickoursin:matrix.org left the room. | 01:16:40 |
ptitfred | Hello :wave: ; 2.94 release notes includes the following breaking change:
Enable zstd with a high compression level instead of xz for binary cache uploads
Does it mean somebody using Lix won't be able to take advantage of public caches?
| 14:01:25 |
raitobezarius | no | 14:09:01 |
raitobezarius | all other algorithms are still there | 14:09:08 |
raitobezarius | if you substitute from cache.nixos.org, it will still work | 14:09:14 |
raitobezarius | if you are using an xz cache, it will work | 14:09:18 |
raitobezarius | but if you create new caches with Lix, it will default to zstd instead of xz | 14:09:31 |
raitobezarius | (that's why it mentions only "binary cache uploads") | 14:09:42 |
ptitfred | makes sense | 14:11:29 |
ptitfred | thank you | 14:11:34 |
raitobezarius | np! | 14:12:49 |
| 10 Mar 2026 |
zoë (she/her) | i'm seeing some weird behavior where both laptop L and server S are unable to locally build a simply FOD derivation with the correct hash, but if L uses S as a builder it succeeds | 04:52:04 |
zoë (she/her) | any idea what i could do to troubleshoot this? | 04:52:24 |
zoë (she/her) | for reference, it's just a simple source FOD:
let
ref = "608d0cadfed240589a7eea422407a547ad626a14";
pkgs = import (builtins.fetchTarball {
url = "https://github.com/NixOS/nixpkgs/archive/${ref}.tar.gz";
}) {};
in
pkgs.fetchFromGitHub {
owner = "tgirlcloud";
repo = "lix-diff";
tag = "v1.4.0";
hash = "sha256-aLmCS+Q6B/DU6DZ0U/FfCOovwZTSTAG5vrCGHZ1Xsrk=";
}
| 04:53:00 |
zoë (she/her) | i get a hash mismatch (in fact, the same hash mismatch) on both machines :( | 04:53:34 |
zoë (she/her) | * i get a hash mismatch (in fact, the same hash mismatch, sha256-JpnndjieoQxOi5iKNjtiqOMPNkZgso7PLk7KyVHCJN0=) on both machines :( | 04:54:07 |
zoë (she/her) | hmm, it might be a lix issue, since nix-shell -p nixVersions.nix_2_33 --run 'nix-build --builders ""' doesn't cause an error | 04:57:32 |
aloisw | Can't reproduce here unfortunately, I get the same hash mismatch with cppnix, even after trying a few times. Now that you have the correct path, can you diffoscope the paths (expected /nix/store/d54vkq7lqi8yyri6gpnglivk105labi4-source, got /nix/store/zg0mhri77m47qbrwqbl6pgdryac2awny-source according to my error message) to see what's going wrong? | 05:27:09 |
zoë (she/her) | yeah, i just tried again with cppnix, the exact same command as above and it failed... this is so weird o_o | 05:28:06 |
aloisw | I mean on the machine where the command succeed once. You should have the correct path there unless you GCd it. (I suspect something is non-deterministic, but without a diff it's really hard to tell what's going on.) | 05:29:01 |
zoë (she/her) | yeah will do a diff, thanks for the tip | 05:30:11 |
zoë (she/her) | ok well after more mucking around, i can't repro this anymore, i'm always getting the wrong hash and can't build the "good"/expected derivation | 05:55:37 |
aloisw | What happened on the machine where you reproduced the good one? GC or you just don't have access for now? | 05:56:55 |
zoë (she/her) | yeah before your comment i deleted it on the builder/server to have a "clean room" to work in, and i can't get it back anymore :( | 05:58:18 |
zoë (she/her) | it's a little spooky lol | 05:58:36 |
aloisw | No problem, I just asked to confirm that there's no need to wait any more because we're likely never going to find out. | 05:58:55 |
aloisw | /aloisw remembers the funet mirror incident | 05:59:13 |
zoë (she/her) | it's like the weird tar/gz failure i got once, it was a weird nix failure that happened multiple times for like an hour and then poof it was gone, and i couldn't get it back the next day despite having done nothing but put my laptop to sleep and then taken it out | 06:00:31 |
aloisw | That may actually be the funet mirror incident (IIRC they wrongly served tar.gz files with Content-Encoding: gzip so that curl would ungz it). | 06:01:23 |
zoë (she/her) | it was i think last week or two weeks ago, so, does that line up? | 06:02:03 |