| 17 Nov 2024 |
 emily | the alternative would be to backport even more patches to set the defaults in GCC itself, which would then make pinning gcc13 not work as expected, and also be more work | 11:02:37 |
 @trofi:matrix.org | On my system c23 will break at least 80 packages: https://trofi.github.io/posts/326-gcc-15-switched-to-c23.html, about 4% of packages. All of nixpkgs will have quite a few more. | 17:47:50 |
| emily | đź« | 17:49:01 |
| emily | 4% didn't seem so bad until I saw the list | 17:49:04 |
| 18 Nov 2024 |
|  @yannis:mozilla.org changed their display name from yannis to yannis|pto_back_nov_26. | 10:40:11 |
 sterni | emily: I don't get why we aren't using env or something instead of execline, surely coreutils or busybox are better optimised w.r.t. closure/bootstrapping? | 15:11:53 |
| emily | IIRC env doesn't work because of CLI arguments or something. https://github.com/NixOS/nixpkgs/pull/324071 originally just used a tiny inline C program but got bikeshedded into using execline because it's there | 15:12:30 |
| emily | I would be okay just doing the tiny inline C program thing | 15:12:35 |
| emily | right, we can't do env -- because we want it to be a binary path rather than an argv | 15:12:53 |
| emily | though some of the other things in there will already break if you give them options so maybe we should be doing wrappers of some kind anyway | 15:13:10 |
| emily | the advantage of our own tiny C program is that it inherently doesn't depend on fetching. | 15:14:08 |
| sterni | It's a bit silly that we can't really return the empty string. | 23:55:21 |
| 19 Nov 2024 |
| emily | yeah. well, it makes sense that we want something that's usable as an argv[0] | 00:08:01 |
| emily | I lean towards just vendoring the C program, but if that doesn't fly I feel like my PR is an improvement. | 00:08:29 |
|  @midirhee12:tchncs.de joined the room. | 05:45:33 |
| sterni | Why is the dependency closure a concern anyways? | 13:53:34 |
| sterni | I think I don't understand the problem yet we are trying to solve | 13:53:42 |
| emily | in the case of https://github.com/NixOS/nixpkgs/pull/351768 it meant >100 more builds to test stdenv changes just because of doing the right thing to handle cross | 13:55:26 |
| emily | the hack works, but it seems basically suboptimal that switching from canExecute to the more general and capable emulator stuff brings in a bunch of stuff, especially in weird platform/cross scenarios | 13:56:28 |
| emily | I mean I thought the original C program was fine | 13:56:38 |
| emily | it just doesn't seem that sensible to be pulling in a bunch of deps for a manpage build for a core stdenv function | 13:57:04 |
| emily | In reply to @emilazy:matrix.org
the hack works, but it seems basically suboptimal that switching from canExecute to the more general and capable emulator stuff brings in a bunch of stuff, especially in weird platform/cross scenarios (well specifically cross scenarios are fine because they'd be picking another emulator I guess…) | 13:57:14 |
| emily | I don't necessarily think execline should have to be held to the standard of having a reasonable closure although it is a sufficiently simple package that it doesn't seem overly burdensome | 13:57:47 |
| emily | but like if it suddenly started depending on ShellCheck or something that would be quite awful for the return value of the nop case of a core lib function | 13:58:10 |
 Randy Eckenrode | If we do switch to emulators for things, that would open up using Rosetta 2 for aarch64- to x86_64-darwin cross. (I have started and stopped adding it several times, but it always seems pointless if it can’t be used to run tests.) | 14:06:48 |
| emily | tests are harder I think | 14:07:47 |
| emily | but it's used for some things in the tree | 14:07:51 |
| emily | e.g. completions | 14:08:14 |
| emily | and gobject-introspection nonsense | 14:08:27 |
| sterni | emily: but we always pull in a bunch of stuff for cross, I don't understand the concern?! | 14:18:29 |
