| 3 Oct 2024 |
|  @kmein:nibbana.jp removed their profile picture. | 19:08:24 |
 maralorn | I am opening a tracking issue, maybe that creates some movement. | 17:13:36 |
| @kmein:nibbana.jp left the room. | 19:13:03 |
| maralorn | https://github.com/NixOS/nixpkgs/issues/346214 | 17:18:26 |
| maralorn | I looked up the maintainers. ghcjs is officially maintained by obsidian systems and they gave us green light to remove it. Of course this will be announced with the policy and in the 24.11 release notes and when we get negative feedback we can reconsider. | 17:21:26 |
| maralorn | emily, sterni: Additionally to the tracking issue above I have revised the proposal to include all your remarks. | 17:38:17 |
| maralorn | (This topic greatly profits from bubbling up to the top of my todo list on a national holiday.) | 17:39:01 |
 emily | maralorn: (your messages from hours ago all came through in one big burst just now) | 20:40:32 |
| maralorn | In reply to @emilazy:matrix.org
maralorn: sterni: ok, so Elm:
elmPackages.elm-instrument builds unmodified with 9.4, so that's not a blocker. an unbound ap error for 9.6 that is probably trivial to fix.elmPackages.elmi-to-json needs its deps sorting since hashable-time is broken on newer GHCs, but it needs deps sorting anyway since it depends on vulnerable library versions. perhaps it could simply be dropped if nobody is using it and nobody wants to patch it, since it should probably have knownVulnerabilities anyway…elmPackages.elm-format also builds cleanly with 9.4; 9.6 fails with guard/unless scope stuff that is presumably also trivial.
that seems to be all the Elm packages that require GHC < 9.6? I don't see any real blocker there, at most one package needs patching and it's one that we probably shouldn't be shipping in its current state anyway.
Great, thank you! | 20:13:51 |
| emily | (gotta love Matrix…) | 20:40:35 |
| emily | I'm guessing yi is dead upstream? | 20:41:25 |
| emily | I remember even in like 2008 it was in a state of "dead, maybe someone will revive it some day", and then it kept getting revived and dying again. | 20:41:37 |
| emily | I think we can probably let it die again as a broken package, and I'm sure it will rise from the ashes yet again in the future | 20:42:00 |
| maralorn | I think we can follow up with the various stuff depending on 8.10 in nixpkgs, but it seems very likely to me that we can figure that stuff out in less than half a year. Thus it would still be reasonable to go through with posting that policy RFC. | 22:47:46 |
| maralorn | However, if my matrix server is dying a slow death, that might hinder communication. 😄 | 22:48:39 |
| 4 Oct 2024 |
 Dominik | Hi! I have a problem with linking when the path to a personal Haskell project managed by Nix contains spaces. Is this a known problem? | 07:55:26 |
| Dominik left the room. | 07:56:01 |
| Dominik joined the room. | 07:57:07 |
| 5 Oct 2024 |
 cdepillabout | In reply to @dschrempf:matrix.org
Hi! I have a problem with linking when the path to a personal Haskell project managed by Nix contains spaces. Is this a known problem? I don't think this is a known problem (although there is a lot of code in Nixpkgs that is sloppy with quoting in bash). Maybe you could post an issue on the Nixpkgs repo, assuming you're using the Nixpkgs Haskell infrastructure? | 01:29:13 |
|  magic_rb changed their profile picture. | 22:17:14 |
|  cliffordbeshers joined the room. | 23:39:34 |
| 6 Oct 2024 |
 linj | Currently, update of 6k emacs packages goes through staging cycles due to the large number of rebuilds. I notice that haskell package updates do not go through staging. Instead, there is a nixpkgs:haskell-updates jobset on hydra. Adopting a similar update workflow for emacs packages can result in more frequent updates. Could you share some pros and cons of haskell update workflow vs staging cycles? | 11:40:54 |
