LICENSE.txt sha256 is wrong. After version bumping from 1.13.3 to 1.15.1
LICENSE.txt sha256 has not be re-calculated.
New LICENSE.txt lists licenses for bundled libraries:
- Numpydoc -> 2-clause BSD
- scipy-sphinx-theme -> 3-clause BSD, PSF and Apache 2.0
- lapack-lite -> 3-clause BSD
- tempita -> BSD derived
- dragon4 -> specific to library, need to refer to dragon4.c file
Update sha256 recalculating it locally.
Fixes:
http://autobuild.buildroot.net/results/08e/08e1121af151c65b2333e06839256eb13f4ad800//http://autobuild.buildroot.net/results/9d0/9d0e557c5946b76aa4c8c87b7616433c16b61e20//
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Building python-numpy on ARC HS with glibc fails due to missing FE_*
definitions in <fenv.h>. Therefore, python-numpy is only available on
ARC HS with a C library other than glibc.
Fixes:
http://autobuild.buildroot.net/results/6b9a3310bb4f8c1fd7db0ef4476458b3eec2bf2e/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This package fails when building for ARCompact due to toolchain issue.
Marking this with special comment "#ARC toolchain issues for
ARCompact" as the package is to be enabled as soon as the issue with
the ARC toolchain is resolved.
Fixes:
http://autobuild.buildroot.net/results/4c4eaa90335756448007ae3c5ae3839fb17d4442/
Signed-off-by: Evgeniy Didin <didin@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: arc-buildroot@synopsys.com
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Current BR2_PACKAGE_PYTHON_NUMPY_ARCH_SUPPORTS variable layout going
to be inconvenient and ugly for adding new architectures or
restricting specific architectures. Lets reformat layout of this
variable.
Signed-off-by: Evgeniy Didin <didin@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: arc-buildroot@synopsys.com
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This enables support for ARC cores in numpy.
Cherry-picked from
8edd610ffa
Hopefully becomes a part of the next major release (like 1.14).
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This is just a bug-fix release.
Removing 0003-BUG-Ensure-_npy_scaled_cexp-f-l-is-defined-when-need.patch
as it is a part of the release.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
With update of Numpy to the latest version we've got one change which
breaks Numpy compilcation in some cases.
This change back-ports upstream fix from:
https://github.com/numpy/numpy/pull/9740
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Cc: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Note previously used location for releases on SourceForge is no longer
supported (latest tarball v1.11.2 available there is dated 2016-10-04)
so as other distros
(see, Fedora http://pkgs.fedoraproject.org/cgit/rpms/numpy.git/tree/numpy.spec?id=7013948f8ba073c69a91a545f0a0898cb62652fa#n22)
we get release tarball directly from GitHub.
Also note 0001-no-fenv-on-uclibc.patch was rebased on v1.13.1.
0002-Don-t-blindly-enable-frexpl-and-ldexpl-for-uClibc.patch is no
longer needed. Since https://github.com/numpy/numpy/pull/4852, there
is a wrapper for frexpl and ldexpl like for the other math functions.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Cc: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Arnout: improve explanation of 0002-Don-t-blindly-enable-frexpl-and-ldexpl-for-uClibc.patch]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
We want to use SPDX identifier for license string as much as possible.
SPDX short identifier for BSD-3c is BSD-3-Clause.
This change is done using following command.
find . -name "*.mk" | xargs sed -ri '/LICENSE( )?[\+:]?=/s/BSD-3c/BSD-3-Clause/g'
Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some packages selects python-numpy. This package has a some CPU specific
code. To simplify and avoid duplicate dependencies this patch introduce an
hidden ARCH_SUPPORTS variable.
[Thomas: fix the definition of the new option to make sure its value
is actually 'y' when a supported architecture is used.]
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It turns out that uClibc only enables the long double math functions
for some architectures (god know why, so what if long double is the
same as double, these functions should still be defined). Since
python-numpy links with those functions, the module will fail to load
on ARM, MIPS and SH.
However, python-numpy actually checks for each function if it is really
available. Only, it overrides that check for ldexpl and frexpl when
long double is the same as double (i.e. in exactly the case the uClibc
doesn't have these functions).
So add another exception for this.
Upstream-status: not applicable (code has changed too much)
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit b0f025386f a patch was added
to make sure that python-numpy does work in uClibc. This patch was
needed for the x86 architecture, because uClibc in fact does support
fenv for x86. However, we don't turn on this support in our uClibc
config. Because the Config.in depends still allowed uClibc for x86,
this lead to a built failure, which lead to the fix in commit b0f02538.
But since this fix also fixes it for all other (supported)
architectures, we can just remove the !uClibc dependency completely.
This is also propagated to the reverse dependency in opencv3.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Autogenerated from rename-patch.py (http://patchwork.ozlabs.org/patch/403345)
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since SourceForge sometimes serves us faulty tarballs, we can tons of
autobuild failures:
http://autobuild.buildroot.org/results/9fb/9fba5bf086a4e7a29e5f7156ec43847db7aacfc4/http://autobuild.buildroot.org/results/6c8/6c837b244c45ac3b3a887734a371cd6d226cf216/
...
Fix that by adding hash files for all SourceForge-hosted packages (thos
etht did not already have it).
We normally prefer to use hashes published by upstream, but hunting them
all one by one is a tedious task, so those hashes were all locally
computed with a script that searched for SF-hosted packages, downloades
the associated tarball, computed the hash, and stored it in the
corresponding .hash file.
Also, SF publishes sha1 hashes, while I used the stronger sha256, since
sha1 is now considered to be relatively weak.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Richard Braun <rbraun@sceen.net>
Cc: Nathaniel Roach <nroach44@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To be consistent with the recent change of FOO_MAKE_OPT into FOO_MAKE_OPTS,
make the same change for FOO_BUILD_OPT.
Sed command used:
find * -type f | xargs sed -i 's#_BUILD_OPT\>#&S#g'
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The numpy/core/include/numpy/npy_cpu.h file has some
architecture-specific definitions, and not all architectures are
supported. This commit makes sure python-numpy cannot be selected on
the architectures that are not supported.
Fixes:
http://autobuild.buildroot.org/results/327/327c85f5b1849d390fcf0727cf48e621b946571f/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
python-numpy can be linked with libblas and liblapack, so
automatically do it when clapack is enabled.
[Thomas:
- Fix issues in the original submission and reformat according to
Yann E. Morin suggestions.
- Properly format the "libraries" entry in site.cfg as outlined in
the example site.cfg file: the list of libraries should be
space-separated.]
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch add NumPy package for python.
Since Fortran support has been deprecated in Buildroot since the 2013.11
release, and because most of the external toolchains do not provide a
Fortran compiler, it is necessary to explicity disable Fortran compiler
to avoid catching the one from the host system if any.
We also need to fill a site.cfg file to tell NumPy build-system where
it should looking for BLAS and LAPACK libraries.
Some packages may include headers provided by python-numpy package, so
python-numpy is installed to the staging directory.
[Thomas:
- add dependency in Config.in to take into account fenv.h
requirement, suggested by Yann E. Morin.
- modified to use the staging installation logic in the python
package infrastructure.]
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
