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