On 04/17/2010 10:53 PM, Carsten Haitzler (The Rasterman) wrote: > On Sat, 17 Apr 2010 22:23:40 -0400 Christopher Michael<cpmicha...@comcast.net> > said: > >> As is apparent here: >> >> http://home.comcast.net/~devilhorns/run_ff.png >> >> It works fine with current svn of e17& efl (as of this writing). I >> would try updating to the latest and greatest that you can...(ideally >> from svn, but you have already stated that you don't want to do that) :) >> >> If the problem does persist for you, the only way we can really be of >> help would be if you had a gdb backtrace of the crash (which would >> require installed from svn and building with -g, etc, etc). > > well if he doesnt want to upgrade to svn and it's fixed.. there is NOTHING he > can do. it's upgrade and have something that works or live with what he has. > not much in between (well unless he wishes to patch his own code and rebuild - > but i am assuming that is even harder tan upgrade , so ruling it out) > Of course...Just trying to toss some 'subtle' hints out there that svn would be the better way to go :)
dh >> In case you feel brave one day ;) here is a link to getting backtraces :) >> http://trac.enlightenment.org/e/wiki/Debugging >> >> devilhorns >> >> On 04/17/2010 10:09 PM, Joe(theWordy)Philbrook wrote: >>> >>> On 4/10/10 a: pacman -Syu :destabilized e17's run command dialog on my >>> Arch Linux installation. >>> >>> Yes I know e17 is still under heavy development, so I can't >>> expect it to be completely stable. But I thought I should bring this >>> up even though I found a workaround that works for me. >>> >>> And I know this "could" be a distro specific problem... But I don't think >>> so because: >>> >>> To quote from the Arch wiki: >>> >>> http://wiki.archlinux.org/index.php/Arch_Linux >>> >>> -> Arch provides non-patched, vanilla software; packages are offered from >>> -> pure upstream sources, how the author originally intended it be >>> -> distributed. Patching only occurs in extremely rare cases, to prevent >>> -> severe breakage in the instance of version mismatches that may occur >>> -> within a rolling release model. >>> >>> However I am a multi-Linux/multi-boot kind of guy, who in each and >>> every distro I install, heavily depends on their package management >>> system to keep me out of dependency hel^Hck... ;-7 >>> >>> And e17 is definitely one "package" that I wouldn't even attempt to >>> install by hand. >>> >>> But of all my currently installed distros, Arch is the one that seems >>> most likely to install an unadulterated upstream package, rather than a >>> distro specific {modified} version. >>> >>> Thus I don't think the fact that the only e17 on my laptop that this has >>> happened to, is the one in Arch, automatically makes it a distro specific >>> issue. It probably only means the Arch e17 is more accurately updated... >>> At least that's mt best guess. >>> >>> I'm not really sure what was the e17 version number that I installed to Arch >>> sometime since my mid March initial installation of Arch itself, but as >>> of now the e17 "help about" lists it as "Enlightenment 0.16.999.063". >>> Prior to this recent "pacman -Syu", e17's run prompt worked normally. >>> Afterwards it's become fussy what the first character I input into it is. >>> That is to say, I usually start opera via the run prompt and when I type >>> "o" the command history displays the last instance of the command And I can >>> in fact start opera. Yet I also use firefox {though I usually start that >>> from inside alpine}. The other day I tried to start firefox from the run >>> prompt. But as soon as I typed an "f" into the first character position of >>> the command input field, I got a pop-up error telling me that >>> "Enlightenment SEGV'd" That also advised me to compile everything with "-g >>> in CFLAGS" So far, the the restore button succeeds in restarting e17 >>> without closing any open applications... But of course firefox didn't >>> start. I can start firefox from an xterm. And I tested that I can type "of" >>> into the run prompt without an immediate SEGV But I can't type an f as the >>> first character. I haven't tested the whole alphabet, BUT I did find I >>> can't type a command starting with "b" or "/" as the first character >>> either. Though just because I'm stubborn I can tell you that I can start >>> firefox [via e17's run prompt] with: "~/../../usr/bin/firefox" (go figure) >>> >>> I did say I've got a work around that works for me... Since I've also got >>> XFCE installed as a back-up desktop, I've reassigned the keybinding I used >>> to use to pull up e17's run prompt with, to "/usr/bin/xfrun4". Which works >>> just fine. >>> >>> I don't know if this is a known issue or a new one. But I thought I >>> should mention it. >>> >> ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
