| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Sorry, something went wrong.
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead. |
Sorry, something went wrong.
|
I added this feature 8 months ago. There was a reason for using localtime. See #124435 (review) and 54a7116 Maybe we can ask @jaraco |
Sorry, something went wrong.
|
@jaraco would you have time to look at this one? Would appreciate your expertise on whether changing to UTC time would be acceptable only for cases where SOURCE_DATE_EPOCH is set. |
Sorry, something went wrong.
|
This PR is stale because it has been open for 30 days with no activity. |
Sorry, something went wrong.
There was a problem hiding this comment.
Here is the conversation where we discussed localtime vs. gmtime.
My concern at the time was that the code was changing localtime(time.time()) to gmtime(time.time()) even for the case where SOURCE_DATE_EPOCH was unset. And at the time, there was no explanation for why that change should be made and it seemed unrelated to the proposed change.
I'm pleased to see that this PR addresses my concern by keeping the behavior unchanged for unset SOURCE_DATE_EPOCH.
Unfortunately, even the tests are merely reflecting the implementation, so aren't capturing an external expectation. We can improve that situation in this PR, at least for the SOURCE_DATE_EPOCH case.
I do think we should apply this proposed change as a bugfix to all relevant Pythons. It seems to me this value was never correct. It will mean some instability, but I'm struggling to think of any other option. Better to have consistent behavior across all patched Pythons than have reproducibility dependent on minor Python version.
It's conceivable that gmtime should also be used unconditionally, but that's a broader problem with greater backward compatibility concerns and would demand larger scrutiny.
Sorry, something went wrong.
Documentation build overview481 files changed · ± 448 modified · - 33 deleted ± Modified
- Deleted |
Sorry, something went wrong.
Co-authored-by: Emma Smith <emma@emmatyping.dev>
|
CI runners are flaky. I've had to retry the jobs twice, both for unrelated reasons. I expect them to pass soon. |
Sorry, something went wrong.
|
Sadly the second retry failed in the same Ubuntu job. Sadly, it's a spurious error unrelated to this change. Here's Copilot's analysis: This job did not fail because of a code or test regression in the PR. It was terminated by the runner infrastructure: make ci was still running tests when the job was killed with exit code 143 the log ends with: The runner has received a shutdown signal there is no Python traceback, assertion failure, compiler error, or failing test name before termination Relevant evidence: The failing step is the ASAN test job’s final test command in .github/workflows/build.yml:547-548:
[build.yml#L547-L548](https://github.com/python/cpython/blob/0f962dc8601f31d7b9e1be6745a7cf7c4d5ef94e/.github/workflows/build.yml#L547-L548)
run: xvfb-run make ci
The job was progressing normally through the test suite when it was interrupted.
make ci is the broad CI target from the top-level Makefile, so the interruption happened during the general test run, not in a specific failing source file.
Solution: Treat this as a spurious CI failure and rerun the job. No code change is justified based on these logs alone. If this becomes repeatable in the same job, reduce susceptibility to runner interruption by narrowing the ASAN test workload rather than changing product code. If you want a code-level mitigation for repeat occurrences, the best change is in the workflow, not CPython itself. For example, replace the broad ASAN command with a more targeted test invocation in .github/workflows/build.yml:
or, if ASAN-specific coverage is still desired but runtime needs to be reduced, run a curated subset instead of make ci. Bottom line: the correct solution for this job is to rerun it; there is no evidence of a bug in the referenced code from this log. |
Sorry, something went wrong.
|
Thanks @ctrlaltf2 for the PR, and @jaraco for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14, 3.15. |
Sorry, something went wrong.
|
GH-150137 is a backport of this pull request to the 3.15 branch. |
Sorry, something went wrong.
|
GH-150138 is a backport of this pull request to the 3.14 branch. |
Sorry, something went wrong.
|
I thought maybe there was a timeout, but that doesn't seem likely, as the second attempt ended after ~15 minutes and the third after ~9 minutes. The fourth attempt (second retry/third attempt of ubuntu freethreading) succeeded. So whatever it is is spurious. |
Sorry, something went wrong.
… builds & tests (GH-134264) (#150138) gh-134261: ZipFile - Don't rely on local time for reproducible builds & tests (GH-134264) --------- (cherry picked from commit 9dcf94e) Co-authored-by: Caleb <23644849+ctrlaltf2@users.noreply.github.com> Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com> Co-authored-by: Emma Smith <emma@emmatyping.dev> Co-authored-by: Jason R. Coombs <jaraco@jaraco.com>
… builds & tests (GH-134264) (#150137) gh-134261: ZipFile - Don't rely on local time for reproducible builds & tests (GH-134264) --------- (cherry picked from commit 9dcf94e) Co-authored-by: Caleb <23644849+ctrlaltf2@users.noreply.github.com> Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com> Co-authored-by: Emma Smith <emma@emmatyping.dev> Co-authored-by: Jason R. Coombs <jaraco@jaraco.com>
| Back | FazBrowse Home | New Git URL |
See #134261 for issue background and technical detail on causes. This solves the issue by using gmtime whenever SOURCE_DATE_EPOCH is involved, to prevent pulling in system timezone information when performing time calculations.