Haskell in Nixpkgs/NixOS - Public Room Timeline

	Haskell in Nixpkgs/NixOS	698 Members
	For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs \| Current Docs: https://haskell4nix.readthedocs.io/ \| More Nix: #community:nixos.org \| More Haskell: #haskell-space:matrix.org	141 Servers

Load older messages

Sender	Message	Time
25 Jun 2025
maralorn	In reply to @ners:nixos.dev I like to encourage people to use `unmarkBroken` rather than `markUnbroken`, as the flag is called `broken`, not `unbroken`. 🙃 I have grown quite fond of that little wart.	11:44:53
lambdatheultimatealias	In reply to @sternenseemann:systemli.org lambdatheultimatealias: note that you can't draw any conclusions from nixpkgs about hackage since we regularly apply patches, modify constraints, build flags, test flags etc. Makes sense. If I follow correctly Hackage just provider the default version and sources which can be overridden depending on stackage and nixpkgs.	11:59:14
sterni (he/him)	Hackage is just a place for maintainers to upload their packages. Metadata (e.g. constraints) can be edited by maintainers and Hackage trustees after the fact. Hackage makes no statement about which version to use which is the job of the cabal solver or tools like stack(age)	12:02:24
Alex	In reply to @ners:nixos.dev I like to encourage people to use `unmarkBroken` rather than `markUnbroken`, as the flag is called `broken`, not `unbroken`. 🙃 I didn't even realise there were two functions for it...	12:55:45
alexfmpe	Aren't there 4?	16:19:31
alexfmpe	Two names each for turning it on and ofd	16:19:42
alexfmpe	* Two names each for turning it on and off	16:19:59
maralorn	In reply to @alexfmpe:matrix.org Aren't there 4? I think in that sense there are 3. Because markBroken cannot not have the un in different places	16:41:06
alexfmpe	Huh I assumed there was unmarkUnbroken	16:43:27
alexfmpe	Can't we just deprecate one of them and end this?	16:43:42
maralorn	We totally could. But I like them too much to do it myself. 😂	16:46:56
maralorn	What the heck is the correct way to run doctests in a nixpkgs package?	21:20:33
maralorn	cabal repl --with-compiler=doctest does not work because the doctest does not have the same pkg db than the ghc used by cabal.	21:21:10
sterni (he/him)	cabal exec -- cabal repl --with-compiler=doctest maybes	22:16:44
sterni (he/him)	* cabal exec -- cabal repl --with-compiler=doctest maybe?	22:16:46
maralorn	Still the same problem: `Configuring library for status-script-0.1.0.0... Loaded package environment from /home/maralorn/git/config/packages/status-script/dist-newstyle/tmp/environment.-175358/.ghc.environment.x86_64-linux-9.8.4 <command line>: cannot satisfy -package-id aeson-2.2.3.0-2mnLs4rnok4A0ksXaTX6dm` and I am relatively certain that is because cabal-install does use a different ghc pkg db.	22:34:42
maralorn	* Still the same problem: `Configuring library for status-script-0.1.0.0... Loaded package environment from /home/maralorn/git/config/packages/status-script/dist-newstyle/tmp/environment.-175358/.ghc.environment.x86_64-linux-9.8.4 <command line>: cannot satisfy -package-id aeson-2.2.3.0-2mnLs4rnok4A0ksXaTX6dm` and I am relatively certain that is because cabal-install does use a different ghc pkg db than doctest.	22:34:46
maralorn	So this seems to me that we should maybe patch doctest so that it picks up the package db from the ghc.withPackages it is used from?	22:35:25
26 Jun 2025
sterni (he/him)	ah yes I remember https://github.com/haskell/cabal/issues/7792#issuecomment-2124304244	21:25:04
28 Jun 2025
Peter Becich	On `haskell-updates` branch, `./maintainers/scripts/haskell/regenerate-hackage-packages.sh` produces `... hackage2nix: user error (cannot parse cabal file /nix/store/kmz1d73l5k1nhv5269dl5i68yjwlbcir-unpacked-cabal-hashes/pms-application-service/0.0.3.0/pms-application-service.cabal) hackage2nix: thread blocked indefinitely in an MVar operation` Does anyone else see this or is it local to me?	20:22:52
29 Jun 2025
chreekat	In reply to @peterbecich:matrix.org On `haskell-updates` branch, `./maintainers/scripts/haskell/regenerate-hackage-packages.sh` produces `... hackage2nix: user error (cannot parse cabal file /nix/store/kmz1d73l5k1nhv5269dl5i68yjwlbcir-unpacked-cabal-hashes/pms-application-service/0.0.3.0/pms-application-service.cabal) hackage2nix: thread blocked indefinitely in an MVar operation` Does anyone else see this or is it local to me? I think the real error is getting swallowed somewhere. I know from fixing Stackage recently that that package uses a newer version of Cabal file format, so hackage2nix (or whatever underlying tool) probably also needs to be built with an updated version of the cabal library	07:11:34
levin	I'm working on a pull-request right now (https://github.com/NixOS/nixpkgs/pull/419877). In the last unresolved comment, I'm asked to get the tests for the package (haskore), which the pull-request originally disabled using `dontCheck`, working. For these tests to work, I would need to have some files (https://archives.haskell.org/code.haskell.org/haskore/revised/core/src/Test/) in the src, which aren't there because they aren't listed in the cabal file under `extra-source-files`. How would I resolve this? I couldn't really find anything...	07:41:19
maralorn	I think that is more a factual correction than a demand.	09:00:26
ners	Would it be possible to cache the pkgsStatic GHC for aarch64 as well, in addition to x86_64 linux?	16:26:11
ners	In Hydra, that is. Currently we can get the musl GHC from haskell-updates for x86_64, but not for aarch64.	16:26:45
ners	* In Hydra, that is. Currently we can get the cached musl GHC from haskell-updates for x86_64, but not for aarch64.	16:26:53
Tom Westerhout	Following up on ners's point, there's this comment in `release-haskell.nix`: https://github.com/NixOS/nixpkgs/blob/dcc4da22e1bf5ed04220e7c5ddaa80abc0dee646/pkgs/top-level/release-haskell.nix#L409 `# pkgsMusl is compiled natively with musl. It is not # cross-compiled (unlike pkgsStatic). We can only # natively bootstrap GHC with musl on x86_64-linux because # upstream doesn't provide a musl bindist for aarch64.` I'm wondering if it still stands because I was able to build stuff locally	16:27:44
Tom Westerhout	Ah wait, never mind. I can't read. I was reading `pkgsMusl` instead of `pkgsStatic`. For `pkgsStatic`, it says "times out on Hydra"	16:29:21
Tom Westerhout	* Ah wait, never mind. I can't read. I was reading `pkgsMusl` instead of `pkgsStatic`. For `pkgsStatic`, it says "times out on Hydra". Is there any chance to get an exception there?	16:29:49
Alex	In reply to @ners:nixos.dev Would it be possible to cache the pkgsStatic GHC for aarch64 as well, in addition to x86_64 linux? My guess, without looking at Hydra, is that it could potentially break the path size limit.	17:17:56

Show newer messages

Back to Room ListRoom Version: 6