Review Request 128437: raise to core dump handlers when drkonqi is done

[Kevin Kofler]

> On Juli 13, 2016, 12:43 nachm., Kai Uwe Broulik wrote:
> > +1 to the idea
> > 
> > However, will this mean we get this awful apport "something crashed, now or in the past" tray icon in addition to Drkonqi?
> 
> Harald Sitter wrote:
>     yes. its upon ubuntu to make that go away though as their use case is more involved.
> 
> Harald Sitter wrote:
>     To expand. here's how I did this for kubuntu in kdelibs4: https://community.kde.org/Kubuntu/QA/Whoopsie tldr: disable apport UI (replaced by drkonqi) but retain whoopsie (crash report sending to errors.ubuntu.com). As I mentioned, this needs dealing with in ubuntu since they essentially attach a UI to coredumps, so either that or drkonqi need disabling on their platform.

The problem with the duplicate UI will also affect Fedora/RHEL's ABRT and probably also other similar crash handlers. In addition, I am not convinced automatic crash report sending to a downstream tracker (i.e., the part of the Apport functionality you retain in Kubuntu) is helpful. (I like how DrKonqi sends the reports directly to the actual developers.)


- Kevin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128437/#review97345
-----------------------------------------------------------


On Juli 13, 2016, 12:40 nachm., Harald Sitter wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128437/
> -----------------------------------------------------------
> 
> (Updated Juli 13, 2016, 12:40 nachm.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcrash
> 
> 
> Description
> -------
> 
> with the rise of useful core dump handlers such as systemd's coredump and
> ubuntu's apport it is no longer useful to handle things exclusively in
> drkonqi. it bypasses sysadmins as well as distros in debugging efforts,
> putting the entire flow of information on us.
> 
> the new behavior instead checks if a core pattern executable is set and if
> so re-raises the signal so the kernel jumps in and invokes the handler.
> 
> (this unfortunately means that the core will contain our kcrash frames,
> but that seems hardly avoidable)
> 
> 
> Diffs
> -----
> 
>   autotests/CMakeLists.txt e442520269835df71968bf7818aa34bd8bd945cf 
>   autotests/core_patterns/exec PRE-CREATION 
>   autotests/core_patterns/no-exec PRE-CREATION 
>   autotests/coreconfigtest.cpp PRE-CREATION 
>   src/CMakeLists.txt e733be69c6ca6e6c1a0608c8910cf4a9b52ffcc9 
>   src/coreconfig.cpp PRE-CREATION 
>   src/coreconfig_p.h PRE-CREATION 
>   src/kcrash.cpp b8c6477a70291ca9c1f0efef3bba061b6af247b0 
> 
> Diff: https://git.reviewboard.kde.org/r/128437/diff/
> 
> 
> Testing
> -------
> 
> builds and passes
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160714/16b397a8/attachment-0001.html>