| 20 Oct 2024 |
 emily | so you could perhaps ignore pkgs/applications/kde | 04:58:29 |
 Tomodachi94 | In reply to@emilazy:matrix.org
oh, because libsForQt5. Didn't even think about qt5.mkDerivation too, completely missed that | 04:58:51 |
| Tomodachi94 | (I did a treewide that fixed most of the libsForQt5-prefixed invocations, except one that I accidentally skipped) | 04:59:35 |
| Tomodachi94 | * (I manually did a treewide that fixed most of the libsForQt5-prefixed invocations, except one that I accidentally skipped) | 04:59:41 |
| emily | yeah. sadly the best options are manual work or writing a hacky bespoke tool right now. that may change soon depending on how macOS stuff goes | 05:01:42 |
| emily | you could coordinate something like https://github.com/NixOS/nixpkgs/issues/326513 if you have a good list of affected packages, but for Qt 5 a lot of them probably won't be around forever (e.g. K900 wants to get rid of Plasma 5, we'll probably have to drop qtwebengine once upstream stops supporting it, etc.), so I would try to ensure you don't waste effort on stuff that will be removed | 05:02:57 |
 mj | so I'm looking to maintain/introduce a package to NixOS which has multiple output binaries. Is it still best practice to write it into pkgs/by-name/*? | 05:11:17 |
| mj | * so I'm looking to maintain/introduce a package to Nix which has multiple output binaries. Is it still best practice to write it into pkgs/by-name/*? | 05:11:33 |
| mj | * so I'm looking to maintain/introduce a package to nixpkgs which has multiple output binaries. Is it still best practice to write it into pkgs/by-name/*? | 05:11:43 |
| mj | it's a platform | 05:12:54 |
| mj | for managing / developing related things | 05:13:13 |
| emily | by-name doesn't have anything to do with the package's contents | 05:16:50 |
| emily | assuming it is one package | 05:16:52 |
| mj | yes it's just got a central gh repository | 05:17:06 |
| mj | weird how I missed that, thanks | 05:23:52 |
|  hexadecimal_dinosaur joined the room. | 05:49:47 |
 K900 | @Tomodachi94 what's the end goal here? | 06:08:49 |
| Tomodachi94 | @k900:0upti.me: removing all usages of qt5.mkDerivation, per https://github.com/NixOS/nixpkgs/issues/180841. Not sure if it's worth the time though, Qt5 has been EOL for quite some time and emilazy mentioned it might be on its way out in Nixpkgs
| 06:49:31 |
| emily | it's only EOL in 2025 FWIW (and KDE people apparently plan to keep it alive past that point, though for e.g. WebEngine that will certainly not be sufficient) | 06:49:57 |
| K900 | Yes but like, why | 06:50:10 |
| emily | I lean towards thinking that removing unmaintained Qt 5 stuff is a better use of time | 06:50:26 |
| K900 | qt5.mkDerivation mostly causes issues on cross, which is already extremely broken for Qt5 | 06:51:30 |
| K900 | So I don't really see why we need to write tooling to get rid of it | 06:51:57 |
| Tomodachi94 | In reply to @emilazy:matrix.org
I lean towards thinking that removing unmaintained Qt 5 stuff is a better use of time I agree :) I'll focus my energy on that
| 06:58:15 |
| Tomodachi94 | Do you think it'd be worth it to lib.warn when qt5.mkDerivation is used? I'm not familiar with when it's appropriate to use that
| 06:59:12 |
| emily | can't do that, warnings are forbidden by CI in Nixpkgs | 07:00:10 |
| K900 | Yeah, the warnings in nixpkgs are intended to be user facing | 07:02:10 |
|  fredrikr set a profile picture. | 08:09:12 |
| fredrikr changed their display name from fredrikr79 to fredrikr. | 08:09:24 |
 Emma [it/its] | not sure if this is a me issue or not, but i get this when i try launching a vm made with nixos-rebuild build-vm: [1] 3933577 segmentation fault (core dumped) ./result/bin/run-matrix-vm
latest nixpkgs | 14:43:59 |
