| 26 May 2021 |
 joe (he/him) | Or similarly: If a package needs to be jailbroken, don't "just do it" if the types haven't changed | 04:24:56 |
 berberman | Hi, haskell-language-server recently upgrades apply-refact to 0.9.3.0, which was released 2021-05-21, but it seems that haskell-updates does not have this new version yet. When will haskell-updates update? Will "Haskell updates #123682" include this? | 05:46:08 |
 maralorn | In reply to @cdepillabout:matrix.org
I'm leaning towards merging haskell-updates into master. But I don't really have a good idea of how risky it is, or what peti would normally do. Do either of you guys have an opinion here? From all I can tell peti never gave a frack about rebuilds. Just merge it.^^ | 08:52:34 |
| maralorn | In reply to @_xmpp_qy=40xa0.uk:matrix.org
This shit's a plague Can you elaborate what exactly annoys you most? | 08:53:53 |
|  fabfianda changed their display name from Fab to fabfianda. | 09:01:07 |
| maralorn | The problem is that this would be a moderately invasive operation on cabal2nix/hackage2nix and none of us maintainers has a lot of free time or familarity with the code base. So any outside help on this topic would be appreciated. | 09:01:35 |
| maralorn | In reply to @berberman:mozilla.org
Hi, haskell-language-server recently upgrades apply-refact to 0.9.3.0, which was released 2021-05-21, but it seems that haskell-updates does not have this new version yet. When will haskell-updates update? Will "Haskell updates #123682" include this? No, I don‘t think so. We do an update roughly every 2 weeks. | 09:02:53 |
| maralorn | berberman: Here is a description of our current progress: https://github.com/NixOS/nixpkgs/issues/121140#issuecomment-830816599 | 09:08:02 |
| maralorn | * berberman: Here is a description of our current process: https://github.com/NixOS/nixpkgs/issues/121140#issuecomment-830816599 | 09:08:19 |
| maralorn | cdepillabout: Your PRs currently reference the HACKING.md which does not yet exist in the repo. | 09:08:39 |
| berberman | maralorn: I see, thank you! | 09:09:11 |
| joe (he/him) | Thanks for keeping Haskell+Nix so great! | 09:21:05 |
| joe (he/him) | There should be a pizza/beer fund to be used by the person doing the merge every period | 09:28:31 |
|  immae (he/him) changed their display name from immae to immae (he/him). | 10:13:07 |
 sterni (he/him) | In reply to @maralorn:maralorn.de
From all I can tell peti never gave a frack about rebuilds. Just merge it.^^ ideally you would merge master into haskell-updates once again wait fro the rebuilds to finish and merge then | 12:39:53 |
| sterni (he/him) | which has the same outcome really, but avoids blocking the channel by accident (I believe cachix is a channel constituent) | 12:40:14 |
| sterni (he/him) | In reply to @maralorn:maralorn.de
The problem is that this would be a moderately invasive operation on cabal2nix/hackage2nix and none of us maintainers has a lot of free time or familarity with the code base. So any outside help on this topic would be appreciated. also this is yet another layer of complexity added to the process we have currently which we already made quite a bit more involved than before (in terms of moving / interacting parts, not necessarily usability) | 12:41:21 |
| maralorn | In reply to @sternenseemann:systemli.org
also this is yet another layer of complexity added to the process we have currently which we already made quite a bit more involved than before (in terms of moving / interacting parts, not necessarily usability) I am not really afraid of that. Yes, automation brings complexity but if done well complexity covered by the code is complexity we developers don't need to deal with. | 12:57:56 |
| sterni (he/him) | It's not just code complexity it's also semantic complexity you have to kinda be aware of when contributing | 12:59:23 |
| sterni (he/him) | at least that is what I am afraid of we'll reach | 12:59:32 |
| maralorn | In reply to @sternenseemann:systemli.org
which has the same outcome really, but avoids blocking the channel by accident (I believe cachix is a channel constituent) If cachix builds on our branch and not on master then in 99% of cases that means that cachix is already broken on master. So in a sense that's not our fault. It should be fixed as soon as possible but that's orthogonal to our PR. Besides build fails channel advancement depends on all package build being finished so that does not have a lot to do with cachix. | 13:02:32 |
| sterni (he/him) | In reply to @maralorn:maralorn.de
If cachix builds on our branch and not on master then in 99% of cases that means that cachix is already broken on master. So in a sense that's not our fault. It should be fixed as soon as possible but that's orthogonal to our PR. Besides build fails channel advancement depends on all package build being finished so that does not have a lot to do with cachix. not about failures, build times | 13:03:02 |
| sterni (he/him) | like the channel will be unable to advance until we have rebuild enough of the haskell packages set to build cachix | 13:03:24 |
| sterni (he/him) | if it takes a day to rebuild we can just do it on the branch and have the cache fully populated already when we merge | 13:03:46 |
| maralorn | In reply to @sternenseemann:systemli.org
It's not just code complexity it's also semantic complexity you have to kinda be aware of when contributing We actually already have the case that broken flags are kinda opaque to drive by contributers. Sometimes packages are marked broken without an easily understandable reason and cdepillabout pings me to figure out why. (this is more of a statement of fact. I am not arguing in any specific direction.) | 13:05:26 |
| maralorn | In reply to @sternenseemann:systemli.org
like the channel will be unable to advance until we have rebuild enough of the haskell packages set to build cachix I understand your point, but this has nothing to do with cachix. The channel will only advance when all jobs in the evaluation are finished. This includes all haskellPackages. Or are we talking about unstable-small and cachix is included in that? I assume it isn't. | 13:07:18 |
| maralorn | In reply to @sternenseemann:systemli.org
if it takes a day to rebuild we can just do it on the branch and have the cache fully populated already when we merge I am torn on this point. The fact is if our merge would mean a 500+ rebuild we would have to target staging. (and haskell builds aren't the fastest.) So we should basically adhere to that. Otoh the longer we push off a merge the higher is the risk that hydra does redundant additional work. | 13:10:15 |
| sterni (he/him) | the channel will advance when all constituents of a certain aggregate job are built not when all of nixpkgs is built | 13:11:13 |
| sterni (he/him) | and cachix is part of the nixpkgs:unstable job | 13:11:23 |
| sterni (he/him) | https://hydra.nixos.org/job/nixpkgs/trunk/unstable | 13:11:59 |
