Write (similar) expressions for GNURadio 3.7 and 3.8 and make 3.8
available as `gnuradio`, and `gnuradio3_7` point to the 3.7 build.
Teach both 3.7 & 3.8 expressions accept a `features` attribute set, that
tells them what features to compile. There are dependencies within the
different features, and we rely on upstream's cmake scripts to make sure
the `configurePhase` will fail if a feature is not enabled and needed by
another feature. All features are enabled by default.
Put shared Nix functions and attributes for both 3.7 and 3.8 in:
pkgs/applications/radio/gnuradio/shared.nix
Add 2 patches accepted upstream, that don't install some python related
examples if python-support is not enabled.
Remove cmake python reference in 3.8 with removeReferencesTo, if
python-support is turned off.
Update gqrx (reverse dependency) to use a build of gnuradio3_7 without
gui components and for it's gr-osmosdr as well.
Write an external, `wrapper.nix` (shared for both 3.7 and 3.8). Teach it
to handle extra `gr-` packages via `GRC_BLOCKS_PATH`. Likely enable it
to accept extra python packages. Wrap the executables with env vars
wrapGAppsHook and wrapQtAppsHook would have likely given them (hence,
fix#87510). Point `gnuradio` to the wrapped 3.8 derivation.
Add @doronbehar to maintainers of both 3.8 and 3.7.
dirty: use upstreamed patches
moved the initial qtcurve package to mkLibsForQt5 function
to decouple from Qt5 version
added an alias qtcurve -> libsForQt5.qtcurve for backward compatibility
add option to disable gtk2 support (still enabled by default)
Intro:
Part of #101369: Every attribute from kdeApplications and kdeFrameworks
can be built with a few different qt5 versions. It's hard to tell the
difference between an application and a library and some applications
rely on inputs from kdeApplications and libsForQt5 alike.
Before this change, some applications that were defined with
`libsForQt5.callPackage` used libraries from the kde* sets compiled with
a specific qt5 version,
Due to `inherit (kde*) <lib or app>;` used in the widest scope, we had
issues with packages that depended on packages defined by this
`inherit`. This led to mismatched qt versions used in the same inputs,
or the inputs of inputs etc.
Hence, we added to all libsForQt5* sets, packages that will be used from
the correct libsForQt5 set, in accordance to the
`libsForQt5*.callPackage` used. All `inherit (kdeApplications) <pkgs>`
and similar inheritance was moved out of all-packages.nix to aliases.nix
only for backwards compatibility.
Now some KDE applications show up in the attribute sets `libsForQt5*`
which didn't show up there previously. This is sort of misleading, as
these are not necessary libraries, but they show up in the wider scope
thanks to them in aliases.nix. Hence it's the best that can be done
considering the circumstances and the urgency of the issue.
Change error messages to start with or at least mention the name of the
package being referenced. This avoids obscure error messages like
"error: Abandoned by upstream." when rebuilding your system.
Also do some trivial cosmetic changes while touching things.
Right now, running `nixos-rebuild` gives an obscure error:
```
$ nixos-rebuild switch
building Nix...
building the system configuration...
error: Abandoned by upstream. Consider switching to bottom instead
(use '--show-trace' to show detailed location information)
```
(And `--show-trace` adds no useful information.)
The error message doesn't indicate that `ytop` is what's causing the problem.
By adding `ytop` to the error message, configurations that still reference
`ytop` will be easier to debug and fix.
This plugin has been merged into the newer "mopidy-local" plugin which I
just added. "mopidy-local-images" and "mopidy-local-sqlite" were added
originally for Mopidy Iris, but Iris now works with mopidy-local, and
does not need the older ones any more.
This plugin has been merged into the newer "mopidy-local" plugin which I
just added. "mopidy-local-images" and "mopidy-local-sqlite" were added
originally for Mopidy Iris, but Iris now works with mopidy-local, and
does not need the older plugins any more.
All packages were outdated.
Asterisk 15 is not supported anymore, but there is 17 now.
All versions bumped pjproject to 2.10 which requires overriding the
prefix.
Since Asterisk 17, `make install-headers` seems to be needed.
Jasper has been marked insecure for a while, and upstream has not
been responsive to CVEs for over a year.
Fixes#55388.
Signed-off-by: David Anderson <dave@natulte.net>
rfkill was subsumed by util-linux in 2017 [1], and the upstream has not
been updated in over 5 years [2]. This package shadows the rfkill from
util-linux, so it can be completely removed with no breaking changes,
because util-linux is in the base package set in nixos/system-path.
[1] d17fb726b5
[2] https://git.sipsolutions.net/rfkill.git/log/
Fails to build with Plasma >= 5.18 and there have not been any changes
in upstream since a long time.
According to the maintainer (@gnidorah) it can be removed.
This software is not longer available for download (for free), the
support for linux has been discontinued and any "freeware" use of this
software past 2019 December 31st is a breach of license terms.
Since the derivation is broken and cannot be fixed, remove it.
Antimicro is broken an no longer maintained (and doesn't compile).
AntimicroX is a fork that does compile, so this removes antimicro and
adds antimicroX.
This package previously did override the systemd package, and instructed
ninja, systemd's previous build system, to only build the
cryptsetup-specific systemd generators (plus some manual rpath
massaging, as ninja install wasn't used).
Afterwards, users were expected to add this package to their
`systemd.generator-packages` (or since
https://github.com/NixOS/nixpkgs/pull/65376/files `systemd.packages`)
NixOS module options, so systemd will use these generators.
As the previous commit added cryptsetup support directly to the systemd
package (and pkgs.systemd now already ships the cryptsetup generators),
we don't need another package shipping the same generators.
* telepathy 0.9.8 no longer supports Qt 4, so telepathy-qt and
telepathy_qt now throw an error suggesting to use the Qt 5 packages
instead.
* telepathy 0.9.8 uses Python 3 instead of Python 2, so that has been
corrected in the package.
* telepathy 0.9.8 includes the patch that was previously manually added,
so therefore it is removed from the package.
This removes the spidermonkey alias and renames it in the packages still
using it
Not sure if we need it in aliases.nix since just about nothing depends
on it anymore
Additionally considering removal should be a good choice, it's at least
insecure so it should get tagged as such
To prevent a breaking change while providing fully backwards compatible
interface to mpv-with-scripts, this replaces the harsh error using
`mpv-with-scripts` had.
Starting geant4 10.6.2 g4py can not be built separately
http://geant4-data.web.cern.ch/geant4-data/ReleaseNotes/Patch4.10.6-2.txt
Also, it appears that g4py itself is now deprecated, it was moved
to environments/g4py/tests/g4pytest in the source distribution. The only
remaining imported module is Geant4, hence python package name
`pythonPackages.geant4`, the capitalization matches the one of the non-python
attribute.
Inspired by `wrapNeovim`, write a wrapMpv Nix function that creates a
derivation that has all of the environment that was added if needed at
the unwrapped version.
Add derivations to all-packages.nix in an almost compatible way and make
`mpv-with-scripts` throw a message implying to switch to `wrapMpv` which
has an incompatible signature.
Add to vapoursynth a new passthru attribute `python3` that is used in
passed down to the wrapper to ensure ABI compatibility with
`PYTHONPATH`.
https://github.com/rhboot/fwupdate
This project is no longer supported.
All code has been merged directly into the fwupd project.
Please switch to that.
* treewide Drop unneeded go 1.12 overrides
* Fix packr to be go module compatible.
I updated to version 2.8.0 which is the latest on master.
Then due to the 2 different sets of go modules which are used, I split
the build into two different derivations, then merged them togethor
using symlinkJoin to have the same output structure as the existing derivation.
* Remove consul dependency on go1.12
I updated the consul version to 1.7.2 and flipped it to building using
modules.
* Remove go1.12 from perkeep.
Update the version to the latest unstable on master.
* Update scaleway-cli to not be pinned to go1.12
Switched the version to 1.20
* Update prometheus-varnish-exporter to not depend on go1.12
* Update lnd to build with go1.12
Updated the version
Forced only building subpackages with main to prevent panics over
multiple modules in one repo
* Remove go1.12 from openshift
Had to update the version to 4.1.0 and do a bit of munging to get this
to work
* Remove go1.12 completely.
These are no longer needed.
* Update bazel-watcher and make it build with go 1.14
Until recently, libusb-compat propagated libusb1 and many packages unknowingly used it to obtain libusb1.
When https://github.com/NixOS/nixpkgs/pull/82944 removed this evil propagation, it broke many packages with such incorrect assumption.
This patch trades the breakage of packages wanting libusb1 caused by the PR for a hopefully less common breakage of the packages relying on the compat library.
Context: discussion in https://github.com/NixOS/nixpkgs/pull/82630
Mesa has been supporting S3TC natively without requiring these libraries
since the S3TC patent expired in December 2017.
This is based on previous work for switching between BLAS and LAPACK
implementation in Debian[1] and Gentoo[2]. The goal is to have one way
to depend on the BLAS/LAPACK libraries that all packages must use. The
attrs “blas” and “lapack” are used to represent a wrapped BLAS/LAPACK
provider. Derivations that don’t care how BLAS and LAPACK are
implemented can just use blas and lapack directly. If you do care what
you get (perhaps for some CPP), you should verify that blas and lapack
match what you expect with an assertion.
The “blas” package collides with the old “blas” reference
implementation. This has been renamed to “blas-reference”. In
addition, “lapack-reference” is also included, corresponding to
“liblapack” from Netlib.org.
Currently, there are 3 providers of the BLAS and LAPACK interfaces:
- lapack-reference: the BLAS/LAPACK implementation maintained by netlib.org
- OpenBLAS: an optimized version of BLAS and LAPACK
- MKL: Intel’s unfree but highly optimized BLAS/LAPACK implementation
By default, the above implementations all use the “LP64” BLAS and
LAPACK ABI. This corresponds to “openblasCompat” and is the safest way
to use BLAS/LAPACK. You may received some benefits from “ILP64” or
8-byte integer BLAS at the expense of breaking compatibility with some
packages.
This can be switched at build time with an override like:
import <nixpkgs> {
config.allowUnfree = true;
overlays = [(self: super: {
lapack = super.lapack.override {
lapackProvider = super.lapack-reference;
};
blas = super.blas.override {
blasProvider = super.lapack-reference;
};
})];
}
or, switched at runtime via LD_LIBRARY_PATH like:
$ LD_LIBRARY_PATH=$(nix-build -E '(with import <nixpkgs> {}).lapack.override { lapackProvider = pkgs.mkl; is64bit = true; })')/lib:$(nix-build -E '(with import <nixpkgs> {}).blas.override { blasProvider = pkgs.mkl; is64bit = true; })')/lib ./your-blas-linked-binary
By default, we use OpenBLAS LP64 also known in Nixpkgs as
openblasCompat.
[1]: https://wiki.debian.org/DebianScience/LinearAlgebraLibraries
[2]: https://wiki.gentoo.org/wiki/Blas-lapack-switch
This is an updated version of the former upstream,
https://github.com/AndroidHardeningArchive/linux-hardened, and provides
a minimal set of additional hardening patches on top of upstream.
The patch already incorporates many of our hardened profile defaults,
and releases are timely (Linux 5.5.15 and 5.6.2 were released on
2020-04-02; linux-hardened patches for them came out on 2020-04-03 and
2020-04-04 respectively).
