| 2 Jun 2021 |
 maralorn | In reply to @Las:matrix.org
How is https://github.com/haskell-gi/haskell-gi/issues/329 going to be dealt with? Do you think there is anything we could reasonably prepare? If not we would probably default to dealing with breakages when they get introduced by the auto update. In general I just hope that once haskell-gi switches to gtk4 we will have support for it in nixpkgs. | 12:53:12 |
 sterni (he/him) | gtk4 is packaged already | 12:53:57 |
 Las | I was thinking a lot of packages would only work with gi-gtk for gtk3 | 12:53:58 |
| Las | so if gi-gtk suddenly becomes gtk4 a lot of packages would break I think | 12:54:38 |
| sterni (he/him) | we can just pin the version for the default attribute and override the package that need the newer one manually | 12:55:11 |
| sterni (he/him) | but may be a lot of annoying manual effort if they don't split the packages, yes | 12:55:35 |
| maralorn | Yeah its quite a hazzle because haskell-gi has so many packages | 13:15:07 |
| Las | Couldn't cabal2nix see what major revision of gi-gtk a package uses and then either use haskellPackages.gi-gtk3 or haskellPackages.gi-gtk4? | 13:25:06 |
| maralorn | Las: Yeah, that would probably not be very hard. But it might require a dive into the code. | 13:27:06 |
| sterni (he/him) | not a fan of inventing virtual packages ourselves though | 13:27:36 |
| Las | You could have a separate package for each major revision of each package to make it orthogonal | 13:29:39 |
| Las | I imagine it's not just gi-gtk that is problematic | 13:29:45 |
| maralorn | Well the general problem is, that the nix derivation of a cabal package has no way to communicate any version bounds. | 13:29:55 |
| Las | Well I imagine all packages depend on a specific major version | 13:30:45 |
| Las | Since they are often incompatible with each other | 13:30:54 |
| maralorn | The question is: Where is the balance between hardcoding that for a certain package or doing it automatically for all packages. | 13:31:51 |
| maralorn | Generally doing that for all packages i.e. let them depend on aeson_1_5 and not on aeson would translate a lot of builderrors into eval errors. Also it would bloat nixpkgs by generating a lot of aliases. | 13:35:27 |
| maralorn | Still having a way to enable that for some packages would grant us a lot of flexibility … | 13:36:16 |
| maralorn | But not even sure if it would solve the haskell-gi problem. | 13:37:16 |
 cdepillabout | The Haskell team in Nixpkgs will helping people with hacking on Nix-related stuff at ZuriHac this year. The event is online and free, so we'd love to have everyone here participate if you're free: https://discourse.nixos.org/t/nix-and-haskell-at-zurihac-2021/13417 | 14:14:27 |
| Las | It's a shame that ZuriHac isn't also using Matrix | 14:36:57 |
| maralorn | Las: I have the fear that Matrix wouldn‘t be able to deliver the same voice/video-chat experience. | 14:38:01 |
| Las | maralorn: I don't think that's a fear, that's a fact | 14:40:16 |
| Las | Video chat still isn't very well developed on Matrix | 14:40:28 |
| Las | For 1-to-1 calls, it's very good though | 14:40:35 |
| Las | For multiple people, screen sharing, etc. it's lacking | 14:40:43 |
| maralorn | I haven‘t tried for quite a while. | 14:40:47 |
| maralorn | Oh, yeah. Screen sharing is probably a pain point. | 14:41:04 |
| Las | Jitsi integration is used for it after all | 14:41:32 |
| Las | I remember reading on HN some comment by Arathorn about them going to do something about it | 14:42:01 |
