This allows users to specify a custom registry src,
because currently every packager would need to create
an outdated Cargo.lock just to be compatible with the
probably outdated rustRegistry in nixpkgs.
Currently there is no easy way to convince cargo to
do that, so this makes that workaround unnecessary.
I think it's ok to export things which aren't wrapped. The cc-wrapper
can be thought of as responsible for all of binutils and the c
compiler, only wrapping those binaries which are necessary to
interposition---as opposed to all binaries it thinks are relevaant.
Conversely, adding the setup hook to the unwrapped compilers would be
unforunate as hooks are ugly hacks and the compilers themselves take
a long time to rebuild. Better to wholely separate "pure packages" from
hacks.
Eventually we should avoid this "pre-wrapping" and just update those
files in nixpkgs. This mass-rebuild change is best done along with
those needed to reduce the disparity between native and cross (i.e.
making native the "identity cross").
We now (on cross) require per-target flag interposition by putting the
triple in the names of the relevant environment variables, e.g:
export NIX_arm_unknown_linux_gnu_CFLAGS_COMPILE=...
The wrapper also has a `infixSalt` attribute (and "_" prefixed and
suffixed variants) to assist downstream packages.
Note how that the dashes are replaced to keep the identifier valid.
Using names like this allows us to keep the settings for different
compilers seperate.
I think it might be even better to use names like `NIX_{BUILD,HOST}...`
using the platform's role rather than the platform itself, but this
would be more work as the previous stages' tools would have to be re-
wrapped to take on their new role. I therefore didn't do this for now,
but that route should be thoroughly explored in the future.
This fixes the Stack Clash issue rediscovered by Qualys. See
https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
for more information on the topic, specifically section III.
We don't have the kernel mitigation available because it is a Grsecurity
feature which we don't support anymore. Other distributions like Gentoo
Hardened and Arch already have `-fstack-check` enabled by default.
See the Gentoo page on Stack Clash for more information on this solution:
https://wiki.gentoo.org/wiki/Hardened/Gentoo_Hardened_and_Stack_Clash
This unfortunately doesn't apply to clang because `-fstack-check` is a
noop there. Note that the GCC implementation also has problems that could
be exploited to circumvent these checks but it is still better than
keeping it disabled.
* ultrastardx-beta: init at 1.3.5
* libbass, libbass_fx: init at 24
* ultrastar-creator: init at 2017-04-12
* buildSupport/plugins.nix: add diffPlugins
Helper function to compare expected plugin lists to the found plugins.
* ultrastar-manager: init at 2017-05-24
The plugins are built in their own derivations, speeding up (re-)compilation.
The `diffPlugins` function from `beets` is reused to test for changes in the
plugin list on updates.
* beets: switch to diffPlugins
The function is basically just extracted for better reusability.
This value is require to get c++ std include path for libclang based tools (vim plugins in my case).
I currently extract it this with this rather command:
```
eval echo $(nix-instantiate --eval --expr 'with (import <nixpkgs>) {}; clang.default_cxx_stdlib_compile')
```
it did not trigger any recompilation on my system.
`SSL_CERT_FILE` has been replaced with `NIX_SSL_CERT_FILE`.
Before this change using `fetchdarcs` resulted in an error message like:
```
Identifying repository http://hub.darcs.net/scravy/easyplot inventory
darcs failed: Not a repository: http://hub.darcs.net/scravy/easyplot (Peer certificate cannot be authenticated with given CA certificates)
HINT: Do you have the right URI for the repository?
builder for ‘/nix/store/imyvcs6lvb5yva66krc5wk39931sam8v-fetchdarcs.drv’ failed with exit code 2
```
I was getting the following error building tide from Melpa:
nix-build -E '(import <nixpkgs> {}).emacs25WithPackages (p: [p.melpaPackages.tide])'
File tide-20170509.1134.tar is large (10.2M), really open? (y or n) Error reading from stdin
builder for ‘/nix/store/gs9ik7yf8iilsikkfing74i70m0diax3-emacs-tide-20170509.1134.drv’ failed with exit code 255
cannot build derivation ‘/nix/store/m3p080aani4rw82llp8nqk93cw2nvirk-emacs-with-packages-25.2.drv’: 1 dependencies couldn't be built
Solution was to disable the large file warning threshold when
installing packages.
This still causes some uncached rebuilds, but master(!) and staging
move too fast forward rebuild-wise, so Hydra might never catch up.
(There are also other occasional problems.)
Therefore I merge at this point where the rebuild isn't that bad.
We need to make sure that `$revs` ends with a space, since files must always
end with newlines. The previous code ignored the last entry in `$revs`, because
read already returns non-zero exit code for the last entry, as it does not end
with a space.
This change fixes several defects in the way `wrapGAppsHook` selected
the executable to wrap.
Previously, it would wrap any top-level files in the target `/bin` and
`/libexec` directories, including directories and non-executable
files. In addition, it failed to wrap files in subdirectories.
Now, it uses `find` to iterate over these directory hierarchies,
selecting only executable files for wrapping.
This change fixes several defects in the way `wrapGAppsHook` selected
the executable to wrap.
Previously, it would wrap any top-level files in the target `/bin` and
`/libexec` directories, including directories and non-executable
files. In addition, it failed to wrap files in subdirectories.
Now, it uses `find` to iterate over these directory hierarchies,
selecting only executable files for wrapping.
When not using sandboxing, /usr/share/git-core/templates may leak into the
nix build through the libgit2 hardcoded default template search path. We now
explictly set the templatedir to avoid this problem.
See https://github.com/bennofs/nix-index/issues/2#issuecomment-296268983 for
an example case of nondeterminism.
This typo was likely introduced by copy-pasting the error message from elsewhere and forgetting to change the text, during the MD5 deprecation process (#4491).
This patch fixes file modification times to $SOURCE_DATE_EPOCH, and
ensures that files originating from the store are owned by root:root.
Both changes improve reproducibility, and the latter allows proper
building on a host where the store is owned by a non-root user.
Every Rust derivation used to emit a warning like the following:
```
setting SOURCE_DATE_EPOCH to timestamp 1490877042 of file cargo-6e0c18c/Cargo.lock
warning: file cargo-6e0c18c/Cargo.lock may be generated; SOURCE_DATE_EPOCH may be non-deterministic
```
The reason is that the dependencies are copied without preserving
timestamps. Changing the build script to timestamp-preserving copy
removes the warning.
