| 15 Nov 2024 |
 emily | there's some iffiness around using the compiler outside the sandbox without an SDK to do Linux-to-Darwin cross but… eh… | 09:23:40 |
| emily | Linux-to-Darwin cross doesn't even work yet for one | 09:23:56 |
| emily | and when it does the divergence will become annoying | 09:24:00 |
 p14 | https://matrix.to/#/!ayCRiZriCVtuCUpeLp:nixos.org/$qpO1aqKQfb-3zGKi_wHlLgQ-nCND4chY_Tc5kHQHqNQ?via=nixos.org&via=matrix.org&via=tchncs.de was just asking about linux-to-darwin cross. I was under the impression it isn't possible. Is there a way? | 09:24:29 |
| emily | I'll reply there :) | 09:25:03 |
| p14 | In reply to @emilazy:matrix.org
should maybe just send this to staging so you can do the --replace-fail thing? I sent this as a separate patch. https://github.com/NixOS/nixpkgs/pull/356120 | 09:52:50 |
| p14 | Currently untested while I await a bunch of staging to build. Is there some automated on-PR testing available? | 09:53:30 |
| emily | don't you mean --replace-fail '--replace ' '--replace-fail '? | 09:54:56 |
| emily | In reply to @p14:matrix.org
Currently untested while I await a bunch of staging to build. Is there some automated on-PR testing available? ofborg does build staging PRs. | 09:55:05 |
| emily | I'd be happy to just hit the button on this though. | 09:55:27 |
| emily | I'm going to bootstrap a Darwin stdenv on the latest staging in the next day or so. | 09:55:36 |
| emily | so if it breaks I know who to complain to | 09:55:44 |
| emily | this will break the Git LLVM without that other PR, though, right? | 09:55:51 |
| emily | those test failures didn't seem like they ought to be related to me | 09:55:57 |
| p14 | Agree with everything you said. | 09:56:09 |
| emily | In reply to @p14:matrix.org
Currently untested while I await a bunch of staging to build. Is there some automated on-PR testing available? another thing you can/should do is base your PR on git merge-base upstream/master upstream/staging | 09:56:26 |
| emily | which lets you target staging but get master amounts of rebuilds for testing | 09:56:38 |
| emily | (of course you don't test its combination with other staging changes but it's better than nothing) | 09:56:54 |
| p14 | It doesn't apply on that unfortunately | 09:57:03 |
| emily | right. tragic | 09:57:46 |
| p14 | (but thanks for the hint! Hopefully I remember that trick when I future have to target staging) | 09:58:08 |
| emily | usually you can just base it on master. the merge base stuff only matters if something from the 6-hour window before the next merge is relevant to your change | 09:58:44 |
| emily | well, relevant or conflicting | 09:59:15 |
| p14 | Depending on the nature of the change I guess there is always some risk from the delta. | 10:00:07 |
| p14 | But same can be said from the delta of when the PR was made vs when it lands I suppose.. | 10:00:26 |
| emily | staging is kind of an aggregator of fun unexpected risk | 10:01:39 |
| emily | mostly by successfully decoupling making changes from dealing with the pain they produce 😅 | 10:02:21 |
|  zoechi joined the room. | 10:17:15 |
| p14 | emily: one thing I wanted to discuss with you which is a CA /storage footgun: https://github.com/NixOS/nixpkgs/issues/153793
The current implementation of this makes binary outputs of derivations depend on the derivation hash, which pretty much completely negates any CA benefit. Unfortunately in the reproducible-builds sense, changing the random seed changes build outputs.
The route is that the current implementation does (-frandom-seed=drvHash).
| 10:40:05 |
| emily | -frandom-seed is a real pain | 10:40:59 |
