Hi Andrej (2012.10.29_17:18:41_+0200)
> >The -dbgsym packages are only generated in primary archive builds.
>
> I'm sorry to disappoint you about the Ubuntu PPAs but look into my
> PPA - https://launchpad.net/~andrej-rep/+archive/ppa/+packages - to see
> all those dbg packages. And users were
Hello!
Tzafrir Cohen has written on Tuesday, 30 October, at 17:04:
>On Mon, Oct 29, 2012 at 05:18:41PM +0200, Andrej N. Gritsenko wrote:
>> Stefano Rivera has written on Monday, 29 October, at 16:57:
>> >Hi Tzafrir (2012.10.29_16:29:06_+0200)
>> >> While clearing your throat, mind telling us h
On Mon, Oct 29, 2012 at 05:18:41PM +0200, Andrej N. Gritsenko wrote:
> Hello!
>
> Stefano Rivera has written on Monday, 29 October, at 16:57:
> >Hi Tzafrir (2012.10.29_16:29:06_+0200)
> >> While clearing your throat, mind telling us how this works in Ubuntu
> >> with PPAs? What happens if you
On Mon, Oct 29, 2012 at 10:48:24AM +, Philip Ashmore wrote:
> >>On Mon, Oct 29, 2012 at 8:50 AM, Philip Ashmore wrote:
> >>>While this feature allows gdb to know the correct source locations, using
> >>>it
> >>>implies that packages requiring the feature contain incorrect source paths
> >>>-
Hello!
Stefano Rivera has written on Monday, 29 October, at 16:57:
>Hi Tzafrir (2012.10.29_16:29:06_+0200)
>> While clearing your throat, mind telling us how this works in Ubuntu
>> with PPAs? What happens if you installed a package from a PPA and you
>> want to generate a backtrace of a progr
Hi Tzafrir (2012.10.29_16:29:06_+0200)
> While clearing your throat, mind telling us how this works in Ubuntu
> with PPAs? What happens if you installed a package from a PPA and you
> want to generate a backtrace of a program that happens to use that
> package?
>
> 1. You'll get debug information
On Sun, Oct 28, 2012 at 08:03:25AM +, Philip Ashmore wrote:
> Yeah, in (cough)Fedora, kdbg even offers to download and install debug
> packages for you.
> Debug packages also make back-traces more than useless, and
> (cough)Ubuntu offers to download debug packages which it installs and
>
On 29/10/12 07:25, Neil Williams wrote:
On Mon, 29 Oct 2012 08:53:05 +0800
Paul Wise wrote:
On Mon, Oct 29, 2012 at 8:50 AM, Philip Ashmore wrote:
While this feature allows gdb to know the correct source locations, using it
implies that packages requiring the feature contain incorrect source
Michael Biebl wrote:
>Afaik the work was started by pochu as port of GSoC [1][2]. According
>to
>[3], Marc was his mentor. I've CCed both, maybe they can comment on
>what's still missing.
>I'd love to see that happen.
Joss ended up being the mentor (melange lists this correctly). I don't rememb
On Mon, 29 Oct 2012 08:53:05 +0800
Paul Wise wrote:
> On Mon, Oct 29, 2012 at 8:50 AM, Philip Ashmore wrote:
>
> > While this feature allows gdb to know the correct source locations, using it
> > implies that packages requiring the feature contain incorrect source paths -
> > wouldn't it be bett
On Mon, Oct 29, 2012 at 8:50 AM, Philip Ashmore wrote:
> While this feature allows gdb to know the correct source locations, using it
> implies that packages requiring the feature contain incorrect source paths -
> wouldn't it be better for these packages to contain correct source paths in
> the f
On 28/10/12 16:09, Wouter Verhelst wrote:
On Sun, Oct 28, 2012 at 08:03:25AM +, Philip Ashmore wrote:
Having the sources installed in /usr/src and referenced there rather
than /buildd would be an improvement too.
That's why there is the 'substitute-path' feature in gdb to fix that. Also se
* Ben Hutchings [121028 17:02]:
> There are plenty of bugs that involve 'undefined behaviour' that in
> practice depends on whether optimisation is enabled. Unless you have a
> good idea what's going wrong, how do you know that 'noopt' won't hide
> the bug?
If the bug still shows up with the lib
On Sun, Oct 28, 2012 at 08:03:25AM +, Philip Ashmore wrote:
> Having the sources installed in /usr/src and referenced there rather
> than /buildd would be an improvement too.
That's why there is the 'substitute-path' feature in gdb to fix that. Also see
http://grep.be/blog/en/computer/code/gdb
On Sun, 2012-10-28 at 11:35 +0100, Bernhard R. Link wrote:
> * Philip Ashmore [121028 09:12]:
> > Yeah, in (cough)Fedora, kdbg even offers to download and install
> > debug packages for you.
> > Debug packages also make back-traces more than useless, and
> > (cough)Ubuntu offers to download debug
* Philip Ashmore [121028 09:12]:
> Yeah, in (cough)Fedora, kdbg even offers to download and install
> debug packages for you.
> Debug packages also make back-traces more than useless, and
> (cough)Ubuntu offers to download debug packages which it installs
> and re-examines the back-trace to see if
Philip Ashmore writes:
> Debug packages also make back-traces more than useless, and
They also allow systemtap to probe userland binaries once
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691167 is fixed.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "
On 27/10/12 19:30, Michael Biebl wrote:
On 27.10.2012 12:25, Vincent Bernat wrote:
Hi!
Libraries with `-dbg` package are a pain to deal with when debugging
some problem. The solution to ask each user to rebuild the library
without stripping debug symbols[1] seem suboptimal. Asking each
maintain
On 27.10.2012 12:25, Vincent Bernat wrote:
> Hi!
>
> Libraries with `-dbg` package are a pain to deal with when debugging
> some problem. The solution to ask each user to rebuild the library
> without stripping debug symbols[1] seem suboptimal. Asking each
> maintainer to ship a `-dbg` package may
Do not kick me, but in Solaris, there are :
1) special ELF section .SUNW_ldynsym extending .dynsym [1]
2) .SUNW_ctf with CTF data [2]
3) Function args are saved in stack for amd64
But from my point all it exists because Solaris lacks robust
package manager :-)
[1] https://blogs.oracle.com/ali/en
❦ 27 octobre 2012 12:42 CEST, Andrey Rahmatullin :
>> Libraries with `-dbg` package are a pain to deal with when debugging
>> some problem.
> You probably mean "without".
Yes.
--
printk(KERN_WARNING "Multi-volume CD somehow got mounted.\n");
2.2.16 /usr/src/linux/fs/isofs/inode.c
pg
On Sat, Oct 27, 2012 at 12:25:31PM +0200, Vincent Bernat wrote:
> Libraries with `-dbg` package are a pain to deal with when debugging
> some problem.
You probably mean "without".
--
WBR, wRAR
signature.asc
Description: Digital signature
am it?
[1]: http://wiki.debian.org/HowToGetABacktrace
[2]:
http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/18-Mandatory-dbg-packages-for-libraries.html
[3]: https://wiki.ubuntu.com/DebuggingProgramCrash
[4]: http://debug.debian.net/
--
To UNSUBSCRIBE, email to debian-devel
On Tue, May 22, 2007 at 11:26:38PM +0200, Wouter Verhelst wrote:
> On Tue, May 22, 2007 at 04:10:06PM -0500, Steve Greenland wrote:
> [...]
> > Those are good reasons. Those are different reasons than "static
> > libraries are faster", which was the previous argument for keeping them.
>
> No, tha
On Tue, May 22, 2007 at 04:10:06PM -0500, Steve Greenland wrote:
[...]
> Those are good reasons. Those are different reasons than "static
> libraries are faster", which was the previous argument for keeping them.
No, that was "one" argument for keeping them, and the only one that I
could come up
On 22-May-07, 13:40 (CDT), Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> On Sun, May 20, 2007 at 09:19:52PM -0500, Steve Greenland wrote:
> > Why should we spend time and space to provide something that doesn't
> > do anything useful?[1]
>
> I also once heard an argument that static libraries are
On Sun, May 20, 2007 at 09:19:52PM -0500, Steve Greenland wrote:
> On 20-May-07, 13:41 (CDT), Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > On Wed, May 09, 2007 at 11:28:49AM -0500, Steve Greenland wrote:
> > > On 09-May-07, 04:02 (CDT), Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > > > I'm not
On 20-May-07, 13:41 (CDT), Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> On Wed, May 09, 2007 at 11:28:49AM -0500, Steve Greenland wrote:
> > On 09-May-07, 04:02 (CDT), Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > > I'm not entirely sure about the specifics, and especially not across
> > > archi
On Wed, May 09, 2007 at 11:28:49AM -0500, Steve Greenland wrote:
> On 09-May-07, 04:02 (CDT), Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > I'm not entirely sure about the specifics, and especially not across
> > architectures; but regardless, doing a PLT lookup is more expensive than
> > doing a
On 09-May-07, 04:02 (CDT), Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> On Tue, May 08, 2007 at 02:23:37PM +0200, Josselin Mouette wrote:
> > Le lundi 07 mai 2007 ? 13:02 +0200, Wouter Verhelst a ?crit :
> > > > Dropping most .a libraries is something I agree with. I see no reason
> > > > why we
On Tue, May 08, 2007 at 02:23:37PM +0200, Josselin Mouette wrote:
> Le lundi 07 mai 2007 à 13:02 +0200, Wouter Verhelst a écrit :
> > > Dropping most .a libraries is something I agree with. I see no reason
> > > why we should have them for most of the libraries.
> >
> > As a courtesy to our users
On Mon, May 07, 2007 at 08:25:53PM +0200, Kurt Roeckx wrote:
> On Mon, May 07, 2007 at 01:02:17PM +0200, Wouter Verhelst wrote:
> > On Mon, Apr 23, 2007 at 12:32:37AM +0200, Kurt Roeckx wrote:
> > > On Sun, Apr 22, 2007 at 11:15:36PM +0100, Roger Leigh wrote:
> > > >
> > > > If there are concerns
Le lundi 07 mai 2007 à 13:02 +0200, Wouter Verhelst a écrit :
> > Dropping most .a libraries is something I agree with. I see no reason
> > why we should have them for most of the libraries.
>
> As a courtesy to our users. Statically linked programs are slightly
> faster (since they don't need to
On Mon, May 07, 2007 at 01:02:17PM +0200, Wouter Verhelst wrote:
> On Mon, Apr 23, 2007 at 12:32:37AM +0200, Kurt Roeckx wrote:
> > On Sun, Apr 22, 2007 at 11:15:36PM +0100, Roger Leigh wrote:
> > >
> > > If there are concerns over archive size, why don't we drop all static
> > > .a libraries at t
On Mon, Apr 23, 2007 at 12:32:37AM +0200, Kurt Roeckx wrote:
> On Sun, Apr 22, 2007 at 11:15:36PM +0100, Roger Leigh wrote:
> >
> > If there are concerns over archive size, why don't we drop all static
> > .a libraries at the same time. Given that in Debian we typically
> > always link dynamicall
Stefano Zacchiroli <[EMAIL PROTECTED]> writes:
> That's all true, but it fails to convince me that is better not to state
> this in the policy than to state it (only Steve's point about "wrong API
> docs", but I'm convinced it will be quantitatively small). My approach
> to this is first to decide
On 29-Apr-07, 03:10 (CDT), Peter Samuelson <[EMAIL PROTECTED]> wrote:
>
> [Neil Williams]
> > I chose Debian as a development platform for my own reasons and my
> > decision was "not deemed to be wise" in the eyes of some of my
> > upstream colleagues. As the newbie to that particular team, I was
On Sun, Apr 29, 2007 at 09:23:03AM +0200, Stefano Zacchiroli wrote:
> docs", but I'm convinced it will be quantitatively small). My approach
> to this is first to decide whether API docs in the policy is something
> we want in debian or not. Then, if it is the case, to state it in the
> policy. Th
[Neil Williams]
> I chose Debian as a development platform for my own reasons and my
> decision was "not deemed to be wise" in the eyes of some of my
> upstream colleagues. As the newbie to that particular team, I was
> under significant pressure to "upgrade to Fedora or SuSE".
Are you saying Fed
On Sat, Apr 28, 2007 at 02:37:46PM -0700, Steve Langasek wrote:
> write documentation or don't understand the API. Wrong API docs are surely
> worse than not having no docs, aren't they?
> If I thought putting it in policy would significantly improve the
> availability of API docs in Debian, I wo
Stefano Zacchiroli <[EMAIL PROTECTED]> writes:
> Fair enough, but note that having man pages is actually addressed by the
> policy. Why do you think API doc shouldn't? After all man pages are docs
> for users and API doc are too, with the only difference that in the
> latter case the "users" are p
On Wed, Apr 25, 2007 at 04:23:38PM +0200, Stefano Zacchiroli wrote:
> On Tue, Apr 24, 2007 at 08:12:46AM -0700, Steve Langasek wrote:
> > > If we are talking about hand-written documentation you're of course
> > > right. However if you're talking about documentation which can be
> > > generated aut
Josselin Mouette <[EMAIL PROTECTED]> writes:
> Le mardi 24 avril 2007 à 18:09 +0200, Reinhard Tartler a écrit :
>> Sending core dumps is of course debatable, espec. if you cannot assert
>> that no sensitive information is transmitted. Still, Apport is more than
>> that. It also describes the mecha
On Tue, 2007-04-24 at 14:40 +0200, Loïc Minier wrote:
> On Tue, Apr 24, 2007, Josselin Mouette wrote:
> > Apport sends complete core dumps, which is a very bad idea. The dumps
> > can be huge (for desktop applications they often grow beyond 200MB) and
> > they can contain gazillions of sensitive in
Le mardi 24 avril 2007 à 18:09 +0200, Reinhard Tartler a écrit :
> Sending core dumps is of course debatable, espec. if you cannot assert
> that no sensitive information is transmitted. Still, Apport is more than
> that. It also describes the mechanism of debug packages (*.ddeb), which
> are genera
Le mardi 24 avril 2007 à 23:43 +0200, Pierre THIERRY a écrit :
> Scribit Daniel Jacobowitz dies 23/04/2007 hora 16:19:
> > Another possible way to change glibc would be to have libc6-dbg
> > contain full debug symbols, libc6-dev contain -g1 symbols only, and
> > have the -dbg divert the -dev.
>
>
On Tue, Apr 24, 2007 at 11:43:02PM +0200, Pierre THIERRY wrote:
> Scribit Daniel Jacobowitz dies 23/04/2007 hora 16:19:
> > Another possible way to change glibc would be to have libc6-dbg
> > contain full debug symbols, libc6-dev contain -g1 symbols only, and
> > have the -dbg divert the -dev.
>
>
On Tue, Apr 24, 2007 at 08:12:46AM -0700, Steve Langasek wrote:
> > If we are talking about hand-written documentation you're of course
> > right. However if you're talking about documentation which can be
> > generated automatically from sources (and not that it was the "ideal"
> > point of Neil)
Scribit Daniel Jacobowitz dies 23/04/2007 hora 16:19:
> Another possible way to change glibc would be to have libc6-dbg
> contain full debug symbols, libc6-dev contain -g1 symbols only, and
> have the -dbg divert the -dev.
Why not do that for every library?
Curiously,
Pierre
--
[EMAIL PROTECTED]
Loïc Minier <[EMAIL PROTECTED]> writes:
> On Tue, Apr 24, 2007, Josselin Mouette wrote:
>> Apport sends complete core dumps, which is a very bad idea. The dumps
>> can be huge (for desktop applications they often grow beyond 200MB) and
>> they can contain gazillions of sensitive information.
> B
On Tue, 2007-04-24 at 14:40 +0200, Loïc Minier wrote:
> On Tue, Apr 24, 2007, Josselin Mouette wrote:
> > Apport sends complete core dumps, which is a very bad idea. The dumps
> > can be huge (for desktop applications they often grow beyond 200MB) and
> > they can contain gazillions of sensitive in
Am Dienstag 24 April 2007 14:12 schrieb Josselin Mouette:
> Using a central server for symbol lookup like Ben proposed looks like a
> better idea. It needs gdb to be adapted or wrapped to access them
> correctly, though.
You can't do offline debugging with a central server. Unless you are always-o
Josselin Mouette <[EMAIL PROTECTED]> writes:
> Le mardi 24 avril 2007 à 12:58 +0200, Reinhard Tartler a écrit :
>> Ben Hutchings <[EMAIL PROTECTED]> writes:
>>
>> > Installing debugging symbols for all binaries involved in a crash
>> > seems... heavyweight. I would expect the user to want to get
On Tue, Apr 24, 2007 at 02:40:22PM +0200, Loïc Minier wrote:
> On Tue, Apr 24, 2007, Josselin Mouette wrote:
> > Apport sends complete core dumps, which is a very bad idea. The dumps
> > can be huge (for desktop applications they often grow beyond 200MB) and
> > they can contain gazillions of sensi
On Tue, Apr 24, 2007 at 09:13:18AM +0200, Stefano Zacchiroli wrote:
> On Mon, Apr 23, 2007 at 04:27:34PM -0700, Steve Langasek wrote:
> > > > On 23-Apr-07, 15:51 (CDT), Neil Williams <[EMAIL PROTECTED]> wrote:
> > > > > I think that all libraries - without exception - must come with some
> > > > >
On Tue, Apr 24, 2007 at 02:12:39PM +0200, Josselin Mouette wrote:
> Le mardi 24 avril 2007 à 12:58 +0200, Reinhard Tartler a écrit :
> > Ben Hutchings <[EMAIL PROTECTED]> writes:
> >
> > > Installing debugging symbols for all binaries involved in a crash
> > > seems... heavyweight. I would expect
On Tue, Apr 24, 2007, Josselin Mouette wrote:
> Apport sends complete core dumps, which is a very bad idea. The dumps
> can be huge (for desktop applications they often grow beyond 200MB) and
> they can contain gazillions of sensitive information.
But Apport is written already, and it's also the
Le mardi 24 avril 2007 à 12:58 +0200, Reinhard Tartler a écrit :
> Ben Hutchings <[EMAIL PROTECTED]> writes:
>
> > Installing debugging symbols for all binaries involved in a crash
> > seems... heavyweight. I would expect the user to want to get on with
> > his or her work at this point.
> >
> >
Ben Hutchings <[EMAIL PROTECTED]> writes:
> Installing debugging symbols for all binaries involved in a crash
> seems... heavyweight. I would expect the user to want to get on with
> his or her work at this point.
>
> Wouldn't it be better - in terms of response rate - to take a
> "minidump" (al
On Mon, 2007-04-23 at 10:37 +0200, Josselin Mouette wrote:
> Le dimanche 22 avril 2007 à 20:39 +0100, Neil Williams a écrit :
> > I'd like to see all library source packages having a minimum of 4
> > binary packages required by Policy: the SONAME, the -dev, the -dbg and
> > a -doc package. (Librar
On Mon, 23 Apr 2007 19:32:46 -0400
Joey Hess <[EMAIL PROTECTED]> wrote:
> Neil Williams wrote:
> > I chose Debian as a development platform for my own reasons and my
> > decision was "not deemed to be wise" in the eyes of some of my
> > upstream colleagues. As the newbie to that particular team, I
On Mon, Apr 23, 2007 at 04:27:34PM -0700, Steve Langasek wrote:
> > > On 23-Apr-07, 15:51 (CDT), Neil Williams <[EMAIL PROTECTED]> wrote:
> > > > I think that all libraries - without exception - must come with some
> > > > API documentation and the docs should be as complete and as accurate
> > > >
Neil Williams wrote:
> There is a distinct lack of man (3) and "coordinated" documentation for
> libraries in Debian. True, some poorly documented packages include test
> programs or examples somewhere under /usr/share/doc/ but it isn't
> simple to track these down.
Is it unreasonable to expect
On Sun, Apr 22, 2007 at 07:29:55PM -0400, Joey Hess wrote:
> Neil Williams wrote:
> > > > Certain packages have already had bug reports requesting a -dbg
> > > > package.
> > >
> > > I'd rather see some offline debug-symbol infrastructure for all
> > > packages implemented, so that you can download
On Mon, 23 Apr 2007 15:05:22 -0400, Joey Hess <[EMAIL PROTECTED]> said:
>> I would rather add it as a recommended practice in policy, with a
>> note that it will become a should/must as we get better coverage, and
>> _also_ provide examples of what maintainers need to do to create
>> separate de
On Sun, 2007-04-22 at 22:14 +0200, Florian Weimer wrote:
> * Neil Williams:
>
> > Apart from those limitations, is there a *technical* reason why -dbg
> > packages should not be available?
>
> GCC's debugging information at -O2 will continue to worsen (in part as
> a result of -O2 getting better)
On Sun, 2007-04-22 at 22:31 +0200, Hendrik Sattler wrote:
> Am Sonntag 22 April 2007 22:12 schrieb Russ Allbery:
> > Hendrik Sattler <[EMAIL PROTECTED]> writes:
> > > Am Sonntag 22 April 2007 21:39 schrieb Neil Williams:
> > >> Apart from those limitations, is there a *technical* reason why -dbg
>
Neil Williams wrote:
> I chose Debian as a development platform for my own reasons and my
> decision was "not deemed to be wise" in the eyes of some of my upstream
> colleagues. As the newbie to that particular team, I was under
> significant pressure to "upgrade to Fedora or SuSE". Debian needs to
On Tue, Apr 24, 2007 at 12:00:59AM +0100, Neil Williams wrote:
> On Mon, 23 Apr 2007 16:15:02 -0500
> Steve Greenland <[EMAIL PROTECTED]> wrote:
> > On 23-Apr-07, 15:51 (CDT), Neil Williams <[EMAIL PROTECTED]> wrote:
> > > I think that all libraries - without exception - must come with some
> > >
Neil Williams wrote:
> Would these changes need a GR?
Why would a policy change need a GR? How could a GR possibly be the best
way to choose a sound technical policy?
--
see shy jo
signature.asc
Description: Digital signature
On Mon, 23 Apr 2007 16:15:02 -0500
Steve Greenland <[EMAIL PROTECTED]> wrote:
> On 23-Apr-07, 15:51 (CDT), Neil Williams <[EMAIL PROTECTED]> wrote:
> > I think that all libraries - without exception - must come with some
> > API documentation and the docs should be as complete and as accurate
> >
On 23-Apr-07, 15:51 (CDT), Neil Williams <[EMAIL PROTECTED]> wrote:
> I think that all libraries - without exception - must come with some
> API documentation and the docs should be as complete and as accurate
> as possible - ideally generated from the source itself.
That's not a Debian issue. Al
On Sun, 22 Apr 2007 20:39:26 +0100
Neil Williams <[EMAIL PROTECTED]> wrote:
After reading the responses so far, the -doc element of my original
idea needs modification.
> I'd like to see all library source packages having a minimum of 4
> binary packages required by Policy: the SONAME, the -dev,
On Mon, 23 Apr 2007 21:19:39 +0100
Mark Brown <[EMAIL PROTECTED]> wrote:
> Reading between the lines I think Neil is assuming that good
> documentation has to be large enough to be worth splitting out.
In a lot of cases, yes. I do accept that some libraries - and
particularly perl modules - do no
On Mon, 23 Apr 2007 12:22:40 -0500
Steve Greenland <[EMAIL PROTECTED]> wrote:
> You seem to be arguing that the man pages should be in the core
> library package, yes?
I would prefer a -doc package that covers the entire API in a
comprehensive and detailed manner, registered with helper programs
On Mon, Apr 23, 2007 at 12:22:40PM -0500, Steve Greenland wrote:
> On 22-Apr-07, 17:01 (CDT), Neil Williams <[EMAIL PROTECTED]> wrote:
> > I think libraries should be encouraged to provide significant
> > documentation - what we have now is simply not enough.
> You seem to be arguing that the ma
On Mon, Apr 23, 2007 at 03:19:23PM -0400, Joey Hess wrote:
> Hmm, I hope this isn't a potential security hole.. I'd be happy if there
> were a way to remove that info from the package, actually.
I have done some work with debugedit, which is shipped with RPM - it's
supposed to be able to do this,
On Mon, Apr 23, 2007 at 03:08:41PM -0400, Joey Hess wrote:
> Daniel Jacobowitz wrote:
> > Yes, it's deliberate. People rarely need them just because they're
> > debugging something linked to libc.so.6. Having them slows down GDB
> > startup and increases its memory usage, for _every_ debug sessio
Steinar H. Gunderson wrote:
> Are you sure the source code is in there with -g? I was pretty sure it
> wasn't, only line numbers.
I was fooled by the fact that the debug packages I was using have:
[EMAIL PROTECTED]:/usr/lib/debug/usr/lib>strings libaa.so.1.0.4|grep joey
/home/joey/src/packages/aa
Mike Hommey wrote:
> The point is that it's pretty useless to have a backtrace without line
> numbers.
That depends on whether the problem you're debugging is a bug in the
library itself, or only a bug triggered by code that calls the library,
or in code called by the library.
--
see shy jo
si
Steinar H. Gunderson wrote:
> Are you sure the source code is in there with -g? I was pretty sure it
> wasn't, only line numbers.
You're right, it doesn't include the actual code, but the size is
still roughly porportional to the size of the code in the library.
--
see shy jo
signature.asc
Des
Daniel Jacobowitz wrote:
> Yes, it's deliberate. People rarely need them just because they're
> debugging something linked to libc.so.6. Having them slows down GDB
> startup and increases its memory usage, for _every_ debug session.
Ok. Of course, this is also generally an argument against havin
Manoj Srivastava wrote:
> On Sun, 22 Apr 2007 19:29:55 -0400, Joey Hess <[EMAIL PROTECTED]> said:
>
> > So while I'd love to have a way to have -dbg packages available for
> > every binary, I actually am happy with this proposal to do it for only
> > every library (plus whatever other binaries re
Tshepang Lekhonkhobe wrote:
> It would be nice if the standard iso images that Debian makes
> available could be made to exclude -dbg packages as a trade-off. It
> actually felt painful someday when doing jigdo on the archive, only to
> see loads of -dbg packages getting downloaded, and knowing I w
On Mon, Apr 23, 2007 at 07:10:15PM +0200, Steinar H. Gunderson <[EMAIL
PROTECTED]> wrote:
> On Mon, Apr 23, 2007 at 07:06:55PM +0200, Mike Hommey wrote:
> > The point is that it's pretty useless to have a backtrace without line
> > numbers. It would be interesting if there was an option similar to
On 22-Apr-07, 17:01 (CDT), Neil Williams <[EMAIL PROTECTED]> wrote:
>
> > 2. Why a seperate -doc? API docs should be part of the -dev package.
>
> In practice, such attitudes are commonly expressed as RTSL. (Read The
> Source, Luke). That does NOT encourage upstream usage of Debian as a
> distro
On 22-Apr-07, 17:29 (CDT), Kurt Roeckx <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 22, 2007 at 04:40:45PM -0500, Steve Greenland wrote:
> > On 22-Apr-07, 16:22 (CDT), Robert Collins <[EMAIL PROTECTED]> wrote:
> > >
> > > Because segfaults are often not easily reproduced. Having the ability to
> > >
On Mon, Apr 23, 2007 at 07:06:55PM +0200, Mike Hommey wrote:
> The point is that it's pretty useless to have a backtrace without line
> numbers. It would be interesting if there was an option similar to -g1,
> but that would keep the line numbers (without the burden of keeping the
> whole source co
On Mon, Apr 23, 2007 at 11:28:06PM +1000, Hamish Moffatt <[EMAIL PROTECTED]>
wrote:
> On Mon, Apr 23, 2007 at 07:38:15AM +0200, Mike Hommey wrote:
> > On Sun, Apr 22, 2007 at 08:26:38PM -0400, Joey Hess <[EMAIL PROTECTED]>
> > wrote:
> > > Mark Brown wrote:
> > > > I'd be interested to see some n
On Sun, Apr 22, 2007 at 07:29:55PM -0400, Joey Hess wrote:
> Even with separated debugging symbols, -dbg packages are frequently
> larger than the package they provide debugging symbols for. See for
> example xserver-xorg-core-dbg. Looking through the 227 lib*-dbg
> packages, I found few contain se
On Mon, Apr 23, 2007 at 07:38:15AM +0200, Mike Hommey wrote:
> On Sun, Apr 22, 2007 at 08:26:38PM -0400, Joey Hess <[EMAIL PROTECTED]> wrote:
> > Mark Brown wrote:
> > > I'd be interested to see some numbers on the archive size impact - my
> > > experience with C++ suggests that the size inflation
Le dimanche 22 avril 2007 à 20:39 +0100, Neil Williams a écrit :
> I'd like to see all library source packages having a minimum of 4
> binary packages required by Policy: the SONAME, the -dev, the -dbg and
> a -doc package. (Libraries for perl or other non-compiled languages
> would be exempt from
On 2007-04-22, Mark Brown <[EMAIL PROTECTED]> wrote:
> I'd be interested to see some numbers on the archive size impact - my
> experience with C++ suggests that the size inflation caused by debug
> symbols can be enormous.
Openoffice currently ships a -g1 -dbg package. If it wasn't -g1, the deb
wo
On Sun, 22 Apr 2007 19:29:55 -0400, Joey Hess <[EMAIL PROTECTED]> said:
> So while I'd love to have a way to have -dbg packages available for
> every binary, I actually am happy with this proposal to do it for only
> every library (plus whatever other binaries really need it). And it's
> a direct
On Sun, Apr 22, 2007 at 08:26:38PM -0400, Joey Hess <[EMAIL PROTECTED]> wrote:
> Mark Brown wrote:
> > I'd be interested to see some numbers on the archive size impact - my
> > experience with C++ suggests that the size inflation caused by debug
> > symbols can be enormous.
>
> I don't know about
On 4/23/07, Joey Hess <[EMAIL PROTECTED]> wrote:
Anyway, doubling the size of the archive is less of an issue than it
might have been in the past, since we've done the archive split, and
since ftp-master has 1.4 Terabytes of disk with half that unused, but
it is still a concern, for mirrors, numb
Mark Brown wrote:
> I'd be interested to see some numbers on the archive size impact - my
> experience with C++ suggests that the size inflation caused by debug
> symbols can be enormous.
I don't know about C++, but for C it depends. For example, aalib is a
102 kb library that compresses to 44kb.
On Sun, Apr 22, 2007 at 08:39:26PM +0100, Neil Williams wrote:
> I'd like to see all library source packages having a minimum of 4
> binary packages required by Policy: the SONAME, the -dev, the -dbg and
> a -doc package. (Libraries for perl or other non-compiled languages
> would be exempt from
I demand that Neil Williams may or may not have written...
[snip]
> Upstream are using SourceForge or Berlios, not Alioth. Upstream don't use
> dh_strip or debhelper
And, of course, upstream is not a Debian package maintainer.
[snip]
--
| Darren Salt| linux or ds at | nr. Ashi
Neil Williams wrote:
> > > Certain packages have already had bug reports requesting a -dbg
> > > package.
> >
> > I'd rather see some offline debug-symbol infrastructure for all
> > packages implemented, so that you can download the debug symbols when
> > you need them.
>
> But the -dbg package on
1 - 100 of 127 matches
Mail list logo
