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.