> 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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
