I ran whatever the ebuild told me to run for bench marks... I ended up having to kill the process from a virtual terminal, look for the xterm that I opened it from (having the game window pop up in all black again and again durring this process, killing it each time) finally finding the windo, hitting control-c and had it pop up a few more times before closing that shell... It was surreal. I mistakenly thought that it was done unmerging, and started the game durring the unmerge process, and ... this just beggs the question... What happens if the application is being used while it is being upgraded? Reproducible: Didn't try Steps to Reproduce: 1. 2.I actually tried to reproduce it, but i didn't remember the flag that the ebuild told me to run. 3.
I'm not sure I understand what your problem was exactly... You do realize that the benchmark runs for QUITE some time and runs multiple times, right? I would say it takes at least 10-15 minutes to run all the way through. Let me know what the exact problem is and I'll look into it. Please REOPEN this bug with more information if there is truly a problem. For now I am resolving this with NEEDINFO. =]
maybe not mentioning it so prominently in the ebuild notes would be helpfull. I killed the sucker many times and it just kept comeing back... It could be an isolated incident, I'm just curious what happens to the programs that are running while they get upgraded.
The scripts run ut2003-demo about 20 times, I believe. It runs each benchmark at both low and high detail, and there are about 10 benchmarks, so yes, it is *supposed* to keep spawning. As for uninstalling a running process, if it requires any external files, it would of course fail, but the running process would continue to run until it was killed or died from a fatal error such as being unable to load a needed file.
I didn't find the process to kill when i ran ps aux | grep ut2003 Also, I had my sound server running, so UT was not happy. /hence the black screen that would not go away I think most games / programs that do not support sound servers, should be run in a wrapper to make sure they run with artsdsp, artsdsp -m, or esd's equivilent... but that is probably a different bug.... even though it contributed to this one
I've never had a problem running any of these games with a sound server. In fact, the version of openal that ships with the game *is* sound server aware, at least for both arts and esd. Most, if not all games that use openal for sound are sound server aware provided the openal was compiled with the proper support. Anyway, the script is *not* named ut2003, which is why you didn't find it. In fact, there are several scripts which are run, if I remember correctly. Look in the /opt/ut2003-demo/System/Benchmark folder to check them all out.
Three weeks, no input. Closing.
clean up bug list after bugzilla update
