Co-authored-by: Guillaume Girol <symphorien@users.noreply.github.com>

Co-authored-by: Guillaume Girol <symphorien@users.noreply.github.com>

This reverts commit 02828f9, reversing
changes made to f0a7fce.

This unreleased version of GHDL fixes a bunch of bugs. It also contains
a few internal API changes for synthesis support -- required by the GHDL
yosys plugin.

Ideally, we can just remove this when 0.38 comes out.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

By default, when yosys looks for plugins with the `-m` flag or `plugin`
command, it always looks in `YOSYS_PREFIX/share/yosys/plugins` for a
`.so` file, and loads that.

By design, this is intended to be a single, global, mutable location
such as `/usr/share/yosys/...` on disk, and plugins are supposed to
install their `.so` files here after yosys is installed, and they all
coexist together. Obviously, this won't work for us, but users might
expect these plugins to still work. More importantly, they won't want to
add special cases to their build systems.

Instead, to allow Nix users to use yosys plugins with the same UX (e.g.
natively call `plugin bluespec` or `-m ghdl`), we add a patch to yosys
that allows it to search a new `NIX_YOSYS_PLUGIN_DIRS` search path
environment variable. In tandem, we add a setup hook that adds to this
search path if a package has a `$out/share/yosys/plugins` directory.

Thus, it's enough to just include `yosys`, and any package that has a
yosys plugin in `$out/share/yosys/plugins`, and you can load it with
`-m` or the `plugin` command.

We could use a style like the haskellPackages set, where the set of
packages are "encased" in a lambda, and we pass packages that are
compatible with that version of the compiler:

    haskell.packages.ghc8102.ghcWithPackages (p: with p; [ ... ])

but, realistically, there will probably only ever be one version of
yosys and one set of compatible plugins, so this seems overdone.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

These plugins can be included in a closure, along with the `yosys`
derivation, and they will be automatically picked up for use. For
example, this allows you to include 'yosys-bluespec' in your
`buildInputs`, and then immediately run:

    $ nix-shell -p yosys yosys-bluespec yosys-ghdl
    $ yosys -m bluespec -p 'help read_bluespec'
    $ yosys -m ghdl -p 'help ghdl'

These two plugins are a bit experimental, admittedly, but they are good,
clean examples of how to write and use the yosys plugin infrastructure,
and make it easy to test updates, etc.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

d81e4d9 contained some minor fixes to the yosys derivation
that make it a little easier to read and maintain. Incorporate those.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Fixes up the usage of patches/postInstall. Also removes `stdenv.lib` and
other minor tweaks.

Based on feedback from Sandro and Mihai.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

https://github.com/hedgedoc/hedgedoc/releases/tag/1.7.2

CVE-2021-21259:
GHSA-44w9-vm8p-3cxw

Release notes:

https://releases.1password.com/linux/0.9/#1password-for-linux-0.9.8

yosys: add support for loading plugins, revert symbiflow changes

move nixos-rebuild into pkgs

A few other things:
 - prep for transition to gtk3 when audacity recommends it
 - we drop the runtime linking with lame as audacity is picking it up on
   its own
 - on linux, add a number of missing dependencies.
 - use a newer (recommended) wxwidgets
 - add a patch (merged upstream) that makes audacity follow XDG for file locations

_1password-gui: 0.9.7 -> 0.9.8

python37Packages.ipyvue: 1.4.1 -> 1.5.0

…-cloud-spanner

python37Packages.google-cloud-spanner: 2.1.0 -> 3.0.0

mtail: 3.0.0-rc38 -> 3.0.0-rc41

checkov: init at 1.0.674