Bug 821188
| Summary: | RFE: Add ecl support to maxima | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Paulo Andrade <paulo.cesar.pereira.de.andrade> |
| Component: | maxima | Assignee: | Rex Dieter <rdieter> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | jamatos, rdieter |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-07-02 19:55:36 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 821183, 837102 | ||
| Bug Blocks: | |||
I updated it again for the ecl runtime support as required by sagemath.
Extra change I did was to not explicitly require maxima-runtime-%{default_lisp}
but just maxima-runtime, you may choose to not add this, but pretty please add the ecl runtime support :-) Only really required by sagemath, so, only needed for fc18 or newer.
Spec URL: http://fedorapeople.org/~pcpa/maxima.spec
SRPM URL: http://fedorapeople.org/~pcpa/maxima-5.27.0-4.fc18.src.rpm
I'm ok with enabling ecl, but not removing the requirement. I want sbcl to be the default backend used, we've had various problems with the others in the past. and yum/rpm doesn't allow any good method to specify a preferred provider for "maxima-runtime" unfortunately. let's see if we can explore other solutions for the maxima-runtime issue separate from this bug. * Sun Jul 1 2012 pcpa <paulo.cesar.pereira.de.andrade> - 5.27.0-4 - Enable ecl support. - Build ecl interface to maxima required by sagemath. (In reply to comment #2) > I'm ok with enabling ecl, but not removing the requirement. > > I want sbcl to be the default backend used, we've had various problems with > the others in the past. > > and yum/rpm doesn't allow any good method to specify a preferred provider > for "maxima-runtime" unfortunately. Ok, no big deal. Actually I was expecting it to have some kind of --auto-select (that should choose the sbcl backend) or ask the user to choose an option as done by urpmi, but I am still novice with yum and fedora tools... Thanks for adding ecl support to maxima. Major requirement actually should be to have the (require "maxima") feature callable from libecl. Looks like maxima FTBFS (fails to build from source) in koji/mock with ecl support enabled, http://koji.fedoraproject.org/koji/taskinfo?taskID=4214249 logs: ... ;;; ;;; Compiling /builddir/build/BUILD/maxima-5.27.0/src/maxima-package.lisp. ;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=2 ;;; ;;; End of Pass 1. ;;; Finished compiling /builddir/build/BUILD/maxima-5.27.0/src/maxima-package.lisp. ;;; /usr/bin/ld: cannot find -lffi collect2: error: ld returned 1 exit status Perhaps ecl is missing a Requires: libffi-devel I'll see if adding that as a buildrequires fixes it. Indeed it is missing the libffi-devel requires. If you can rebuild ecl correcting it, please do! Thanks. %changelog * Mon Jul 02 2012 Rex Dieter <rdieter> 5.27.0-6 - BR: libffi-devel (workaround ecl bug #837102) |
This is required by my work in progress sagemath package, and is the current blocking point in generating a package, as it fails when building documentation, requiring manual intervention, with a log in this format: reading sources... [ 8%] sage/algebras/steenrod/steenrod_algebra_misc reading sources... [ 8%] sage/algebras/steenrod/steenrod_algebra_mult reading sources... [ 8%] sage/calculus/calculus In function MAKE-FOREIGN-DATA-FROM-ARRAY, the value of argument is "Module error: Don't know how to REQUIRE MAXIMA." which is not of expected type BASE-STRING Available restarts: 1. (USE-VALUE) Supply a new value of type BASE-STRING. Top level in: #<process TOP-LEVEL>. > Internal or unrecoverable error in: GO found an inexistent tag [2: No such file or directory] ;;; ECL C Backtrace ;;; /usr/lib64/libecl.so.11.1(si_dump_c_backtrace+0x2f) [0x7f5228cc70bf] ;;; /usr/lib64/libecl.so.11.1(ecl_internal_error+0x44) [0x7f5228caf314] ;;; /usr/lib64/libecl.so.11.1(+0x3f4ca61098) [0x7f5228be7098] ;;; /usr/lib64/libecl.so.11.1(cl_funcall+0x83) [0x7f5228c903b3] ;;; /usr/lib64/libecl.so.11.1(ecl_check_cl_type+0x2c) [0x7f5228ccd15c] ;;; /usr/lib64/libecl.so.11.1(ecl_base_string_pointer_safe+0x1f) [0x7f5228ceb68f] ;;; /home/pcpa/rpmbuild/BUILDROOT/sagemath-5.0.rc0-1.fc16.x86_64/usr/lib64/python2.7/site-packages/sage/libs/ecl.so(+0x6d49) [0x7f5228f9ed49] ;;; /home/pcpa/rpmbuild/BUILDROOT/sagemath-5.0.rc0-1.fc16.x86_64/usr/lib64/python2.7/site-packages/sage/libs/ecl.so(+0x80cd) [0x7f5228fa00cd] ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5cb9) [0x32afae06f9] ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x32afae15a5] ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCode+0x32) [0x32afae16d2] ;;; /usr/lib64/libpython2.7.so.1.0(PyImport_ExecCodeModuleEx+0xc2) [0x32afaf1a72] ;;; /usr/lib64/libpython2.7.so.1.0() [0x32afaf1ed6] ;;; /usr/lib64/libpython2.7.so.1.0() [0x32afaf2dfc] ;;; /usr/lib64/libpython2.7.so.1.0() [0x32afaf3082] ;;; /usr/lib64/libpython2.7.so.1.0() [0x32afaf3714] ;;; /usr/lib64/libpython2.7.so.1.0(PyImport_ImportModuleLevel+0x44) [0x32afaf3cc4] ;;; /usr/lib64/libpython2.7.so.1.0() [0x32afad86af] ;;; /usr/lib64/libpython2.7.so.1.0(PyObject_Call+0x53) [0x32afa49193] ;;; /home/pcpa/rpmbuild/BUILDROOT/sagemath-5.0.rc0-1.fc16.x86_64/usr/lib64/python2.7/site-packages/sage/misc/lazy_import.so(+0xc878) [0x7f524ba6b878] ;;; /home/pcpa/rpmbuild/BUILDROOT/sagemath-5.0.rc0-1.fc16.x86_64/usr/lib64/python2.7/site-packages/sage/misc/lazy_import.so(+0x5e17) [0x7f524ba64e17] ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x50d3) [0x32afadfb13] ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b40) [0x32afae0580] ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b40) [0x32afae0580] ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x32afae15a5] ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x509b) [0x32afadfadb] ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x32afae15a5] ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x509b) [0x32afadfadb] ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b40) [0x32afae0580] ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b40) [0x32afae0580] ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x32afae15a5] ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x509b) [0x32afadfadb] I have added support to build maxima with ecl support in a local rpm, so the problem above no longer happens. Note that it is first required to rebuild ecl as reported in https://bugzilla.redhat.com/show_bug.cgi?id=821183 The proposed changes add the new maxima-runtime-ecl package, that also happens to build a maxima module for ecl, so that ecl can "require" maxima, an interface required by sagemath. Spec URL: http://fedorapeople.org/~pcpa/maxima.spec SRPM URL: http://fedorapeople.org/~pcpa/maxima-5.27.0-3.fc16.src.rpm