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.
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.
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).
There are a variety of additional scripts that are included with the
JRuby installation that use JRuby itself.
For instance the `bin/gem` had the following contents:
```bash
❯ cat /nix/store/kglkqf56ii83yl6yrgcaj5r3s9m2fzr0-jruby-9.2.13.0/bin/gem
load File.join(File.dirname(__FILE__), 'jgem')
```
This is clearly wrong. Patchshebangs was not picking up the fix as part
of stdenv because the patch is not a build input but the final output
itself.
We have to rely on substituteInPlace so that we get the correct version.
```bash
❯ cat /nix/store/k4fnrn0dcsh2wzw81217r0ywsspb468f-jruby-9.2.13.0/bin/gem
```
fixes c88f3adb17, which resulted in
qt 5.15 being used in pythonPackages, despite 5.14 being
declared, and adapts qutebrowser accordingly.
'callPackage { pkgs = pkgs // { … }; }' does not work, because
it does not take into account the recursive evaluation of nixpkgs:
`pkgs/development/interpreters/python/default.nix` calls
`pkgs/top-level/python-packages.nix` with `callPackage`.
Thus, even if the former gets passed the updated `pkgs`,
the latter always gets passed `pkgs.pkgs`.
For the change in the qt5 version to apply consistently, 'pkgs.extend'
must be used.
qutebrowser only used the right qt5 version (5.15) because all
pythonPackages used it anyway.
Optional setting of format == "pyproject", "egg" had been documented
in the manual, but they weren't listed in the function header for
``mk-python-derivation.nix``.
On darwin the compilation would fail with the following warning:
```
clang-7: error: argument unused during compilation: '-fno-strict-overflow' [-Werror,-Wunused-command-line-argument]
```
This error happens because the `-fno-strict-overflow` is passed to the compiler. To fix this, disable the `strictoverflow` hardening feature. Also see #39687.
ZHF: #97479
/cc roundup issues: #96821, #96828.
The diff upstream is fairly small, so let me trust Mike Pall on this.
Both versions get a pair of commits that seem to address the CVE
https://github.com/LuaJIT/LuaJIT/issues/603
and 2.1 additionally gets one other small commit.
The erlang `generic-builder` accepts a lot of arguments that would
affect the `configureFlags` passed to `mkDerivation`. Though all these
arguments would be without any effect if additionally `configureFlags`
is passed and not the empty list.
This change should make it easier to "compose" arbitrary erlang overrides.
This commit introduces two changes.
First, cpython gets optional BlueZ support, which is needed for
AF_BLUETOOTH sockets. Therefore bluezSupport was added as a parameter.
Second, the call to the pythonFull packages has been adjusted. The
Python packages have a self-reference called self. This was not adjusted
for the override. As a result, Python packages for this special version
of Python were not built with the overridden Python, but with the
original one.
Before this commit, we only built the main ACL2 executable. Most users
will also want the standard library (the "Community Books"), so after
this commit, we build the entire `make everything` suite, which includes
essentially everything provided in the ACL2 repository.
There's also a new top-level package called `acl2-minimal` which has
just the core ACL2 executable, for those who really only want that.
Future work: modularize the build so that we can support multiple
different subsets of the standard library. A lot of the stuff in this
complete build is probably superfluous to almost all users. Also,
because some of the books have unclear or idiosyncratic licenses, the
full build will not be cached on cache.nixos.org, and installing it will
mean spending a few hours building it. So it would be good to have a
pared down build which excluded non-free books and things that people
rarely or never use.
This adds a warning to the top of each “boot” package that reads:
Note: this package is used for bootstrapping fetchurl, and thus cannot
use fetchpatch! All mutable patches (generated by GitHub or cgit) that
are needed here should be included directly in Nixpkgs as files.
This makes it clear to maintainer that they may need to treat this
package a little differently than others. Importantly, we can’t use
fetchpatch here due to using <nix/fetchurl.nix>. To avoid having stale
hashes, we need to include patches that are subject to changing
overtime (for instance, gitweb’s patches contain a version number at
the bottom).
