Bug 821188 - RFE: Add ecl support to maxima
RFE: Add ecl support to maxima
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: maxima (Show other bugs)
rawhide
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
: Reopened
Depends On: 821183 837102
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-12 18:15 EDT by Paulo Andrade
Modified: 2012-07-02 15:55 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-02 15:55:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paulo Andrade 2012-05-12 18:15:31 EDT
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
Comment 1 Paulo Andrade 2012-07-01 11:09:33 EDT
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
Comment 2 Rex Dieter 2012-07-01 12:58:54 EDT
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.
Comment 3 Rex Dieter 2012-07-01 13:02:33 EDT
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@gmail.com> - 5.27.0-4
- Enable ecl support.
- Build ecl interface to maxima required by sagemath.
Comment 4 Paulo Andrade 2012-07-01 13:21:07 EDT
(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.
Comment 5 Rex Dieter 2012-07-02 15:25:52 EDT
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.
Comment 6 Paulo Andrade 2012-07-02 15:39:37 EDT
Indeed it is missing the libffi-devel requires. If you can rebuild ecl correcting it, please do! Thanks.
Comment 7 Rex Dieter 2012-07-02 15:55:36 EDT
%changelog
* Mon Jul 02 2012 Rex Dieter <rdieter@fedoraproject.org> 5.27.0-6
- BR: libffi-devel (workaround ecl bug #837102)

Note You need to log in before you can comment on or make changes to this bug.