Better infrastructure for dbgsyms (was: Automatic way to install dbgsym packages for a process?)

2017-08-10 Thread Stefan Fritsch
Hi,

On Wed, 9 Aug 2017, David Kalnischkies wrote:
> I haven't seen the perl script (and I don't speak perl, so even if
> I had), but from the description of the functionality it doesn't sound
> too hard and like a natural fit. Personally I would just prefer if
> someone writes it who knows how it should work and would use it – not me
> who doesn't even have the debug archive in its sources (as libc6-dbg is
> not a -dbgsym yet) nor deals with crash.dumps all too often…
> 
> 
> Long story short: I am happy to help via IRC/deity@ & Julian is at
> DebConf in case someone wants to talk about apt in person.

I agree that integration in apt would be a good idea. But until then, 
having the script packaged makes sense. I have filed a wishlist bug 
agianst debian-goodies:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871620

BTW, in some discussions some other questions were raised:

- Is it really a good idea that foo-dbgsym depends on "foo (== 
foo-version)"? Wouldn't a Conflict or breaks on "foo (!= foo-version)" 
make more sense respective package? Consider that you want to analyze the 
core dump on a different system and foo may pull in quite a lot of 
dependencies, start servers, etc.

- Is it allowed for packages that are not in the debug section to depend 
on packages in the debug section. For example, to make a meta package that 
depends on a set of useful dbgsym packages? But the need for this would 
probably go away with better apt integration.

- Would an option to put all symbols from a source package into a single 
dbgsym package make sense? This would allow to get rid of all those dbgsym 
packages with only a single small file in them.

- Should we put the URL of the debug sym sources.list entry into the 
release file of the non-debug sym section? That way, apt could determine 
the location of the dbgsym packages by itself without having to edit 
sources.list.


Cheers,
Stefan

Re: Automatic way to install dbgsym packages for a process?

2017-08-09 Thread David Kalnischkies
On Wed, Aug 09, 2017 at 06:07:23AM +0900, Mike Hommey wrote:
> One would argue this should be a feature of apt. In Fedora land, you use

And apt developers would argue back that apt could indeed do it if
someone would write a patch – which isn't a new idea, the ddeb
granddaddy of what we have now already suggested apt changes [0] in
2006…

I haven't seen the perl script (and I don't speak perl, so even if
I had), but from the description of the functionality it doesn't sound
too hard and like a natural fit. Personally I would just prefer if
someone writes it who knows how it should work and would use it – not me
who doesn't even have the debug archive in its sources (as libc6-dbg is
not a -dbgsym yet) nor deals with crash.dumps all too often…


Long story short: I am happy to help via IRC/deity@ & Julian is at
DebConf in case someone wants to talk about apt in person.


Best regards

David Kalnischkies

[0] https://wiki.ubuntu.com/AptElfDebugSymbols


signature.asc
Description: PGP signature


Re: Automatic way to install dbgsym packages for a process?

2017-08-08 Thread Mike Hommey
On Tue, Aug 08, 2017 at 04:02:59PM +0200, Vincent Lefevre wrote:
> On 2017-08-08 15:53:34 +0200, Stefan Fritsch wrote:
> > Now, where to put it? Into devscripts? The disadvantage is that devscripts 
> > already pulls in quite a few other packages via recommends. But I don't 
> > have a better idea. Unless we want to include it in reportbug or something 
> > like that?
> 
> The one-line description of devscripts is:
> 
>   scripts to make the life of a Debian Package maintainer easier
> 
> So it's mainly targeted at Debian Package maintainers, while such
> a script would be useful to end users.
> 
> Perhaps debian-goodies?

One would argue this should be a feature of apt. In Fedora land, you use
yum or dnf for debug packages, and btw, that's really something that's
missing in Debian.

Mike



Re: Automatic way to install dbgsym packages for a process?

2017-08-08 Thread Stefan Fritsch
On Tue, 8 Aug 2017, Vincent Lefevre wrote:

> On 2017-08-08 15:53:34 +0200, Stefan Fritsch wrote:
> > Now, where to put it? Into devscripts? The disadvantage is that devscripts 
> > already pulls in quite a few other packages via recommends. But I don't 
> > have a better idea. Unless we want to include it in reportbug or something 
> > like that?
> 
> The one-line description of devscripts is:
> 
>   scripts to make the life of a Debian Package maintainer easier
> 
> So it's mainly targeted at Debian Package maintainers, while such
> a script would be useful to end users.
> 
> Perhaps debian-goodies?

True, that's a better match. I will polish it a bug and then submit it.

Cheers,
Stefan



Re: Automatic way to install dbgsym packages for a process?

2017-08-08 Thread Vincent Lefevre
On 2017-08-08 15:53:34 +0200, Stefan Fritsch wrote:
> Now, where to put it? Into devscripts? The disadvantage is that devscripts 
> already pulls in quite a few other packages via recommends. But I don't 
> have a better idea. Unless we want to include it in reportbug or something 
> like that?

The one-line description of devscripts is:

  scripts to make the life of a Debian Package maintainer easier

So it's mainly targeted at Debian Package maintainers, while such
a script would be useful to end users.

Perhaps debian-goodies?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Re: Automatic way to install dbgsym packages for a process?

2017-08-08 Thread Stefan Fritsch
On Mon, 7 Aug 2017, Paul Wise wrote:

> On Sun, Aug 6, 2017 at 12:14 PM, Stefan Fritsch wrote:
> 
> > Is there some tool that parses /proc/maps and the build-ids fields from
> > the apt repository to determine which dbgsym packages to install?
> 
> Not AFAIK but I guess that Fedora probably has a script for this somewhere.

Thanks for the pointer. I didn't find anything for /proc/$$/maps but there 
is eu-unstrip from elfutils which gives the list of Build-IDs from a core 
file.

I hacked together a perl script that uses that and grep-aptavail to get 
the list of packages (assuming you already have the correct entries in 
sources.list).

Now, where to put it? Into devscripts? The disadvantage is that devscripts 
already pulls in quite a few other packages via recommends. But I don't 
have a better idea. Unless we want to include it in reportbug or something 
like that?

> The service to map build-ids to snapshot.d.o packages is not fully
> implemented yet either.
> 
> http://build-id.debian.net/ (code on lw08.d.o)

That would be nice. But I don't think I have time to look into that in the 
forseeable future.

Cheers,
Stefan



Re: Automatic way to install dbgsym packages for a process?

2017-08-07 Thread Paul Wise
On Sun, Aug 6, 2017 at 12:14 PM, Stefan Fritsch wrote:

> Is there some tool that parses /proc/maps and the build-ids fields from
> the apt repository to determine which dbgsym packages to install?

Not AFAIK but I guess that Fedora probably has a script for this somewhere.

The service to map build-ids to snapshot.d.o packages is not fully
implemented yet either.

http://build-id.debian.net/ (code on lw08.d.o)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Automatic way to install dbgsym packages for a process?

2017-08-06 Thread Stefan Fritsch
Hi,

I am looking into switching apache2/libapr/libaprutil from explicit -dbg 
packages to the automatic dbgsym packages. And since I have included a 
README.backtrace in apache2, I wonder how one describes to a sysadmin that 
has no clue about software development which dbgsym packages they need to 
install.

There is of course the problem that there are many modules for apache2, 
and also libaprutil1 has some plugins. So the obvious approach of 
recommending to install all dbgsym packages that may be relevant is not 
feasible.

Is there some tool that parses /proc/maps and the build-ids fields from 
the apt repository to determine which dbgsym packages to install?

Cheers,
Stefan