| 28 Mar 2026 |
 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 |
| alexfmpe | I also have a little roadmap of things I want to change in cabal2nix but still haven't gone over them properly with the maintainer team to gauge fit/interest | 16:06:15 |
| alexfmpe | Also, are you talking about haskell or nix gsoc? I mean, if it's on the intersection of domains I guess this is the room to ask about context, but the orgs deciding on applications have different priorities so a project/proposal might be desirable for one and not for the another | 16:08:05 |
 chreekat | yeah, speaking as somebody who was a GSOC mentor for Haskell a couple years ago, I would actually reconsider skipping out this year depending on what developed here. :) Assuming it's not too late to get registered as a mentor for this year.. | 16:23:42 |
| chreekat | Is Jens Petersen here? Looks like it. A group of us had discussed distro-agnostic tooling at Zurihac last year, along with teo (they/he) and maralorn . Offhand the details are fuzzy. I recall: (1) nixpkgs, stackage, clc-stackage, and head.hackage all test a bunch of packages against chosen versions of ghc. (2) It would be good to somehow share tooling or reporting methods for these distributions?
I'll be honest, there's not enough in what I'm writing to really go anywhere, but maybe others can fill in more details if they remember them
| 16:26:43 |
| catsarecute | Ah that makes sense, thanks for the context.
I hadn’t considered that many of the broken packages might just be abandoned upstream. The idea of reducing the number of overrides by upstreaming fixes sounds really interesting though.
I was thinking along the lines of identifying overrides in nixpkgs that could be upstreamed and sending patches upstream or improving tooling around cabal2nix or the Haskell packaging workflow to reduce the need for overrides
I was considering nixos as the gsoc org
| 16:28:39 |
| catsarecute | Ah sorry, I meant as a student, not a mentor 😅
And thank you, I appreciate that. I think I’ll probably skip applying this year and spend some time first getting more familiar with the haskell side of nixpkgs and contributing a bit.
| 16:31:17 |
| chreekat | Sorry, I knew you meant doing this as a student -- I meant I would consider being the mentor. :D Anyway I encourage you to pursue whatever strikes your fancy | 16:32:08 |
| chreekat | I would caution that submitting PRs to a bunch of different projects, who may or may not care/be alive/have time/have any idea what GSOC is might not be considered a strong proposal. I also know from experience you'd just spend a lot of time waiting to hear from maintainers | 16:33:22 |
| chreekat | Useful, but thankless | 16:33:25 |
| catsarecute | Yeah that makes sense, I can see how that could end up being a lot of waiting around.
If you’d be interested in mentoring though, I’d really like to hear what kind of project you think would make sense here. I’m mostly drawn to the Haskell/Nix intersection so I’m happy to adjust the idea if there’s something in that area that would actually be more useful.
| 16:36:07 |
| chreekat | Right now I'm more familiar with the Stackage world. Do any of you Nixpkgs maintainers have any ideas worth considering? | 16:38:12 |
 maralorn | catsarecute: Unless the override is very nix specific we normally don’t accept patches which don’t have open PR upstream. So basically most of what would be done from our side is already been taken care of. | 17:29:18 |
| maralorn | catsarecute: What you also might not be aware of: The fact that we have so many broken packages is also because we autogenerate expressions from hackage and thus there is zero curation. Generally nixpkgs has quite a large adoption in the Haskell community so I assume that most popular packages do probably build. | 17:31:56 |
| maralorn | That being said there are certainly a lot of things that could be improved in our setup. I am just not sure if we can manage to bring in GSoC form. | 17:33:08 |
| alexfmpe | In reply to @maralorn:maralorn.de
catsarecute: Unless the override is very nix specific we normally don’t accept patches which don’t have open PR upstream. So basically most of what would be done from our side is already been taken care of. that's the case for new patches, but I'd assume a lot of them over the years crept in without this standard?
Also there's the work of following through for unmerged PRs that might require addressing maintainer feedback.
There's also the possibility of taking over unmaintained packages on hackage just to keep them building.
Given the number of overrides numbers in the hundreds, I imagine there's all sorts of stuff to be found | 18:07:05 |
| alexfmpe | In reply to @b:chreekat.net
yeah, speaking as somebody who was a GSOC mentor for Haskell a couple years ago, I would actually reconsider skipping out this year depending on what developed here. :) Assuming it's not too late to get registered as a mentor for this year.. From https://summer.haskell.org/ideas.html
This is not an all-inclusive list, so you can apply for projects not in this list and we will try our best to match you with a mentor.
| 18:12:26 |
| alexfmpe | * that's the case for new patches, but I'd assume a lot of them over the years crept in without this standard?
Also there's the work of following through for unmerged PRs that might require addressing maintainer feedback.
There's also the possibility of taking over unmaintained packages on hackage just to keep them building.
Given the number of overrides numbers in the hundreds, I imagine there's all sorts of stuff to be found.
Though I assume 'lots of small things' aren't what most gsoc projects are about | 18:13:28 |
 Alex |
we autogenerate expressions
And as a result many of the broken ones are a doJailbreak away from building.
(Random idea: would automatically trying jailbreak = true on the failing packages as part of the Stackage bump workflow be worth doing?) | 19:16:06 |
| alexfmpe | If you just want to make them build, then yeah that's not too different than what my sweep script does (actually in the other direction to see if jailbreak/etc are no longer needed) | 20:47:38 |
| alexfmpe | In reply to @maralorn:maralorn.de
catsarecute: Unless the override is very nix specific we normally don’t accept patches which don’t have open PR upstream. So basically most of what would be done from our side is already been taken care of. But if we then merge as is it goes against this criteria | 20:48:05 |
| alexfmpe | But maybe it could be somewhat more automated than is | 20:48:53 |
| maralorn | This would in practice help a lot. Although error messages for build errors would get worse. And some people hate nixpkgs and will never touch it because we have doJailbreak. I remember hearing one story where someone lost data in production because we ignored a bound which didn’t prevent a compile error but a runtime error … | 21:51:47 |
 sterni | of course 9.12.4 released when I was busy. I've updated the RC PR now: https://github.com/NixOS/nixpkgs/pull/500108 | 21:53:05 |
