| 28 Aug 2025 |
 sterni (he/him) | Thibaut: we are updating to the latest version of dhall as part of https://github.com/NixOS/nixpkgs/pull/429810. We could use some help fixing build failures in the dhall-related packages: https://hydra.nixos.org/eval/1818002?filter=dhall&compare=1817909&full= | 13:14:48 |
 emily | how should we handle llvm-ffi in https://github.com/NixOS/nixpkgs/pull/437137? I think it's not great to break CI here, and I question whether we really want llvm-ffi to be using the latest possible LLVM version rather than the one for our default llvmPackages? | 20:17:05 |
| emily | it would make sense if the warning was triggered only for haskell-updates, but it just blocks eval for any PR instead | 20:17:34 |
| emily | and in this case it's asking for an upgrade to an LLVM version that the Haskell library version on master doesn't really support | 20:18:28 |
| emily | I'm tempted to say we just comment out the warning until a better way of doing it is found? | 20:21:53 |
| emily | (which I think would look like: "if the default llvmPackages was bumped and we're on haskell-updates, then warn Haskell maintainers") | 20:22:30 |
 maralorn | emily: Sadly, I have no clue and would have to research the supported versions llvm-ffi. Generally deactivating a warning that blocks you while pinging involved people seems fine. Possibly the person with the most bandwidth to think about this is wolfgangwalther who is not here but is already part of the conversation on github. | 20:28:47 |
| emily | I talked about the warning with sterni in #staging:nixos.org recently :) | 20:29:04 |
| emily | but I don't recall what the concrete conclusion was | 20:29:09 |
| maralorn | Well, I’ll take the opportunity and join that room now. | 20:30:46 |
| sterni (he/him) | llvm-ffi 21.0.0.2 should support LLVM 21 proper | 20:33:42 |
| emily | we don't have that on master, though | 20:34:33 |
| sterni (he/him) | Either bump it manually until the upgrade trickles through via haskell-updates or remove the warning as long as the build doesn't break either should work. | 20:34:57 |
| emily | we could cherry-pick it but it feels dubious for updating an LLVM off an rc to get blocked on this when we haven't even bumped the default version yet | 20:35:01 |
| sterni (he/him) | yes | 20:35:27 |
| sterni (he/him) | I wrote that code when LLVM default was a few versions back, seems like now where it's practically latest we could also sync it with the default version | 20:36:03 |
| sterni (he/him) | instead of latest available | 20:36:07 |
|  Las changed their profile picture. | 20:36:52 |
| emily | right | 20:36:55 |
| emily | we should be defaulting to LLVM 21 for 25.11, hopefully | 20:37:39 |
| Las removed their profile picture. | 20:40:53 |
 Artem | In reply to @sternenseemann:systemli.org
Thibaut: we are updating to the latest version of dhall as part of https://github.com/NixOS/nixpkgs/pull/429810. We could use some help fixing build failures in the dhall-related packages: https://hydra.nixos.org/eval/1818002?filter=dhall&compare=1817909&full= I took a brief look at the hydra log linked. I only saw logs for three failed jobs and from those one is the text/show issue and another one is too strict upper bound on data-defaylt that was PRed recently but has no progress in merging :-( i pinged them on that PR: https://github.com/dhall-lang/dhall-haskell/pull/2659#issuecomment-3234999428 | 21:37:33 |
 Thibaut | I think adding a data-default == 0.7.1.3 and adding it to the failed packages' override could work, I'm checking on dhall-lsp-server | 21:41:02 |
| Thibaut | Redacted or Malformed Event | 23:15:20 |
| Thibaut | it's not enough | 23:15:42 |
| 29 Aug 2025 |
|  @luna-null:matrix.org left the room. | 02:40:19 |
|  @zeorin:matrix.org left the room. | 07:03:56 |
| sterni (he/him) | downgrading data-default is not a good option anyways since it is likely to cause issues elsewhere | 10:41:45 |
| sterni (he/him) | We can do the bound adjustment via patches/overrides as well, we don't need to wait for upstream | 10:43:00 |
 Uraraka ~ Ochaco | Ughh I've had terrible trouble with data-default-class vs data-default. Had to update bounds for another package because of the incompatible update. | 10:58:40 |
