| 10 Dec 2025 |
 iqubic (she/her) | Why? | 11:08:27 |
 maralorn | Because it is not "has no attribute sbv_13_3". | 11:09:07 |
| maralorn | You can find possible sbv attributes by launching nix repl binding pkgs = import <nixpkgs> {} and then doing tabcompletion. | 11:10:53 |
| iqubic (she/her) | Oh... I see what the issue is.. | 11:15:39 |
| iqubic (she/her) | { pkgs ? import <nixpkgs> {} }:
let
src = pkgs.nix-gitignore.gitignoreSource [] ./.;
newSbv = { sbv = pkgs.haskell.packages.ghc912.sbv_12_2; };
myPkg = pkgs.haskell.packages.ghc912.callCabal2nix "aoc25" src { sbv = newSbv; };
in
pkgs.stdenv.mkDerivation {
name = "aoc-shell";
buildInputs = [
myPkg.env.nativeBuildInputs
pkgs.cabal-install
pkgs.haskell.packages.ghc912.haskell-language-server
# pkgs.z3
];
}
| 11:15:49 |
|  @felineterrorist:matrix.org left the room. | 11:16:09 |
| iqubic (she/her) | Extra set of brackets in the declaration of newSbv | 11:16:09 |
| iqubic (she/her) | Even after fixing that, sbv is still marked as broken... | 11:17:29 |
| iqubic (she/her) | maralorn: I have no clue why this is marked as broken... | 11:22:07 |
| iqubic (she/her) | I did the tab completion ting to get a valid thing... | 11:22:28 |
| maralorn | iqubic (she/her): Im the broadest terms: sbv is probably marked broken because it has no maintainer in nixkpgs. | 11:25:05 |
| maralorn | And I don’t know what the specific reason is. | 11:25:40 |
| maralorn | It is probably noted in a comment in a file called broken.yaml in nixpkgs. | 11:26:07 |
| maralorn | But anyway you can remove the broken flag and see what happens. | 11:26:36 |
| maralorn | ... sbv = pkgs.haskell.lib.compose.unmarkBroken pkgs.… | 11:27:14 |
| maralorn | If you are really lucky it just builds. | 11:27:27 |
| maralorn | If you are medium lucky it builds after you apply pkgs.haskell.lib.compose.doJailbreak or pkgs.haskell.lib.compose.dontCheck to the package. | 11:28:12 |
| maralorn | If you are not lucky none of that helps and then we get to the reason why toonn recommendation might not be that bad after all. 😄 | 11:29:03 |
| maralorn | I mean every package is fixable but the effort can get larger.^^ | 11:29:34 |
 toonn | My personal preference for Haskell.nix is because it sticks to Cabal's dependency model, which is constraint resolution. The Nixpkgs Haskell infra is for when you want to package something for Nixpkgs or when you really don't want to every build your dependencies in exchange for dealing with all the version incompatibilities that implies. IMO, reasonable people can have differing opinions. | 11:44:46 |
| maralorn | Yeah, its very usecase dependent. For me staying nixpkgs compatible has a very high value. At least I had to learn the nixpkgs intricacies anyway. | 11:49:17 |
| maralorn | The dependency resolution argument for haskell.nix is very strong. | 11:49:58 |
| maralorn | I am very torn on whether in iqubics position learning haskell.nix right now would have better pay off then further learning how to fix the nixpkgs stuff. 😕 | 11:51:25 |
| toonn | Probably not something you want to do in the middle of AoC, yes. Though I wouldn't want to fight with Haskell infra either at such a time. | 11:54:02 |
| maralorn | Yeah, this should really just be working(tm). | 11:55:58 |
 iopq | if I can't compile my package on the newest nixpkgs, how do I distribute from my machine that I'm not upgrading to other computers | 13:49:05 |
| maralorn | iopq: It is not obvious to me that the sbv problem is better on an older nixpkgs. In general there are multiple solutions to pin your inputs. aka, the hash of nixpkgs. The lowest barrier would be a fetchtarball + hash based solutions others being flakes, npins or niv. | 14:01:15 |
| iopq | how do I do that | 14:04:18 |
| maralorn | https://nix.dev/reference/pinning-nixpkgs.html | 14:20:02 |
| iqubic (she/her) | Is it possible for me to just mark this as unbroken and also skip the tests too? | 16:20:17 |
