| 21 Jan 2025 |
 Randy Eckenrode | I didn’t call it out in my comments, but I think there was at least one that looked like it would evaluate differently after the change. | 16:57:31 |
| Randy Eckenrode | In reply to @rosscomputerguy:matrix.org
Yeah which is why I switched to libunwind-system I didn’t see a reply to my comment, but that takes care of it. Thanks! | 16:58:09 |
| Randy Eckenrode | The only other possibility is some of the useLLVM logic that was converted now evaluates to true on Darwin. If something is getting new/additional CMake flags, that would cause rebuilds. | 16:58:35 |
| Randy Eckenrode | Also, I think changing the order of flags can cause rebuilds. | 16:59:12 |
| Randy Eckenrode | Though looking at compiler-rt, I think it’s more the former. Those flags are probably fine, but if you want to target master, they would need a !stdenv.hostPlatform.isDarwin that could be dropped to enable them in staging. | 17:00:58 |
 Tristan Ross | Yeah, I need to run a nix-diff to figure things out | 17:01:15 |
 emily | I think this can just go to staging… bootstrap changes will almost certainly have to go through there anyway | 17:01:21 |
| Tristan Ross | I just don't have time right now lol | 17:01:22 |
| emily | it's not like it will result in any urgent behaviour fixes | 17:01:44 |
| emily | (though of course we should make sure that any builds it changes get more correct) | 17:01:50 |
| Randy Eckenrode | I’d just like all the conditionals to be simplified. If unwinderlib is being checked for libgcc_s, that should never be true on Darwin. If it ever is, then maybe that conditional should be enabled. | 17:02:29 |
| Randy Eckenrode | The extra granularity should help clean things up a lot instead of having useLLVM && (not three or four platforms). | 17:02:50 |
| Randy Eckenrode | But I didn’t suggest more of those changes to keep the scope simple for now. | 17:03:23 |
| Tristan Ross | In reply to @emilazy:matrix.org
I think this can just go to staging… bootstrap changes will almost certainly have to go through there anyway The thing is, this is supposed to be like a semantics change | 17:03:48 |
| Tristan Ross | So that shouldn't cause rebuilds | 17:03:56 |
| emily | right. but along the way we are likely to discover that some useLLVM conditionals were wrong. so we should at least fix those (but doing that separately on staging is fine too) | 17:04:33 |
| emily | (precisely because Darwin is almost entirely useLLVM but not included in it) | 17:04:42 |
| 22 Jan 2025 |
| Tristan Ross | Rebuild counts are going down yay | 03:34:12 |
| emily | I'll try to give it a proper re-review in the next day or two | 03:40:41 |
| Tristan Ross | Rebuild count is down to nothing now, only 3 because of references to the lib directory's path. | 04:31:18 |
| 23 Jan 2025 |
|  @paparodeo:matrix.org left the room. | 01:24:26 |
|  Yogansh joined the room. | 08:09:16 |
| Tristan Ross | While I'm waiting for reviews, I've decided to resurrect the CPU model PR I had and start fresh. https://github.com/NixOS/nixpkgs/pull/376197 this is very WIP. | 19:22:53 |
| 30 Jan 2025 |
 Alex | Is this the right place to ask about adding a boot GHC to tarballs.nixos.org for RISC-V?
Upstream does not yet provide bindists and even if they started to do so in a new version, it would take a very long time for that version to become the Nixpkgs default.
(This was also asked back in 2024-09 but it was slightly too early back then.) | 15:25:04 |
| Tristan Ross | In reply to @alex:tunstall.xyz
Is this the right place to ask about adding a boot GHC to tarballs.nixos.org for RISC-V?
Upstream does not yet provide bindists and even if they started to do so in a new version, it would take a very long time for that version to become the Nixpkgs default.
(This was also asked back in 2024-09 but it was slightly too early back then.) I don't have any real negativity towards it. I can see how it would be useful. | 17:54:24 |
| Tristan Ross | But how much maintenance does it require? Would we drop it once upstream does? | 17:55:03 |
| Tristan Ross | How big would we expect the GHC bootstrap to be? Which versions should we support? | 17:55:50 |
| Alex | The bare minimum would be one for the oldest GHC release that Nixpkgs wants to support.
Unless there's a serious problem with the tarball, there would be little need to change it.
Having tarballs for other major.minor releases could provide a shorter build path for newer versions.
We could drop the tarball once upstream provide a tarball that can build all Nixpkgs supported versions, or at the very least the active Nixpkgs default.
AFAIK upstream has made no effort to support booting GHC with a newer major.minor release, so I suspect that we'll need to keep around one of our own tarballs past the release of an official tarball.
GHC tarballs tend to be quite large, but if necessary, we can configure the build to be the bare minimum needed to boot GHC and make them much smaller.
I would need to experiment with this to find how small we can go, but I think it's reasonable to say that in the worst case it would be no larger than the current upstream bindists, which are meant to be used as fully functional GHCs.
For reference, upstream bindists for 9.12.1 seem to be around 300 MiB with xz compression. | 19:05:39 |
|  ofalvai joined the room. | 19:45:34 |
| 31 Jan 2025 |
|  SomeoneSerge (back on matrix) changed their display name from SomeoneSerge to SomeoneSerge (Bruxelles). | 19:34:42 |
