Remove ancient CUDA toolkits (and corresponding CuDNN versions):
- Not supported by upstream anymore.
- We do not use them in nixpkgs.
- We do not test or actively maintain them.
- Anything but ancient GPUs is supported by newer toolkits.
The NixOS 21.03 release has been delayed to 21.05. See NixOS/rfcs#80.
There are two instances of 21.03 which have been left as is, since they
are in stateVersion comparisons. This will ensure that existing user
configurations which refer to 21.03 will continue to work.
The attribute was initially renamed in ef403beb this way due to
incompatibilities between versions 0.4.x and 0.5.x back in 2010.
Additionally it hinders intuitive discovery of the package, because the
versioned package name is nothing a user would guess.
As we are moving to 0.6.0 this makes little sense anymore.
Related issue #108606.
Nowadays we have multiple outdated versions of Flutter in nixpkgs.
Instead, let's focus in having in having stable versions of Flutter
working.
Users needing to use beta or dev versions of Flutter can use mkFlutter
function, that still exists.
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
The comment at the top of git-and-tools/default.nix said:
/* All git-relates tools live here, in a separate attribute set so that users
* can get a fast overview over what's available.
but unfortunately that hasn't actually held up in practice.
Git-related packages have continued to be added to the top level, or
into gitAndTools, or sometimes both, basically at random, so having
gitAndTools is just confusing. In fact, until I looked as part of
working on getting rid of gitAndTools, one program (ydiff) was
packaged twice independently, once in gitAndTools and once at the top
level (I fixed this in 98c3490196).
So I think it's for the best if we move away from gitAndTools, and
just put all the packages it previously contained at the top level.
I've implemented this here by just making gitAndTools an alias for the
top level -- this saves having loads of lines in aliases.nix. This
means that people can keep referring to gitAndTools in their
configuration, but it won't be allowed to be used within Nixpkgs, and
it won't be presented to new users by e.g. nix search.
The only other change here that I'm aware of is that
appendToName "minimal" is not longer called on the default git
package, because doing that would have necessitated having a private
gitBase variable like before. I think it makes more sense not to do
that anyway, and reserve the "minimal" suffix only for gitMinimal.
This makes it much easier to create customisations around emacs via
the a new convenience passthru attr:
- `emacs.pkgs`: What used to be emacsPackages is now `emacs.pkgs`
The previous versioned names `emacs*Packages` have been moved to
aliases.nix and are now considered deprecated in favour of `emacs*.pkgs`.
Updates calibre version to 5.9.0 by pinning the Python version to 3.
Calibre upgraded to Python 3 since the 5.0 release.
Adds aliases for removed packages.
Fixes#106256.
For in NixOS it is beneficial if both plasma5 and pam use the same Qt5
version. Because the plasma5 desktop may use a different version as the
default Qt5 version, we introduce plasma5Packages.
Starting from Linx 5.6, there is partial upstream support for the Multipath TCP
protocol. There are no downsides to enabling it afaict, since
applications need to opt-in when creating a socket.
From https://github.com/multipath-tcp/mptcp_net-next/wiki:
"[...] users of regular TCP continue to get the same type of connection and
performance unless MPTCP is requested."
These packages were duplicated, and often weren't being updated in sync.
The only difference between them was the lack of pkg-config in
libraspberrypi, which is easily fixable.
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.
