These are unnecessarily composed. Disabling useRailsExpress changes to
using a tarball instead of fetching directly from git, which will have
unexpected effects. In come cases (Ruby 2.7) it will cause the build
to fail due to en error rubygems/installer.rb. It also changes the set
of gems that are available, since the bundled gems[1] are only
included in the tarball.
[1]: https://stdgems.org/
stripping config data was introduced in #138368, but was unintentionally
added to the wrong `optionalString` condition. This isn't a problem in
practice (as the relevant condition flag is enabled by default), but was
unintended and therefore fixed here.
Building Ruby with jit by default includes clang in its closure, hence
causing a large closure size.
Ruby jit support is optional, and is only enabled at runtime through the
`--jit` flag, hence it should not cause any regression.
It's been at least a year since I kept up to date with Ruby, and I
don't think I really have anything left to offer Nixpkgs in terms of
Ruby expertise.
If JIT support is built in to ruby, there's no choice other then to
leave this cc reference as is. removeReferencesToCC didn't do it's job
completely since some time ago. That's why it was practically redundant
- `lib/ruby/${version}/<platform>/rbconfig.rb` still referenced cc.
Removing this reference from
`lib/ruby/${version}/<platform>/rbconfig.rb` as well might lead to
breakage in some Gems that require this feature.
But, if JIT support is not desired, it should be safe enough to
completely remove all cc references, both in
lib/ruby/${version}/<platform>/rbconfig.rb and in $out/lib/libruby.so .
Hence now `rubyMinimal` has JIT support disabled and it has no
references at all to stdenv.cc.
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).
JR Boyens