Thread: [Celestia-developers] Segfault when running Lua scripts
Real-time 3D visualization of space
Status: Beta
Brought to you by:
cjlaurel
From: Nick U. <ni...@ni...> - 2006-07-29 07:15:32
|
Dear Folks, I have built a Celestia 1.4.1 RPM package for Fedora Core 5, linking it to the lua libraries. However, when I run it, I get segmentation faults when I open a .celx lua script from the File menu. Does anyone have any suggestions about what may be wrong? Or have any suggestions as to what I could try to debug this problem? (gdb) run Starting program: /usr/bin/celestia Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xbffff000 [Thread debugging using libthread_db enabled] [New Thread -1208952416 (LWP 15681)] render path: 1 [New Thread -1366787168 (LWP 15686)] [New Thread -1463317600 (LWP 15687)] [Thread -1463317600 (LWP 15687) exited] [New Thread -1463317600 (LWP 15688)] [Thread -1463317600 (LWP 15688) exited] Error: 0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208952416 (LWP 15681)] LuaState::resume (this=3D0xb7313a8) at celx.cpp:721 721 alerter->fatalError(errorMessage); (gdb) bt #0 LuaState::resume (this=3D0xb7313a8) at celx.cpp:721 #1 0x080b6bb4 in LuaState::tick (this=3D0xb7313a8, dt=3D0.1779389999574050= 3) at celx.cpp:823 #2 0x0808b69f in CelestiaCore::tick (this=3D0x9863e18) at celestiacore.cpp= :2175 #3 0x080ce5a2 in glarea_idle (app=3D0x97c4548) at glwidget.cpp:69 #4 0x415db7a1 in g_list_remove_link () from /usr/lib/libglib-2.0.so.0 #5 0x415dd15d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #6 0x415e03ef in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #7 0x415e0799 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #8 0x47265634 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #9 0x080be2a4 in main (argc=3D160279968, argv=3D0x98d9730) at main.cpp:502 (gdb) --=20 Nick Urbanik RHCE http://nicku.org ni...@ni... GPG: 7FFA CDC7+5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 |
From: Hank R. <hr...@qw...> - 2006-07-30 01:22:48
|
Nick, From the traceback, it looks to me as if the CelestiaCore alerter has not been properly initialized, causing the segfault when the alerter is called due to a problem with the Lua script. The 'errorMessage' argument to 'alerter->fatalError' should indicate what the problem with the script was. What version of Lua are you using? I think Celestia has been using 5.0, not 5.1, although I don't know if this would a problem. - Hank Ramsey On Jul 29, 2006, at 12:15 AM, Nick Urbanik wrote: > Dear Folks, > > I have built a Celestia 1.4.1 RPM package for Fedora Core 5, linking > it to the lua libraries. However, when I run it, I get segmentation > faults when I open a .celx lua script from the File menu. > > Does anyone have any suggestions about what may be wrong? Or have any > suggestions as to what I could try to debug this problem? > > (gdb) run > Starting program: /usr/bin/celestia > Reading symbols from shared object read from target memory...done. > Loaded system supplied DSO at 0xbffff000 > [Thread debugging using libthread_db enabled] > [New Thread -1208952416 (LWP 15681)] > render path: 1 > [New Thread -1366787168 (LWP 15686)] > [New Thread -1463317600 (LWP 15687)] > [Thread -1463317600 (LWP 15687) exited] > [New Thread -1463317600 (LWP 15688)] > [Thread -1463317600 (LWP 15688) exited] > Error: 0 > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1208952416 (LWP 15681)] > LuaState::resume (this=0xb7313a8) at celx.cpp:721 > 721 alerter->fatalError(errorMessage); > (gdb) bt > #0 LuaState::resume (this=0xb7313a8) at celx.cpp:721 > #1 0x080b6bb4 in LuaState::tick (this=0xb7313a8, > dt=0.17793899995740503) > at celx.cpp:823 > #2 0x0808b69f in CelestiaCore::tick (this=0x9863e18) at > celestiacore.cpp:2175 > #3 0x080ce5a2 in glarea_idle (app=0x97c4548) at glwidget.cpp:69 > #4 0x415db7a1 in g_list_remove_link () from /usr/lib/libglib-2.0.so.0 > #5 0x415dd15d in g_main_context_dispatch () from > /usr/lib/libglib-2.0.so.0 > #6 0x415e03ef in g_main_context_check () from > /usr/lib/libglib-2.0.so.0 > #7 0x415e0799 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 > #8 0x47265634 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 > #9 0x080be2a4 in main (argc=160279968, argv=0x98d9730) at main.cpp:502 > (gdb) > -- > Nick Urbanik RHCE http://nicku.org ni...@ni... > GPG: 7FFA CDC7+5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 > ----------------------------------------------------------------------- > -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV_________________________________ > ______________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Nick U. <ni...@ni...> - 2006-07-30 04:17:03
|
Dear Folks, On 29/07/06 18:24 -0700, Hank Ramsey wrote: >Nick, > >From the traceback, it looks to me as if the CelestiaCore alerter has =20 >not been properly initialized, causing the segfault when the alerter is = =20 >called due to a problem with the Lua script. The 'errorMessage' =20 >argument to 'alerter->fatalError' should indicate what the problem with = =20 >the script was. Well, I examined this, and in fact, the value of errorMessage was printed. Please see below. >What version of Lua are you using? I think Celestia has been using 5.0, = =20 >not 5.1, although I don't know if this would a problem. I am using lua 5.1 (as comes with FC5), as are the Gentoo people. Perhaps they might be able to help me, I don't know. I am also using gcc 4.1, as are the Gentoo folks. Thank you very much for your help. >- Hank Ramsey > > >On Jul 29, 2006, at 12:15 AM, Nick Urbanik wrote: > >>Dear Folks, >> >>I have built a Celestia 1.4.1 RPM package for Fedora Core 5, linking >>it to the lua libraries. However, when I run it, I get segmentation >>faults when I open a .celx lua script from the File menu. >> >>Does anyone have any suggestions about what may be wrong? Or have any >>suggestions as to what I could try to debug this problem? >> >>(gdb) run >>Starting program: /usr/bin/celestia >>Reading symbols from shared object read from target memory...done. >>Loaded system supplied DSO at 0xbffff000 >>[Thread debugging using libthread_db enabled] >>[New Thread -1208952416 (LWP 15681)] >>render path: 1 >>[New Thread -1366787168 (LWP 15686)] >>[New Thread -1463317600 (LWP 15687)] >>[Thread -1463317600 (LWP 15687) exited] >>[New Thread -1463317600 (LWP 15688)] >>[Thread -1463317600 (LWP 15688) exited] >>Error: 0 ---------^ This is the value of errorMessage. Please see line 716 of celx.cpp, which is: cout << "Error: " << errorMessage << '\n'; When I ran it again, then I got: Error: 0.1 Hmm, I don't understand this yet. I think the person who wrote celc.cpp might have a better understanding of the code. >>Program received signal SIGSEGV, Segmentation fault. >>[Switching to Thread -1208952416 (LWP 15681)] >>LuaState::resume (this=3D0xb7313a8) at celx.cpp:721 >>721 alerter->fatalError(errorMessage); >>(gdb) bt >>#0 LuaState::resume (this=3D0xb7313a8) at celx.cpp:721 >>#1 0x080b6bb4 in LuaState::tick (this=3D0xb7313a8, =20 >>dt=3D0.17793899995740503) >> at celx.cpp:823 >>#2 0x0808b69f in CelestiaCore::tick (this=3D0x9863e18) at =20 >>celestiacore.cpp:2175 >>#3 0x080ce5a2 in glarea_idle (app=3D0x97c4548) at glwidget.cpp:69 >>#4 0x415db7a1 in g_list_remove_link () from /usr/lib/libglib-2.0.so.0 >>#5 0x415dd15d in g_main_context_dispatch () from =20 >>/usr/lib/libglib-2.0.so.0 >>#6 0x415e03ef in g_main_context_check () from =20 >>/usr/lib/libglib-2.0.so.0 >>#7 0x415e0799 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 >>#8 0x47265634 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 >>#9 0x080be2a4 in main (argc=3D160279968, argv=3D0x98d9730) at main.cpp:5= 02 >>(gdb) Any suggestions of what I might try would be highly appreciated. --=20 Nick Urbanik RHCE http://nicku.org ni...@ni... GPG: 7FFA CDC7+5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 |
From: Hank R. <hr...@qw...> - 2006-07-30 15:58:43
|
On Jul 29, 2006, at 9:16 PM, Nick Urbanik wrote: > Dear Folks, > > On 29/07/06 18:24 -0700, Hank Ramsey wrote: >> Nick, >> >> From the traceback, it looks to me as if the CelestiaCore alerter has >> not been properly initialized, causing the segfault when the alerter >> is called due to a problem with the Lua script. The 'errorMessage' >> argument to 'alerter->fatalError' should indicate what the problem >> with the script was. > > Well, I examined this, and in fact, the value of errorMessage was > printed. Please see below. > Sorry I missed the print statement. Obviously "Error: 0.1" isn't very helpful. I think the error message should be a string rather than a number, so there may be a problem returning the error message, or perhaps it is normal result being misinterpreted as an error somehow. > Thank you very much for your help. > I'll let you know if I come up with anything useful. Did you verify that the alerter has been properly initialized? That wouldn't fix the underlying Lua problem but might avoid the segfault. - Hank |
From: Hank R. <hr...@qw...> - 2006-07-30 17:12:14
|
On Jul 29, 2006, at 9:16 PM, Nick Urbanik wrote: > Dear Folks, > > On 29/07/06 18:24 -0700, Hank Ramsey wrote: >> What version of Lua are you using? I think Celestia has been using >> 5.0, not 5.1, although I don't know if this would a problem. > > I am using lua 5.1 (as comes with FC5), as are the Gentoo people. > Perhaps they might be able to help me, I don't know. I am also using > gcc 4.1, as are the Gentoo folks. Nick, I did a little more research and I think I may have found the problem. The Lua 5.0 manual says: > lua_resume returns 0 if there are no errors running the coroutine, or > an error code (see 3.15). In case of errors, the stack contains only > the error message. The Lua 5.1 manual says: > lua_resume returns LUA_YIELD if the coroutine yields, 0 if the > coroutine finishes its execution without errors, or an error code in > case of errors (see lua_pcall). In case of errors, the stack is not > unwound, so you can use the debug API over it. The error message is on > the top of the stack. This change isn't mentioned in the section of the 5.1 manual concerning incompatibilities with 5.0. The original code in auxresume in celx.cpp is: > status = lua_resume(co, narg); > if (status == 0) > { > int nres = lua_gettop(co); > #if 0 > if (!lua_checkstack(L, narg)) > luaL_error(L, "too many results to resume"); > #endif > lua_xmove(co, L, nres); // move yielded values > return nres; > } > else > { > lua_xmove(co, L, 1); // move error message > return -1; // error flag > } Note that with the line: > if (status == 0) the code interprets any non-zero status returned by lua_resume as an error. So with 5.1, a LUA_YIELD would be interpreted as an error. It seems likely that's what's happening here. I think for 5.1 this line could be changed to: > if (status == 0) return 0; else if (status == LUA_YIELD) although I'm not certain this will handle normal coroutine completion correctly. It should be possible with 5.1 to eliminate the hack in Celestia for detecting coroutine completion, but this would involve a more substantial code change. Neither of these changes would be compatible with 5.0. Another potential problem is that the line: > lua_xmove(co, L, 1); // move error message assumes that the error message is the only thing in the stack, which was correct for 5.0 but not 5.1. If this line is changed to: > lua_xmove(co, L, -1); // move error message I think that should work with both versions. - Hank |
From: Pat S. <pa...@su...> - 2006-07-30 18:22:44
|
Hank Ramsey wrote: > although I'm not certain this will handle normal coroutine completion > correctly. It should be possible with 5.1 to eliminate the hack in > Celestia for detecting coroutine completion, but this would involve a > more substantial code change. Neither of these changes would be > compatible with 5.0. The big thing holding back to older Lua would be the magic binaries that the Windows distribution uses. I would say that if we can have nicer code from Lua 5.1, we should go for it. Of course, I'm saying this without actually knowing how much work would be required. --Pat |
From: Nick U. <ni...@ni...> - 2006-07-30 18:57:47
|
Dear Folks, Please read futher below. On 30/07/06 10:13 -0700, Hank Ramsey wrote: >On Jul 29, 2006, at 9:16 PM, Nick Urbanik wrote: > >>Dear Folks, >> >>On 29/07/06 18:24 -0700, Hank Ramsey wrote: >>>What version of Lua are you using? I think Celestia has been using=20 >>>5.0, not 5.1, although I don't know if this would a problem. >> >>I am using lua 5.1 (as comes with FC5), as are the Gentoo people. >>Perhaps they might be able to help me, I don't know. I am also using >>gcc 4.1, as are the Gentoo folks. > >Nick, > >I did a little more research and I think I may have found the problem. > >The Lua 5.0 manual says: > >>lua_resume returns 0 if there are no errors running the coroutine, or=20 >>an error code (see 3.15). In case of errors, the stack contains only=20 >>the error message. > >The Lua 5.1 manual says: > >>lua_resume returns LUA_YIELD if the coroutine yields, 0 if the=20 >>coroutine finishes its execution without errors, or an error code in=20 >>case of errors (see lua_pcall). In case of errors, the stack is not=20 >>unwound, so you can use the debug API over it. The error message is on=20 >>the top of the stack. > >This change isn't mentioned in the section of the 5.1 manual concerning=20 >incompatibilities with 5.0. > >The original code in auxresume in celx.cpp is: > >> status =3D lua_resume(co, narg); >> if (status =3D=3D 0) >> { >> int nres =3D lua_gettop(co); >>#if 0 >> if (!lua_checkstack(L, narg)) >> luaL_error(L, "too many results to resume"); >>#endif >> lua_xmove(co, L, nres); // move yielded values >> return nres; >> } >> else >> { >> lua_xmove(co, L, 1); // move error message >> return -1; // error flag >> } > >Note that with the line: > >> if (status =3D=3D 0) > >the code interprets any non-zero status returned by lua_resume as an=20 >error. So with 5.1, a LUA_YIELD would be interpreted as an error. It=20 >seems likely that's what's happening here. I think for 5.1 this line=20 >could be changed to: > >> if (status =3D=3D 0) return 0; else if (status =3D=3D LUA_YIELD) > >although I'm not certain this will handle normal coroutine completion=20 >correctly. It should be possible with 5.1 to eliminate the hack in=20 >Celestia for detecting coroutine completion, but this would involve a=20 >more substantial code change. Neither of these changes would be=20 >compatible with 5.0. > >Another potential problem is that the line: > >> lua_xmove(co, L, 1); // move error message > >assumes that the error message is the only thing in the stack, which=20 >was correct for 5.0 but not 5.1. If this line is changed to: > >> lua_xmove(co, L, -1); // move error message > >I think that should work with both versions. Thank you very much Hank. It seems to work so far. I have built an RPM package of celestia for FC5 at http://nicku.org/software/celestia/. The patch you have suggested is http://nicku.org/software/celestia/celestia-lua51-resume.patch I will test this further before submitting the changes to the maintainer at Fedora Extras. This is the first time I have been able to use Celestia to run .celx scripts. I was using the planetarium.celx script from http://www.celestiamotherlode.net/creators/lordi/planetarium.celx and found that I was able to get a nan (Not a Number) value displayed for "Altitude" through moving around with the mouse. After pressing Esc, I was able to exit the script, and Celestia seems to be still working. --=20 Nick Urbanik RHCE http://nicku.org ni...@ni... GPG: 7FFA CDC7+5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 |
From: Nick U. <ni...@ni...> - 2006-07-30 20:56:03
|
Dear Folks, It's not solved yet. Please see below. On 31/07/06 04:57 +1000, Nick Urbanik wrote: >On 30/07/06 10:13 -0700, Hank Ramsey wrote: >>Note that with the line: >> >>> if (status =3D=3D 0) >> >>the code interprets any non-zero status returned by lua_resume as an=20 >>error. So with 5.1, a LUA_YIELD would be interpreted as an error. It=20 >>seems likely that's what's happening here. I think for 5.1 this line=20 >>could be changed to: >> >>> if (status =3D=3D 0) return 0; else if (status =3D=3D LUA_YIELD) >> >>although I'm not certain this will handle normal coroutine completion=20 >>correctly. It should be possible with 5.1 to eliminate the hack in=20 >>Celestia for detecting coroutine completion, but this would involve a=20 >>more substantial code change. Neither of these changes would be=20 >>compatible with 5.0. >> >>Another potential problem is that the line: >> >>> lua_xmove(co, L, 1); // move error message >> >>assumes that the error message is the only thing in the stack, which=20 >>was correct for 5.0 but not 5.1. If this line is changed to: >> >>> lua_xmove(co, L, -1); // move error message >> >>I think that should work with both versions. > >Thank you very much Hank. It seems to work so far. I have built an >RPM package of celestia for FC5 at >http://nicku.org/software/celestia/. The patch you have suggested is >http://nicku.org/software/celestia/celestia-lua51-resume.patch > >I will test this further before submitting the changes to the >maintainer at Fedora Extras. > >This is the first time I have been able to use Celestia to run .celx >scripts. I was using the planetarium.celx script from >http://www.celestiamotherlode.net/creators/lordi/planetarium.celx and >found that I was able to get a nan (Not a Number) value displayed for >"Altitude" through moving around with the mouse. After pressing Esc, >I was able to exit the script, and Celestia seems to be still working. However, I consistently get a segfault when running the script=20 http://celestia.h-schmidt.net/nineplanets_v1.0.celx, at the point where the number of views is reduced back to one, right at the end of the script. (gdb) run Starting program: /usr/bin/celestia Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xbffff000 [Thread debugging using libthread_db enabled] [New Thread -1208436320 (LWP 20215)] render path: 1 [New Thread -1366271072 (LWP 20222)] [New Thread -1462801504 (LWP 20223)] [Thread -1462801504 (LWP 20223) exited] [New Thread -1462801504 (LWP 20224)] [Thread -1462801504 (LWP 20224) exited] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208436320 (LWP 20215)] 0x080b6a47 in LuaState::resume (this=3D0xb9cbed8) at celx.cpp:716 716 if (strcmp(errorMessage, "cannot resume dead coroutine") != =3D 0) (gdb) bt #0 0x080b6a47 in LuaState::resume (this=3D0xb9cbed8) at celx.cpp:716 #1 0x080b6bc4 in LuaState::tick (this=3D0xb9cbed8, dt=3D0.1549230000237003) at celx.cpp:825 #2 0x0808b69f in CelestiaCore::tick (this=3D0x9b04000) at celestiacore.cpp= :2175 #3 0x080ce5b2 in glarea_idle (app=3D0x9a46548) at glwidget.cpp:69 #4 0x415db7a1 in g_list_remove_link () from /usr/lib/libglib-2.0.so.0 #5 0x415dd15d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #6 0x415e03ef in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #7 0x415e0799 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #8 0x47265634 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #9 0x080be2b4 in main (argc=3DCannot access memory at address 0x1d ) at main.cpp:502 It looks like the error handling for lua is not quite right here. --=20 Nick Urbanik RHCE http://nicku.org ni...@ni... GPG: 7FFA CDC7+5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 |
From: Nick U. <ni...@ni...> - 2006-07-30 21:07:15
|
Dear Folks, On 31/07/06 06:55 +1000, Nick Urbanik wrote: >It's not solved yet. Please see below. >However, I consistently get a segfault when running the script=20 >http://celestia.h-schmidt.net/nineplanets_v1.0.celx, at the point >where the number of views is reduced back to one, right at the end of >the script. In fact Celestia consistently segfaults when reaching the end of any =2Ecelx script; it does not do so if I press Esc before it has finished. So what needs to be done to fix that? --=20 Nick Urbanik RHCE http://nicku.org ni...@ni... GPG: 7FFA CDC7+5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 |
From: Hank R. <hr...@qw...> - 2006-07-30 22:08:35
|
On Jul 30, 2006, at 2:07 PM, Nick Urbanik wrote: > Dear Folks, > > On 31/07/06 06:55 +1000, Nick Urbanik wrote: >> It's not solved yet. Please see below. >> However, I consistently get a segfault when running the script >> http://celestia.h-schmidt.net/nineplanets_v1.0.celx, at the point >> where the number of views is reduced back to one, right at the end of >> the script. > > In fact Celestia consistently segfaults when reaching the end of any > .celx script; it does not do so if I press Esc before it has > finished. So what needs to be done to fix that? > Nick, The traceback indicates that the segfault is occurring in LuaState::resume at line 716 of celx.cpp: > if (strcmp(errorMessage, "cannot resume dead coroutine") > != 0) This is presumably because errorMessage in nil. You might try: > if (errorMessage && strcmp(errorMessage, "cannot resume > dead coroutine") != 0) - Hank |
From: Nick U. <ni...@ni...> - 2006-07-30 22:23:42
|
Dear Folks, On 30/07/06 15:09 -0700, Hank Ramsey wrote: > >On Jul 30, 2006, at 2:07 PM, Nick Urbanik wrote: > >>Dear Folks, >> >>On 31/07/06 06:55 +1000, Nick Urbanik wrote: >>>It's not solved yet. Please see below. >>>However, I consistently get a segfault when running the script=20 >>>http://celestia.h-schmidt.net/nineplanets_v1.0.celx, at the point >>>where the number of views is reduced back to one, right at the end of >>>the script. >> >>In fact Celestia consistently segfaults when reaching the end of any >>.celx script; it does not do so if I press Esc before it has >>finished. So what needs to be done to fix that? > >Nick, > >The traceback indicates that the segfault is occurring in=20 >LuaState::resume at line 716 of celx.cpp: > >> if (strcmp(errorMessage, "cannot resume dead coroutine")=20 >>!=3D 0) > >This is presumably because errorMessage in nil. You might try: > >> if (errorMessage && strcmp(errorMessage, "cannot resume=20 >>dead coroutine") !=3D 0) Thanks Hank, that seems to have fixed it. I'll test futher before submitting the RPM package to the Fedora Extras Celestia maintainer. --=20 Nick Urbanik RHCE http://nicku.org ni...@ni... GPG: 7FFA CDC7+5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 |
From: Nick U. <ni...@ni...> - 2006-07-31 00:58:18
|
Dear Folks, On 31/07/06 08:23 +1000, Nick Urbanik wrote: >Thanks Hank, that seems to have fixed it. > >I'll test futher before submitting the RPM package to the Fedora >Extras Celestia maintainer. The patch that implements *all* your changes, Hank, are in http://nicku.org/software/celestia/celestia-lua51-resume.patch and the source rpm is http://nicku.org/software/celestia/celestia-1.4.1-2.3nu.src.rpm for FC5. --=20 Nick Urbanik RHCE http://nicku.org ni...@ni... GPG: 7FFA CDC7+5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 |