Per comment in the upstream release notes, the `beta` track is no longer
maintained, and parity only has `stable` releases, so this deletes the beta
expression entirely.
https://github.com/paritytech/parity-ethereum/releases
This also updates to the new fetchCargoTarball implementation as part of #79975
This package consists mostly of command-line tools, but there are also two qt5-based image viewers (`mrview` and `shview`). I have provided an option `withGui = true` to allow users to disable these viewers. They work on NixOS but unlikely to work out-of-the box on non-NixOS Linux (see #62169), but I've refrained from asserting that they shouldn't be built since a user might want to fiddle with runtime GL stuff.
Some programs rely on FSL and/or ANTs backends; I have somewhat heavy-handedly wrapped all binaries to point to ANTs, while FSL is not available in Nix at the moment and has a non-commercial license so would be convenient to disable by default for Hydra builds.
- Init libuninameslist at 20190701 as it is a new dependency to fontforge
- Remove gnulib, as it is not used anymore
- Remove a non-applying patch
- Add myself as maintainer
The upstream repository has been archived, with a note that this should never be needed:
https://github.com/alexcrichton/wasm-gc
It also happens to have custom patch logic that will fail the newer cargo
verification in #79975
This gets rid of a few patches that aren't needed any more, adds one
to make the tests work again and updates the MacOS patch. It also
introduces two builds - one with the Qt application and one without.
The patch to get the tests working will be submitted upstream and
hopefully not be needed for future releases.
One of the motivations for this change is the following Discourse
discussion:
https://discourse.dhall-lang.org/t/offline-use-of-prelude/137
Many users have requested Dhall support for "offline" packages
that can be fetched/built/installed using ordinary package
management tools (like Nix) instead of using Dhall's HTTP import system.
I will continue to use the term "offline" to mean Dhall package
builds that do not use Dhall's language support for HTTP imports (and
instead use the package manager's support for HTTP requests, such
as `pkgs.fetchFromGitHub`)
The goal of this change is to document what is the idiomatic way to
implement "offline" Dhall builds by implementing Nixpkgs support
for such builds. That way when other package management tools ask
me how to package Dhall with their tools I can refer them to how it
is done in Nixpkgs.
This change contains a fully "offline" build for the largest Dhall
package in existence, known as "dhall-packages" (not to be confused
with `dhallPackages`, which is our Nix attribute set containing
Dhall packages).
The trick to implementing offline builds in Dhall is to take
advantage of Dhall's support for semantic integrity checks. If an
HTTP import is protected by an integrity check and a cached build
product matches the integrity check then the HTTP import is never
resolved and the expression is instead fetched from cache.
By "installing" dependencies in a pre-seeded and isolated cache
we can replace remote HTTP imports with dependencies that have
been built and supplied by Nix instead.
The offline nature of the builds are enforced by compiling the
Haskell interpreter with the `-f-with-http` flag, which disables
the interpreter's support for HTTP imports. If a user forgets
to supply a necessary dependency as a Nix build product then the
build fails informing them that HTTP imports are disabled.
By default, built packages are "binary distributions", containing
just a cache product and a Dhall expression which can be used to
resolve the corresponding cache product.
Users can also optionally enable a "source distribution" of a package
which already includes the equivalent fully-evaluated Dhall code (for
convenience), but this is disabled by default to keep `/nix/store`
utilization as compact as possible.
This version is 5 commits ahead of version 1.0.0 because we need at
least one patch [0] that prevents CMake from trying to use Git to fetch
the already fetched submodule...
Also some files have the wrong formatting (CRLF line endings) which
makes the patching really messy. At this point is seems therefore better
to use the master version instead (1.0.0 is pretty broken regarding
CMake).
[0]: 0ca73ee30e
