| 15 Nov 2024 |
 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 |
| emily | "the hash of the path of the object file being built so that it is unique to the object file rather than the project being built" doesn't even work because you can have two copies of the same file, or compile the same file twice, or whatever, I think | 10:41:30 |
| emily | maybe hash of the file contents + hash of command line + a counter (but then, nondeterminism from parallelism?) | 10:41:57 |
| emily | ideally C++ wouldn't work like that | 10:42:12 |
| emily | I wonder how viable it would be to just set -frandom-seed=0 and set it specifically in packages that would break | 10:42:28 |
| p14 | https://github.com/NixOS/nixpkgs/issues/151475#issuecomment-1245992562 | 10:42:36 |
| p14 | I've been doing -frandom-seed=fixed in some projects and haven't become aware of ill effects but I do not know what the true generalised consequences might be. | 10:43:10 |
| p14 | The need to have such a seed seems a bit bonkers from a reproducible builds standpoint | 10:43:33 |
