Compilation aborts at: usr/lib64/python3.6/site-packages/numpy/distutils/system_info.py:1510: UserWarning: Atlas (http://math-atlas.sourceforge.net/) libraries not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [atlas]) or by setting the ATLAS environment variable. warnings.warn(AtlasNotFoundError.__doc__) Running from scipy source directory. /usr/lib64/python3.6/site-packages/numpy/distutils/system_info.py:620: UserWarning: Specified path /usr/lib64/python3.6/site-packages/numpy/__init__.py/include/python3.6m is invalid. warnings.warn('Specified path %s is invalid.' % d) /usr/lib64/python3.6/site-packages/numpy/distutils/system_info.py:1608: UserWarning: Atlas (http://math-atlas.sourceforge.net/) libraries not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [atlas]) or by setting the ATLAS environment variable. warnings.warn(AtlasNotFoundError.__doc__) "object of type 'type' has no len()" in evaluating 'len(list)' (available names: []) "object of type 'type' has no len()" in evaluating 'len(list)' (available names: []) "object of type 'type' has no len()" in evaluating 'len(list)' (available names: []) "object of type 'type' has no len()" in evaluating 'len(list)' (available names: []) "object of type 'type' has no len()" in evaluating 'len(list)' (available names: []) "object of type 'type' has no len()" in evaluating 'len(list)' (available names: []) error: Command "/usr/bin/gfortran -Wall -g -Wl,-O1 -shared /var/tmp/portage/sci-libs/scipy-0.18.1/work/scipy-0.18.1-python3_6/build/temp.linux-x86_64-3.6/var/tmp/portage/sci-libs/scipy-0.18.1/work/scipy-0.18.1-python3_6/build/src.linux-x86_64-3.6/scipy/fftpack/_fftpackmodule.o /var/tmp/portage/sci-libs/scipy-0.18.1/work/scipy-0.18.1-python3_6/build/temp.linux-x86_64-3.6/scipy/fftpack/src/zfft.o /var/tmp/portage/sci-libs/scipy-0.18.1/work/scipy-0.18.1-python3_6/build/temp.linux-x86_64-3.6/scipy/fftpack/src/drfft.o /var/tmp/portage/sci-libs/scipy-0.18.1/work/scipy-0.18.1-python3_6/build/temp.linux-x86_64-3.6/scipy/fftpack/src/zrfft.o /var/tmp/portage/sci-libs/scipy-0.18.1/work/scipy-0.18.1-python3_6/build/temp.linux-x86_64-3.6/scipy/fftpack/src/zfftnd.o /var/tmp/portage/sci-libs/scipy-0.18.1/work/scipy-0.18.1-python3_6/build/temp.linux-x86_64-3.6/var/tmp/portage/sci-libs/scipy-0.18.1/work/scipy-0.18.1-python3_6/build/src.linux-x86_64-3.6/scipy/fftpack/src/dct.o /var/tmp/portage/sci-libs/scipy-0.18.1/work/scipy-0.18.1-python3_6/build/temp.linux-x86_64-3.6/var/tmp/portage/sci-libs/scipy-0.18.1/work/scipy-0.18.1-python3_6/build/src.linux-x86_64-3.6/scipy/fftpack/src/dst.o /var/tmp/portage/sci-libs/scipy-0.18.1/work/scipy-0.18.1-python3_6/build/temp.linux-x86_64-3.6/var/tmp/portage/sci-libs/scipy-0.18.1/work/scipy-0.18.1-python3_6/build/src.linux-x86_64-3.6/fortranobject.o -L/usr/lib64 -L/var/tmp/portage/sci-libs/scipy-0.18.1/work/scipy-0.18.1-python3_6/build/temp.linux-x86_64-3.6 -ldfftpack -lfftpack -lpython3.6m -lgfortran -o /var/tmp/portage/sci-libs/scipy-0.18.1/work/scipy-0.18.1-python3_6/build/lib/scipy/fftpack/_fftpack.cpython-36m-x86_64-linux-gnu.so" failed with exit status 1
Created attachment 468914 [details] emerge --info output
This seems caused for not having python-3.5, in other box with python-3.5 and python3.6 installed scipy merges correctly. May be I should close the report!
Got hit. I don't think having to install python 3.5 for scipy to install is an acceptable solution. It is certainly not sustainable when you consider that one day 3.5 will be removed from the tree. We better have a better solution by then for 3.6 and potentially later versions of python.
The message about atlas is standard and has nothing todo with the build failure. I see it myself using atlas on all supported python ABIs and it works fine. Could you please add a full build.log?
You emerge info doesn't show you have the science overlay installed. How do you use atlas?
Created attachment 473460 [details] full build log
I have attached a full log. I use the science overlay, the use of openblas should be a give away. I have just enabled python 3.6 and was proceeding to rebuild everything python related.
I cannot see the actual error which gfortran throws. it just errors. Any chance you can run the command by hand and see more?
(In reply to Justin Lecher from comment #8) > I cannot see the actual error which gfortran throws. it just errors. Any > chance you can run the command by hand and see more? Actually thought of that, and the command did not fail. I have restarted building to see if there was actually a file produced when run from inside portage. Waiting for the result.
OK so just after the ebuild failure, if I inspect the folder where the file should have been produced. It is not present, but If I execute the command manually, it doesn't fail and the file is produced in the right place. Is there some parallelism in the build with python 3.6. I seem to remember something about scipy introducing some parallel building. In that case we may have a race condition.
Could you try some serial build?
Started, may take some time... I will let you know the result ASAP.
Success with `MAKEOPTS=-j1`! We do have a race condition.
I can reproduce the full error. Failed to rebuild scipy-0.18.1 multiple times with only python2_7 and python3_6. Previous builds where python3_5 was enabled as well passed. After a (lengthly) serial build a can confirm that it does not occur with MAKEOPTS="-j1". Environment is almost identically to Andrés. Using openblas from the science overlay as blas/cblas provider in combination with the reference lapack.
Still present in 0.19.1.
*** Bug 631298 has been marked as a duplicate of this bug. ***
What is the version of your dev-python/numpy?
I can trigger it using numpy-1.13.1, trying to build scipy-0.19.1 (vs. openblas-0.2.19, if thats interesting).
The problem is independent of blas. python 3.6 (and may be 3.5) are able to do parallel builds and an object is not compiled in time. I don't know how python3 does manage target dependencies but obviously there is something broken upstream here.
even with MAKEOPTS=-j1, the error is still the same. The only difference with the bug report here maybe I use gcc 7.2.
OK, that's weird because the cause of the problem is definitely an object not being compiled yet that is being used in a linking command. Could you post the full python3 build log?
Anyone forwarded it upstream?
*** Bug 634858 has been marked as a duplicate of this bug. ***
Spack has hard-coded it to be a serial build https://github.com/spack/spack/pull/3275/commits/607520e938aa5268dfbdbb52b95a93630af333cc
I added a comment upstream. I may have a deeper look but no promises.
Just repeating some observations I made upstream. numpy's distutils can compile C/C++ code in parallel but not fortran code. This is rather explicit in their distutils. All three instances (reported by spack and at least two the reports here) are when gfortran is used for linking. This particular report is about a case where the source is mixed fortran/C so you could expect troubles. The other two are pure fortran. In all case it appears some parallel processing is done in a context it shouldn't and the problem is more likely to be in numpy or some subtle way the sources are prepared.
(In reply to François Bissey from comment #26) > > In all case it appears some parallel processing is done in a context it > shouldn't and the problem is more likely to be in numpy or some subtle way > the sources are prepared. The problem is very likely to be in numpy. Although I forgot about the details, my package.env says: # Fatal Python error: Couldn't create autoTLSkey mapping dev-python/numpy one-make.conf one-make.conf contains MAKEOPTS="-j1" it was re-added by me at least 3 times in the past 5+ years.
Just re-reading numpy distutils. I believe they must parallelize fortran and c source because of the way fortran is implemented. Only explicit f90 sources are serialized.
I was hoping that something like --- /usr/lib64/python2.7/site-packages/numpy/distutils/ccompiler.py 2017-09-29 13:31:46.000000000 +1300 +++ /usr/lib64/python3.6/site-packages/numpy/distutils/ccompiler.py 2017-11-20 20:02:36.411464265 +1300 @@ -337,6 +337,7 @@ pool = multiprocessing.pool.ThreadPool(jobs) pool.map(single_compile, build_items) pool.close() + pool.join() else: # build serial for o in build_items: would be sufficient but it appears not. Strangely enough it move the error to another file I hadn't seen before error: Command "/usr/bin/gfortran -Wall -g -Wl,-O1 -Wl,--as-needed -shared /dev/shm/portage/sci-libs/scipy-0.19.1/work/scipy-0.19.1-python3_6/build/temp.linux-x86_64-3.6/dev/shm/portage/sci-libs/scipy-0.19.1/work/scipy-0.19.1-python3_6/build/src.linux-x86_64-3.6/scipy/integrate/_test_odeint_bandedmodule.o /dev/shm/portage/sci-libs/scipy-0.19.1/work/scipy-0.19.1-python3_6/build/temp.linux-x86_64-3.6/dev/shm/portage/sci-libs/scipy-0.19.1/work/scipy-0.19.1-python3_6/build/src.linux-x86_64-3.6/scipy/integrate/fortranobject.o /dev/shm/portage/sci-libs/scipy-0.19.1/work/scipy-0.19.1-python3_6/build/temp.linux-x86_64-3.6/scipy/integrate/tests/banded5x5.o /dev/shm/portage/sci-libs/scipy-0.19.1/work/scipy-0.19.1-python3_6/build/temp.linux-x86_64-3.6/dev/shm/portage/sci-libs/scipy-0.19.1/work/scipy-0.19.1-python3_6/build/src.linux-x86_64-3.6/scipy/integrate/_test_odeint_banded-f2pywrappers.o -L/usr/lib64 -L/usr/lib64 -L/dev/shm/portage/sci-libs/scipy-0.19.1/work/scipy-0.19.1-python3_6/build/temp.linux-x86_64-3.6 -lodepack -lmach -lopenblas_threads -lreflapack -lopenblas_threads -lpython3.6m -lgfortran -o /dev/shm/portage/sci-libs/scipy-0.19.1/work/scipy-0.19.1-python3_6/build/lib/scipy/integrate/_test_odeint_banded.cpython-36m-x86_64-linux-gnu.so" failed with exit status 1 One of the problem here is that we deal with a undocumented python process http://lucasb.eyer.be/snips/python-thread-pool.html and there may be a bug in its behavior or possibly some functionality missing for .join() to work.
The point of failure seems random. I can repeat the build and have it break at a different file. I have patched numpy's distutils to enforce serialization and I can still get a failed build. In all cases the actual error, when you search for it higher up than the last message about the failed compilation, is of the kind (file will vary): /dev/shm/portage/sci-libs/scipy-0.19.1/work/scipy-0.19.1-python3_6/build/temp.linux-x86_64-3.6/scipy/special/cdf_wrappers.o: file not recognized: File truncated collect2: error: ld returned 1 exit status /dev/shm/portage/sci-libs/scipy-0.19.1/work/scipy-0.19.1-python3_6/build/temp.linux-x86_64-3.6/scipy/special/cdf_wrappers.o: file not recognized: File truncated collect2: error: ld returned 1 exit status Which is indicative of an unfinished compilation. The fact that you still get a failure when you disable the threading of the build from numpy's distutils means that it is probably the wrong place to search.
I think what we are hitting at is that https://github.com/numpy/numpy/issues/7139 is not really fixed.
Correct that. The fact that when you disable threading from numpy, you still get problems means that the issue is in python-3.5+ distutils which enables parallel building. I don't think it is a numpy problem anymore this is a python problem. Interestingly passing "-j1 --parallel $(makeopts_jobs)" - that is disabled parallelism from python's distutils while enabling the one from numpy still leads to failures. So neither implementations seem to be good enough to deal with scipy.
And I think all I have done needs re-doing. I have been testing with python3.6 but the ebuild doesn't know how to deal with python3.6. Only 3.5. distutils-r1_python_compile \ $(usex python_targets_python3_5 "" "-j $(makeopts_jobs)") \ ${SCIPY_FCONFIG} So parallelism must have taken default values from the number of cores.
Unrelated but this is a QA problem. The logic enabling parallel building is not sound. If python3.5 is enabled in PYTHON_TARGETS, the builds of all the python versions will receive the "-j $(makeopts_jobs)", including python2.7 and 3.4 if they are enabled. On the other hand if python3.5 is disabled in PYTHON_TARGETS no builds should receive the option, including python3.6. Which may explain why there are reports of failed build when MAKEOPTS=-j1. It may join the random pool. I have just been incredibly lucky. Things are still random when adjusted for python 3.6 so my conclusion on brokenness seem to still stand.
This would be much better for selecting parallel building --- /usr/portage/sci-libs/scipy/scipy-0.19.1.ebuild 2017-07-05 05:43:02.000000000 +1200 +++ scipy-0.19.1.ebuild 2017-11-23 17:24:52.840105829 +1300 @@ -102,9 +102,16 @@ } python_compile() { + is_python_35_plus(){ + [[ ${EPYTHON} == python3.[^0-4] ]] + } + local parallel_build="" + if is_python_35_plus ; then + parallel_build="-j $(makeopts_jobs)" + fi ${EPYTHON} tools/cythonize.py || die distutils-r1_python_compile \ - $(usex python_targets_python3_5 "" "-j $(makeopts_jobs)") \ + ${parallel_build} \ ${SCIPY_FCONFIG} }
I don't think we can fix this. This is a problem from python3.5 onward. numpy bravely tried to fix their own distutils to behave with python3.5+'s one, but I don't think they succeeded. So to add salt to the injury. numpy's distutils parallelism is supposed to work with any python including python2.7 and 3.4. And it does for those versions of python. Which means passing "--parallel $(makeopts_jobs)" works for those versions of python but for 3.5 and 3.6 the best thing is to pass nothing at this stage.
I just ran into this problem myself. Is will hardcoding MAKEOPTS=-j1 disable both python and numpy parallelization? And if so, will doing so guarantee a successful build? IMO if so it should either just be hardcoded in the ebuild or added as a gentoo patch. Going to try with a user patch now.
Just removing the bit "-j $(makeopts_jobs)" altogether is the better solution. Although I'll admit to use the following in a private overlay python_compile() { is_python_34_under(){ [[ ${EPYTHON} == python3.[0-4] || ${EPYTHON} == python2.7 ]] } local parallel_build="" if is_python_34_under ; then parallel_build="--parallel $(makeopts_jobs)" fi ${EPYTHON} tools/cythonize.py || die distutils-r1_python_compile \ ${parallel_build} \ ${SCIPY_FCONFIG} }
*** Bug 635872 has been marked as a duplicate of this bug. ***
(In reply to François Bissey from comment #38) > Just removing the bit "-j $(makeopts_jobs)" altogether is the better > solution. Although I'll admit to use the following in a private overlay > python_compile() { > is_python_34_under(){ > [[ ${EPYTHON} == python3.[0-4] || ${EPYTHON} == python2.7 ]] > } > local parallel_build="" > if is_python_34_under ; then > parallel_build="--parallel $(makeopts_jobs)" > fi > ${EPYTHON} tools/cythonize.py || die > distutils-r1_python_compile \ > ${parallel_build} \ > ${SCIPY_FCONFIG} > } Is it possible to add this override via /etc/portage/package.env without going through a local overlay? I have tried a few things and portage does not seem to be picking up the override for the function.
(In reply to matoro from comment #40) > (In reply to François Bissey from comment #38) > > Just removing the bit "-j $(makeopts_jobs)" altogether is the better > > solution. Although I'll admit to use the following in a private overlay > > python_compile() { > > is_python_34_under(){ > > [[ ${EPYTHON} == python3.[0-4] || ${EPYTHON} == python2.7 ]] > > } > > local parallel_build="" > > if is_python_34_under ; then > > parallel_build="--parallel $(makeopts_jobs)" > > fi > > ${EPYTHON} tools/cythonize.py || die > > distutils-r1_python_compile \ > > ${parallel_build} \ > > ${SCIPY_FCONFIG} > > } > > Is it possible to add this override via /etc/portage/package.env without > going through a local overlay? I have tried a few things and portage does > not seem to be picking up the override for the function. Not that I know of. A simpler and equally effective alteration is python_compile() { ${EPYTHON} tools/cythonize.py || die distutils-r1_python_compile \ ${SCIPY_FCONFIG} } You don't have any parallelism with any python but the loss seems to be negligible as far as I can measure it.
(In reply to François Bissey from comment #41) > (In reply to matoro from comment #40) > > (In reply to François Bissey from comment #38) > > > Just removing the bit "-j $(makeopts_jobs)" altogether is the better > > > solution. Although I'll admit to use the following in a private overlay > > > python_compile() { > > > is_python_34_under(){ > > > [[ ${EPYTHON} == python3.[0-4] || ${EPYTHON} == python2.7 ]] > > > } > > > local parallel_build="" > > > if is_python_34_under ; then > > > parallel_build="--parallel $(makeopts_jobs)" > > > fi > > > ${EPYTHON} tools/cythonize.py || die > > > distutils-r1_python_compile \ > > > ${parallel_build} \ > > > ${SCIPY_FCONFIG} > > > } > > > > Is it possible to add this override via /etc/portage/package.env without > > going through a local overlay? I have tried a few things and portage does > > not seem to be picking up the override for the function. > > Not that I know of. A simpler and equally effective alteration is > python_compile() { > ${EPYTHON} tools/cythonize.py || die > distutils-r1_python_compile \ > ${SCIPY_FCONFIG} > } > You don't have any parallelism with any python but the loss seems to be > negligible as far as I can measure it. This works great, including on =sci-libs/scipy-1.0.0 . Is this grounds for changing the ebuild in the official tree? IMO a functional build is more important than features advertised by upstream.
(In reply to matoro from comment #42) > (In reply to François Bissey from comment #41) > > (In reply to matoro from comment #40) > > > (In reply to François Bissey from comment #38) > > > > Just removing the bit "-j $(makeopts_jobs)" altogether is the better > > > > solution. Although I'll admit to use the following in a private overlay > > > > python_compile() { > > > > is_python_34_under(){ > > > > [[ ${EPYTHON} == python3.[0-4] || ${EPYTHON} == python2.7 ]] > > > > } > > > > local parallel_build="" > > > > if is_python_34_under ; then > > > > parallel_build="--parallel $(makeopts_jobs)" > > > > fi > > > > ${EPYTHON} tools/cythonize.py || die > > > > distutils-r1_python_compile \ > > > > ${parallel_build} \ > > > > ${SCIPY_FCONFIG} > > > > } > > > > > > Is it possible to add this override via /etc/portage/package.env without > > > going through a local overlay? I have tried a few things and portage does > > > not seem to be picking up the override for the function. > > > > Not that I know of. A simpler and equally effective alteration is > > python_compile() { > > ${EPYTHON} tools/cythonize.py || die > > distutils-r1_python_compile \ > > ${SCIPY_FCONFIG} > > } > > You don't have any parallelism with any python but the loss seems to be > > negligible as far as I can measure it. > > This works great, including on =sci-libs/scipy-1.0.0 . Is this grounds for > changing the ebuild in the official tree? IMO a functional build is more > important than features advertised by upstream. I think it is. I experimented all sorts of combinations and python-3.5+'s distutils cannot cope with scipy. End of story. However, I am not in charge of this ship.
(In reply to François Bissey from comment #43) > (In reply to matoro from comment #42) > > (In reply to François Bissey from comment #41) > > > (In reply to matoro from comment #40) > > > > (In reply to François Bissey from comment #38) > > > > > Just removing the bit "-j $(makeopts_jobs)" altogether is the better > > > > > solution. Although I'll admit to use the following in a private overlay > > > > > python_compile() { > > > > > is_python_34_under(){ > > > > > [[ ${EPYTHON} == python3.[0-4] || ${EPYTHON} == python2.7 ]] > > > > > } > > > > > local parallel_build="" > > > > > if is_python_34_under ; then > > > > > parallel_build="--parallel $(makeopts_jobs)" > > > > > fi > > > > > ${EPYTHON} tools/cythonize.py || die > > > > > distutils-r1_python_compile \ > > > > > ${parallel_build} \ > > > > > ${SCIPY_FCONFIG} > > > > > } > > > > > > > > Is it possible to add this override via /etc/portage/package.env without > > > > going through a local overlay? I have tried a few things and portage does > > > > not seem to be picking up the override for the function. > > > > > > Not that I know of. A simpler and equally effective alteration is > > > python_compile() { > > > ${EPYTHON} tools/cythonize.py || die > > > distutils-r1_python_compile \ > > > ${SCIPY_FCONFIG} > > > } > > > You don't have any parallelism with any python but the loss seems to be > > > negligible as far as I can measure it. > > > > This works great, including on =sci-libs/scipy-1.0.0 . Is this grounds for > > changing the ebuild in the official tree? IMO a functional build is more > > important than features advertised by upstream. > > I think it is. I experimented all sorts of combinations and python-3.5+'s > distutils cannot cope with scipy. End of story. > However, I am not in charge of this ship. Well according to https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html fixing a build issue does not warrant a new revision, and according to https://devmanual.gentoo.org/ebuild-maintenance/index.html#touching-other-developers-ebuilds we should give the dev time to fix it. I've sent an email with the appropriate patch, if nothing is forthcoming I will submit a pull request myself.
If you do, check if the "multiprocessing" eclass is still needed. I am fairly sure it is only included to get makeopts_jobs().
(In reply to François Bissey from comment #41) > Not that I know of. A simpler and equally effective alteration is > python_compile() { > ${EPYTHON} tools/cythonize.py || die > distutils-r1_python_compile \ > ${SCIPY_FCONFIG} > } > You don't have any parallelism with any python but the loss seems to be > negligible as far as I can measure it. So, in short there is no hope to support parallel build of scipy on distutils and we just use the serialized build unconditionally. Is that correct?
(In reply to Benda Xu from comment #46) > (In reply to François Bissey from comment #41) > > > Not that I know of. A simpler and equally effective alteration is > > python_compile() { > > ${EPYTHON} tools/cythonize.py || die > > distutils-r1_python_compile \ > > ${SCIPY_FCONFIG} > > } > > You don't have any parallelism with any python but the loss seems to be > > negligible as far as I can measure it. > > So, in short there is no hope to support parallel build of scipy on > distutils and we just use the serialized build unconditionally. Is that > correct? I cannot fix python 3.5+ distutils. numpy's one perform better but python's one cannot be shut off without patching. So yes serialize unconditionally, or use numpy parallelism in python <3.5. Too complicated in my opinion.
GRAPHITE="-floop-interchange -floop-strip-mine -floop-block -fgraphite-identity" CFLAGS="-march=sandybridge -O2 -ftree-vectorize ${GRAPHITE} -pipe" CXXFLAGS="${CFLAGS}" USE="-doc -sparse {-test}" PYTHON_TARGETS="python3_6 -python2_7 -python3_4 -python3_5" sci-libs/scipy-1.0.0 fails for me with -j5 builds successfully when package.env / MAKEOPTS="-j1"
Was bitten by this with scipy-1.1.0 when switching to python 3.6, using MAKEOPTS=-j1 did the trick for me. See also Bug 658864 someone else reported, which is a duplicate.
*** Bug 658864 has been marked as a duplicate of this bug. ***
I can confirm that using MAKEOPTS=-j1 fixes problem for x86.
*** Bug 646328 has been marked as a duplicate of this bug. ***
[master dea904d8d71a] sci-libs/scipy: Parallel build fails (#614464) 3 files changed, 7 insertions(+), 4 deletions(-)
*** Bug 701642 has been marked as a duplicate of this bug. ***
*** Bug 704226 has been marked as a duplicate of this bug. ***
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=809afd4a24533311ced5ecfb2f022b539a3b6dd2 commit 809afd4a24533311ced5ecfb2f022b539a3b6dd2 Author: Benda Xu <heroxbd@gentoo.org> AuthorDate: 2020-01-27 04:54:55 +0000 Commit: Benda Xu <heroxbd@gentoo.org> CommitDate: 2020-01-27 04:59:38 +0000 sci-libs/scipy: disable parallel build completely. After 4 years discussion and debugging, we conclude that Python 3 is deeply broken in parallel builds for anything involving compiling of C/C++/fortran code. The problem is universal, regardless how dev-python/numpy is built. Numpy and scipy upstream cannot do anything about this. We bite the bullet and disable parallel build of scipy completely. Thanks to all who have contributed to this heroic marathon debugging. We regret that only a workaround can be provided at this moment. Credit: Andrés Becerra Sandoval, Hendrik v. Raven, younky.yang@yahoo.com Credit: matoro, Denis Descheneaux, Mathy Vanvoorden, email200202@yahoo.com Credit: jon R-B, Anton Kochkov, Jonas Stein, edes, David Duchesne Credit: thulle, Mathy Vanvoorden, Sasha Medvedev, rtgiskard@gmail.com Credit: Lukasz Ligowski, Zentoo, Jouni Kosonen, Neil, Harris Landgarten Credit: Markus Oehme, Andreas Proteus Suggested-By: François Bissey, Arfrever Frehtes Taifersar Arahesis Reference: https://github.com/numpy/numpy/issues/13080 Reference: https://github.com/scipy/scipy/issues/7112 Closes: https://bugs.gentoo.org/614464 Package-Manager: Portage-2.3.79, Repoman-2.3.18 Signed-off-by: Benda Xu <heroxbd@gentoo.org> sci-libs/scipy/scipy-1.4.1.ebuild | 2 ++ 1 file changed, 2 insertions(+)
*** Bug 639778 has been marked as a duplicate of this bug. ***
The stable 1.1.0 ebuild is still missing this fix.
*** Bug 676640 has been marked as a duplicate of this bug. ***
