| 29 Aug 2023 |
 K900 | I know | 18:46:41 |
| K900 | That just makes it funnier | 18:46:48 |
 infinisil | Yeah xD | 18:47:03 |
| infinisil | Looking into it.. | 18:47:12 |
| 30 Aug 2023 |
 Robert Hensing (roberth) | sorry, didn't get a notification while I was recovering my system from a fried ssd 😞 | 08:40:16 |
| Robert Hensing (roberth) | In reply to @k900:0upti.me
infinisil: https://hydra.nixos.org/build/233371356/nixlog/1 just wrap it in testBuildFailure and grep the output to make sure it still fails | 08:42:02 |
| Robert Hensing (roberth) | (I know, I know. I'm just plugging that function because why not. Test functions are cool) | 08:42:37 |
| infinisil | Robert Hensing (roberth): I don't think that would work well here, it's the channel tarball build that's failing, and it should definitely keep on failing when such files are present | 10:44:45 |
| infinisil | No problem ;) | 10:47:02 |
| infinisil | Nice, the pkgs/by-name CI check runs in about 30 seconds! https://github.com/NixOS/nixpkgs/actions/runs/6026577029/job/16349848006?pr=237439 | 15:00:39 |
| 31 Aug 2023 |
| infinisil | Question for https://github.com/NixOS/nixpkgs/pull/237439:
We can almost declare all top-level packages in pkgs/by-name, except ones that should be declared using e.g. python3Packages.callPackage, libsForQt5.callPackage, etc. | 18:28:28 |
| infinisil | Now there's two options, either: | 18:29:05 |
| infinisil |
- Keep the category hierarchy alive only for new packages of that kind
| 18:29:39 |
| infinisil |
- Deprecate the category hierarchy and introduce something like
pkgs/alt-callPackage, where you can put all packages of that kind
| 18:30:39 |
| K900 | We can absolutely get rid of libsForQt5.callPackage and qt6Packages.callPackage | 18:31:04 |
| infinisil | Both kind of suck but also aren't very significant, but I think in order to keep the number of changes to a minimum I'll go with the first one | 18:31:07 |
| K900 | At least | 18:31:08 |
| K900 | But we can do that in a follow-up | 18:31:17 |
| infinisil | It's a bit tricky because there seems to be some cross compilation shenanigans sometimes | 18:31:46 |
| K900 | In fact I'd really like to get rid of those and maybe get smaller better scoped package sets for KF6/Plasma6/KDE Gear stuff | 18:31:50 |
| K900 | qt6Packages isn't even spliced | 18:32:02 |
| K900 | And qt5 cross was broken until like two days ago | 18:32:20 |
| infinisil | See also my little rant from yesterday: https://matrix.to/#/!kjdutkOsheZdjqYmqp:nixos.org/$U5DUxbsottP-50Q5d0PQYHnX0xZdNpJDJ4hXiNkBdfs?via=nixos.org&via=matrix.org&via=nixos.dev | 18:32:24 |
| infinisil | But yeah, all of those callPackages could be gotten rid of, but that also does affect the derivation interface, and it makes the definitions a bit more complicated, so I don't want to touch that in that PR | 18:33:17 |
 Alyssa Ross | whoa can we cross compile QT 5 now? | 18:33:17 |
| infinisil | * But yeah, all of those callPackages could be gotten rid of, but that also does affect the override interface, and it makes the definitions a bit more complicated, so I don't want to touch that in that PR | 18:33:28 |
| K900 | Yes, and all it took was like five screens of drama | 18:34:40 |
 raitobezarius | Well, amjoseph is probably the one behind it I guess | 18:35:11 |
| infinisil | In reply to @infinisil:matrix.org
Question for https://github.com/NixOS/nixpkgs/pull/237439:
We can almost declare all top-level packages in pkgs/by-name, except ones that should be declared using e.g. python3Packages.callPackage, libsForQt5.callPackage, etc. So then, regarding this, I think it should be fine to say that new top-level packages should always be added to pkgs/by-name | 18:40:59 |
| infinisil | Because there shouldn't be a need to use e.g. python3Packages.callPackage for new packages | 18:41:14 |
