Enable autoreconfHook by default: The build tried to execute autoconf, which was
in the wrong build input. Regenerating autotools configure files is always a good
idea since it delivers fixes.
Also move groff to the native since it is only used at build-time
* substitute(): --subst-var was silently coercing to "" if the variable does not exist.
* libffi: simplify using `checkInputs`
* pythonPackges.hypothesis, pythonPackages.pytest: simpify dependency cycle fix
* utillinux: 2.32 -> 2.32.1
https://lkml.org/lkml/2018/7/16/532
* busybox: 1.29.0 -> 1.29.1
* bind: 9.12.1-P2 -> 9.12.2
https://ftp.isc.org/isc/bind9/9.12.2/RELEASE-NOTES-bind-9.12.2.html
* curl: 7.60.0 -> 7.61.0
* gvfs: make tests run, but disable
* ilmbase: disable tests on i686. Spooky!
* mdds: fix tests
* git: disable checks as tests are run in installcheck
* ruby: disable tests
* libcommuni: disable checks as tests are run in installcheck
* librdf: make tests run, but disable
* neon, neon_0_29: make tests run, but disable
* pciutils: 3.6.0 -> 3.6.1
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/pciutils/versions.
* mesa: more include fixes
mostly from void-linux (thanks!)
* npth: 1.5 -> 1.6
minor bump
* boost167: Add lockfree next_prior patch
* stdenv: cleanup darwin bootstrapping
Also gets rid of the full python and some of it's dependencies in the
stdenv build closure.
* Revert "pciutils: use standardized equivalent for canonicalize_file_name"
This reverts commit f8db20fb3a.
Patching should no longer be needed with 3.6.1.
* binutils-wrapper: Try to avoid adding unnecessary -L flags
(cherry picked from commit f3758258b8895508475caf83e92bfb236a27ceb9)
Signed-off-by: Domen Kožar <domen@dev.si>
* libffi: don't check on darwin
libffi usages in stdenv broken darwin. We need to disable doCheck for that case.
* "rm $out/share/icons/hicolor/icon-theme.cache" -> hicolor-icon-theme setup-hook
* python.pkgs.pytest: setupHook to prevent creation of .pytest-cache folder, fixes#40273
When `py.test` was run with a folder as argument, it would not only
search for tests in that folder, but also create a .pytest-cache folder.
Not only is this state we don't want, but it was also causing
collisions.
* parity-ui: fix after merge
* python.pkgs.pytest-flake8: disable test, fix build
* Revert "meson: 0.46.1 -> 0.47.0"
With meson 0.47.0 (or 0.47.1, or git)
things are very wrong re:rpath handling
resulting in at best missing libs but
even corrupt binaries :(.
When we run patchelf it masks the problem
by removing obviously busted paths.
Which is probably why this wasn't noticed immediately.
Unfortunately the binary already
has a long series of paths scribbled
in a space intended for a much smaller string;
in my testing it was something like
lengths were 67 with 300+ written to it.
I think we've reported the relevant issues upstream,
but unfortunately it appears our patches
are what introduces the overwrite/corruption
(by no longer being correct in what they assume)
This doesn't look so bad to fix but it's
not something I can spend more time on
at the moment.
--
Interestingly the overwritten string data
(because it is scribbled past the bounds)
remains in the binary and is why we're suddenly
seeing unexpected references in various builds
-- notably this is is the reason we're
seeing the "extra-utils" breakage
that entirely crippled NixOS on master
(and probably on staging before?).
Fixes#43650.
This reverts commit 305ac4dade.
(cherry picked from commit 273d68eff8)
Signed-off-by: Domen Kožar <domen@dev.si>
* 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
Fixes a number of CVEs:
- a DNS request hijacking vulnerability. (CVE-2017-0902)
- an ANSI escape sequence vulnerability. (CVE-2017-0899)
- a DoS vulnerability in the query command. (CVE-2017-0900)
- a vulnerability in the gem installer that allowed a malicious gem to overwrite arbitrary files. (CVE-2017-0901)
* Manage patches in git
* Fixes the hook invocation to be more safe. Thanks @Mic92
* Install gems as user by default
* Install gem binaries with the /usr/bin/env shebang
* Fixes a bug where the passthru.libPath and passthru.gemPath would
point to the wrong directory
* Overhaul ruby version heuristics
In the tarball job:
````
checking find-tarballs.nix
error: while evaluating anonymous function at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:6:1, called from undefined position:
while evaluating ‘operator’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:27:16, called from undefined position:
while evaluating ‘immediateDependenciesOf’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:39:29, called from /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:27:44:
while evaluating anonymous function at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/lib/attrsets.nix:224:10, called from undefined position:
while evaluating anonymous function at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:40:37, called from /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/lib/attrsets.nix:224:16:
while evaluating ‘derivationsIn’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:42:19, called from /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:40:40:
while evaluating ‘optional’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/lib/lists.nix:175:20, called from /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:44:33:
while evaluating ‘canEval’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:48:13, called from /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:44:43:
while evaluating the attribute ‘pkgs’ of the derivation ‘ruby-dev-2.3.1-p0’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/pkgs/build-support/trivial-builders.nix:10:14:
while evaluating ‘override’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/lib/customisation.nix:60:22, called from /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/pkgs/development/interpreters/ruby/dev.nix:10:13:
while evaluating ‘makeOverridable’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/lib/customisation.nix:54:24, called from /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/lib/customisation.nix:60:31:
anonymous function at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/pkgs/development/ruby-modules/bundix/default.nix:1:1 called with unexpected argument ‘ruby’, at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/lib/customisation.nix:56:12
````
Setting the GEM_PATH after ruby is started is not reliable enough. In
some cases rubygems would have already loaded and ignore these settings.
Fixes#14048
After ruby initializes, rubygems no longer reads the GEM_PATH. Before,
we have the following scenario:
Gem.path # => ["a"]
ENV['GEM_PATH'] = ["b"]
Gem.path # => ["a"] # Still returns the same
Gem.use_paths is the documented way to create isolated environments as
documented in [1].
[1] http://www.rubydoc.info/github/rubygems/rubygems/Gem.use_paths
The idea is to bundle ruby, bundler and bundix together. I was
having issues where bundler was installed with ruby 2.3.0 and I wanted to use
ruby 2.0.0.
With this change all the developer has to do is install `ruby_2_0_0.dev`
either in his environment or in a nix-shell.
Having a separate rubygems package can lead to split-brain scenarios.
Since rubygems is designed to replace himself on a ruby installation,
let's do that.
This was preventing any ruby gem with a c extension to build.
mkmf would fail with a misleading error:
/nix/store/dmkcai8fnv21qxiasx628nim3mq4r4wg-ruby-2.2.3-p0/lib/ruby/2.2.0/mkmf.rb:456:in `try_do': The compiler failed to generate an executable file. (RuntimeError)
You have to install development tools first.
