On Mon, Jun 24, 2019 at 5:57 AM wrote:
>
> On Mon, Jun 24, 2019 at 6:50 AM, mcatanz...@gnome.org wrote:
> > That's not right. The backtrace was processed on the retrace server,
> > so installing debuginfo locally should not be required.
> >
> > I think it's a longstanding ABRT bug.
> >
> > Michael
On Mon, Jun 24, 2019 at 6:50 AM, mcatanz...@gnome.org wrote:
That's not right. The backtrace was processed on the retrace server,
so installing debuginfo locally should not be required.
I think it's a longstanding ABRT bug.
Michael
Oh, I forgot what I was actually planning to write about whe
On Sun, Jun 23, 2019 at 9:34 PM, Sam Varshavchik
wrote:
That's your key piece of info. You're missing the debuginfo package,
without it the backtrace has no info.
With a native, directly-installed RPM, the debug repo gets
automatically enabled, and the debuginfo packages gets automatically
f
OK so after spending three hours downloading and installing debug
symbols, because the generation can't tell me all the symbols needed
in one whack, I get to learn that this is a dup of another bug. I'm
perplexed why a locally generated back trace figures this out, but the
retrace server gives up?
On Sun, Jun 23, 2019 at 8:35 PM Sam Varshavchik wrote:
>
> Chris Murphy writes:
>
> > Please try to install debuginfo manually using the command:
> > "debuginfo-install flatpak-1.4.1-1.fc30" and try again.
>
> That's your key piece of info. You're missing the debuginfo package, without
> it the ba
Chris Murphy writes:
Please try to install debuginfo manually using the command:
"debuginfo-install flatpak-1.4.1-1.fc30" and try again.
That's your key piece of info. You're missing the debuginfo package, without
it the backtrace has no info.
With a native, directly-installed RPM, the deb
ce job started
Analyzing crash data
..
Preparing environment for backtrace generation
.
Generating backtrace
Cleaning environment after backtrace generation
Saving crash statistics
Looking for similar problems in bugzilla
Reporting is disabled because t
