Description of problem: If ABRT catches a crash which is not related to a Fedora component, and user selects Retrace Server to generate the backtrace, then it uploads fine and seems to end-up in an infinite loop "Initializing virtual root" hence wasting both server resources (I assume) and user's time :) Maybe instead, if the component is not related to Fedora, - Retrace Server shouldn't be offered in backtrace option, or if possible, - Retrace Server should abort immediately and return a meaningful message. or at the very least - Some red warning should be displayed in the GUI, at the time the User may select this option Version-Release number of selected component (if applicable): abrt-2.0.7-2.fc16.x86_64 How reproducible: Always so far i.e. 3 or 4 times = 100% so far (first while I wasn't realizing the component wasn't part of Fedora, and one last time just now to confirm the behaviour) Steps to Reproduce: 1. Pick up a crash related to some extra component eg. guvcview from rpmfusion-free 2. Select "Retrace Servers" Actual results: (I did hit "stop" this time) 2012-05-15-22:26:52> Querying server settings 2012-05-15-22:26:53 Preparing an archive to upload 2012-05-15-22:26:55 Uploading 1178244 bytes 2012-05-15-22:27:05 Uploading 38% 2012-05-15-22:27:16 Uploading 72% 2012-05-15-22:27:25 Upload successful 2012-05-15-22:27:32 Retrace job started 2012-05-15-22:27:44 Analyzing crash data 2012-05-15-22:27:55 Initializing virtual root 2012-05-15-22:28:06 Initializing virtual root 2012-05-15-22:28:17 Initializing virtual root 2012-05-15-22:28:28 Initializing virtual root 2012-05-15-22:28:40 Initializing virtual root 2012-05-15-22:28:51 Initializing virtual root 2012-05-15-22:29:02 Initializing virtual root 2012-05-15-22:29:13 Initializing virtual root 2012-05-15-22:29:24 Initializing virtual root 2012-05-15-22:29:35 Initializing virtual root 2012-05-15-22:29:46 Initializing virtual root 2012-05-15-22:29:57 Initializing virtual root 2012-05-15-22:30:08 Initializing virtual root 2012-05-15-22:30:19 Initializing virtual root 2012-05-15-22:30:30 Initializing virtual root 2012-05-15-22:30:41 Initializing virtual root 2012-05-15-22:30:52 Initializing virtual root 2012-05-15-22:31:03 Initializing virtual root 2012-05-15-22:31:14 Initializing virtual root 2012-05-15-22:31:25 Initializing virtual root 2012-05-15-22:31:36 Initializing virtual root 2012-05-15-22:31:47 Initializing virtual root 2012-05-15-22:31:58 Initializing virtual root 2012-05-15-22:32:09 Initializing virtual root 2012-05-15-22:32:19 Initializing virtual root 2012-05-15-22:32:30 Initializing virtual root 2012-05-15-22:32:42 Initializing virtual root 2012-05-15-22:32:53 Initializing virtual root 2012-05-15-22:33:04 Initializing virtual root 2012-05-15-22:33:15 Initializing virtual root 2012-05-15-22:33:26 Initializing virtual root 2012-05-15-22:33:37 Initializing virtual root 2012-05-15-22:33:48 Initializing virtual root 2012-05-15-22:33:59 Initializing virtual root 2012-05-15-22:34:10 Initializing virtual root 2012-05-15-22:34:21 Initializing virtual root 2012-05-15-22:34:28* (killed by signal 15)
I've modified Retrace Server so that right after upload, it checks whether it is able to handle the specified package or not. Not showing the Retrace Server option in GUI is not a solution - you can still set up your own instance synchronizing with Fedora, rpmfusion and any other 3rd party repository. This way everything will work as expected.
Created attachment 586679 [details] GUI captures "try again later" (with, without "Show log"), no wrap (sorry, long comment) 1. Server abandon > I've modified Retrace Server so that right after upload, it checks > whether it is able to handle the specified package or not. Tested (appended client log to this comment for reference) Not only does it give up gracefully, but ask the "Rightful Question"(tm). Thanks :) My test tarball is 1.2 MiB and took (up to) 1 minute just to get uploaded. Even if greatly reduced, some time, bandwidth and resources are still at pure loss on both server and client sides. Would an earlier check, require a protocol change ? i.e. - Querying server settings *for* package(s) [foo-1.2.3,bar-4.5.6] - Unrecognized package(s) [bar-4.5.6] by server (new exit code) Unless you wanted to collect more data nevertheless, for any reason ? 2. Client UI > Not showing the Retrace Server option in GUI is not a solution - > you can still set up your own instance [...] Indeed, sorry I had missed that point, thanks for clarifying. IMMO, at present the GUI is misleading (cf. attached screen caps). Evil Pop-Up is *commanding* the User to repeat, « Retrace failed. Try again later and if the problem persists report this issue please » which I assume is the client's fixed wording for "no trace obtained for server". Sounds like a 404/502/3/4 http-alike response, so usual on the web, but it's the exact opposite to the current case: * retrace server *was* fully available * it *chose* to reject the job, no point retrying * it *did* respond to the client * retrace did *not* fail Rightful Question is embedded, it gives a perfect clue about what is really going on, but severely lacks visibility: * Show log" is collapsed by default. Why would User expand it after such a common, simple, "temporary unavailable" error did pop up ? * Even if User is following progress in "Show log" while waiting, Evil Pop-Up steals focus *before* Rightful Question gets printed on screen. Then, first printed is the wrong client wording (again). Why would User give any credit, or even read, the rest of the log ? * "Show log" doesn't wrap text either, so the Rightful Question is partly appearing "off-window" by default. Why would User scroll or maximize to find it, again ? * In terms of typography, too, Evil Pop-Up wins by K.O. ! :) So, may I suggest to update the client message for exit code 1, e.g.: « Retrace was not produced by server [retrace.fedoraproject.org]. Cause might be a temporary incident *or* a legitimate refusal. Please read log details carefully. If behavior is abnormal and persistent, please report it. » or better (but heavier change cf. protocol/exit code ?) « One or more of the packages involved were not recognized by retrace server at [retrace.fedoraproject.org]. Please read log details carefully. » (could there be more than one package ?) and/or eventually * complete/refresh "Show log" before Pop-Up window is created * auto-expand "Show log" text area if exit code > x * wrap lines in "Show log" text area (might not be convenient with many long lines) * insert a new line before Rightful Question i.e. "\nIs it a part..." (might not be convenient with numerous extra packages) --- Running analyze_RetraceServer --- Querying server settings Preparing an archive to upload Uploading 1257656 bytes Uploading 28% Uploading 54% Uploading 80% Upload successful Retrace job started Retrace job failed Retrace failed. Try again later and if the problem persists report this issue please. Analyzing crash data Error Package 'guvcview-1.5.3-1.fc16.x86_64' was not recognized. Is it a part of official Fedora release 16 (Verne) repositories? (exited with 1)
> « Retrace failed. Try again later and if the problem persists > report this issue please » I agree, the message is misleading. > (could there be more than one package ?) It can't. Anyway, your request sounds reasonable. Although it is not the highest priority at the moment, I'm probably going to look it.
Fixed in git
Great news, thanks -- I doubt I could find the time to build and install from source any soon, but at least I could test an rpm from UPT if you wish.
Just to clarify cf. closed CURRENTRELEASE, to date latest F16 stable is still 2.0.7-3.fc16.x86_64 and the current behaviour is similar to comment #2. F16 will soon be EOL anyway :) Thanks.