And send where? Upstrem? Where we have a different build config than them? (Let alone think about external libraries). Do we really want our LO to "phone home" on a crash? Do we want to set up a web service for those reports? (The latter one definitely is no)
Well I am not a familiar with QA, but according to what I understand, in TDF releases (I tried nightly before going back to Debian as it was useless), when LO crashes, a crash report is somewhere on the TDF infra. It also is stored on the locl computer. From this file, a user can check wether a bug is opened or not and if not, fill one with reproducible steps and this file to help upstream devs.
Nethertheless I understand that if our build config is different, it may be less relevant. But then, how should users address crashes? Reporting on Debian BTS? Upstream explaining this differences? Only a reproducible scenario and not any trace?
See for example
For a meaningful backtrace you just need the *-dbgsym's, not necessarily the "crash reporter".
Yes but it also requirs skills related to gdb then, doesn't it? I mean, -dbgsym are a base to get relevant crash reports, but how to generate them? The only way I know is running gdb, but il Libreoffice the problem is knowing on which binary.
I perfectly admit that I am not a tchnician, and that is exactly why I try having solutions to help trace and fix bugs upstream without programming skills.
And then there's it using libbreakpad. Which TTBOMK is not packaged, and I am not going to do that (and I am not going to use the internal library for this either).
I can understand, I did not know what implied such wish, hence my will to open the topic.
And if I read upstreams configure.ac right the default for --enable-breakpad even is no. So no: won't do it.
My question is then: is reporting bug upstream from a Debian build relevant? If yes, should not we write something to assist users doing it (a short wiki page about how to help debugging LO from a Debian release)?
Regards
Regards, Rene