| 19 Sep 2025 |
Wolfgang Walther | will do.. and put it in a PR at first, so that we can just have a look for now. | 18:47:19 |
maralorn | I think I haven’t made it through all my packages. I think especially hls should really work on all versions. But it seems fair to put a bit pressure on that because I had enough time already. | 18:52:55 |
Wolfgang Walther | I fixed some easy ones of yours yesterday, but not HLS :D | 18:53:50 |
| 20 Sep 2025 |
Wolfgang Walther | List in https://github.com/NixOS/nixpkgs/pull/444422, we should merge before "either tonight or tomorrow", when staging-next will be created. | 09:59:00 |
sterni (he/him) | I’ll make a list of packages I’d want to fix on staging-next and then merge it later | 11:17:05 |
maralorn | Wolfgang Walther: sterni Who wants to answer on https://github.com/NixOS/nixpkgs/issues/444721? I think the main point is that we will achieve the switch to 9.10 and have no blockers. Right? | 19:10:34 |
| 21 Sep 2025 |
bglgwyng | I found that 7479392276eede7c7cb89abf1693e8ef9ae5aebd fixed the issue | 05:25:55 |
bglgwyng | but it's just a stackage snapshot update, so there's a problem in my package override logic. | 05:26:22 |
bglgwyng | I did 10+ python3, ghc build for 1 day bisecting between 60,000 commits lol | 05:27:01 |
bglgwyng | https://github.com/bglgwyng/nix-x-cabal/blob/main/modules/cabal-project.nix#L181
I build configured packages and put them into the package db by using ghcWithPackage. Is is safe way to do it? Do we have a more lower level function to build package db?
| 05:50:13 |
bglgwyng | * https://github.com/bglgwyng/nix-x-cabal/blob/main/modules/cabal-project.nix#L181
I build configured packages in plan.json and put them into the package db by using ghcWithPackage. Is is safe way to do it? Do we have a more lower level function to build package db?
| 05:50:22 |
Wolfgang Walther | We had planned to look at Template Haskell in pkgsStatic for this release cycle and I feel that we really shouldn't push this out much further. The gap between pkgsStatic with GHC 9.4 and default with GHC 9.10 is widening now. I think we should discuss how to proceed here first, before deciding on whether we have any blockers or not. | 07:46:43 |
maralorn | I just tried to run nixpkgs-review unix2dos PR and got 23k builds. I feel like I am holding it wrong. | 08:17:58 |
Puna | if you're using local evaluation to get the list of rebuilds, try applying this patch: https://github.com/Mic92/nixpkgs-review/commit/558b6d4da3032bb43c396d6042c41681ac2b9408 | 08:22:09 |
sterni (he/him) | maralorn: sounds about right | 08:23:02 |
maralorn | Okay. I mean, I don’t think we can realistically hold-up the release so this would be more like setting ourselves a deadline. I have no stakes in pkgsStatic I don’t know much about the current problem and I don’t use it. But if there is a way forward to fix it I would of course like that to happen. | 08:23:52 |
maralorn | I see. Then I was just … naive. | 08:24:05 |
maralorn | Would it make more sense then to merge it into haskell-updates to get more visibility whether it breaks any haskell packages? | 08:26:26 |
sterni (he/him) | We could | 08:26:55 |
maralorn | btw. what’s up with the nixpkgs-ci bot regularly closing and opening PRs? Seems a bit spamy?^^ | 08:27:07 |
maralorn | Fixing stuff on staging-next really sucks for review builds … | 08:28:26 |
Wolfgang Walther | That's whenever you change the base branch of a PR. It's a lot less spammy than the alternatives. | 08:43:28 |
maralorn | It prevents the mass pings? | 08:45:39 |
Wolfgang Walther | No, it prevents having to run CI on edited events, which happen for the base branch, but also for any PR title or description changes. If you run CI on these, but skip the jobs, the job log is spammed with a lot of skipped jobs. | 08:52:35 |
sterni (he/him) | maralorn: will get better as builds finish. for now you can base the PRs themselves on haskell-updates which has cache | 10:37:02 |
maralorn | Yeah, that’s what I am doing. | 10:39:37 |
maralorn | Currently fixing HLS on 9.6 and 9.4 which is a complete nightmare. | 10:39:52 |
sterni (he/him) | emily: if both work, is it preferrable to use python3.pkgs.xattr or darwin.xattr? I originally packaged the latter because xattr/xattr lacked some flags but seems like they merged Apple's changes back… | 14:19:57 |
emily | hmm, I think we use darwin.file_cmds (which xattr is now an output of) for very little, e.g. we use GNU coreutils over the BSD-derived Darwin commands generally… so using whatever "everything else" uses generally seems sensible to me. OTOH, why is the other one… Python? it's a C codebase, right? | 14:23:30 |
emily | I guess it looks like either they ported the main() to Python, or they forked from Apple when its main() was Python but Apple have since ported it to C?! | 14:24:13 |