The hack of using `crossConfig` to enforce stricter handling of
dependencies is replaced with a dedicated `strictDeps` for that purpose.
(Experience has shown that my punning was a terrible idea that made more
difficult and embarrising to teach teach.)
Now that is is clear, a few packages now use `strictDeps`, to fix
various bugs:
- bintools-wrapper and cc-wrapper
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/spidermonkey/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/47rbdzbgccrrdc63fnsnwklria9clmms-spidermonkey-52.7.4/bin/js52 -h’ got 0 exit code
- ran ‘/nix/store/47rbdzbgccrrdc63fnsnwklria9clmms-spidermonkey-52.7.4/bin/js52 --help’ got 0 exit code
- ran ‘/nix/store/47rbdzbgccrrdc63fnsnwklria9clmms-spidermonkey-52.7.4/bin/js52 -v’ and found version 52.7.4
- ran ‘/nix/store/47rbdzbgccrrdc63fnsnwklria9clmms-spidermonkey-52.7.4/bin/js52 --version’ and found version 52.7.4
- ran ‘/nix/store/47rbdzbgccrrdc63fnsnwklria9clmms-spidermonkey-52.7.4/bin/js52-config --version’ and found version 52.7.4
- found 52.7.4 with grep in /nix/store/47rbdzbgccrrdc63fnsnwklria9clmms-spidermonkey-52.7.4
- directory tree listing: https://gist.github.com/7e5182415a0a1bce8071576312c08a3a
Note that a bunch of non-python packages use this attribute already.
Some of those are clearly unaware of the fact that this attribute does
not exists in stdenv because they define it but don't to add it to
their `bulidInputs` :)
Also note that I use `buildInputs` here and only handle regular
builds because python and haskell builders do it this way and I'm not
sure how to properly handle the cross-compilation case.
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/jruby/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/g4a83h4462412zd3cf95j5ny19bxgha6-jruby-9.1.17.0/bin/jruby -h’ got 0 exit code
- ran ‘/nix/store/g4a83h4462412zd3cf95j5ny19bxgha6-jruby-9.1.17.0/bin/jruby --help’ got 0 exit code
- ran ‘/nix/store/g4a83h4462412zd3cf95j5ny19bxgha6-jruby-9.1.17.0/bin/jruby.bash -h’ got 0 exit code
- ran ‘/nix/store/g4a83h4462412zd3cf95j5ny19bxgha6-jruby-9.1.17.0/bin/jruby.bash --help’ got 0 exit code
- ran ‘/nix/store/g4a83h4462412zd3cf95j5ny19bxgha6-jruby-9.1.17.0/bin/ruby -h’ got 0 exit code
- ran ‘/nix/store/g4a83h4462412zd3cf95j5ny19bxgha6-jruby-9.1.17.0/bin/ruby --help’ got 0 exit code
- found 9.1.17.0 with grep in /nix/store/g4a83h4462412zd3cf95j5ny19bxgha6-jruby-9.1.17.0
- directory tree listing: https://gist.github.com/20468ca63db765e0d42a1c93191f0901
upstream issue:
https://bugs.python.org/issue31940
There are two PR's proposed to fix this,
but both seem to be stalling waiting for review.
I previously used what appears to be the favored
of the two approaches[1] to fix this,
with plan of keeping it musl-only until PR was merged.
However, while writing up a commit message
explaining the problem and why it needed fixing...
I investigated a bit and found it increasingly
hard to justify anything other than ...
simply not using lchmod.
Here's what I found:
* lchmod is non-POSIX, seems BSD-only these days
* Functionality of lchmod isn't supported on Linux
* best scenario on Linux would be an error
* POSIX does provide lchmod-esque functionality
with fchmodat(), which AFAICT is generally preferred.
* Python intentionally overlooks fchmodat()[2]
electing instead to use lchmod() behavior
as a proxy for whether fchmodat() "works".
I'm not sure I follow their reasoning...
* both glibc and musl provide lchmod impls:
* glibc returns ENOSYS "not implemented"
* musl implements lchmod with fchmodat(),
and so returns EOPNOTSUPP "op not supported"
* Python doesn't expect EOPNOTSUPP from lchmod,
since it's not valid on BSD's lchmod.
* "configure" doesn't actually check lchmod usefully,
instead checks for glibc preprocessor defines
to indicate if the function is just a stub[3];
somewhat fittingly, if the magic macros are defined
then the next line of the C source is "choke me",
causing the compiler to trip, fall, and point
a finger at whatever is near where it ends up.
(somewhat amusing, but AFAIK effective way to get an error :P)
I'm leaving out links to threads on mailing lists and such,
but for now I hope I've convinced you
(or to those reading commit history: explained my reasons)
that this is a bit of a mess[4].
And so instead of making a big mess messier,
and with hopes of never thinking about this again,
I propose we simply tell Python "don't use lchmod" on Linux.
[1] https://github.com/python/cpython/pull/4783
[2] 28453feaa8/Lib/os.py (L144)
[3] 28453feaa8/configure (L2198)
[4] Messes happen, no good intention goes unpunished :).
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
(cherry picked from commit ba52ae5048)
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/j/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/s4j1rrnwdrrqdaiyqci4c0cqy3azlnl2-j-808/bin/jconsole -h’ got 0 exit code
- ran ‘/nix/store/s4j1rrnwdrrqdaiyqci4c0cqy3azlnl2-j-808/bin/jconsole --help’ got 0 exit code
- ran ‘/nix/store/s4j1rrnwdrrqdaiyqci4c0cqy3azlnl2-j-808/bin/jconsole help’ got 0 exit code
- found 808 with grep in /nix/store/s4j1rrnwdrrqdaiyqci4c0cqy3azlnl2-j-808
- directory tree listing: https://gist.github.com/3c6f38056c15de42a7496ff1f576064e
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/supercollider/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/4azhvz3aw8jkcs3vib2aaii15yq5rr8k-supercollider-3.9.3/bin/supernova -h’ got 0 exit code
- ran ‘/nix/store/4azhvz3aw8jkcs3vib2aaii15yq5rr8k-supercollider-3.9.3/bin/supernova --help’ got 0 exit code
- ran ‘/nix/store/4azhvz3aw8jkcs3vib2aaii15yq5rr8k-supercollider-3.9.3/bin/sclang -h’ got 0 exit code
- found 3.9.3 with grep in /nix/store/4azhvz3aw8jkcs3vib2aaii15yq5rr8k-supercollider-3.9.3
- directory tree listing: https://gist.github.com/1dcdb0888d56e74baf1a827e371acad1
Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/renpy/versions.
These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 6.99.14.2 with grep in /nix/store/ppm0viw59sf9hl0c6m9i84zf68yyjnhi-renpy-6.99.14.2
- found 6.99.14.2 in filename of file in /nix/store/ppm0viw59sf9hl0c6m9i84zf68yyjnhi-renpy-6.99.14.2
- directory tree listing: https://gist.github.com/0e25657f100ee2ecfeda5f3e8fb08167
Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/supercollider/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/a6z8q6az7fzhh0sp4llp4fzp8c95bm6y-supercollider-3.9.2/bin/scsynth -v` and found version 3.9.2
- ran `/nix/store/a6z8q6az7fzhh0sp4llp4fzp8c95bm6y-supercollider-3.9.2/bin/supernova -h` got 0 exit code
- ran `/nix/store/a6z8q6az7fzhh0sp4llp4fzp8c95bm6y-supercollider-3.9.2/bin/supernova --help` got 0 exit code
- ran `/nix/store/a6z8q6az7fzhh0sp4llp4fzp8c95bm6y-supercollider-3.9.2/bin/supernova -v` and found version 3.9.2
- ran `/nix/store/a6z8q6az7fzhh0sp4llp4fzp8c95bm6y-supercollider-3.9.2/bin/supernova --version` and found version 3.9.2
- ran `/nix/store/a6z8q6az7fzhh0sp4llp4fzp8c95bm6y-supercollider-3.9.2/bin/sclang -h` got 0 exit code
- ran `/nix/store/a6z8q6az7fzhh0sp4llp4fzp8c95bm6y-supercollider-3.9.2/bin/sclang -v` and found version 3.9.2
- found 3.9.2 with grep in /nix/store/a6z8q6az7fzhh0sp4llp4fzp8c95bm6y-supercollider-3.9.2
- directory tree listing: https://gist.github.com/5b90384fd1df273cba0757c752a352d6
Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/php/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/phar.phar help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/phar.phar version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/phar.phar help` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php -h` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php --help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php -v` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php --version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/phpdbg -V` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/phpdbg --version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-cgi -h` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-cgi --help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-cgi -v` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-cgi --version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pear -h` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pear --help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pear help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pear -V` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pear version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/peardev -h` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/peardev --help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/peardev help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/peardev -V` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/peardev version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pecl -h` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pecl --help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pecl help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pecl -V` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pecl version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-fpm -h` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-fpm --help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-fpm -v` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-fpm --version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-fpm -h` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-fpm --help` and found version 7.2.4
- found 7.2.4 with grep in /nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4
- directory tree listing: https://gist.github.com/3c197892ad9174dae3d07c1dd61b418c
Erlang's generic-builder isn't using the right /bin/sh in some
situations, causing build errors either in the erlang build itself or
in derivations depending on it.
This patch runs `patchShebangs make/` before running the rest of the
`postPatch` phase, hopefully using the right shell early enough.
This might be a solution for #36853, #36823 and #37638.
mostly just forward environment variables to make arguments,
this partially reverts 5d1e51a199
which removed them because they're already set in env--
but that's not enough to override make vars.
Also, readline is buildInput not nativeBuildInput
(we need headers and to link against it)
Resolved the following conflicts (by carefully applying patches from the both
branches since the fork point):
pkgs/development/libraries/epoxy/default.nix
pkgs/development/libraries/gtk+/3.x.nix
pkgs/development/python-modules/asgiref/default.nix
pkgs/development/python-modules/daphne/default.nix
pkgs/os-specific/linux/systemd/default.nix
Semi-automatic update. These checks were done:
- built on NixOS
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/grape -h` got 0 exit code
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/grape --help` got 0 exit code
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/grape help` got 0 exit code
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/grape -v` and found version 2.4.14
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/grape --version` and found version 2.4.14
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/java2groovy -h` got 0 exit code
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/java2groovy --help` got 0 exit code
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/java2groovy help` got 0 exit code
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/groovy -h` got 0 exit code
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/groovy --help` got 0 exit code
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/groovy -v` and found version 2.4.14
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/groovy --version` and found version 2.4.14
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/groovydoc --help` got 0 exit code
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/groovydoc --version` and found version 2.4.14
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/groovyc -h` got 0 exit code
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/groovyc --help` got 0 exit code
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/groovyc -v` and found version 2.4.14
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/groovyc --version` and found version 2.4.14
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/groovysh -h` got 0 exit code
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/groovysh --help` got 0 exit code
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/groovysh -V` and found version 2.4.14
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/groovysh --version` and found version 2.4.14
- ran `/nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14/bin/groovyConsole --help` got 0 exit code
- found 2.4.14 with grep in /nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14
- found 2.4.14 in filename of file in /nix/store/x26aa3454yhk91kncw7nnzl0pw4piwsy-groovy-2.4.14
Semi-automatic update. These checks were performed:
- built on NixOS
- ran `/nix/store/4wlhzjj8k4a49dvpzgwhll2m03hvvcz9-supercollider-3.9.1/bin/scsynth -v` and found version 3.9.1
- ran `/nix/store/4wlhzjj8k4a49dvpzgwhll2m03hvvcz9-supercollider-3.9.1/bin/supernova -h` got 0 exit code
- ran `/nix/store/4wlhzjj8k4a49dvpzgwhll2m03hvvcz9-supercollider-3.9.1/bin/supernova --help` got 0 exit code
- ran `/nix/store/4wlhzjj8k4a49dvpzgwhll2m03hvvcz9-supercollider-3.9.1/bin/supernova -v` and found version 3.9.1
- ran `/nix/store/4wlhzjj8k4a49dvpzgwhll2m03hvvcz9-supercollider-3.9.1/bin/supernova --version` and found version 3.9.1
- ran `/nix/store/4wlhzjj8k4a49dvpzgwhll2m03hvvcz9-supercollider-3.9.1/bin/sclang -h` got 0 exit code
- ran `/nix/store/4wlhzjj8k4a49dvpzgwhll2m03hvvcz9-supercollider-3.9.1/bin/sclang -v` and found version 3.9.1
- found 3.9.1 with grep in /nix/store/4wlhzjj8k4a49dvpzgwhll2m03hvvcz9-supercollider-3.9.1
This involved:
* Installing miniperl as $dev/bin/perl
* Setting miniperl to take INC from
lib/perl5/{site_perl/,}cross_perl/${version} as well as
lib/perl5/{site_perl/,}/${version}/${runtimeArch}, in that
order. miniperl taking from runtimeArch is not really correct, but
it works in some pure-perl cases (e.g. Config.pm) and can be
overridden with the cross_perl variant.
* Installing perl-cross's stubs into
$dev/lib/perl5/cross_perl/${version}
* Patching MakeMaker.pm to gracefully degrade (very slightly) if B.pm
can't be loaded, which it can't in cross-compilation.
* Passing the right build-time and runtime perls to Makefile.PL
Semi-automatic update. These checks were performed:
- built on NixOS
- ran `/nix/store/yxs5d6pasfvp6000pm1sqhj89iirj3mv-jruby-9.1.16.0/bin/jruby -h` got 0 exit code
- ran `/nix/store/yxs5d6pasfvp6000pm1sqhj89iirj3mv-jruby-9.1.16.0/bin/jruby --help` got 0 exit code
- ran `/nix/store/yxs5d6pasfvp6000pm1sqhj89iirj3mv-jruby-9.1.16.0/bin/jruby -v` and found version 9.1.16.0
- ran `/nix/store/yxs5d6pasfvp6000pm1sqhj89iirj3mv-jruby-9.1.16.0/bin/jruby --version` and found version 9.1.16.0
- ran `/nix/store/yxs5d6pasfvp6000pm1sqhj89iirj3mv-jruby-9.1.16.0/bin/jruby.bash -h` got 0 exit code
- ran `/nix/store/yxs5d6pasfvp6000pm1sqhj89iirj3mv-jruby-9.1.16.0/bin/jruby.bash --help` got 0 exit code
- ran `/nix/store/yxs5d6pasfvp6000pm1sqhj89iirj3mv-jruby-9.1.16.0/bin/jruby.bash -v` and found version 9.1.16.0
- ran `/nix/store/yxs5d6pasfvp6000pm1sqhj89iirj3mv-jruby-9.1.16.0/bin/jruby.bash --version` and found version 9.1.16.0
- found 9.1.16.0 with grep in /nix/store/yxs5d6pasfvp6000pm1sqhj89iirj3mv-jruby-9.1.16.0
Semi-automatic update. These checks were performed:
- built on NixOS
- ran `/nix/store/16sl6aacbf5yg39jy7k5851ixs26hsnh-joker-0.8.9-bin/bin/joker -h` got 0 exit code
- ran `/nix/store/16sl6aacbf5yg39jy7k5851ixs26hsnh-joker-0.8.9-bin/bin/joker --help` got 0 exit code
- ran `/nix/store/16sl6aacbf5yg39jy7k5851ixs26hsnh-joker-0.8.9-bin/bin/joker help` got 0 exit code
- ran `/nix/store/16sl6aacbf5yg39jy7k5851ixs26hsnh-joker-0.8.9-bin/bin/joker -v` and found version 0.8.9
- ran `/nix/store/16sl6aacbf5yg39jy7k5851ixs26hsnh-joker-0.8.9-bin/bin/joker --version` and found version 0.8.9
- found 0.8.9 with grep in /nix/store/16sl6aacbf5yg39jy7k5851ixs26hsnh-joker-0.8.9-bin
- found 0.8.9 in filename of file in /nix/store/16sl6aacbf5yg39jy7k5851ixs26hsnh-joker-0.8.9-bin
cc "@andrestylianos @ehmry @lethalman"
Technically, racket compiles and packages too, but it doesn't pass all
tests yet, so the build fails.
gcc7Stdenv is GCC 7 with the MacOS-specific adaptations retained.
Building on MacOS with that works, but we should be using clang.
I'm hoping that the next person wanting to override the compiler
version in some other derivation sees that attribute and doesn't
inadvertently break a MacOS build again.
* remove EOL ruby versions for security and maintenance reasons.
* only expose ruby_MAJOR_MINOR to the top-level. we don't provide
guarantees for the TINY version.
* mark all related packages as broken
* switch the default ruby version from 2.3.x to 2.4.x
Documents the reason why it's needed and also prevents the
ensureNewerSourcesHook call being evaluated again and again for every
single Python package.
Racket without the bundled packages, such as Mr Racket.
The essential package racket-libs is included, as well as libraries
that live in collections. In particular, raco and the pkg library are
still bundled.
This hardcoded list of CFFI extension modules gets stale when PyPy adds
more, but fortunately the main translation step already builds these now
(hack_for_cffi_modules in pypy/goal/targetpypystandalone.py).
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Wrappers already included `PYTHONNOUSERSITE=1`, but now this env var is
also set in the Python setup hook. This improves purity in case of
non-sandboxes builds and nix-shell.
The `PYTHONNOUSERSITE` was exported to prevent impurities during
runtime. The downside of exporting environment variables is that they
always propagate all the way down the process tree, unless they are
explicitly unset at some point. Using the `-s` argument applies it only
to the process executed in the wrapper. That way, subprocesses are free
to do impure things.
Clojure 1.9 adds native cli tools, which are now used instead of
creating a java wrapper with a clojure.jar arguments. See
https://clojure.org/guides/deps_and_cli for more details on
clojure native cli tools.
When a Python script has the extension `.py`, bytecode is generated.
Typically, executables in bin have no extension, so no bytecode is
generated. However, some packages do provide executables with
extensions, and thus bytecode is generated.
28299f669a introduced the first Python
packages having multiple outputs. The required outputs were not picked
up by `python.buildEnv` (#31857).
This commit modifies `python.buildEnv` so that it always includes the
$out output and thus fixes#31857.
Python libraries or modules now have an attribute `pythonModule = interpreter;` to indicate
they provide Python modules for the specified `interpreter`.
The package set provides the following helper functions:
- hasPythonModule: Check whether a derivation provides a Python module.
- requiredPythonModules: Recurse into a list of Python modules, returning all Python modules that are required.
- makePythonPath: Create a PYTHONPATH from a list of Python modules.
Also included in this commit is:
- disabledIf: Helper function for disabling non-buildPythonPackage functions.
This continues #23374, which always kept around both attributes, by
always including both propagated files: `propgated-native-build-inputs`
and `propagated-build-inputs`. `nativePkgs` and `crossPkgs` are still
defined as before, however, so this change should only barely
observable.
This is an incremental step to fully keeping the dependencies separate
in all cases.
One should depend on
- `stdenv.cc.bintools`: for executables at build time
- `libbfd` or `libiberty`: for those libraries
- `targetPackages.cc.bintools`: for exectuables at *run* time
- `binutils`: only for specifically GNU Binutils's executables, regardless of
the host platform, at run time.
Fixes the build failure after the upgrade to glibc 2.26 in
9bb67d5c1e.
From the cfree(3) manpage:
This function should never be used. Use free(3) instead. Starting with
version 2.26, it has been removed from glibc.
From the glibc 2.26 release notes[1]:
* The obsolete function cfree has been removed. Applications should use
free instead.
[1]: https://sourceware.org/ml/libc-alpha/2017-08/msg00010.html
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @7c6f434c, @tohl
