| 29 May 2025 |
 Alison Jenkins | It just shows it in most packages as it appears i686 support has been dropped on lots of the packages in Nixpkgs. | 09:46:21 |
| Alison Jenkins | I will get you the stack trace but it doesn't really show anything useful | 09:46:32 |
| Alison Jenkins | Download stacktrace.txt | 09:48:16 |
 dramforever | can you try nix eval --raw --show-trace github:alisonjenkins/nix-config#nixosConfigurations.ali-desktop.config.system.build.toplevel | 14:47:44 |
| dramforever | this should give you the full stack trace | 14:51:12 |
| dramforever | and point to what is actually throwing the error | 14:51:20 |
|  Daniel Huang joined the room. | 20:46:55 |
| 30 May 2025 |
|  George joined the room. | 12:14:17 |
| 23 Sep 2025 |
|  @rick:matrix.ciphernetics.nl left the room. | 07:35:25 |
| 30 May 2025 |
|  ordnungswidrig joined the room. | 16:18:20 |
| ordnungswidrig | Hi all, I've got a flake that builds fine on all but one system. On that system I get a hash mismatch in the cache.
> specified: sha256:07klv1yi9hwav9j73afk2vhddxgmd3d57nmmbmzj3a5fphjwww41
> got: sha256:0dghvnk7npd74jv359vpms76fpnigykd3v923jjr80hvccg4bi18
How to I debug this? I've updated the flake lock, I've tried unstable, 24.11 and 25.05 as the input source and nix store repair and more. I'm a little list.
| 16:19:30 |
| ordnungswidrig | * Hi all, I've got a flake that builds fine on all but one system. On that system I get a hash mismatch in the cache.
> specified: sha256:07klv1yi9hwav9j73afk2vhddxgmd3d57nmmbmzj3a5fphjwww41
> got: sha256:0dghvnk7npd74jv359vpms76fpnigykd3v923jjr80hvccg4bi18
How to I debug this? I've updated the flake lock, I've tried unstable, 24.11 and 25.05 as the input source and nix store repair and more. I'm a little lost. Flake can be found here: https://gist.github.com/ordnungswidrig/55120535ab4a1e99cccdc76decac10c5
| 16:19:46 |
| Alison Jenkins | Thanks dramforever sorry for the slow reply. Just running the command now | 17:19:17 |
| Alison Jenkins | Download stacktrace.txt | 17:20:31 |
| Alison Jenkins | I am looking through it but don't see anything interesting so far | 17:21:56 |
| dramforever | In reply to @ordnungswidrig-test:matrix.org
Hi all, I've got a flake that builds fine on all but one system. On that system I get a hash mismatch in the cache.
> specified: sha256:07klv1yi9hwav9j73afk2vhddxgmd3d57nmmbmzj3a5fphjwww41
> got: sha256:0dghvnk7npd74jv359vpms76fpnigykd3v923jjr80hvccg4bi18
How to I debug this? I've updated the flake lock, I've tried unstable, 24.11 and 25.05 as the input source and nix store repair and more. I'm a little lost. Flake can be found here: https://gist.github.com/ordnungswidrig/55120535ab4a1e99cccdc76decac10c5
try nix-hash --type sha256 /nix/store/9545lc12nznckmbrsgsjy5vhvgrj5i4n-getty on your various systems and see what they have? | 17:22:10 |
| Alison Jenkins | From my understanding of it it is basically just stating that it is evaluating the openjdk-17 package and that it doesn't support i686 | 17:23:24 |
| Alison Jenkins | but the problem is I don't know why it thinks it needs to be. I need to track down what is specifying we need i686. | 17:23:52 |
|  Martin Lindbüchl joined the room. | 18:11:33 |
| 31 May 2025 |
| dramforever | okay. granted, it's not the most easy to read, but what you can do is pare it down a bit. there are lines inserted in the trace like "… while evaluating". if we grep while it looks much more managable | 03:14:09 |
| dramforever | we can get it down even further while evaluating derivation | 03:14:25 |
| dramforever | * we can get it down even further with while evaluating derivation | 03:14:30 |
| dramforever | this paints a pretty clear picture of what's going on:
… while evaluating derivation 'home-manager-generation'
… while evaluating derivation 'home-manager-files'
… while evaluating derivation 'man-cache'
… while evaluating derivation 'man-paths'
… while evaluating derivation 'heroic-2.16.1'
… while evaluating derivation 'heroic-2.16.1-bwrap'
… while evaluating derivation 'heroic-2.16.1-fhsenv-rootfs'
… while evaluating derivation 'alsa-plugins-1.2.12'
… while evaluating derivation 'ffmpeg-7.1.1'
… while evaluating derivation 'libbluray-1.3.4'
… while evaluating derivation 'openjdk-17.0.14+7'
| 03:14:56 |
| dramforever | heroic depends on 32-bit versions of various stuff, which eventually goes to ffmpeg, which depends on libbluray | 03:15:25 |
| dramforever | but an overlay of yours made libbluray depend on java | 03:15:40 |
| dramforever | i don't know enough about your use case but what i would do is to override whatever you actually use for bluray to use the overridden libbluray | 03:17:13 |
| Alison Jenkins | In reply to @dramforever:matrix.org
i don't know enough about your use case but what i would do is to override whatever you actually use for bluray to use the overridden libbluray I will temporarily disable that and see if it helps. The reason for the Java is the Blu-ray menus | 06:09:35 |
| Alison Jenkins | I disabled the overlay for the libbluray and this is the new stack trace | 06:40:04 |
| Alison Jenkins | Download stacktrace.txt | 06:40:11 |
| Alison Jenkins | seems to be still getting hung up on libbluray | 06:40:55 |
