| 22 Aug 2024 |
 emily | In reply to @emilazy:matrix.org
by having someone record a profile and shipping that as an input, right? this does work though, right? it seems like a benign kind of blob to me since the optimization decisions "shouldn't" affect the actual behaviour of the program (and because you can always reproduce an ~equivalent blob, a la bootstrap tarballs) | 15:59:47 |
| emily | I think Firefox PGO works like that or something? | 15:59:55 |
 Alyssa Ross | I don't think it's benign at all. | 16:00:11 |
| Alyssa Ross | It's not auditable to my knowledge, and compilers are not generally written to be secure against malicious input. | 16:00:45 |
| Alyssa Ross | Firefox PGO in Nixpkgs profiles during the build. | 16:00:53 |
| emily | good point re: malicious input. (I don't have any idea of how elaborate the PGO files actually are) | 16:05:23 |
|  nyanbinary 🏳️⚧️ left the room. | 17:18:57 |
 Atemu | An idea that sprung to my mind just now is that we could install the pgo files generated during a build into an output which should allow reproducing the binary if it's otherwise deterministic | 18:53:09 |
| Atemu | Though that again hinges on PGO files not having the ability to make the compiler produce arbitrary output | 18:54:32 |
| 23 Aug 2024 |
|  @nam3l33ss:matrix.org left the room. | 09:22:00 |
| 24 Aug 2024 |
|  h33p joined the room. | 10:19:04 |
|  @adbjesus:matrix.org left the room. | 15:53:46 |
| 25 Aug 2024 |
|  von.dev joined the room. | 08:30:41 |
|  SomeoneSerge (utc+3) joined the room. | 23:03:45 |
| 26 Aug 2024 |
 @adis:blad.is | I found a reproducibility bug yesterday: https://github.com/NixOS/nixpkgs/issues/337209
The kernel version of the builder causes a Python check hook to fail/succeed depending on the uname of the builder.
It's because of platform_release from https://peps.python.org/pep-0508/#environment-markers
Conceptually the fix is pretty easy: We scrub platform_release and platform_version from the environment.
My problem is that I don't even know what to set them to.
We can probably skip platform_version, but platform_release needs to be a valid version number.
| 02:29:21 |
| emily | pin it to something bigger than any current Linux/macOS/etc. kernel release I guess? | 02:30:44 |
| emily | probably relatively few stuff will treat the latest kernel and really new ones differently | 02:30:55 |
| emily | alternatively we could pin it to the lowest we support on all platforms | 02:31:01 |
| emily | although I don't know if anyone has actually decided what we support for Linux lol | 02:31:08 |
| @adis:blad.is | In reply to @emilazy:matrix.org
although I don't know if anyone has actually decided what we support for Linux lol Using the version of linuxHeaders would make sense there I think | 02:31:38 |
| emily | sounds reasonable. and for macOS, apple-sdk (when it exists in a few weeks) | 02:32:00 |
| emily | though actually you want the darwinMinVersion I guess | 02:32:15 |
| emily | and for other platforms, ??? | 02:32:22 |
| @adis:blad.is | In reply to @emilazy:matrix.org
and for other platforms, ??? I'm inclined to set it to an empty string on those and let the hook fail loudly | 02:32:49 |
| @adis:blad.is | It will only fail for builds which reference platform_release | 02:33:00 |
| emily | I take it setting it to an empty string in general isn't viable? | 02:33:06 |
| @adis:blad.is | And if we can't do something correct we might as well fail | 02:33:17 |
| @adis:blad.is | In reply to @emilazy:matrix.org
I take it setting it to an empty string in general isn't viable? No. That was my initial attempt but that trips up the version parser | 02:33:34 |
| emily | right | 02:33:47 |
| emily | IMO, platforms should actually expose this information | 02:33:59 |
