https://github.com/hensm/fx_cast/releases/tag/v0.0.4
(cherry picked from commit c8e2559)

(cherry picked from commit 61576be)

(cherry picked from commit c6d6f63)

(cherry picked from commit a01a80a)

Systemd dependencies for scripted mode
were refactored according to analysis in #34586.

networking.vswitches can now be used with systemd-networkd,
although they are not supported by the daemon, a nixos receipe
creates the switch and attached required interfaces (just like
the scripted version).

Vlans and internal interfaces are implemented following the
  template format i.e. each interface is
described using an attributeSet (vlan and type at the moment).
If vlan is present, then interface is added to the vswitch with
given tag (access mode). Type internal enabled vswitch to create
interfaces (see openvswitch docs).

Added configuration for configuring supported openFlow version on
the vswitch

This commit is a split from the original PR #35127.

On Darwin/macOS, chatterino2's install phase copies no files into the
output. `make install` does not copy chatterino2.app. Copy the .app
manually, fixing the installation.

With this patch, chatterino2 almost works on macOS. Issue #42893
applies, so to make chatterino2 work, you must install qtbase in your
environment. For example:

    $ nix-env -iA nixpkgs.qt5.qtbase
    $ open ~/.nix-profile/Applications/chatterino.app

wrapQtAppsHook ignores Mach-O binaries [1]. Additionally, wrapQtAppsHook
doesn't look inside $out/Applications [2], which is where chatterino2 is
installed. This means chatterino2 for Darwin/macOS is not wrapped
properly, causing the following error when launched:

> qt.qpa.plugin: Could not find the Qt platform plugin "cocoa" in ""
>
> This application failed to start because no Qt platform plugin could
> be initialized. Reinstalling the application may fix this problem.

On macOS, explicitly wrap chatterino2's executable.

[1] pkgs/development/libraries/qt-5/hooks/wrap-qt-apps-hook.sh line 85
[2] pkgs/development/libraries/qt-5/hooks/wrap-qt-apps-hook.sh line 76

…uild fails

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.

There is no need to provide a separate `kubernetesVersion` argument
since the `file` argument works just fine

We don't compile blender with alembic. The linux build is able to detect
that, but this is not done for darwin. This explicitly disables alembic
to fix blender build on darwin.

https://www.zsh.org/mla/zsh-announce/141

... as requested by @Profpatsch

So that applications can find hunspell dictionaries installed through
environment.systemPackages.

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.

https://github.com/OWASP/Amass/releases/tag/v3.4.3
https://github.com/OWASP/Amass/releases/tag/v3.4.4

LibreOffice doesn't know where to look for hunspell dictionaries on
NixOS but we can use the DICPATH env var to point to them. Now
spellchecking with system dictionaries works.

Note that some of these dictionaries are built from LibreOffice repos -
this is preferable to building them as part of LO as other applications
can use them.

Upstream decided to split the lines we were patching out, so the patch
would fail.