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).
The v7 series is very different.
This commit introduces the 3 packages: fahclient, fahcontrol and
fahviewer. It also rebuilds the NixOS module to map better with the new
client.
* source-han-sans: 1.004R -> 2.001
* source-han-serif: switch to Super OTC
* source-han-mono: init at 1.002
The Source Han fonts now use shared package infrastructure, and the
Super OTC distributions, which unify the various scripts into a single
bundle file, improving automatic font selection and reducing overall
disk space usage. This also means that the Traditional
Chinese—Hong Kong language variant is now included.
The old package names including language are aliased to the Super OTC
bundle packages.
According to https://endoflife.software/programming-languages/server-side-scripting/ruby
ruby 2.4 will go end-of-life in march, where the new release of nixpkgs
will be cut. We won't be able to support it for security updates.
Remove all references to ruby_2_4 and add ruby_2_7 instead where
missing.
Mark packages that depend on ruby 2.4 as broken:
* chefdk
* sonic-pi
Package is marked as broken for >2 years and used a fairly old
snapshot from the gcc7-branch, so I fairly doubt that this is
somewhere used (and is also pretty misleading as you don't expect a
random snapshot from gcc7 at `pkgs.gcc-snapshot`).
There are no new releases of sqldeveloper v17/v18 and I don't think that
we should keep obviously unmaintained software that interacts with
database systems.
I removed `sqldeveloper_18` and `pkgs.sqldeveloper` now points to
version 19.4. Unfortunately I had to drop darwin support as JavaFX is
required for 19.4 which is part of the `oraclejdk` which isn't packaged
for darwin yet.
For further information please refer to the release notes:
https://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/sqldev-relnotes-194-5908846.html
See u-boot@8fa7f65dd02c176ee6021eaf40114560b8954ba2
> configs: Remove am335x_boneblack_defconfig
>
> The am335x_evm_defconfig supports all am335x_boneblack variants. Remove
> the redundant am335x_boneblack_defconfig.
On numerous occasions I have seen users mistake this
module as libinput because it being called "multitouch"
and them being unaware that the actually module they want
is libinput. They then run into several decrepit bugs due
to the completely out-of-date nature of the underlying package.
The underlying package hasn't been changed to an up-to-date
fork in a period of 8 years. I don't consider this to be production quality.
However, I'm not opposed for the module being readded to NixOS
with new packaging, and a better name.
These are all based on firefox versions with known vulnerabilities
exploited in the wild.
We seriously shouldn't ship this in nixpkgs, especially not for
sensitive applications as the Tor Browser.
`tor-browser-bundle` is just a wrapper around
`firefoxPackages.tor-browser`, so let's remove it too.
`tor-browser-bundle-bin` is the much safer bet, which is individually
downloaded from `dist.torproject.org` and just `patchelf`-ed locally to
work on NixOS.
Co-Authored-By: Alyssa Ross <hi@alyssa.is>
Co-Authored-By: Andreas Rammhold <andreas@rammhold.de>
Co-Authored-By: Graham Christensen <graham@grahamc.com>
make unstable use kicad-libraries
still using a link in $out..., not sure that's a bad thing
this allows setting that path in makeWrapperArgs
can't use $out there
kicad-with-packages3d -> kicad and kicad-small
default to OCCT, OCE is outdated
enforce OCCT on aarch64, where OCE is broken
withOCE flag allows using OCE on non-aarch64
People have only been using this for the spell-entry widget, i.e even
hexchat just has the code vendored and are maintaining it themselves.
There is a continuation that could be packaged if anyone needs it
* https://github.com/TingPing/libsexy3
but currently no package within nixpkgs has a use for this.
This package actually uses the old abandoned code base.
However the code base has been revieved by new maintainers
* https://github.com/projecthamster/
if there is a request for it could be re-added to nixpkgs.
Samba 3 has been discontinued since Q1/2015. So I think it's time
to just wipe it from the pkgs. FuseSMB is pretty much abandoned,
upstream does not exist and it's also not as useful as it used to
be anyways.
osquery was marked as broken since April.
If somebody steps up to fix it, we can always revive it from the
histroy, but there's not much value in shipping completely broken things
in current master.
cc @ma27
Required to build with Phonon 4.11 (https://github.com/NixOS/nixpkgs/pull/71745).
Requires qttools for Qt5LinguistTools.
Qt4 support removed since Phonon no longer supports it either.
Co-authored-by: worldofpeace <worldofpeace@protonmail.ch>
Required to build with Phonon 4.11 (https://github.com/NixOS/nixpkgs/pull/71745). Not having this blocks the channels.
Requires qttools for Qt5LinguistTools.
Qt4 support removed since Phonon no longer supports it either.
Co-authored-by: worldofpeace <worldofpeace@protonmail.ch>
All code that was at xfce4-14 has been moved to xfce/*.
Old expressions that aren't rewritten might be abandoned or broken.
Additonally I've ported the xfce4-14 thunar expression to support
thunarPlugins. We can now support this interface in the Xfce module
again, although I'm not sure if we have any plugins packaged that support
latest thunar.
The SLIM project is abandoned and their last release was in 2013.
Because of this it poses a security risk to systems, no one is working
on it or picked up maintenance. It also lacks compatibility with systemd
and logind sessions. For users, there liikely isn't anything like slim
that's as lightweight in terms of dependencies.
There are no longer separate programs called SDLMAME or SDLMESS. Instead, the SDL capability is included in MAME and MESS, and the makefile will auto-detect if you are on a non-Windows system and run accordingly.
