Reproducible builds of pyproject projects using pip is resolved.
Fixes https://github.com/pypa/pip/issues/7808
Fixes https://github.com/NixOS/nixpkgs/issues/81441
The more recent c409f694807e8cd16db8e2affb630073c1aadc48 caused trouble
with pyproject troubles and had to be reverted anyway.
https://github.com/NixOS/nixpkgs/pull/102222#issuecomment-722380794
Revert "pythonPackages.pip: make reproducible (#102222)"
This reverts commit c409f694807e8cd16db8e2affb630073c1aadc48.
Revert "python3Packages.pip: allow setting reproducible temporary directory via NIX_PIP_INSTALL_TMPDIR"
This reverts commit aedbade43e615d7893d268632f5e7f2570fd3233.
with #99631 and #102693 merged, it's possible to bump the babashka
version again.
However recent versions of babashka depend on java11 features and I
spoke in Slack with the project lead and this java11 dependency will
exist going forward.
Now that we have community builds of graalvm landed in #99631, both
clj-kondo and babashka can depend on those versions of graalvm rather
than the one that requires building from source - this can be built in
hydra, and generally is much easier to build and test.
ext/io/console/io-console.gemspec was embedding a timestamp which made
the build not reproducible. Gems respect SOURCE_DATE_EPOCH so it's
enough to just delete that line if it exists.
This file has been fixed in
679a941d05 (diff-d8422f096931c58d4463e2489f62a228b0f24f0492950ba88c8c89a0d741cfe6)
And then ruby regularly merges that gem into their own repository. Ruby
master is fixed but none of the ruby releases have been fixed yet.
lib/ruby/gems/2.6.0/specifications/default/io-console-0.4.7.gemspec now
contains:
s.date = "1980-01-01"
I made a mistake merge. Reverting it in c778945806b undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2b
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c209)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
This reverts commit c778945806b44d46ec16bc4302e7e7163e6bab97.
I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
I'm sorry; I didn't notice it contained staging commits.
This reverts commit 17f5305b6c20df795c365368d2d868266519599e, reversing
changes made to a8a018ddc0a8b5c3d4fa94c94b672c37356bc075.
