See the attached test.log. I'm not sure what causing the failures, if someone has any clue, that would be nice. Thanks, Diego
Created attachment 120199 [details] test.log
Created attachment 120220 [details, diff] files/numarray-1.5.2-freebsd.patch The problem was that the expected exceptions were not being generated. FreeBSD was not included in the pre-processor checks, so the code to do this (which happens to be the same as linux, darwin, etc.) was not being used. Attached is a patch for the source. I'll attached the new ebuild next.
Created attachment 120222 [details, diff] numarray-1.5.2-r1.ebuild Here's the ebuild diff file.
Python herd, can you accept this patch? By the way, seems like numeric is used for tests, so it might be a good idea to put it into a test? ( ) dependency.
Hi > Python herd, can you accept this patch? sci herd is. > By the way, seems like numeric is used for tests, so it might be a good idea to > put it into a test? ( ) dependency. On my boxes, tests run fine if numeric is absent. It seems that if numeric and/or numpy are present, some extras tests for array_protocol are performed. Do you confirm this? Sébastien
My python knowledge is quite wacky, so I'm not sure if I can confirm anything :) But Joe was reporting problems with an older numeric version installed on Linux (x86 stable versus ~x86), that's why I asked.
Here's what I found regarding the tests and "Numeric": 1) If Numeric is not there, it will not be used in the tests, and it is quiet about this. 2) If you run the tests with the stable Numeric (=dev-python/numeric-23.7), you will get errors (mismatching typecodes). Running with dev-python/numeric-24.2-r3 works fine (I have not tested other versions). So it does not appear necessary to put a DEPEND on Numeric in for test in terms of successfully running the test phase, but the downside would be that the Numeric tests are not run if Numeric cannot be imported. I have not looked into what other array_protocol tests are done in that case and if they would be just as valid tests.
I added Joe's patch and a fix to remove array_protocol test, because it was uncompatible with various versions of numeric and numpy (and numarray is being soon obsoleted by numpy). Please test it. Note that for freebsd, the lapack flag still needs work.
Great, thanks! By the way, numarray, even though it will eventually be replaced by numpy, is still required for the non-beta version of PyFITS, so it'll be important for a while at least. And yep, I will have to test numpy on g/fbsd.
On "lapack": I have taken a crack at fixing blas-atlas to compile on FreeBSD. Not easy, due to the fact that there is C code (yes, you heard it right!) that executes "make" (and other) commands via the system() call during the emerge process. On FreeBSD, $(MAKE) is set to "gmake" (not "make"). I patched ATLAS/bin/atlas_install.c to use getenv("MAKE") instead of hard-coding it to correct errors resulting from this. However, I am still having issues, and I stopped there for now, since this is starting to look ugly. On another note, this build seems to time itself at certain points in order to determine speed of operation. This info is saved and used somehow (I have not delved into it more). So it relies on the machine's not doing other tasks at the time, which cannot be assured, since lots of people run emerge in the background while doing other things, and they'd never know this (nor should they have to). This seems bad. One thing we could do is mask the lapack USE flag on FreeBSD, but that seems ashame. Any comments? I'm not sure the best course of action regarding lapack & blas-atlas right now. -Joe
Hi Joe, Instead of using blas-atlas, you could also use {blas,cblas,lapack}-reference to avoid masking the lapack or blas USE flag. These builds are not as fast as the *atlas, but are much more stable ebuilds in general. Sébastien
Hi Sébastien, I was going down that route, (i.e. using cblas-reference), but it turns out that it depends on virtual/blas, which seems to want blas-atlas.
> I was going down that route, (i.e. using cblas-reference), but it turns out > that it depends on virtual/blas, which seems to want blas-atlas. install blas-reference first, it also gives a virtual/blas.
I will try this - except we should not have to rely on someone's having blas-reference installed first; it should "just work". Is there a way to have the virtual rely on either instead of just blas-atlas? Or maybe it should be changed to default to the [safer] cblas-reference... -Joe
For people using ~x86-fbsd keyword, once it's applied on the ebuilds, that will be enough to have it just work.
I have added the following to /etc/portage/package.keywords in order for emerging numarray with USE="lapack" to not fail on dependencies: sci-libs/blas-atlas x86 ~x86 sci-libs/blas-reference x86 ~x86 sci-libs/cblas-reference x86 ~x86 sci-libs/lapack-atlas x86 ~x86 app-admin/eselect-blas x86 ~x86 app-admin/eselect-cblas x86 ~x86 app-admin/eselect-lapack x86 ~x86 However, it will try to install blas-atlas. When I install blas-reference first, it also needs to install blas-atlas, so this does not seem to help. Isn't the above equivalent to keywording for ~x86-fbsd?
To clarify further: Installing blas-reference does indeed allow emerging cblas-reference (with USE="lapack"), but even after both of these are installed, I cannot emerge numarray, since it still needs blas-atlas (needed bu lapack-atlas).
Joe, Here are the steps you need to go forward: - keywords ~x86-fbsd all the sci-libs/*-reference to make sure to take the last versions which use the eselect stuff. - emerge blas-reference cblas-reference lapack-reference - emerge numarray The virtual/lapack will be provided by the reference. blas-atlas is selected first because profiles/base/virtuals pulls it. You may override this by providing virtual/blas and virtual/lapack (e.g. pointing at the *-reference) in the child bsd profiles. Sébastien
Sébastien, Yep, changing virtuals in the profile did indeed solve the issue (of using "reference" by default rather than "atlas"). I had originally wondered if this could be done through selective keywording only - thanks for the tip. Diego, Is it reasonable to change these virtuals for the default-bsd profile?
Yep changing virtuals is good to go.
To change this arch to use the "reference implementation" rather than "atlas" (blas-atlas has build issues that are non-trivial), I added the following to profiles/default-bsd/virtuals: virtual/blas sci-libs/blas-reference virtual/cblas sci-libs/blas-reference ...and... virtual/lapack sci-libs/lapack-reference Also, I keyworded the following with ~x86-fbsd, which are needed: sci-libs/blas-reference sci-libs/cblas-reference sci-libs/lapack-reference app-admin/eselect-blas app-admin/eselect-cblas app-admin/eselect-lapack Now, numarray will now run and pass tests using USE="lapack".
