21:19 < gardengnome> stuarta: so, your grief was that the apport stacktraces don't give you the
thread id and the line number, right?
21:20 < stuarta> grief is a bit strong, but yes, the 3 line summary that gdb prints before it gives
you a prompt
21:20 < gardengnome> is it just the lack of a summary? because it seems like the information does
exist in the traces generated by apport
21:21 < gardengnome> let's look at this bug:
21:21 < gardengnome> https://bugs.launchpad.net/ubuntu/+source/mythtv/+bug/107882
21:22 < stuarta> yeah, the info is there but it's much harder to use.
21:23 < gardengnome> ah, you found it yourself. i forgot which one of those traces i meant. :)
21:25 < gardengnome> so, all you need is that short summary?
21:25 < stuarta> that's a good backtrace to look at, there are 34 threads and the one that's dying
is thread 1
21:26 < stuarta> there's 2 basic things that can be improved
21:26 < stuarta> 1. a build that allow the backtraces to have line numbers on all of the myth
21:27 < stuarta> 2. adding that 3 line summary
21:27 < stuarta> #2 isn't major, it's minor, but it cuts down debugging time by making it easier to
find what's going wrong
21:27 -!- cattelan_ [n=cattelan@68.178.56.115] has quit [Read error: 104 (Connection reset by peer)]
21:28 < gardengnome> #2 is easy for this particular, i agree
21:28 < stuarta> if it's easy to add, it would be appreciated.
21:28 < gardengnome> #1 should be doable. #2 might require changing apport to make it act more
gdb-like
21:29 < stuarta> to me, the apport output looks like the gdb output
21:29 < stuarta> that's why we are all suspecting it's using gdb behind the scenes