| 24 Nov 2024 |
 sterni | In reply to @maralorn:maralorn.de
sterni: I am trying to understand the current state of the haskell-updates branch. I guess we could just merge it into staging at any time if we have enough visibility, right? Yes, but realistically we won't be able to have any confidence before we have builds on Hydra again. When staging-next is branched off, is probably the best time for this as we are based on staging as well, so we'd able to share a lot of builds. | 15:44:28 |
 lxsameer | In reply to @sternenseemann:systemli.org
lxsameer: it just reads the data base that is managed by cabal-install. Fetching and updating is done with cabal {v2-,}update as usual I see. For the freeze tool we should pull down the snapshot of hackage db that is provided by the freeze file. When i swtiched to cabal2nix generated drivation, cabal2nix seems to look up the database on my local version of nixpks. | 16:54:18 |
| sterni | cabal2nix does not know about all-cabal-hashes in nixpkgs, so that's not possible | 16:55:34 |
| lxsameer | Hmmm so i can't explain what i see. It complains about a missing dependency. I use cabal2nix' function to generate the drvs | 16:59:37 |
| sterni | what dependency is missing? | 17:10:29 |
| lxsameer | I'll send the logs later | 19:40:51 |
| 25 Nov 2024 |
| lxsameer | In reply to @sternenseemann:systemli.org
what dependency is missing? here is an example of the error:
[Error]: user error (No such package rts-1.0.2 in the cabal database. Did you run cabal update?) | 10:49:28 |
| lxsameer | cabal update did not help either | 10:49:37 |
| sterni | rts is a core package that is part of ghc and not updloaded to hackage, so you'd expect that | 10:50:15 |
| sterni | I think the easiest is probably to check ghc-pkg list if the package of the freeze file is already present in the correct version and omit such cases | 10:51:22 |
| lxsameer | ah ok let me see | 10:52:10 |
| lxsameer | In reply to @sternenseemann:systemli.org
I think the easiest is probably to check ghc-pkg list if the package of the freeze file is already present in the correct version and omit such cases what if the version didn't match? | 10:57:37 |
| sterni | then you are using different versions of ghc compared to when the freeze file was generated | 10:58:02 |
| sterni | i'm not sure maybe there is a better way, i.e. maybe the freeze file tells you where the package comes from | 10:58:20 |
| lxsameer | In reply to @sternenseemann:systemli.org
i'm not sure maybe there is a better way, i.e. maybe the freeze file tells you where the package comes from i don't think that is possible, but I'll have a look | 11:01:13 |
| lxsameer | sterni: maralorn What do you think about this generated file: https://dpaste.com/CFP3B5JFW | 14:00:39 |
 maralorn | lxsameer: Nice. I personally wouldn’t send this through a formatter, I think those newlines are just noise. But that does not seem important. | 14:03:44 |
| lxsameer | In reply to @maralorn:maralorn.de
lxsameer: Nice. I personally wouldn’t send this through a formatter, I think those newlines are just noise. But that does not seem important. I applied the formatter manually | 14:05:34 |
| lxsameer | I still don't know what to do with packages like zlib | 14:06:17 |
| maralorn | lxsameer: Okay, so the hackage2nix code in the cabal2nix repo has some logic to inject a zlib = pkgs.zlib in the {} at the end of the corresponding callPackage call. | 14:08:20 |
| maralorn | You need to generate something like:
description = "Compression and decompression in the gzip and zlib formats";
license = lib.licenses.bsd3;
})
{ zlib = pkgs.zlib; };
| 14:09:12 |
| lxsameer | I'm a bit confused about zlib. is this the famous zlib or a haskell version? | 14:11:08 |
| lxsameer | and since it's in ghc-pkgs list, should I ignore it? The version does not match in my case | 14:12:06 |
| maralorn | lxsameer: The problem is, it is the Haskell version, but it requires the "famous" C library as an input. But because of how name resolution works in haskellPackages by default it get’s itself as input which creates the loop. | 14:18:08 |
| lxsameer | ahhh got it. so it gets tricker than I expected | 14:20:11 |
| maralorn | To drive that point home: When callPackage sees "zlib" it will first look for a package called zlib in final and only if it doesn’t find one it will fallback to zlib from pkgs. So the Haskell lib shadows the system lib on lookup. I really encourage you to look at the hackage-packages.nix file in nixpkgs because you are basically recreating what it does. There you can see how system libraries often get manual overrides. | 14:41:31 |
| lxsameer | In reply to @maralorn:maralorn.de
To drive that point home: When callPackage sees "zlib" it will first look for a package called zlib in final and only if it doesn’t find one it will fallback to zlib from pkgs. So the Haskell lib shadows the system lib on lookup. I really encourage you to look at the hackage-packages.nix file in nixpkgs because you are basically recreating what it does. There you can see how system libraries often get manual overrides. that is my reference file. I look at it occasionally. I think we need to maintain a list of such packages | 14:44:45 |
| lxsameer | for example, as sterni suggested I'm using ghc-pkg list to ignore some packages like rts but that cause some issues with other packages like primitive | 14:46:04 |
| lxsameer | i think at the end of the day we need to maintain a list of packages that need special care | 14:46:31 |
| maralorn | In reply to @lxsameer:matrix.org
i think at the end of the day we need to maintain a list of packages that need special care Maybe, but as I said, hackage2nix has logic to do this for packages like zlib and it works. And even if we have to maintain a manual list, this list already has to exist in cabal2nix/hackage2nix. | 14:55:21 |
