Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
Comments on conflicts:
- llvm: d6f401e1 vs. 469ecc70 - docs for 6 and 7 say the default is
to build all targets, so we should be fine
- some pypi hashes: they were equivalent, just base16 vs. base32
By changing the default toolchain to JDK8, we broke the default Java
toolchain, which assumes JDK9.
Instead, set `host_java_toolchain` manually for our build of bazel,
and set `java_toolchain` to run the java tests with the build JDK as
well.
Fixes https://github.com/NixOS/nixpkgs/issues/54289
Unfortunately the tarball was modified for the official release and
"nix-store -r --check $(nix-instantiate -A scons.src)" did not catch
this (not sure why ATM).
Thanks @pbogdan for noticing this :)
Since the 0.21 upgrade, the host `$PATH` is not forwarded anymore by
default to the sandboxes in charge to realize Bazel actions. This
default change broke the `py_binary` rule among other things.
Every python binary is wrapped in a stub in charge to setup the
execution environment. Currently, this stub's shebang points to a
`/usr/bin/env python` which cannot be resolved with the current
`$PATH`.
This results in breaking any build pipeline requiring the use of
python at some point. On top of the incorrect shebang, the stub
template is unable to find the actual python binary using
`SearchPath`.
This PR fixes those two things by re-writing the stub template shebang
to the actual python binary and by substituting the faulty default
python binary lookup to the right one.
ninja sources include re2c's output files, so unless we change the sources by applying a patch, re2c is not even launched
anyway, it is not relevant to building docs
0.21 removed the bundled openjdk-distribution. Instead, tries to fetch
the “right” distribution on-the-fly when building.
So we need to provide our own openjdk.
According to
https://github.com/bazelbuild/bazel/issues/6865#issuecomment-447261288
we should set `--host_javabase="@local_jdk//:jdk` if we want to do
that. This uses the jdk that is currently in the environment, which is
openjdk 8 in our case. 0.21 defaulted to a toolchain for JDK9, which
we don’t package in nixpkgs, so we use the JDK8 toolchain.
This commit also replaces the line-number-based sed invocations with
something more stable.
With the wrapper detection patch, if a build invokes an executable that cannot
be found in PATH by `find_executable`, bear will fail with an `AttributeError`
in `os.path.realpath`.
This can happen if the build invokes some project-local tool or command, like
`./build-something`.
Instead of calling using the result of `find_executable` directly, first check
whether the executable was found and fall back to original Bear behavior if
it was not.
Bazel runs actions in a sandbox by default on Darwin and Linux.
However, the sandboxing was always and *silently* disabled previously,
because a Bazel feature test was always failing. The feature test
involved running `/bin/true` inside a sandbox. But on NixOS,
`/bin/true` does not exist...
This change is going to be required when upgrading to Bazel 0.20.0,
because in the checkPhase we're not wrapping the Bazel binary yet to
set some necessary default arguments.
gnumake can support subsecond mtimes if it is available. But Darwin
doesn’t support setting subsecond mtimes until 10.13! So we can just
disable this check to avoid the issue where most of our built tools
use seconds but make uses nanoseconds. Might fix some parallel issues
along the way.
Fixes#51221
To make updating large attribute sets faster, the update scripts
are now run in parallel.
Please note the following changes in semantics:
- The string passed to updateScript needs to be a path to an executable file.
- The updateScript can also be a list: the tail elements will then be passed
to the head as command line arguments.
Things changed in the Ninja setup-hook:
- Respect installFlags
- Automatically add checkPhase (can be disabled with dontUseNinjaCheck
in the same way as dontUseNinjaBuild and dontUseNinjaInstall). Tests
are only run when "ninja test" exists.
- Error in build phase when build.ninja is missing. We don’t have a
way to fall back to other build methods, so it’s best to be very
clear when we aren’t able to build with ninja
- Set -l flag to 1 when enableParallelBuilding is disabled
Changes added in 4d1fd3775d break
automated updates by moving to a custom version scheme.
This switches back to upstream versioning, while maintaining version
schema convention of `builtins.parseDrvName`.
See issue #43717
xboxdrv doesn’t use scons for installing, but instead using a
makefile! Everything else is in scons so we have to keep that. I’ve
added a dontUseSconsInstall flag to the scons setup-hook to skip the
automatic overwrite of default “make install” call.
The scons build system is python-based and has a binary named scons. Unlike CMake, it cannot generate makefiles so we end up having to override the build, install, and check phases. I have added the setupHook to the scons package so that integration requires no unique steps - just putting scons in nativeBuildInputs should be enough. sconsFlags controls the flags specifically passed to scons while buildFlags, installFlags, and checkFlags should still be usable. Some packages use different names for the prefix flag. In those cases you will have to set "prefixKey" to something like "PREFIX=" as there are multiple names for the "prefix" used in scons.
The waf build system is python-based and hosted locally in each package in the executable file named "waf". Unlike CMake, it cannot generate makefiles so we end up having to override the configure, build, and install phases. I've tried to keep these as close to what's in setup.sh as possible. If there is no waf file in the root directory, then we just copy the one hosted in Nixpkgs. Otherwise the only thing you have to add to a package using Waf is "wafHook" into nativeBuildInputs. wafFlags controls the flags specifically passed to waf while configureFlags, buildFlags, and installFlags are still used as in the generic builder.
Bazel supports per-workspace bootstrap scripts at $WORKSPACE_ROOT/
tools/bazel. This adds support for this behavior, which is needed
by many Bazel projects (OSS and private).
For Git to work properly, I used fetchgit with leaveDotGit. This seems
to be causing hash to change on different systems in different times.
I've replaced generation of last_commit_position.h in tools/gen.py with
just plain nix template. "gn --version" will loose a bit (just commit
hash, without commit height in front of it), but I hope noone relies on
it.
This also updates the bootstrap tool builder to LLVM 5, but not the ones
we actually use for bootstrap. I'll make that change in a subsequent commit
so as to provide traceable provenance of the bootstrap tools.
See https://hydra.nixos.org/build/80727495
`pants' works with requests==2.19 to build successfully and `nixpkgs' currently uses `requests==2.19.1`.
Patching the version constraint in `setup.py' accordingly fixes the problem.
Addresses #45960
- our version is from 2015
- it doesn't build
- upstream project is dead, last release 2012, last commit Oct 2016.
- used by only 1 nixpkgs package: `boo`, marked broken since 2016.
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.
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>
Bazel either reuses the `PATH` from the client, or sets a hardcoded
one. The former mode in problematic for build hermeticity. But the
latter is crippled on NixOS, because the hardcoded value is
`/bin:/usr/bin`. So we set the hardcoded value to match what
`customBash` provides. This has the effect of aligning the
environments for `ctx.actions.run` and `ctx.actions.run_shell`, which
were previously distinct (bug).
Updates rebar3 to version 3.6.1, which amongst other things introduces
support for rebar3 on Erlang/OTP 21.
Changes made:
* rebar3 and dependencies updated to new versions
* rebar3 hermeticity patch updated to apply against new version
* hex package registry snapshot updated
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/conan/versions.
These checks were done:
- built on NixOS
- Warning: no invocation of /nix/store/c92p18la19jbr7ya0ml77gn6z9c9zagn-conan-1.5.1/bin/.conan_server-wrapped had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/c92p18la19jbr7ya0ml77gn6z9c9zagn-conan-1.5.1/bin/conan_server had a zero exit code or showed the expected version
- /nix/store/c92p18la19jbr7ya0ml77gn6z9c9zagn-conan-1.5.1/bin/.conan_build_info-wrapped passed the binary check.
- /nix/store/c92p18la19jbr7ya0ml77gn6z9c9zagn-conan-1.5.1/bin/conan_build_info passed the binary check.
- Warning: no invocation of /nix/store/c92p18la19jbr7ya0ml77gn6z9c9zagn-conan-1.5.1/bin/.conan-wrapped had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/c92p18la19jbr7ya0ml77gn6z9c9zagn-conan-1.5.1/bin/conan had a zero exit code or showed the expected version
- 2 of 6 passed binary check by having a zero exit code.
- 0 of 6 passed binary check by having the new version present in output.
- found 1.5.1 with grep in /nix/store/c92p18la19jbr7ya0ml77gn6z9c9zagn-conan-1.5.1
- directory tree listing: https://gist.github.com/097b90f575be6117eceec5c70235c405
- du listing: https://gist.github.com/54f8f4a3882e828289ab5b96dd0fa338
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/meson/versions.
These checks were done:
- built on NixOS
- /nix/store/r959bxd7pgfd9crp3fagw4x6j6pl105l-meson-0.47.0/bin/meson passed the binary check.
- Warning: no invocation of /nix/store/r959bxd7pgfd9crp3fagw4x6j6pl105l-meson-0.47.0/bin/mesonconf had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/r959bxd7pgfd9crp3fagw4x6j6pl105l-meson-0.47.0/bin/mesonintrospect had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/r959bxd7pgfd9crp3fagw4x6j6pl105l-meson-0.47.0/bin/mesontest had a zero exit code or showed the expected version
- /nix/store/r959bxd7pgfd9crp3fagw4x6j6pl105l-meson-0.47.0/bin/wraptool passed the binary check.
- 2 of 5 passed binary check by having a zero exit code.
- 1 of 5 passed binary check by having the new version present in output.
- found 0.47.0 with grep in /nix/store/r959bxd7pgfd9crp3fagw4x6j6pl105l-meson-0.47.0
- directory tree listing: https://gist.github.com/921992f726772b72a0e2ccd9591141b1
- du listing: https://gist.github.com/22365bf0c1a1ab300e07e36d205c7eb7
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/redo/versions.
These checks were done:
- built on NixOS
- /nix/store/vn68xm8zhynjkr2fwy9kqsl6018gdpxx-redo-1.3/bin/redo passed the binary check.
- /nix/store/vn68xm8zhynjkr2fwy9kqsl6018gdpxx-redo-1.3/bin/redo-ifcreate passed the binary check.
- /nix/store/vn68xm8zhynjkr2fwy9kqsl6018gdpxx-redo-1.3/bin/redo-ifchange passed the binary check.
- /nix/store/vn68xm8zhynjkr2fwy9kqsl6018gdpxx-redo-1.3/bin/cubehash passed the binary check.
- 4 of 4 passed binary check by having a zero exit code.
- 0 of 4 passed binary check by having the new version present in output.
- found 1.3 with grep in /nix/store/vn68xm8zhynjkr2fwy9kqsl6018gdpxx-redo-1.3
- directory tree listing: https://gist.github.com/84977503f6853a878440094f1cbc80bf
- du listing: https://gist.github.com/d612673ea44c5055de7d93cbb8e63acc
Bazel is a build tool, much like Make and many others. Like Make, it
should be agnostic to the compiler toolchains the user brings into
scope. Bazel has special rules that encode domain specific knowledge
for how to compile a C++ program, or indeed a Java program and a few
others. But that's not to say that at runtime Bazel should assume
a specific C++ compiler or Java compiler anymore than Make does.
The main impact of this change is that packages that build with Bazel
will have to list the compilers they want in their `buildInputs` or
similar, rather than relying on the `bazel` package pulling them in
transitively.
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/conan/versions.
These checks were done:
- built on NixOS
- Warning: no invocation of /nix/store/gid7f7w71lbiissjcbjsjvlxhmix6i94-conan-1.4.5/bin/.conan_server-wrapped had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/gid7f7w71lbiissjcbjsjvlxhmix6i94-conan-1.4.5/bin/conan_server had a zero exit code or showed the expected version
- /nix/store/gid7f7w71lbiissjcbjsjvlxhmix6i94-conan-1.4.5/bin/.conan_build_info-wrapped passed the binary check.
- /nix/store/gid7f7w71lbiissjcbjsjvlxhmix6i94-conan-1.4.5/bin/conan_build_info passed the binary check.
- Warning: no invocation of /nix/store/gid7f7w71lbiissjcbjsjvlxhmix6i94-conan-1.4.5/bin/.conan-wrapped had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/gid7f7w71lbiissjcbjsjvlxhmix6i94-conan-1.4.5/bin/conan had a zero exit code or showed the expected version
- 2 of 6 passed binary check by having a zero exit code.
- 0 of 6 passed binary check by having the new version present in output.
- found 1.4.5 with grep in /nix/store/gid7f7w71lbiissjcbjsjvlxhmix6i94-conan-1.4.5
- directory tree listing: https://gist.github.com/25fd7dbaab3b2c2b870221856de5199b
- du listing: https://gist.github.com/b94750efe01cb63b9541d4b897485f62
In particular, this contains Firefox-related and libgcrypt updates.
Other larger rebuilds would apparently need lots of time to catch up
on Hydra, due to nontrivial rebuilds in other branches than staging.
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/conan/versions.
These checks were done:
- built on NixOS
- Warning: no invocation of /nix/store/pdza6q7n1rywgra2022zvbi05fj47kjy-conan-1.4.4/bin/.conan_server-wrapped had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/pdza6q7n1rywgra2022zvbi05fj47kjy-conan-1.4.4/bin/conan_server had a zero exit code or showed the expected version
- /nix/store/pdza6q7n1rywgra2022zvbi05fj47kjy-conan-1.4.4/bin/.conan_build_info-wrapped passed the binary check.
- /nix/store/pdza6q7n1rywgra2022zvbi05fj47kjy-conan-1.4.4/bin/conan_build_info passed the binary check.
- Warning: no invocation of /nix/store/pdza6q7n1rywgra2022zvbi05fj47kjy-conan-1.4.4/bin/.conan-wrapped had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/pdza6q7n1rywgra2022zvbi05fj47kjy-conan-1.4.4/bin/conan had a zero exit code or showed the expected version
- 2 of 6 passed binary check by having a zero exit code.
- 0 of 6 passed binary check by having the new version present in output.
- found 1.4.4 with grep in /nix/store/pdza6q7n1rywgra2022zvbi05fj47kjy-conan-1.4.4
- directory tree listing: https://gist.github.com/0da299922c958da51520fdd195a2d369
- du listing: https://gist.github.com/7e5d6a9b06f35b233151c026f6dd089b
When dontUseCmakeBuildDir is true (aka the default), it overrides
cmakeDir regardless of the package configuration.
While packaging netbee, I needed to both keep dontUseCmakeBuildDir to
true (some hardcoded paths expect the build folder) and set cmakeDir
(since CMakeList.txt was in a subfolder) which proved impossible.
Here is the fix.
Lots of packages are missing versions in their name. This adds them
where appropriate. These were found with this command:
$ nix-env -qa -f. | grep -v '\-[0-9A-Za-z.-_+]*$' | grep -v '^hook$'
See issue #41007.
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
On GNU/Linux the build references these files, so let's fetch them from
the Chromium repository. I haven't checked whether they are heavily
patched or whether we can use the version from LLVM, but when looking at
the changes, they do seem to divert a bit from upstream LLVM.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @matthewbauer, @stesie
The tarball from upstream seems to be generated on the fly, so the
output is not deterministic and using fetchzip makes this more reliable
as we have a recursively hashed output path without any of the
non-determinisms in tarballs.
Unfortunately, the build still fails on NixOS systems, because we need a
few more stuff in the build tree.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @matthewbauer, @stesie
This has already been patched against gnumake4 (519f0b8db2)
but we still have packages depending on gnumake3, so let's also apply
the same patch to gnumake 3.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @shlevy, @vcunat
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/doit/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/xgn48w19lgr8xnijgqcx91389b5hldv2-doit-0.31.1/bin/.doit-wrapped --help` got 0 exit code
- ran `/nix/store/xgn48w19lgr8xnijgqcx91389b5hldv2-doit-0.31.1/bin/.doit-wrapped help` got 0 exit code
- ran `/nix/store/xgn48w19lgr8xnijgqcx91389b5hldv2-doit-0.31.1/bin/.doit-wrapped --version` and found version 0.31.1
- ran `/nix/store/xgn48w19lgr8xnijgqcx91389b5hldv2-doit-0.31.1/bin/doit --help` got 0 exit code
- ran `/nix/store/xgn48w19lgr8xnijgqcx91389b5hldv2-doit-0.31.1/bin/doit help` got 0 exit code
- ran `/nix/store/xgn48w19lgr8xnijgqcx91389b5hldv2-doit-0.31.1/bin/doit --version` and found version 0.31.1
- found 0.31.1 with grep in /nix/store/xgn48w19lgr8xnijgqcx91389b5hldv2-doit-0.31.1
- directory tree listing: https://gist.github.com/a0ba66d49e0c01c3003ca50e9ad705a0
