* ghcHEAD: bump to 8.11.20200403
* ghcHead: reduce diff vs. 8.10.1
dontAddExtraLibs was removed by accident (IMO) in ea19a8ed1e
* ghcHEAD: add ability to use system libffi
- enable nixpkgs' libffi
- minimise diffs against 8.10.1
- remove patching
* remove configure warning about --with-curses-includes
configure: WARNING: unrecognized options: --with-curses-includes
This provides a means to build a PHP package based on a list of
extensions from another.
For example, to generate a package with all default extensions
enabled, except opcache, but with ImageMagick:
php.withExtensions (e:
(lib.filter (e: e != php.extensions.opcache) php.enabledExtensions)
++ [ e.imagick ])
So now we have only packages for human interaction in php.packages and
only extensions in php.extensions. With this php.packages.exts have
been merged into the same attribute set as all the other extensions to
make it flat and nice.
The nextcloud module have been updated to reflect this change as well
as the documentation.
- Use git.Repo(ROOT, search_parent_directories=True) to find nixpkgs
repo.
- Don't commit overrides.nix.
- Remove "-a" short argument.
- Remove "--commit" flag and commit by default.
- Improve help/error messages.
- Favor closure pattern over classes.Use a closure to wrap the update
function with state rather than a callable class.
- break NixpkgsRepo class into functions
- Optional None-type arguments
- Remove repo checks from update.py. Git is too flexible and permits too
many workflows for my attempt to replace documentation with code to work.
My goal would be to separate the `--add` functionality from the update
functionality in the near term and then there will be no reason for this
usage to create commits anyway.
This reverts commit 5e8545e723.
It breaks eval:
attribute 'rev' missing, at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-0-gleber.ewr1.nix.ci/pkgs/top-level/make-tarball.nix:106:39
I din't try to pinpoint the exact commit, but we started getting:
> The extension smart is not supported for docbook
Reading pandoc docs, I can't see what use to us "smart" could be
when writing the in-between docbook (to be converted to html).
https://pandoc.org/MANUAL.html#extension-smart
Previously, we would asssert that the lockfiles are consistent during the
unpackPhase, but if the pkg has a patch for the lockfile itself then we must
wait until the patchPhase is complete to check.
This also removes an implicity dependency on the src attribute coming from
`fetchzip` / `fetchFromGitHub`, which happens to name the source directory
"source". Now we glob for it, so different fetchers will work consistently.
