On Sun, Apr 25, 2021 at 10:38 PM Albert Astals Cid <aa...@kde.org> wrote: > KDE can't do retracing because KDE hasn't built the packages people use > (except KDE Neon).
I've mused on this in the past and I think it can be done, it's just a lot of work that in particular also will need to involve some web software to upload to, and manage crashes in. In broad strokes what needs to happen is: * get a core instead of a trace - sounds simpler than it is because cores can be huge and network speed may be limited. google's breakpad has a special minidump format that seeks to deal with that, I think apport also has its own reduction format. * get all the metadata we can find - this likely needs distro integration depending on the data. this will need (e.g.) a list of either all installed binary packages and their version, or at least the ones supplying the files loaded in memory * upload all the data to a web service and put it in a processing queue * send all the data off to a distro-specific retracing service - the distros would need to supply/maintain this. it'd setup an env as similar to the crashing system as possible, then run a series of gdb commands to then send the output back to us (this could conceivably be as simple as a dockerfile) * we parse the output (which would include a trace) to then either record a new crash or attach the data to an existing crash All of this ideally without falling for alluring NIH solutions. It'd be a huge undertaking and is a bit undermined by the rather excellent debuginfod [1] that makes our existing way of doing things more accessible, albeit network-wise just as expensive. [1] https://sourceware.org/elfutils/Debuginfod.html For further reference: - https://abrt.readthedocs.io/en/latest/ - https://launchpad.net/errors HS
