22 Aug 2024 |
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 |
adisbladis | 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 |
adisbladis | 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 |
adisbladis | 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 |
adisbladis | 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 |
adisbladis | And if we can't do something correct we might as well fail | 02:33:17 |
adisbladis | 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 |
emily | the "minimum supported version of the platform" | 02:34:04 |
emily | rather than Python stuff having to figure it out | 02:34:15 |
Alyssa Ross | We have a fake uname package | 08:31:48 |
Alyssa Ross | Although I think here setting it to linuxHeaders.version probably makes sense. | 08:32:15 |