| 21 Mar 2026 |
sterni (he/him) | * Not sure if the patch would be upstreamable though I suspect that, currently, --with-system-* does not work when building a cross compiler with anything but Nix and with Nix it's sometimes broken if the headers are platform specific (i.e. libffi). So maybe it would be a net positive. | 14:03:39 |
| @galileocharonvostok1:matrix.org joined the room. | 14:53:20 |
| @galileocharonvostok1:matrix.org left the room. | 14:54:10 |
sterni (he/him) | alexfmpe: Alex: https://github.com/NixOS/nixpkgs/pull/501983 so this is my idea, just letting cc wrapper deal with stage0 (since we're in stdenv anyways) | 16:30:59 |
sterni (he/him) | gonna clean that up, patch doesn't seem too terrible to maintain, may even be upstreamable in some shape or form | 16:31:27 |
Teo (he/him) | I'm not sure if there's an existing issue. Creating one sounds great! https://gitlab.haskell.org/ghc/ghc/-/merge_requests/15231 might cover this but I'm not sure.
Even if it's just nix specific it would be good to have it upstream since then we'd be less likely to break downstream all the time.
| 16:53:41 |
| 24 Mar 2026 |
alexfmpe | do we have any idea what causes the rts configure error mentioned in
https://github.com/NixOS/nixpkgs/pull/482251#issuecomment-3779413252 | 18:25:28 |
alexfmpe | I also hit it for s390x | 18:25:33 |
alexfmpe | * affects some powerpc variants, i686, s390x | 18:25:59 |
| @libjared:matrix.org left the room. | 21:26:45 |
| 26 Mar 2026 |
aiya | say I wanted to fix a C++ lib that is relevant for a haskell package (i.e. fix libtorch to fix libtorch-ffi), would that be done in the haskell-updates branch or another branch? | 17:18:26 |
alexfmpe | Usually haskell-updates is for LTS bump related shenanigans. If your error is present on master and can be fixed there, usually that's what you want | 17:27:14 |
alexfmpe | Unless it causes mass rebuilds, then it goes on staging | 17:27:34 |
aiya | i don't understand, i thought haskell-updates was for all Haskell package changes? | 17:28:00 |
aiya | * i don't understand, i thought haskell-updates was for all Haskell package changes? or are you specifically talking about non-haskell packages | 17:28:09 |
sterni (he/him) | it's a development branch for haskell related changes, but that doesn't mean that it needs to be used in every case | 22:37:26 |
sterni (he/him) | we were stricter about this in the past, but due to workflow changes going via haskell-updates means changes don't see master for weeks | 22:38:17 |
| 27 Mar 2026 |
| Mrjtjmn changed their display name from Mrjt. to Mrjtjmn. | 11:11:11 |
aiya | okay it's actually a bit involved: | 18:08:12 |
aiya | * okay it's actually a bit involved:
- C++ library and haskell package are both v1.4 on
master
- C++ library is v1.4 on
haskell-updates, haskell package is v1.5
so i think i'm going to update both in haskell-updates otherwise we get dependency hell (it may also be that the haskell package is not following PVP) | 18:09:53 |
| 28 Mar 2026 |
woobilicious | anyone here know how to get pandoc haskell filters to work?
Could not find module ‘Text.Pandoc.JSON’. | 09:11:21 |
woobilicious | is this just pandoc packagers forgetting to include pandoc with the interpreter? lol | 09:12:07 |
woobilicious | oh it just uses the environments runhaskell | 09:17:24 |
catsarecute | Hi! I'm a physics undergrad who uses NixOS and Haskell a lot, and I'm planning to apply for GSoC with the NixOS org this year.
I noticed that a number of Haskell packages in nixpkgs are currently marked broken or fail to build. I was thinking of working on systematically identifying and fixing these packages, and possibly building some tooling around detecting and categorizing the failures.
Does this sound like a useful GSoC project? Are there specific areas in the Haskell infrastructure of nixpkgs that would benefit from this kind of work?
| 15:40:41 |
alexfmpe | I don't know whether it'd make for a GSOC project but I can give you some context | 15:58:28 |
alexfmpe | https://github.com/cdepillabout/nix-haskell-updates-status/tree/79f26d542486bf7d8f1ea74c5aacc254aec4f005 | 15:58:40 |
alexfmpe | I recently went through the first dozen or so of the 'top 50' broken packages there and most of them were just hopelessly bitrotten upstream | 15:59:26 |
alexfmpe | So one problem would be identifying which packages are even worth spending time on | 16:00:19 |
alexfmpe | I suspect a more useful thing would be trying to upstream some of our overrides to upstream packages that are still maintained enough to look at PRs | 16:01:58 |
alexfmpe | As for tooling, there might be stuff worth doing, not sure.
I did https://github.com/NixOS/nixpkgs/pull/384591 a while back and it was nice bang for buck, I ought to wrap that up. The approach isn't particularly haskellPackages specific either | 16:04:51 |