Bug 843109
Summary: | Jed doesn't find S-Lang path as normal user | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mauricio Vergara Ereche <mave> |
Component: | jed | Assignee: | François Cami <contribs> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | drjohnson1, michal, rakesh.pandit, sato_ichi, udorta |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-08-01 00:22:42 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: |
Description
Mauricio Vergara Ereche
2012-07-25 15:35:57 UTC
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Apparently this is a bug in using -O2 optimization when compiling the S-Lang library. I was able to fix the problem with jed by rebuilding the slang package with the -O0 flag. Here is what I did: 1. Installed the slang-2.2.4-5.fc18.src.rpm RPM: rpm -ivh slang-2.2.4-5.fc18.src.rpm 2. Added this line to the slang.spec file, right below %build and before %configure: export CFLAGS='-O0 -g' 3. Ran rpmbuild -bb slang.spec. Installing the new slang RPM caused jed to run properly for all users on my F18 system. Are you able to reproduce on f18, f19 or rawhide? François, The bug occurred for me in F18, which is why I created the fix for it in F18. I don't use F19 or rawhide. Have you been able to use jed in F19 or rawhide? Mauricio, Sato, well, I cannot reproduce on my Fedora 18 systems - i.e. jed works as expected as a normal user. Im still using F17 and the behavior is the same. I downgraded to a jed{,-common}-0.99.14-2 version to avoid this issue Unable to reproduce issue with: jed-0.99.19-5.fc18.x86_64.rpm oniguruma-5.9.4-1.fc18.x86_64.rpm slang-slsh-2.2.4-5.fc18.x86_64.rpm Ran as normal user and opened a file for edit without any problems. This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. (In reply to François Cami from comment #5) > Mauricio, Sato, well, I cannot reproduce on my Fedora 18 systems - i.e. jed > works as expected as a normal user. I had an ecounter with what could be a manifestation of the same bug. This was with jed-0.99.19-5.fc18 on Fedora 18 installation. These binaries were installed on "Tue 19 Feb 2013" and worked fine for a while. Around July 5th I could not start jed. AFAICS a direct trigger was the following line in ~/.jedrc: () = evalfile ("emacs"); strace showed the following: 2359 stat("/usr/share/jed/lib(/usr/share/slsh(/usr/share/slsh/local-packages/emacs", 0x7fff60f814b0) = -1 ENOENT (No such file or directory) 2359 stat("/usr/share/jed/lib(/usr/share/slsh(/usr/share/slsh/local-packages/emacs.slc", 0x7fff60f814d0) = -1 ENOENT (No such file or directory) 2359 stat("/usr/share/jed/lib(/usr/share/slsh(/usr/share/slsh/local-packages/emacs.sl", 0x7fff60f814d0) = -1 ENOENT (No such file or directory) 2359 stat("/usr/share/jed/lib(/usr/share/slsh(/usr/share/slsh/local-packages/emacs.slc", 0x7fff60f814b0) = -1 ENOENT (No such file or directory) Small wonder that things were failing. Other jed library files also were becoming not-loadable. Attempts to be explicit with set_jed_library_path were not helpful. I run out of time and replaced a jed use with 'emacsclient -A ""'. To my considerable surprise the same jed binaries today work just fine again. Looking at updates between July 5th and today an update of glibc from glibc-2.16-31.fc18 glibc-2.16-33.fc18 smells like the most plausible "fix" candidate; even if likely not on its own. This is just a guess and probably even not a good one. Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |