Since version `0.6.0` the `rust-src` component (or declaring
`RUST_SRC_PATH`) is needed. Just like in `rust-analyzer`, this is solved by
setting `RUST_SRC_PATH` to `rustPlatform.rustLibSrc` for tests and
wrapped executables.
ChangeLog: https://github.com/google/evcxr/blob/v0.6.0/RELEASE_NOTES.md#version-060
Before this change, a Dhall package like the Prelude would be
encoded as a record with one field per supported version. Then
downstream packages would specify which package to override
by selecting a different record field.
The problem with that approach is that it did not provide an
easy way to override a package to a version other than the default
ones supplied by Nixpkgs. Normally you would use the `.override`
method for this purpose, but the `override` method added by
`buildDhall{Directory,GitHub}Package` is clobbered by the
`override` method added by `callPackage` in
`./pkgs/top-level/dhall-packages.nix`.
The solution is to add a separate `.overridePackage` method which is
essentially the exact same as `.override`, except that it is no
longer clobbered by `callPackage`. This `.overridePackage` method
allows one to override the arguments supplied to
`buildDhall{Directory,GitHub}Package`, making it easier to specify
package versions outside of the ones supported by Nixpkgs..
This also includes a change to only build one (preferred) version of each
package (instead of multiple supported versions per package), in order to
minimize the maintenance burden for the Dhall package set.
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 c778945806 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: 4effe769e2
- `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 (803ca85c20)
- 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 c778945806.
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).
