Useful update-- adds support for accepting multiple files as arguments
and fixes handling of large executables (>2Gb).
While touching this, modify version to include more info.
Preserving version format previously used, although not usual style.
sometimes we want the "SDK" version from xcbuild so we do something
like:
$ xcbuild -version -sdk MacOSX10.10
SDKSettings.plist - MacOSX10.10 (MacOSX10.10)
SDKVersion: 10.10
Path: /nix/store/6k7crm1n4drf09ga0dwvbmb59x4zl2i2-SDKs/MacOSX10.10.sdk
PlatformPath: /nix/store/vhfwb1znfy65s2xs27j8xribk6mp6lbw-Platforms/MacOSX.platform
ProductName: Mac OS X
ProductVersion: 10.10
This was previously overriden by the current xcode version so you
would get:
Xcode 9.4.1
Build version 17E189
This should fix the other usage of -version in nodejs 6.x.
Use unpackCmd and installPhase instead of overwriting buildCommand.
This makes the derivation more readable, and adds binary stripping and
shebang patching of the output as a bonus :-)
Use makeWrapper instead of a custom wrapper script, and only export
environment variables that are used.
Set JAVA_HOME to ${jdk.home}, making it more generic and independent of
the specific jdk path being used (was a different one on zulu). This
fixes sqldeveloper on darwin, so add it to supported platforms
(plus the known-working x86_64-linux)
This bumps Hydra to the latest revision available. As Hydra doesn't have
a release model (and therefore no tags) ATM, the derivation will pin
against the actual git revision and the date of the commit in the
derivation name.
Additionally the following changes have been made:
* Dropped `postUnpack` phase. It is useful when working with the Hydra
source (and no dirty changes shall be used in `release.nix`, but is has
no use in `nixpkgs`).
* Added myself as maintainer to have more folks available in case of
future breakage.
* Implemented support for Nix 2.0 and `unstable` (currently 2.1):
Since 1672bcd230447f1ce0c3291950bdd9a662cee974 in NixOS/nix the
evaluator differentiates between `settings` and `evalSettings`.
Previously `restrictEval` in `hydra-eval-jobs.cc` has been set in
`settings`, this doesn't work anymore in Nix 2.1 and is therefore
incompatible to Nix 2.0 on an API level.
To resolve this, the flag `isGreaterNix20` parses the version string
of `pkgs.nix` and applies a patch if nix.version<=2.0.
Furthermore the Hydra build with Nix 2.1 requires `boost` as build input
which is not needed for Nix 2.0. To avoid unnecessary increase in the
closure size this library will only used as build input for
nix.version>2.0.
* Fixed the NixOS test for `hydra`:
disabled binary cache to allow sandbox builds (otherwise it would
query `cache.nixos.org` during the Hydra build inside the test).
Additionally the trivial.nix jobset required simplification (as done
in NixOS/hydra, e.g. tests/api-test.nix) as bash is not available in
the build sandbox as builder (even when adding pkgs.bash to
systemPackages).
The easiest workaround to confirm a the functionality of a jobset
without importing nixpkgs is to use the default shell /bin/sh which
is mounted from `pkgs.busybox` into the build env
(https://github.com/NixOS/nixpkgs/pull/44841#discussion_r209751972) in the
VM and a named pipe to create $out.
Closes#44044
This commit also swaps the build tool to use python3 internally (which waf fully
supports and prefers) and swaps the src to be downloaded from gitlab. The waf.io
site only keeps source tarballs of the latest version, so once a new waf comes
out we can no longer reproduce older versions.
We need the ensureNewerSources hook to avoid this error, in both `python2` and `python3`:
ValueError: ZIP does not support timestamps before 1980
I *want* cross-specific overrides to be verbose, so I rather not have
this shorthand. This makes the syntactic overhead more proportional to
the maintainence cost. Hopefully this pushes people towards fewer
conditionals and more abstractions.
Because the hadoop project also provides a binary `yarn`, the yarn project [added this alias to help people with both hadoop and yarn installed](https://github.com/yarnpkg/yarn/issues/673#issuecomment-254004512). Some scripts in the wild use this alias for the same reason.
While I'm not sure whether it's suitable for my tasks it might be useful
for others doing reverse engineering, so I decided to package it.
The software seems to have stalled development since a while but became
active again recently, so hopefully some of the issues with packaging
will be fixed and they might want to move away from their handwritten
configure script.
I've tested the package on both i686-linux and x86_64-linux, however the
automated test suite seems to be broken upstream at the moment so I
didn't set doCheck to true, but once this is fixed, we can enable them
in a future update.
Signed-off-by: aszlig <aszlig@nix.build>
Lack of 32bit support led to the creation
of an overlay to add it back again,
but since it at least builds and seems to work
don't see why we'd disallow it here :).
* The ELK stack is upgraded to 6.3.2.
* `elasticsearch6`, `logstash6` and `kibana6` now come with X-Pack which is
a suite of additional features. These are however licensed under the unfree
"Elastic License".
* Fortunately they also provide OSS versions which are now packaged
under: `elasticsearch6-oss`, `logstash6-oss` and `kibana6-oss`.
Note that the naming of the attributes is consistent with upstream.
* The test `nix-build nixos/tests/elk.nix -A ELK-6` will test the OSS
version by default. You can also run the test on the unfree ELK using:
`NIXPKGS_ALLOW_UNFREE=1 nix-build nixos/tests/elk.nix -A ELK-6 --arg enableUnfree true`
This finally fixes the build to avoid having to completely rebuild
bazel from source a second time just to generate the bash completion
script!
It also makes completion actually _work_ for bash users by
correcting the name of the installed script.
* 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>
In 3027bca, binutils was upgraded from 2.28.1 to 2.30. However, in 2.30,
the ldmain.c file within binutils, which the nixpkgs new-dtags.patch
file is meant to modify, was changed in such a way that the patch no
longer works. As a result, the new dtags are not actually enabled, and
binaries are built with RPATH set instead of RUNPATH, thereby preventing
LD_LIBRARY_PATH from overriding this built-in path. This change corrects
this. The patch file is no longer necessary because binutils's ldmain.c
now sets link_info.new_dtags based on the configuration flags.
This was probably not noticed immediately because, when the derivation
is built with nix-build, the fixupPhase runs patchelf --shrink-rpath.
patchelf converts any RPATH in the binary into RUNPATH (unless
--force-rpath is specified). Of course, if the binary is built without
nix-build (such as in a nix-shell), this never occurs, and any RPATH in
the binary is left in place.
Since years I'm not maintaining anything of the list below other
than some updates when I needed them for some reason. Other people
is doing that maintenance on my behalf so I better take me out but
for very few packages. Finally!
