- Add a conditional flag for the c++ std lib
- Build binaries that get linked by our own dyld (someday)
- Automatically add framework directories in the setup hook
- nix-template-rpm can now split the generated templates into
a static part that goes into the nixpkgs tree
a dynamic part that can be updated easily to track the rpm spec files
- add lookup mechanism for package names and package paths
- add mechanism to update existing nix-expression with new download files
These packages, and maybe some more include unix.h for some reason.
Creating that file makes them build, and in the case of xdebug also
appear to work.
We now have an alternate setup hook for gcc-wrapper that uses -I to add
include paths rather than -isystem. The latter flag can change the
search order specified by the build system. For KDE 5 packages, we don't
want that!
The default setup-hook for gcc-wrapper adds include directories with
-isystem, which upsets the order -I flags are processed. This adds an
alternative setup-hook that only uses -I flags. The build system's
ordering of -I flags is then respected. This is important when different
packages provide includes with the same name, such as building packages
that depend on Qt4 and Qt5.
This resolves a regression introduced in fc01353703, where providing a
name without a proper extension breaks existing uses of fetchzip (they
now fail to unpack). Of particular note, that commit broke all uses of
fetchFromGitHub because it uses a name like so: "${repo}-${rev}-src"
Fixes #5954
This fixes:
* Passing stripRoot.
* Archives containing a single file.
* Archives where the root folder has the same name as one of it's children.
Fixes #5851
This option tells the kernel to ignore plug-in events of USB devices. Useful to
protect against attacks with malicious hardware. Currently disabled by default,
though.
The name detection didn't work for e.g. http://git.suckless.org/sinit/.
I tested the tarball builds now.
@shlevy claimed nixpkgs requires nix-1.8 features anyway,
so the additional check with message were superfluous.
Problems are worked around by using older gcc wrapper for gnat bootstrap.
(from ca441636f1^)
I tried nicer solutions first, but I was unable to fix all problems for hours.
Especially new users could be confused by this, so we're now marking
services.virtualbox.enable as obsolete and defaulting to
services.virtualboxGuest.enable instead. I believe this now makes it
clear, that this option is for guest additions only.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is because libxml/libxslt are not the only implementations that
respect $XML_CATALOG_FILES.
Also, look in share/xml for catalogs (in addition to the
now-deprecated xml/dtd and xml/xsl).
Multi-threaded builds exacerbate the non-determinism in ghc package ids, which
is a serious problem for libraries. Packages that define only executables,
however, should be safe to build with parallelism enabled.
Packages that don't have a Setup.hs file get to use a default version that
lives in the Nix store. By default ghc tries to put the Setup.o and Setup.hi
files in the same directory as the source file, which isn't writable. This
leads to build errors [1]. Thus, we re-direct those paths to a build-local
writable location: $TMPDIR.
Arguably, we could also use "." or copy the /nix/store/deadbeef-Setup.hs file
into the local source directory before compiling, which would work fine, too.
[1] https://github.com/NixOS/nixpkgs/issues/4851
Without this, the generated pack files are non-deterministic.
I didn't notice this issue in my earlier testing, because my test repo
had too few commits for the thread scheduling to take effect. (Test repo
had about 10 commits.)
Add more files to the delete list:
* .git/FETCH_HEAD
* .git/ORIG_HEAD
* .git/refs/remotes/origin/HEAD
* .git/config
Further, remove all remote branches, remove tags not reachable from the
given 'rev', do a full repack and then garbage collect unreferenced
objects.
According to my testing, the result is fully deterministic. As in "any
change done to the upstream repo, ahead of 'rev', will not affect the
hash of the resulting 'clone'". Even changing the clone URL will not
change the output hash, because .git/config is removed.
A new version of git can of course change store format, but that's
unavoidable.
For big repositories, the repack operation may be a bit heavy. But as
far as I can see there is no cheaper way to determinism.
Hydra generates a GHC closure for Darwin that for no apparent reason
contains an ancient, broken Haddock binary -- probably because of an
impurity in the build system. That bug makes those GHC binaries
unusable: <https://github.com/NixOS/nixpkgs/issues/2689>.
This likely exacerbates the non-determinism in ghc package ids, so until
that is fixed let's live with the slow builds.
This reverts commit 817c0e4144.
This should fix the OpenJDK build, which was failing because paxctl is
in sbin and therefore not automatically added to $PATH.
http://hydra.nixos.org/build/15658346
This patch makes two changes.
(1) It memoizes the computation of dependsOnOld.
(2) It replaces rewrittenDerivations with a similar memoized table rewriteMemo.
This prevents the entire tree of run-time dependencies from being traversed and instead only traverses the graph of run-time dependencies.
In the case of deep dependency changes (such as changing one's bash version for an entire NixOS system) this can lead to an exponential speedup in processing time
because shared dependencies are no longer traversed multiple times.
This patch isn't quite derivation-per-derivation equivalent to the original computation.
There are two immaterial differences.
(1) The previous version would always call upon sed to replace oldDependency with newDependency even when the store object being updated doesn't directly depend on
oldDependency.
The new version only replaceds oldDependency with newDependency when the store object being updated actually directly depends on oldDependency (which means there is
actually a hash to replace).
(2) The previous version would list the old store object as a source input of the new store object, *except* for the root derivation being updated. Because the
root derivation being updated has its actual derivation avaiable the previous verions would make the updated root derivation depend on the old derivation as a
derivation input instead of a source input.
The new version always lists the old store object as a source input, including the root derivation.
