----- Original Message -----
On Wed, 13.04.16 08:44, Bastien Nocera (bnocera(a)redhat.com) wrote:
> > On Tue, Apr 12, 2016 at 10:49 PM, Michael Catanzaro
> > <mcatanzaro(a)gnome.org> wrote:
> > > Second, my understanding is
> > > that the ABRT developers prefer to improve abrt-cli and tell people to
> > > use that rather than coredumpctl.
> > Any particular reason for that preference? As coredumpctl gets more
> > and more widespread, having the same tool as other distros should make
> > Fedora more approachable which I think is a good thing?
> The upstream systemd developers I talked to weren't interested in adapting
> coredumpctl to be usable for use cases other than for developers.
What precisely do you need?
I asked, through private mail, and after we discussed this face-to-face:
Could you please send me a piece of code that would:
- monitor the journal for new coredumps
- gather information about the crashed binary (abrt collects things
like envvars and more that allows us to determine which application or
component crashed, whether it's packaged or not, etc.)
- gather information about kernel oopses/lockdep warnings
- store additional metadata about the report, if journald can support
that (whether it was reported and where for example)
> It doesn't claim to be usable for end-users reporting bugs,
> developers have no interest in making changes that would allow that.
I indeed think coredumpctl should probably be something for more
professional users. But I'd be curious what you are missing in
Some help implementing one of:
So that we can eventually move that down a level from ABRT.
To be fair, I misrepresented the discussion, I was actually told it would
be too much work, and that you didn't have the manpower.