Description of problem: Abrt-cli shows up a broken report on i686/armhfp Version-Release number of selected component (if applicable): abrt-2.6.1-2.fc22.armv7hl How reproducible: Always Steps to Reproduce: 1. Make the app crash 2. abrt-cli ls Actual results: id 8c7f4f30a53901836d2cb8ef8ae378926d542582 reason: caller_uid:%ld method:'%s' time: caller_uid:%ld method:'%s' cmdline: caller_uid:%ld method:'%s' package: caller_uid:%ld method:'%s' uid: caller_uid:%ld method:'%s' (caller_uid:%ld method:'%s') count: caller_uid:%ld method:'%s' Directory: /var/spool/abrt/ccpp-2015-08-24-10:52:41-6154 Journalctl: abrt-server[6178]: Server responded with an error: 'uReport data is invalid.' Expected results: Correct abrt-cli output, report is accepted by server Additional info:
This is present in the KDE live of Fedora 23 RC5 as well. ABRT's version is "abrt-2.6.2-7.fc23.i686" here.
Proposed as a Blocker and Freeze Exception for 23-final by Fedora user juliuxpigface using the blocker tracking app because: Since this affects gnome-abrt, which is a standard application of both release blocking desktops, this bug seems to violate the "2.4.6 Default application functionality" Final criteria. "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." References: - https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria#Default_application_functionality
Yeah, I see it on 32-bit too. In gnome-abrt you have to click 'Details' on a crash to see it. I think I did get a valid report submission, though; perhaps it depends if you use remote retrace or not.
Well, that 'caller_uid' line appears to come from abrt, abrt/src/dbus/abrt-dbus.c , in handle_method_call() : log_notice("caller_uid:%ld method:'%s'", (long)caller_uid, method_name); not sure what's going wrong, there, though, yet.
I'm at least +1 FE for this. I'm kinda on the fence about blocker-iness, it would depend on exactly how likely it would be to submit broken reports.
+1FE here... but yeah, would like to know more before calling it a blocker.
I've reported this and another bug (https://bugzilla.redhat.com/show_bug.cgi?id=1275838) with the "broken" gnome-abrt and found no further issues. If new tests will uncover some bugs, I'll change my votes. But for now... Even though I've proposed it, I'm -1 blocker and +1 FE.
+1 FE and +1 Blocker if it's submitting bad reports all the time.
That's enough votes for FE at least, marking Accepted.
I was able to report #1275844 from a KDE live image suffering from this bug, so it does seem like this is cosmetic (affecting only the info displayed in abrt-cli and gnome-abrt), it doesn't affect actual crash report submission. Funnily, that makes it quite a weak FE for me - fixing https://bugzilla.redhat.com/show_bug.cgi?id=1272355 seems like actually a bigger deal.
Upstream commit https://github.com/abrt/abrt/commit/7fe8403abed51dc951aa497bf149c19d61a19555 fixes this bug. I am going to push the patch to distgit and update https://bodhi.fedoraproject.org/updates/FEDORA-2015-cc585b503f
abrt-2.7.0-2.fc23 libreport-2.6.3-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-cc585b503f
-1 blocker, +1 FE If it's still submitting valid data, then that's the part that's fundamentally important. We can fix the UI in an update.
Yeah, what Stephen Gallagher said. -1 blocker, +1 fe.
abrt-2.7.0-2.fc23, libreport-2.6.3-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.