Bazel 981b7bc1 depends on protobuf-2.5 and won't work with 2.6 (and in
bbe84fe3d upgraded straight to protobuf 3.0.0-alpha3); this commit fixes
the dependency to depend on protobuf2_5 specifically.
The bazel compile.sh needs `which` on the PATH; so this commit adds that
as a dependency.
Setting JAVA_HOME to ${jdk} broke bazel when used with openjdk, with the
message:
Problem with java installation: couldn't find/access rt.jar in /nix/store/z9vc0vzyzhnpl5l5inmqdnvdnbxmmmg7-openjdk-8u60b24
This is because if you set JAVA_HOME, bazel will look for rt.jar in
$JAVA_HOME/lib and $JAVA_HOME/jre/lib, but the nixpkgs openjdk
distribution puts rt.jar in ${jdk}/lib/openjdk/jre/lib for some reason.
To fix this, this commit uses the ${jdk.home} passthru value to use the
appropriate JAVA_HOME for the given jdk.
As bazel now works with openjdk, and openjdk is free while oraclejdk is
not, this commit changes the default jdk for bazel to openjdk.
Since this package didn't have a listed maintainer, I'm claiming it.
For now, let's remove `leaveDotGit`. The only visible effect I could see
was that `cargo --version` won't report the git commit anymore, but
that's only a minor issue compared to the build breaking often.
Fixes#8566 and closes#8862.
Update snapshot to avoid rust-lang/cargo#976, which otherwise breaks the
build.
Also move the `cargoSnapshot` derivation inside a set in
pkgs/top-level/all-packages.nix in order to hide the `cargo-snapshot`
packages from `nix-env -qa`, since it's only used to build the `cargo`
package.
This happened in VM builds:
make flags: SHELL=/nix/store/dbxpkswwc7rh6g1iy6dwqklzw39hihb1-bash-4.3-p33/bin/bash
/nix/store/jm26xg0h3jcrg4bbrwiqx3jpirscdk0p-stdenv/setup: line 658: 5957 Segmentation fault make ${makefile:+-f $makefile} ${enableParallelBuilding:+-j${NIX_BUILD_CORES} -l${NIX_BUILD_CORES}} $makeFlags "${makeFlagsArray[@]}" $buildFlags "${buildFlagsArray[@]}"
Instead, discover it automatically when building the package.
This makes `buildRustPackage` more future-proof with respect to changes
in how `cargo` generates the hash.
Also, it fixes broken builds in i686 because apparently, cargo generates
a different registry index hash in this architecture (compared to
x86-64).
It seems that when you pass `leaveDotGit = true` to `fetchgit`, sometimes
the output can still change (i.e. it's not completely deterministic).
This could be due to changes in the upstream git repository...
This makes buildRustPackage portable to non-Linux platforms.
Additionally, now we also save the `Cargo.lock` file into the fetch output, so
that we don't have to run $cargoUpdateHook again just before building.
Instead, move that code into buildRustPackage.
The setup hook was only doing part of the work anyway, and having it in
a separate place was obscuring what was really going on.
It turns out that `cargo`, with respect to registry dependencies, was
ignoring the package versions locked in `Cargo.lock` because we changed
the registry index URL.
Therefore, every time `rustRegistry` would be updated, we'd always try
to use the latest version available for every dependency and as a result
the deps' SHA256 hashes would almost always have to be changed.
To fix this, now we do a string substitution in `Cargo.lock` of the
`crates.io` registry URL with our URL. This should be safe because our
registry is just a copy of the `crates.io` registry at a certain point
in time.
Since now we don't always use the latest version of every dependency,
the build of `cargo` actually started to fail because two of the
dependencies specified in its `Cargo.lock` file have build failures.
To fix the latter problem, I've added a `cargoUpdateHook` variable that
gets ran both when fetching dependencies and just before building the
program. The purpose of `cargoUpdateHook` is to do any ad-hoc updating
of dependencies necessary to get the package to build. The use of the
'--precise' flag is needed so that cargo doesn't try to fetch an even
newer version whenever `rustRegistry` is updated (and therefore have to
change depsSha256 as a consequence).
- there were many easy merge conflicts
- cc-wrapper needed nontrivial changes
Many other problems might've been created by interaction of the branches,
but stdenv and a few other packages build fine now.
Instead, figure out VERSION at build-time. This simplifies using
overrideDerivation (no need to copy and modify installPhase).
Also add a check that the file exists (catch potential failure early).
New build system using configure script and GNU Make 4.0, and new
releases of the following using the new build system:
execline 2.0.0.0
s6 2.0.0.0
s6-dns 2.0.0.0
s6-linux-utils 2.0.0.0
s6-networking 2.0.0.0
s6-portable-utils 2.0.0.0
skalibs 2.0.0.0
Cargo downloads your Rust project's dependencies and builds your
project.
The cargoSnapshot derivation simply uses a binary build, because
it's not easy to build cargo from source yet.
In the future, it's expected that we'll also add a derivation for
building cargo from source.
(My OCD kicked in today...)
Remove repeated package names, capitalize first word, remove trailing
periods and move overlong descriptions to longDescription.
I also simplified some descriptions as well, when they were particularly
long or technical, often based on Arch Linux' package descriptions.
I've tried to stay away from generated expressions (and I think I
succeeded).
Some specifics worth mentioning:
* cron, has "Vixie Cron" in its description. The "Vixie" part is not
mentioned anywhere else. I kept it in a parenthesis at the end of the
description.
* ctags description started with "Exuberant Ctags ...", and the
"exuberant" part is not mentioned elsewhere. Kept it in a parenthesis
at the end of description.
* nix has the description "The Nix Deployment System". Since that
doesn't really say much what it is/does (especially after removing
the package name!), I changed that to "Powerful package manager that
makes package management reliable and reproducible" (borrowed from
nixos.org).
* Tons of "GNU Foo, Foo is a [the important bits]" descriptions
is changed to just [the important bits]. If the package name doesn't
contain GNU I don't think it's needed to say it in the description
either.
This includes a lot of fixes for cross-building to Windows and Mac OS X
and could possibly fix things even for non-cross-builds, like for
example OpenSSL on Windows.
The main reason for merging this in 14.04 already is that we already
have runInWindowsVM in master and it doesn't work until we actually
cross-build Cygwin's setup binary as the upstream version is a fast
moving target which gets _overwritten_ on every new release.
Conflicts:
pkgs/top-level/all-packages.nix
Both branches have quite a lot in common, so it's time for a merge and
do the cleanups with respect to both implementations and also generalize
both implementations as much as possible.
This also closes#1876.
Conflicts:
pkgs/development/interpreters/lua-5/5.2.nix
pkgs/development/libraries/SDL/default.nix
pkgs/development/libraries/glew/default.nix
pkgs/top-level/all-packages.nix
For instance, a package can now say:
buildInputs = [ ant jre ecj ];
which would cause the Eclipse compiler to be used with the OpenJRE.
Similarly:
buildInputs = [ ant gcj ];
uses the GNU JVM with the GNU Java compiler.
Also, Ant no longer has a build-time dependency on a particular JDK.
It finds the JDK via $JAVA_HOME or $PATH (by looking up javac). This
way, we don't need to have separate packages like apacheAntOpenJDK and
apacheAntOracleJDK. It also seems reasonable: after all, installing
GNU Make doesn't give you a C compiler either. It does mean that
instead of
buildInputs = [ ant ];
you now need to write something like
buildInputs = [ ant jdk ];
* Remove package name
* Start with upper case letter
* Remove trailing period
Also reword some descriptions and move some long descriptions to
longDescription.
I'm not touching generated packages.
There are many more packages to fix, this is just a start.
Rules:
* Don't repeat the package name (not always that easy...)
* Start with capital letter
* Don't end with full stop
* Don't start with "The ..." or "A ..."
I've also added descriptions to some packages and rewritten others.
Unfortunately, leiningen will now pull in some dependencies via maven (via http) on `lein version' so the test at the end of builder.sh failed. This is okay because leiningen is used only as a interactive tool and no other package in Nixpkgs depends on it.
Signed-off-by: Moritz Ulrich <moritz@tarn-vedra.de>
This breaks some packages (notably liblapack) due to a broken macro
(CTEST_CUSTOM_POST_TEST). See NixOS/nixpkgs#762
This reverts commit ebc424c3ab.
Signed-off-by: Shea Levy <shea@shealevy.com>
The changelog is available at:
http://www.cmake.org/files/v2.8/CMakeChangeLog-2.8.11
I had to create a new patch from scratch, that's why it contains a lot
of differences. CMake developers has rewritten the files
(Modules/Platform/Linux.cmake and Modules/Platform/UnixPaths.cmake) to
comply to their coding style requirements and a lot of elements has
switched from upper to lower case.
Also, the previous patch partially consisted of commenting some
instructions mixed with line removals whereas mine is directlty
removing them in order to avoid useless evaluations and parsing in
resulting files.
Version 1.2.0 is way too old in order to build the latest chromium (29) version,
so let's get it up to date (especially because no other package is referencing
ninja, so it should be non-critical).
The dependency on unzip is not needed here, because GitHub also provides
archives in tar.gz format.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
set CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH based on NIX_CFLAGS_COMPILE and
NIX_LDFLAGS so that cmake's find_library like functions find all the libraries
gcc knows about thanks to the gcc wrapper
This is particular useful with myEnvFun which then also sets those CMAKE_* env
variables.`
Because setup.sh has to change this causes many rebuilds - thus it should be
included in a stdenv-update like branch
Also cmake builds in parallel perfectly fine
update cmake to latest minor number, I didn't change the patches,
just reapplied them manually recordin a new patch
ninja is a build system written in C++ that just happens to use python
to build/install *itself*. It is not a "python package".
After this commit, ninja will be at pkgs.ninja instead of
pkgs.pythonPackages.ninja.
* 0.8.7p1 doesn't contain *.info documentation; use manpage
instead
* Update meta.description to not contain the package name (redundant)
* 0.8.7p1 only builds with python dateutil==1.5, so that has to be added
as well
Runtime tested with the buildbot slave that is added in the next commit.
Vladimír Čunát
Gabriel Ebner
William A. Kennington III
Robin Gloster
Tobias Geerinckx-Rice
goibhniu
Tim Cuthbertson
Samuel Rivas
Peter Simons
koral
Eelco Dolstra
Thomas Tuegel
Desmond O. Chang
Moritz Ulrich
Rickard Nilsson
j-keck
Profpatsch
lethalman
Ragnar Dahlén
Nikolay Amiantov
Philip Potter
Ricardo M. Correia
Austin Seipp
Stewart Mackenzie
Jude Taylor
Robert Irelan
Michael Raskin
Rok Garbas
Pascal Wittmann
Florian Friesdorf
Arseniy Seroka
Joel Taylor
Pascal Wittmann
Georges Dubus
Charles Cooper
Dmitry Belyaev
Eric Seidel
John Wiegley
Luis G. Torres
goodwillcoding
Rob Vermaas
Jordan Woehr
Bjørn Forsman
Shea Levy
Johannes Bornhold
Benjamin Saunders
Ludovic Courtès
John Ericson
Patrick Mahoney
bbarker
Alexander Flatter
Mateusz Kowalczyk
Henry Till
宋文武
Daniel Peebles
William Roe
aszlig
Domen Kožar
Petr Rockai
Mathijs Kwik
bbenoist
Evgeny Egorochkin
Marc Weber