I'm running a current beta of F11. I installed Maxima, and tried to run it. It gives a segfault. -bash-4.0$ maxima Segmentation fault -bash-4.0$ maxima -v + '[' gcl = clisp ']' + '[' gcl = cmucl ']' + '[' gcl = scl ']' + '[' gcl = gcl ']' + exec /usr/lib64/maxima/5.17.1/binary-gcl/maxima -eval '(cl-user::run)' -f -- -v '' '' '' '' '' '' '' '' Segmentation fault -bash-4.0$ yum list maxima Loaded plugins: refresh-packagekit Installed Packages maxima.x86_64 5.17.1-7.fc11 installed -bash-4.0$ uname -a Linux Ahmed.US 2.6.29.1-70.fc11.x86_64 #1 SMP Mon Apr 13 14:16:25 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Mind trying another runtime? yum install maxima-runtime-sbcl maxima -l sbcl
Ah ha! I installed SBCL and Maxima works. I didn't even have to pass Maxima the option to specify the runtime. SBCL seems to be the default.
Can't reproduce here on my newly installed f11/rawhide box, hopefully it was just a transient error (rawhide being rawhide).
(In reply to comment #3) > Can't reproduce here on my newly installed f11/rawhide box, hopefully it was > just a transient error (rawhide being rawhide). Oops. Sorry, but I still get the error. Do you have SBCL installed? If so, you won't see the error. The problem only happens when you are using GNU Common Lisp as the runtime. Try uninstalling SBCL and then run Maxima again.
I tried all available runtimes, and they all worked fine for me. If it makes you feel better to keep this open, fine, but until we have a way to reproduce this, or more/new information, there's not much to do. In the meantime, I'll test out the i386 builds.
(In reply to comment #5) > I tried all available runtimes, and they all worked fine for me. > > If it makes you feel better to keep this open, fine, but until we have a way to > reproduce this, or more/new information, there's not much to do. > > In the meantime, I'll test out the i386 builds. He he. Never mind. We can close it.
Rats, I had selinux in permissive mode, with it enabled I can reproduce the failure to run: maxima -l gcl Reassigning to gcl for input/advice.
(In reply to comment #7) > Rats, I had selinux in permissive mode, with it enabled I can reproduce the > failure to run: > maxima -l gcl > > Reassigning to gcl for input/advice. Oh yeah. I forgot to mention: there's an SELinux error that comes with the segfault. That probably would have been good to include in my original post.
confirmed reproducible on both i586, x86_64 (I'd venture this is independant of arch).
Dealing with the SELinux issues took me much longer than any of the other problems I had to solve to get GCL building on Fedora again. It looks like I'm still not done... To get the GCL binary to run, I created a type gcl_exec_t. My intention was that all GCL images would use this type. However, I foolishly did not separate out the SELinux definitions into a separate gcl-selinux package. So to solve the maxima problem, you'd have to install the gcl package just to get the gcl_exec_t type. I tried "chcon -t gcl_exec_t %{_libdir}/maxima/5.17.1/binary-gcl/maxima". That got it to run. Now I worry about the original type, lib_t, of that file, though. Do I need to make a gcl_lib_t type that combines the lib_t permissions with gcl_exec_t? (I haven't looked at lib_t yet, so I don't know.) It's probably okay, since maxima seems to be functioning with gcl_exec_t. So I'll push a new GCL build ASAP that will contain a gcl-selinux subpackage. You'll need to require that, and either use semanage to give the image the gcl_exec_t type or produce your own SELinux policy file. For which distributions do you need this? Just F-11 & Rawhide?
awesome, F-11+ only for now, but had partial intentions to re-introduce the gcl runtime for prior releases at some date in the future (no rush though).
just peeked into /usr/share/selinux/ , noticed gcl seems to be the only one using packages/ (and that dir is unowned), and all other policy lives in targeted/ (and is bzipped). Is this expected?
That was supposed to have been fixed. See the thread rooted here: https://www.redhat.com/archives/fedora-selinux-list/2009-January/msg00053.html If it still isn't fixed, I guess I'd better file a bug.
gcl-2.6.8-0.3.20090303cvs.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/gcl-2.6.8-0.3.20090303cvs.fc11
gcl-2.6.8-0.3.20090303cvs.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/gcl-2.6.8-0.3.20090303cvs.fc10
gcl-2.6.8-0.3.20090303cvs.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gcl'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-4053
gcl-2.6.8-0.3.20090303cvs.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
Per comment #10, I'll need to also make appropriate changes to maxima , re-opening and re-assigning there (sorry for bz noise, I guess I should've made 2 bugs)
I probably shouldn't have set this bug to autoclose when the new gcl build was pushed. What do you want to do about F-11? You can't build with the new gcl because it is a pending zero-day update. Do you want me to ask rel-eng to tag it for F-11 final?
I'll figure something out. I'm on the rel-eng team, so can do any necessary tagging. (Just need to carve out some time to do the work).
gcl-2.6.8-0.3.20090303cvs.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
FYI, until I find the time to fix this properly, I'm going to omit the broken -runtime-gcl support here (patches welcome though).
What needs to be done? Just setting the appropriate SELinux type, or is there something more?
yeah, selinux love, testing, per comment #20
OK, there's an ulterior motive too, I want/prefer the -sbcl backend to be used by default, but yum's current algorithm for choosing which -runtime-* to install by default picks the one with the shortest name, so most users get -gcl instead.
*** Bug 509549 has been marked as a duplicate of this bug. ***
*** Bug 512972 has been marked as a duplicate of this bug. ***
Jerry, sorry for the delay, been looking at this today finally, and I was about to jump in with some semanage scriptlets, when it occurred to me, is there some reason we can't just add the maxima-gcl related files to gcl.fc when generating gcl-selinux ? something like: /usr/lib/maxima/[^/]+/binary-gcl -- gen_context(system_u:object:r:gcl_exec_t,s0) /usr/lib64/maxima/[^/]+/binary-gcl -- gen_context(system_u:object:r:gcl_exec_t,s0) (or am I missing something)?
Sure, that should be fine. For what branches do you want this?
cool. More the merrier, but start with devel/F-12 first, then we can maybe think about F-11 eventually too.
gcl-2.6.8-0.5.20090701cvs.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/gcl-2.6.8-0.5.20090701cvs.fc12
It's built in F-13 and is ready to go to F-12 testing as soon as that is possible.
Saw this upgrading today (on F-11), didn't look into details yet, Updating : gcl-selinux-2.6.8-0.3.20090701cvs.fc11.x86_64 17/45 libsepol.context_from_record: role object is not defined libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object:r:gcl_exec_t:s0 to sid invalid context system_u:object:r:gcl_exec_t:s0 libsemanage.semanage_install_active: setfiles returned error code 1. libsepol.context_from_record: role object is not defined libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object:r:gcl_exec_t:s0 to sid invalid context system_u:object:r:gcl_exec_t:s0 libsemanage.semanage_install_active: setfiles returned error code 1. /usr/sbin/semodule: Failed! Updating : gcl-2.6.8-0.3.20090701cvs.fc11.x86_64
That was a fat fingers error. Dan Walsh asked me to make another change to the policy anyway, so I'm building new packages now. Sorry about that...
gcl-2.6.8-0.6.20090701cvs.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/gcl-2.6.8-0.6.20090701cvs.fc12
gcl-2.6.8-0.4.20090701cvs.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/gcl-2.6.8-0.4.20090701cvs.fc11
regarding F-12, you can still request inclusion in F-12 final, just do a 'make tag-request' instead of 'make update'. See also, https://www.redhat.com/archives/fedora-devel-announce/2009-October/msg00006.html
gcl-2.6.8-0.4.20090701cvs.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Closing, let's consider the issue closed. At some future, date, when I collect enough round-tuits, maxima-runtime-gcl will be re-introduced.
maxima-5.22.1-5.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/maxima-5.22.1-5.fc13
maxima-5.22.1-5.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/maxima-5.22.1-5.fc14
maxima-5.22.1-5.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
maxima-5.22.1-5.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.