DrKonqi backtrace generation broken with gdb 7.8
Albert Astals Cid
aacid at kde.org
Fri Oct 10 18:46:21 UTC 2014
El Divendres, 10 d'octubre de 2014, a les 20:33:14, Andreas K. Huettel va
escriure:
> Am Freitag, 10. Oktober 2014, 19:20:21 schrieb Albert Astals Cid:
> > > > -Exec=gdb -nw -n -batch -x %tempfile -p %pid %execpath
> > > > +Exec=gdb -nw -n -batch -ex "mt set target-async off" -ex "attach
> > > > %pid" -x %tempfile %execpath
> > > >
> > > > BatchCommands=set width 200\nthread\nthread apply all bt
> > >
> > > Upstream bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17446
> > > Upstream commit (probably):
> > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7ec5670becb3f
> > > 9
> > > 78f 4d2f4df252ad0cbf805e37a
> > >
> > > One could also attempt to backport that.
> >
> > I'd say that makes more sense than us changing our code because someone
> > else introduced a regression.
> >
> > Opinions?
>
> A change/backport/patch/update in a core system package is always harder to
> push through on distro level than a corresponding change in a desktop
> environment application.
>
> Please don't rely on the gdb backport.
I'm not relying in a gdb backport, i'm relying in distros doing their job.
I said that i don't think it makes sense to change our code because someone
else introduced a regression.
In your distro you can chose between:
a) fix it in the proper place
b) workaround it in drkonqi
c) let it broken.
It is your duty as system integrator to make sure the systems integrate
correctly, in my opinion KDE has enough problems making sure our own code
works to care when others decide to break theirs.
Cheers,
Albert
More information about the release-team
mailing list