| 21 Jan 2025 |
 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 (hash-versioned python modules when) changed their display name from SomeoneSerge to SomeoneSerge (Bruxelles). | 19:34:42 |
| 2 Feb 2025 |
|  pbsds changed their display name from pbsds to pbsds (FOSDEM). | 16:04:16 |
 connor (he/him) (UTC-5) | When using the multiple outputs setup hooks, is it possible to define per-output propagated dependencies besides manually adding them to the relevant file in the nix-support directory of the output?
As an example, a header-only output may have a dependency on another derivation’s header-only output. My understanding is that the current way to handle this would be to add the dependency in propagatedBuildInputs, though that would add the dependency to every output, correct? | 21:24:39 |
| 3 Feb 2025 |
| SomeoneSerge (hash-versioned python modules when) changed their display name from SomeoneSerge (Bruxelles) to SomeoneSerge (Gand St. Pieters). | 13:40:06 |
| pbsds changed their display name from pbsds (FOSDEM) to pbsds. | 16:25:09 |
| 5 Feb 2025 |
|  hexadecimal_dinosaur joined the room. | 02:46:03 |
|  Sergei Zimmerman (xokdvium) joined the room. | 07:29:48 |
| Sergei Zimmerman (xokdvium) | Not strictly stdenv, but very stdenv-adjacent. Would appreciate some eyes from on https://github.com/NixOS/nixpkgs/pull/379426. The ctest ugliness has been bugging me, so I whipped up this POC as a separate hook first without going through stdenv. | 07:36:17 |
| 6 Feb 2025 |
| SomeoneSerge (hash-versioned python modules when) changed their display name from SomeoneSerge (Gand St. Pieters) to SomeoneSerge (UTC+U[-12,12]). | 17:49:57 |
| 7 Feb 2025 |
 truby | I wanted to test something from gcc's git master branch, is it difficult to get a stdenv with a gcc built from there? I tried the obvious (overriding gcc-unwrapped's src = ..) and it doesn't build, it seems to still be trying to apply patches even though I have patches = [];
Am I missing something to get this working, or is it just more difficult than this? | 14:10:44 |
| Alex | In reply to @truby:matrix.org
I wanted to test something from gcc's git master branch, is it difficult to get a stdenv with a gcc built from there? I tried the obvious (overriding gcc-unwrapped's src = ..) and it doesn't build, it seems to still be trying to apply patches even though I have patches = [];
Am I missing something to get this working, or is it just more difficult than this? Use replaceStdenv? | 16:09:52 |
| truby | My issue is actually getting the unwrapped gcc from a specific git hash I guess, rather than wrapping that into a stdenv | 16:10:52 |
|  @terrorjack:matrix.terrorjack.com left the room. | 22:28:06 |
