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
Reproducible setuptools #104009
Reproducible setuptools #104009
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Have you checked bootstrapped-pip
is also reproducible?
@FRidh Someone on IRC mentioned that only |
@GrahamcOfBorg build python3.pkgs.setuptools |
I think the tar command is fine, bootstrapped-pip and setuptools are building and passing |
@r-burns I think you might need to run |
@basile-henry by changing the expression the derivation is changed, so there is no issue with cache using here. Anyway, I will wait for ofborg on darwin for confirmation. |
You are right for the first build. What I am unsure about is how deep |
The |
Building it once on darwin is indeed sufficient to check if the tar command works. Thanks for checking that 👍 I just wanted to check for myself if
|
|
||
# Here we untar the sdist and retar it in order to control the timestamps | ||
# of all the files included | ||
tar -xzf dist/${pname}-${version}.post0.tar.gz -C dist/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will the filename always contain post0 or can that change with an update?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the name of the release tag post0
is deterministic now (it used to contain the date). The patch of setup.cfg
ensures that.
It is possible that an update of the source changes that (if the build system upstream is updated), but I would assume that the tag-date.patch
would also need to be updated then. If/when that happens this buildPhase
should fail loudly, so I don't think hardcoding it is an issue.
If you have any suggestion to make this better, do tell! 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can replace the hardcoded value of '1970-01-01'
with "@$SOURCE_DATE_EPOCH"
Co-authored-by: Pavol Rusnak <pavol@rusnak.io>
Motivation for this change
Part of the efforts at https://r13y.com/ to get a reproducible iso_minimal
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)