Skip to content
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

Please make the version (and documention build) reproducible. #16

Conversation

lamby
Copy link
Contributor

@lamby lamby commented Nov 5, 2018

Whilst working on the Reproducible Builds effort [0], we noticed
that python-multipletau could not be built reproducibly.

This is because it uses the current date which gets embedded into
the documentation file if you are building from a tarball release
and not Git.

Patch attached that uses SOURCE_DATE_EPOCH [1]. This was originally
filed in Debian as #912957 [2].

 [0] https://reproducible-builds.org/
 [1] https://reproducible-builds.org/specs/source-date-epoch/
 [2] https://bugs.debian.org/912957

Whilst working on the Reproducible Builds effort [0], we noticed
that python-multipletau could not be built reproducibly.

This is because it uses the current date which gets embedded into
the documentation file if you are building from a tarball release
and not Git.

Patch attached that uses SOURCE_DATE_EPOCH [1]. This was originally
filed in Debian as #912957 [2].

 [0] https://reproducible-builds.org/
 [1] https://reproducible-builds.org/specs/source-date-epoch/
 [2] https://bugs.debian.org/912957
@paulmueller
Copy link
Member

paulmueller commented Nov 5, 2018

Sorry that my manual versioning approach does not work out for the reproducible builds effort. I cannot accept the current PR without modifications, because it would break my versioning approach.

How are you retrieving the source tarball of multipletau? If you obtained it from PyPI (recommended), then the versioning should be correct (there is a _version_save.py) file in that tarball.

If you are retrieving the source tarball from GitHub (not recommended), then the date (https://github.com/FCS-analysis/multipletau/blob/master/multipletau/_version.py#L119-L125) is used, which is what I believe is the problem here.

If you want to be as close as possible to upstream and have to use the GitHub repo, then I would accept this PR if the changes were incorporated in #3 instead of in #1.5. I could do that within the next few days if you are too busy.

@lamby
Copy link
Contributor Author

lamby commented Nov 5, 2018

because it would break my versioning approach.

How so? Only if SOURCE_DATE_EPOCH is present, no?

How are you retrieving the source tarball of multipletau?

I'm not the maintainer of this package in Debian so I cannot canonically say...

@paulmueller
Copy link
Member

paulmueller commented Nov 5, 2018

It turns out that this might just be a bug and I fixed it in d2734df.

@mestia Please try again with multipletau 0.3.1 0.3.2

@lamby
Copy link
Contributor Author

lamby commented Nov 5, 2018

(Did you mean mestia or myself?)

@mestia
Copy link

mestia commented Nov 5, 2018

(Did you mean mestia or myself?)

I guess he meant me, I am preparing the new upload which hopefully will solve the problem.

@lamby
Copy link
Contributor Author

lamby commented Nov 7, 2018

Yay!

@mestia
Copy link

mestia commented Nov 9, 2018

Sun is shining for python-multipletau at https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-multipletau.html
I think the issue can be closed now. Thanks Chris for reporting and Paul for the quick fix!

@paulmueller
Copy link
Member

Thank you!

@paulmueller paulmueller closed this Nov 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants