reproducible builds problem from NUM_JOBS

[bmwiedemann]

While working on reproducible builds for openSUSE, I found that
our yazi 25.2.11 package varied because the number of cores in the build-VM got recorded into the build result:

/usr/src/debug/yazi-25.2.11/target/release/build/rav1e-ded541fb470593d5/out/built.rs    2025-02-12 10:23:43.000000000 +0000
@@ -57,7 +57,7 @@
 pub static OPT_LEVEL: &str = "3";
 #[doc=r#"The parallelism that was specified during compilation."#]
 #[allow(dead_code)]
-pub static NUM_JOBS: u32 = 4;
+pub static NUM_JOBS: u32 = 1;

What would be the best way to avoid that and is it possible to change behaviour so that it is reproducible if the $SOURCE_DATE_EPOCH env var is set?

[lukaslueg]

I guess we could hardcode NUM_JOBS to 1 in case $SOURCE_DATE_EPOCH is set, as the variable being set is a good indicator that a reproducible build is desired, and NUM_JOBS is somewhat of a useless info anyway. However, reproducible builds have been somewhat of a non-goal, since they can be somewhat difficult to support. Is this the only reproducibility diff you get, under all conditions?

[bmwiedemann]

It is the only issue here.

You don't have to actively test for support reproducible builds. I test all our (openSUSE) packages for variations anyway and tell upstreams. When possible, I even send patches.

[lukaslueg]

Do the have the option to test current head from git and see if this resolves your problem?

[bmwiedemann]

I added commit 7ee42a5 into our vendor tarball and it made yazi build reproducibly now. Thank you for the nice fix.

[lukaslueg]

Bumped to 0.7.7