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