Description of problem: The results.xml format includes a runtime syslog output and additional files beyond sysreport.tar and test.wav. The syslog output should receive it's own column/link in the run log view and the attachments other than sysreport and test.wav should each be listed in the extra files column.
(In reply to comment #0) > Description of problem: > > The results.xml format includes a runtime syslog output and additional files > beyond sysreport.tar and test.wav. The syslog output should receive it's own > column/link in the run log view we didn't extract the system.log from rpm package today, do we need to enable this for rpm formatted pakcages, or just for gz?
Only for xml.gz however it's not limited to just system.log but any attached file should be retrievable. Please note this requires an update to the way xml results are handled, the current method is to pretend that are results.rpm which is not the goal, instead we should using xsl to render the requested parts from the singular stored xml.gz in the db.
Instead of runtime log syslog could be added to the files column? This would avoid the additional column. Sysreport 263452 appears twice I think. Once in run1 once in run2, both times under storage instead of info. Is this correct? The info sosreports-{filename} still show as "sysreport"; can this be updated as well to use the correct file name? Test.wav may need a similar update? (This could be opened as a(two) new BZ?)
(In reply to comment #9) > Instead of runtime log syslog could be added to the files column? This would > avoid the additional column. If we add runtime log to files column, files column will be too crowd > > Sysreport 263452 appears twice I think. Once in run1 once in run2, both times > under storage instead of info. Is this correct? I don't have gz packages those include other attachments than sysreport and test.wav, so, i copied the sysreport from info > > The info sosreports-{filename} still show as "sysreport"; can this be updated > as well to use the correct file name? Test.wav may need a similar update? > (This could be opened as a(two) new BZ?) I think a new bz shoule be opened for this
change status to post, open a new bug for the file name of test.wav and sysreport https://bugzilla.redhat.com/show_bug.cgi?id=803630
patch looks good for me