Question about debugging info for AppImage and Snap
Boudewijn Rempt
boud at valdyas.org
Fri Jun 17 13:20:56 UTC 2016
On Fri, 17 Jun 2016, Dmitry Kazakov wrote:
> > > 2) If not, why don't we build a dbg-enabled version of the package? I
> > don't
> > > think it is too difficult. It might be done from the same build tree from
> > > the same script, just skipping/packaging before the stripping phase. Can
> > we
> > > correct our scripts to produce that?
> >
> > Yes, that's possible. The package would be really big, and files.kde.org
> > is
> > already groaning under the strain of all the packages we do, so I would do
> > this for specific investigations instead of as a matter of course.
> >
> > I haven't tried getting a backtrace from a package with debug symbols yet.
> >
>
> How about having the the backtrace-enabled package for the latest build
> only? Like having 'krita3-current.appimage' and
> 'krita3-dbg-current.appimage'? That would solve both problems, the amount
> of space occupied on the depot and the presence at least of one testing
> package for everyone.
Yes, that should be doable.
> The dbg version could be updated in the same way as I
> do for translations tarball.
That actually broke so I had to remove the symlink again. CentOS's wget
got confused by it.
>
>
> > > 3) What is the status of debugging info for the snap packages? Do they
> > > support that? If yes can we use them for testing the bugreports?
> >
> > No idea at all. Well, that's not quite true. I know that snap got a lot of
> > flak because their libreoffice snap was soooooo big, but that included the
> > debug symbols, too: http://lwn.net/Articles/691309/#Comments
> >
>
> I guess we should ask Michael about that...
>
>
>
--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
More information about the kimageshop
mailing list