Closed lamby closed 6 years ago
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.
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...
It turns out that this might just be a bug and I fixed it in https://github.com/FCS-analysis/multipletau/commit/d2734df4680e615c3577b22d88670d972956da88.
@mestia Please try again with multipletau ~0.3.1~ 0.3.2
(Did you mean mestia or myself?)
(Did you mean mestia or myself?)
I guess he meant me, I am preparing the new upload which hopefully will solve the problem.
Yay!
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!
Thank you!