Currently broken; see #79975 for details. Would also be fixed by #80153
eventually, but since we want to upgrade either way we might as well do so now.
Resolves#80117 by using the newer fetcher; see #79975 for details.
Would also be fixed by #80153 eventually, but we want to upgrade Rust packages
either way, so might as well start with the broken ones!
Includes some bugfixes/cleanups to the scripts and packaging, a run of the
updater, a bump of the version, an upgrade to the newer cargo fetcher in #79975,
and gets the web assembly portion to compile successfully.
Fixes#75863
Changes the default fetcher in the Rust Platform to be the newer
`fetchCargoTarball`, and changes every application using the current default to
instead opt out.
This commit does not change any hashes or cause any rebuilds. Once integrated,
we will start deleting the opt-outs and recomputing hashes.
See #79975 for details.
The readme was nice to discuss in the implementation PR, but now that this is
merged it's better to have an issue that can be linked against in PRs and
doesn't require further merges to update status.
Ported with a status update in #79975
With the new update to 1.2 in https://github.com/NixOS/nixpkgs/pull/79426, some
the install tree coming out of cmake seems to have produced a duplicate copy of
the nix tree.
This has several advantages:
1. It takes up less space on disk in-between builds in the nix store.
2. It uses less space in the binary cache for vendor derivation packages.
3. It uses less network traffic downloading from the binary cache.
4. It plays nicely with hashed mirrors like tarballs.nixos.org, which only
substitute --flat hashes on single files (not recursive directory hashes).
5. It's consistent with how simple `fetchurl` src derivations work.
6. It provides a stronger abstraction between input src-package and output
package, e.g., it's harder to accidentally depend on the src derivation at
runtime by referencing something like `${src}/etc/index.html`. Likewise, in
the store it's harder to get confused with something that is just there as a
build-time dependency vs. a runtime dependency, since the build-time
src dependencies are tarred up.
Disadvantages are:
1. It takes slightly longer to untar at the start of a build.
As currently implemented, this attaches the compacted vendor.tar.gz feature as a
rider on `verifyCargoDeps`, since both of them are relatively newly implemented
behavior that change the `cargoSha256`.
If this PR is accepted, I will push forward the remaining rust packages with a
series of treewide PRs to update the `cargoSha256`s.
It was previously referencing `$bin`, but this package no longer produces a
`bin` output, just `out` and `share`. Updated to make the comparison check a bit
more robust.
Also updated to avoid direct dependency on the `$src` directory out of the nix
store, instead using the processed src setup in the unpackPhase. This provides a
cleaner abstraction between the build/install phase and the input src phase, and
avoids an unnecessary dependency on whether the source disted tarball comes from
`fetchFromGitHub` (in which case it's an unpacked directory) or something like
`fetchurl`. In either case, stdenv is responsible for processing the input `src`
and setting up a clean build dir for us, so we should use that.
This produces an equivalent directory tree, except that the vim plugin is no
longer broken.
No material changes to docs, but trying to sanitize them for consistent
readability prior to looking at #75837.
- Use `*` for lists instead of `-`. I have no opinion one way or the other, but
the latter was only used in 1-2 places.
- Pad the code blocks with whitespace.
- Wrap to 80 characters, except for a few 1-liners that were only slightly over.
This cleans up our dependency footprint by ensuring a consistent version, and
also avoids duplicating the logic for how to build a waf package by deferring to
the `wafHook` helper for the `configurePhase`, `buildPhase`, and `installPhase`.
This commit continues the work proposed in #68014, and provides an entirely FOSS
variant of the `dnnl` package. Updates to add an `mkl` flavor will be added
later, pending discussion about the cleanest way to overlay this consistently.
Fixes#67982, closes#68014
Co-authored-by: Alex Rice <alexrice999@hotmail.co.uk>
The `bash` pragma gives syntax highlighting on the file, and removing the
prompts allows a user to just copy-paste the entire block into the terminal to
run the update.
This is very out of date, is pinned to an old version of boost, and the last
update was 2.5 years ago marking it as broken. Since no one has fixed it or
upgraded to the least version, it seems a strong indication it's no longer
used/wanted/maintained and should be removed.
When this fails, the user may want to copy-paste the path to the "bad"
Cargo.lock file to inspect. The trailing `.` on `$cargoDeps.` gets caught in
most terminal copy-pastes. Since half the lines already don't have it, this
removes it from all of them for consistent output.
Upstream openssl has dropped support for 1.0.2; see #77503 for details. This
also cleans up the old `asio` dependency, which now comes from `boost`, and
documents why the test driver fails.
This override to the old 1.x version of `prompt_toolkit` appears to be
unnecessary; removing it does not change the hash of `awscli`.
In a follow-up, we could likely remove the RSA override as well, if we're OK
with patching out the `setup.cfg` requirements. This dropped support for some
old modules, but appears to not break API compatibility otherwise:
https://github.com/sybrenstuvel/python-rsa/blob/master/CHANGELOG.md#version-40---released-2018-09-16
Upstream has moved the src tarball download location and homepage for `libcerf`,
so the current package is broken. While fixing it, let's upgrade to the latest
version, which is built with cmake now.
Co-Authored-By: Jon <jonringer@users.noreply.github.com>
- pname makes it easier to override the version in an overlay and looks generally cleaner
- Updated the meta sections to match between the various versions
No real functional change, just cleanup.
Users who want to patch boost may put a postInstall hook in an overlay, which
requires that that expression runs them on the buildPhase and installPhase.
This package was written more than a decade ago; this commit updates the layout
to be more conventional without making any meaningful changes. Note that because
it now has a version attribute in the derivation this does change the hash.
Since Intel's default openmp implementation is available in the same src
tarball, we can just include it in the package. This means that `mkl` now "just
works" without any environment variables, fragile setup-hooks, or forced
propagation.
Since the openmp implementation is only needed at runtime (and for test cases),
users can substitute a different one if they prefer by exporting it with
`LD_PRELOAD`, which is how Intel recommends handling this. If they do not do so,
`libiomp.so` lives next to `libmkl_rt.so` and thus will be in the RPATH as a
sane default.
Since this still comes from the same src tarball, we can ship it without losing
the fixed-output derivation; likewise, since Hydra is not building or caching
these, shipping these proprietary packages costs no bandwidth for the nix
community.
* fetchurl: fix and add extra KDE mirrors (#51480)
- The gwdg.de mirror has moved the relative path of its KDE tarballs
- Add new mirrors from Berkeley and MIT, which are on the list of officially supported mirrors
https://download.kde.org/extra/download-mirrors.html
* More KDE mirror touchups
- The official one is a redirect to HTTPS anyways, so go directly to HTTPS
- Add China USTC for Asian users
- Swap Finland university from FTP to HTTP
* fetchurl: keep one ftp KDE mirror
HTTPS is never worse and often better than FTP, since it's faster, more secure,
and more likely to be accessible through firewalls.
This does not change the tarball sha, as confirmed by `nix-prefetch-url`.
No real function change here, but this updates the trivial and melpa builders to
be formatted more consistently with the rest of the builders, and swaps
`eval "$preBuild"` for the more standard `runHook preBuild`.
If the nix store lives on NFS, `ghc 8.2.1` is unable to build a package
database. This bug was fixed by @bgamari in `ghc 8.2.2` here:
https://ghc.haskell.org/trac/ghc/ticket/13945
This commit upgrades the unpacked bootstrap GHC version, so that we can build
newer versions of GHC even if the store is on NFS.
This commit renames the pythondaemon module to match its module name, github
name, and pypi name, which makes it easier to find and reference. In order to
avoid breaking any external users, I've left an alias with a deprecated warning.
The upgraded version has memory leak fixes and test case fixes for qt5.
This also swaps to git due to difficulties in fetching src with `bzr` without
'not a branch' errors.
This touches up a handful of places in the python documentation to try to make
the current best-practices more obvious. In particular, I often find the
function signatures (what to pass, what not to pass) confusing and have added
them to the docs.
Also updated the metas to be more consistent with the most frequently used
modern style.
HTTPS is unlikely to be worse and is often better than FTP. Aside from being
faster, there are many networking setups where outgoing FTP traffic is blocked.
The `unfree` and `unfreeRedistributable` licenses both have `free = false`,
which will trigger the first portion of logic. This removes dead code to
simplify the logic.
As a follow-up, I plan to add an attribute `redistributable = [true|false]`,
which can be used by Hydra to determine whether a given package with a given
license can be included in the channel.
This packags the Intel Math Kernel library on x86-64 platforms, which is a
dependency for many data science and machine learning packages.
Upstream, Intel provides proprietary binary RPMs with a permissive
redistribution license. These have been repackaged in both Debian and Anaconda,
so we are not the first distribution to redistribute.
A few months ago I moved these patches to the new debian alsa instance [1], but
it looks like their `sha256`s on the tag at the remote have changed again.
It doesn't appear that debian's source remote is stable in the way we need it to
be; let's just vendor the patches to avoid future issues.
[1] https://github.com/NixOS/nixpkgs/pull/41769
Benjamin Hipple