This allows customizing the nixpkgs arguments by the caller. My use case
is creating a personal nixpkgs channel containing some unfree packages.
The default is still to not build unfree packages, so for nixpkgs this
is no functional change.
This commit removes all references to emacs24 with the exception of
emacs24-macports. The two folders in `pkgs/applications/editors` named
`emacs-24` and `emacs-24` are consolidated to a new `emacs` folder.
Various parts in nixpkgs also referenced `emacs24Packages` (pinned to
`emacs24`) explicitly where `emacsPackages` (non-pinned) is more
appropriate. These references get fixed by this commit too.
not part of nixpkgs/nixos jobsets in 16.03+ since ccd1029f58. Until
it gets added again, adding some python packages that take really
long to build.
(cherry picked from commit 713c240563)
From now on, only the testing branch of grsecurity will be supported.
Additionally, use only patches from upstream.
It's impossible to provide meaningful support for grsecurity stable.
First, because building and testing \(m \times n \times z) [1], packages
is infeasible. Second, because stable patches are only available from
upstream for-pay, making us reliant on third-parties for patches. In
addition to creating yet more work for the maintainers, using stable
patches provided by a third-party goes against the wishes of upstream.
nixpkgs provides the tools necessary to build grsecurity kernels for any
version the user chooses, however, provided they pay for, or otherwise
acquire, the patch themselves.
Eventually, we'll want to remove the now obsolete top-level attributes,
but leave them in for now to smoothe migration (they have been removed
from top-level/release.nix, though, because it makes no sense to have
them there).
[1]: where \(m\) is the number of grsecurity flavors, \(n\) is the
number of kernel versions, and z is the size of the `linuxPackages` set
This cuts nixpkgs:trunk from 78K to 31K jobs by disabling builds of
{node,go,python,emacs,coq,r,ocaml,perl}Packages. Thus these are now
only built if they are dependencies of top-level packages (such as
end-user applications). I left haskellPackages because they take
typically longer to build than the others (which are mostly
interpreted languages), so disabling them would be more painful to
users.
This is a temporary measure until we have a binary cache based Hydra
running on faster hardware, necessitated by the fact that evaluations
now regularly time out after 6 hours.
The R people don't bother providing stable URLs for their package
releases. Released versions are edited or flat-out disappear at will,
which causes us a bit of trouble, like in [1]. Hopefully, enabling R
builds on Hydra will mitigate those problems by caching the release
tarballs.
[1] https://github.com/NixOS/nixpkgs/issues/11230
