This adds a warning to the top of each “boot” package that reads:
Note: this package is used for bootstrapping fetchurl, and thus cannot
use fetchpatch! All mutable patches (generated by GitHub or cgit) that
are needed here should be included directly in Nixpkgs as files.
This makes it clear to maintainer that they may need to treat this
package a little differently than others. Importantly, we can’t use
fetchpatch here due to using <nix/fetchurl.nix>. To avoid having stale
hashes, we need to include patches that are subject to changing
overtime (for instance, gitweb’s patches contain a version number at
the bottom).
Unfortunately the output of git.savannah.nongnu.org changes with each
gitweb update. This means that the current has
“0gja54fz79a9ma6b4mprnjxq77l5yg2z9xknlwhmkcrfnam02qxp” is no longer
correct:
$ nix-prefetch-url
https://git.savannah.nongnu.org/cgit/attr.git/patch/\?id=14adc898a36948267bfe5c63b399996879e94c98
1g8sky52rjg9fpmrddza1af89s9qd4bzsbxqb7mc5bv8gyh10s1k
Normally, we use fetchpatch to strip this out, but unfortunately attr
cannot use fetchpatch due to being used in bootstrapping fetchurl.
That is, it can’t use a custom postFetch since <nix/fetchurl.nix>
doesn’t support that.
To solve this problem, just inline the patch for now.
This is needed for cross-compiling for LLVM.
After https://github.com/NixOS/nixpkgs/pull/94088, we still need some
of these, so I’ve whitelisted those that are in binutils.
/cc @DavidTruby
We need to set FC so that CMake and other tools can find the fortran
compiler. Also we need to limit the hardening flags since fortify and
format don’t work with fortran.
Fixes#88449
This makes it possible to only start IPFS when needed. So a user’s
IPFS daemon only starts when they actually use it.
A few important warnings though:
- This probably shouldn’t be mixed with services.ipfs.autoMount
since you want /ipfs and /ipns aren’t activated like this
- ipfs.socket assumes that you are using ports 5001 and 8080 for the
API and gateway respectively. We could do some parsing to figure
out what is in apiAddress and gatewayAddress, but that’s kind of
difficult given the nonstandard address format.
- Apparently? this doesn’t work with the --api commands used in the tests.
Of course you can always start automatically with startWhenNeeded =
false, or just running ‘systemctl start ipfs.service’.
Tested with the following test (modified from tests/ipfs.nix):
import ./make-test-python.nix ({ pkgs, ...} : {
name = "ipfs";
nodes.machine = { ... }: {
services.ipfs = {
enable = true;
startWhenNeeded = true;
};
};
testScript = ''
start_all()
machine.wait_until_succeeds("ipfs id")
ipfs_hash = machine.succeed("echo fnord | ipfs add | awk '{ print $2 }'")
machine.succeed(f"ipfs cat /ipfs/{ipfs_hash.strip()} | grep fnord")
'';
})
Fixes#90145
Update nixos/modules/services/network-filesystems/ipfs.nix
Co-authored-by: Florian Klink <flokli@flokli.de>
Previously we had three services for different config flavors. This is
confusing because only one instance of IPFS can run on a host / port
combination at once. So move all into ipfs.service, which contains the
configuration specified in services.ipfs.
Also remove the env wrapper and just use systemd env configuration.
We can use cacert to validate that the data passes SSL certificates.
Normally, this doesn’t happen because we already have the hash, but in
the hash = "" case we don’t.
This is very confusing. “stdenv” is created from the parent stage so
pkgsTargetTarget.stdenv.cc is a compiler that runs /on/ host platform
and creates binaries for target platform. gfortran on the other hand
is not special cased like stdenv, so the equivalent to
pkgsTargetTarget.stdenv.cc is pkgsHostTarget.gfortran.
I’ve rewritten this to be a little less confusing, “pkgsHostTarget” is
equivalent to “pkgs” so it is unneeded. All that is left is
“pkgsTargetTarget.stdenv” which is equivalent to
“targetPackages.stdenv”.
Fixes#88951
/cc @markuskowa @ericson2314
flat hashes can be substituted through hashed-mirrors, while recursive
hashes can’t. This is especially important for Bazel since the bazel
fetch dependencies can come from multiple different methods (git,
http, ftp, etc.). To do this, we create tar archives from the
output/external directory, which is then extracted to build. All of
the Bazel hashes are all updated.
When using netlib lapack/blas, the section name doesn’t match what
numpy expects. So we need to add extra sections for both so that the
right directory is found. The original “blas.implementation” section
may not actually be still required, but it is still a good idea so
that numpy know whether to apply any blas-implementation specific
quirks.
Fixes#86613
Matthew Bauer