New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] perl: build deterministically #45064
Conversation
Nice, thank you for working on this! Please add comments to your changes, explaining the reasons. It would be ideal to propose upstream changes that make patches unnecessary. Also you shouldn't put the details in the commit headline, they should be in the description text. |
b9fd952
to
835917a
Compare
Added a comment in the Nix expression and reformatted the commit message. How would I go about contacting Perl upstream maintainers? I'm afraid I am not used to contributing to such long-established projects (or open-source projects in general to some extent) … |
Yeah it can be a bit intimidating. You usually start by looking at the meta |
cc @volth |
The idea is that since the bootstrap files are pulled in as trusted binaries, they (and everything on the path to building them) should at least be reproducible. With a second patch to make-bootstrap-tools.nix I have everything (in that dependency graph) except GCC building deterministically and idempotently on my machines (and, on my as of yet unpublished ppc64le port, all of it). So this is one step to making this critical piece of infrastructure reproducible. Re: fontforge building fixed-output derivations: those don't result in the same file on ppc64le BTW. |
* replace configuration time with $SOURCE_DATE_EPOCH * set configuration user to 'nixpkgs' * set configuration host to 'nixpkgs' * replace uname and OS version with more reproducible values on Linux
835917a
to
4704d26
Compare
After talking to some perl packagers and looking into how Debian package their perl, I've rewritten the PR to use some config overrides instead of using a patch to rip out offending lines. I don't have the time to test it in any real capacity today, I'll write back tomorrow. |
Did we give that up? I think it is a very practical goal with big advantages. Everything is not practical, but I'm happy about every additional reproducible package. I see that the effort has stalled a bit, but I would be sad if we actually gave that up. @CrystalGamma nice, keep us updated when you tested it. |
And you even found a place to report it upstream, awesome :) |
I've run the test suite, and it seems to produce one more failure than staging, which is weird since it seems to be a part of the language itself rather than anything interacting with the system (specifically it is t/op/each). I'll investigate it some more … |
Are there any updates on this pull request, please? |
Any updates? |
Hi! I agree that the perl build should be reproducible, will try to have a look at this PR a bit later. Some links on the current status in Debian/Arch/openSUSE:
|
Rebased this PR against master in stigtsp@ebfa253, and did a build (with The both return: $ nix-hash --type sha256 /nix/store/ysmbh64nhzjhjkvjh0cl5pv6ikc7njqk-perl-5.33.4 Both outputs give the same hash, appears to be reproducible. |
Running NixOS on my MacBook Pro 11,1:
|
@CrystalGamma Sorry, this has taken a while. But are you available to continue this PR? If not, I'm happy to move your contributions to a new PR and work on finishing it. |
openSUSE's reproducibility patches: |
I marked this as stale due to inactivity. → More info |
Motivation for this change
As it is, Perl does not build deterministically because some information about the build system as well as the build date is written to the output. This patch seeks to remedy this situation.
Things done
nix-shell -p nox --run "nox-review wip"
(I have no time to rebuild all of nixpkgs)nix path-info -S
before and after)