In opencv 2.x, unfree libraries are built by default. The package
should therefore have been marked as unfree, but wasn't.
I've disabled the non-free libraries by default, and added an option
to enable them. There are three programs in Nixpkgs that depend on
opencv2: mathematica, pfstools, and p2pvc. pfstools requires the
non-free libraries if it's built with opencv support, so I've disabled
opencv by default there and added an option to enable it. p2pvc links
fine, so presumably doesn't need the non-free libraries. I can't test
mathematica, so I'm just going to leave it alone.
- Updated to 4.5.2
- Removed glog from buildInputs because of this error on python-opencv:
```
python -c "import cv2"
/nix/store/slfzk1gk74nfx3ky2vpdf9nb7b8nvdf2-opencv-4.5.2/lib/libopencv_sfm.so.4.5: error: symbol lookup error: undefined symbol: _ZN6google21kLogSiteUninitializedE (fatal)
```
- Enabled ffmpeg and gstreamer to open more video formats
- nixpkg-fmt
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.
It updates the repository URL to opencv/opencv. opencv2, p2pvc and
pfstools are built without errors but not really tested.
Signed-off-by: Masanori Ogino <167209+omasanori@users.noreply.github.com>
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>
After making `ffmpeg` point to the latest `ffmpeg_4`, all packages that
used `ffmpeg` without requiring a specific version now use ffmpeg_3
explicitly so they shouldn't change.
This makes packages use lapack and blas, which can wrap different
BLAS/LAPACK implementations.
treewide: cleanup from blas/lapack changes
A few issues in the original treewide:
- can’t assume blas64 is a bool
- unused commented code
resolving CVE-2019-14491, CVE-2019-14492 & CVE-2019-15939
most internal downloads are unchanged except for "ade" which was bumped
from v0.1.1d to v0.1.1f between these releases
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299