>
>
> I am open to adding those at a later stage. Though at this point, I
> would really like to get ddebs into unstable, before we scope creep
> it
> any further.
Thanks for explanation.
For now I'll leave manual debug packages for Python.
At the same time - current DH
On 2015-09-20 19:04, Tomasz Rybak wrote:
> Dnia 2015-08-25, wto o godzinie 13:41 +, Jean-Michel Vourgère
> pisze:
>> Hi
>>[...]
>>
>> The question is also valid for python2:
>>
>> When using dh --with python2 *and* build-depending on python-all-dbg,
>> I'm getting [1]:
>> * Some files like /usr
Dnia 2015-08-25, wto o godzinie 13:41 +, Jean-Michel Vourgère
pisze:
> Hi
>
> Nikolaus Rath wrote:
> > On Aug 24 2015, Sebastian Ramacher wrote:
> > > What's the plan for python(3)-*-dbg packages that include both
> > > Python extensions
> > > built for the python-dbg interpreter and debug sy
nding
>> foo_1.23-dbgsym.deb package.
>
> Are they named .deb or .ddeb?
>
That would be ".deb" with a single "D" - sorry for the copy-waste mistake.
I should probably start calling them dbgsym or adbg (for "automatic
debug" packages) inste
On Mon, Aug 24, 2015 at 11:12:41PM +0200, Niels Thykier wrote:
> * ddebs are Debian packages with the extension .deb that
> contain debugging symbols and are built implicitly.
> - A package foo_1.23.deb will receive a corresponding
> foo_1.23-dbgsym.ddeb package.
Are they named .deb or .dd
On Mon, Aug 24, 2015 at 02:28:05PM -0700, Steve Langasek wrote:
> I wonder how this list was arrived at. Offhand, I see the libc6-dbg and
> python3.5-dbg packages are both in section 'debug', both of which are part
> of the build-dependency closure of main; I'm pretty sure we don't want them
> shu
Hi
Nikolaus Rath wrote:
> On Aug 24 2015, Sebastian Ramacher wrote:
>> What's the plan for python(3)-*-dbg packages that include both Python
>> extensions
>> built for the python-dbg interpreter and debug symbols? Should they also
>> change
>> their Section to something else?
>
>
> .. and wil
On 2015-08-25 11:29, Matthias Klose wrote:
> On 08/24/2015 11:12 PM, Niels Thykier wrote:
>> * debhelper will be including debug-ids in the control file to make it
>>easier to find the necessary debug symbols for a given file.
>>- Thanks to paultag for this idea.
>>- This is merged int
On 08/24/2015 11:12 PM, Niels Thykier wrote:
> * debhelper will be including debug-ids in the control file to make it
>easier to find the necessary debug symbols for a given file.
>- Thanks to paultag for this idea.
>- This is merged into git and will be included in the next upload.
a
On Aug 24 2015, Sebastian Ramacher wrote:
> Hi
>
> On 2015-08-24 23:12:41, Niels Thykier wrote:
>> * Up to 5 packages need to change section (see "Implementation-
>>details" below)
>>- See #796834, #796836, #796839, #796840, and #796842.
>
> What's the plan for python(3)-*-dbg packages th
Hi
On 2015-08-24 23:12:41, Niels Thykier wrote:
> * Up to 5 packages need to change section (see "Implementation-
>details" below)
>- See #796834, #796836, #796839, #796840, and #796842.
What's the plan for python(3)-*-dbg packages that include both Python extensions
built for the python
On 2015-08-24 23:28, Steve Langasek wrote:
> Hi Niels,
>
> On Mon, Aug 24, 2015 at 11:12:41PM +0200, Niels Thykier wrote:
>> [...]
>
> I wonder how this list was arrived at. Offhand, I see the libc6-dbg and
> python3.5-dbg packages are both in section 'debug', both of which are part
> of the bui
=
>
> There are some details behind the implementation that might be of
> general interest.
>
> * All packages in the "debug" section will be moved from unstable to
>the new "unstable-debug" (separate mirror list)
>- Including "manual"
Hi,
Here is the "post-debconf" status on automatic debug packages ("ddebs").
The previous status from 2015-06-29 can be found in [0].
What is it?
===
* ddebs are Debian packages with the extension .deb that
contain debugging symbols and are built implicitly.
> * Do we want users which build private packages to build also DDeps and
>TDeps?
DDeps from private builds are useful to track bugs.
Samuel
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Arch
* Philipp Kern [2011-03-08 16:30 +]:
> On 2011-03-08, Carsten Hey wrote:
> > A prerequisite to automatically add debug packages for all
> > architectures is to change the way how packages are uploaded and/or
> > build[1]. In the upcoming ftpmaster meeting[2] from the 21
Le mardi 08 mars 2011 à 16:30 +, Philipp Kern a écrit :
> I don't think that's true. In fact I also suggested back then that it should
> "just" part of the normal build process. Then DDs would upload ddebs just
> like
> the buildds would.
FWIW, this is how the proposed changes to the toolc
On 2011-03-08, Carsten Hey wrote:
> * Emil Langrock [2011-03-08 00:48 +0100]:
>> I browsed a little bit in the goals which were planned for squeeze and
>> noticed
>> that the debug packages aka ddebs[1] weren't implemented in the debian
>> infrastructure.
>
* Emil Langrock [2011-03-08 00:48 +0100]:
> I browsed a little bit in the goals which were planned for squeeze and noticed
> that the debug packages aka ddebs[1] weren't implemented in the debian
> infrastructure.
A prerequisite to automatically add debug packages for all archi
Hi,
I browsed a little bit in the goals which were planned for squeeze and noticed
that the debug packages aka ddebs[1] weren't implemented in the debian
infrastructure. I thought that many things happened [2] and there were also
some wrappers implemented [3] to automatically generate
Theodore Tso writes:
> On Fri, Aug 14, 2009 at 05:50:50PM -0700, Russ Allbery wrote:
>> Joerg was also advocating one ddeb per source package in the summary
>> message that he sent about the ftp-master approach, and Emilio has
>> mentioned a few times that ftp-master needs to buy in on that decis
On Fri, Aug 14, 2009 at 05:50:50PM -0700, Russ Allbery wrote:
> Peter Samuelson writes:
> > [Emilio Pozuelo Monfort]
>
> >> We haven't agreed on whether there should be one ddeb per source or
> >> per binary package, so I would leave this still opened.
>
> > Maybe I'm losing track of things here
Peter Samuelson writes:
> [Emilio Pozuelo Monfort]
>> We haven't agreed on whether there should be one ddeb per source or
>> per binary package, so I would leave this still opened.
> Maybe I'm losing track of things here, but it seems to me that everyone
> except you is saying one ddeb per binar
[Emilio Pozuelo Monfort]
> We haven't agreed on whether there should be one ddeb per source or
> per binary package, so I would leave this still opened.
Maybe I'm losing track of things here, but it seems to me that everyone
except you is saying one ddeb per binary. And then you say "sure, we
co
looking at the Ubuntu spec at all, but I might
have been mislead into a false sense of security:
From: Philipp Kern
Subject: Re: Automatic Debug Packages
Message-ID:
>>> This use case is IMHO implicitly addressed by making them
>>> downloadable and installable on the
]] Emilio Pozuelo Monfort
| > Because you're trying to debug a binary on your system that's linked
| > against it.
|
| Then you should work on making your package build with the new library, since
it
| will be FTBFS anyway :)
No, it won't. You're confusing changed ABI from changed API.
Say y
On Fri, Aug 14, 2009 at 12:55:38PM -0500, Manoj Srivastava wrote:
> >> > Yes, dpkg, apt-get, aptitude and synaptic all work perfectly fine.
> >> The debug command addresses my concerns here.
> > You know this command doesn't actually exist, right? AFAIK it's only
> > referenced in an Ubu
On Fri, Aug 14 2009, Steve Langasek wrote:
> On Thu, Aug 13, 2009 at 09:42:55AM -0500, Manoj Srivastava wrote:
>> On Thu, Aug 13 2009, Emilio Pozuelo Monfort wrote:
>
>> > Yes, dpkg, apt-get, aptitude and synaptic all work perfectly fine.
>
>> The debug command addresses my concerns here.
On Thu, Aug 13, 2009 at 09:42:55AM -0500, Manoj Srivastava wrote:
> On Thu, Aug 13 2009, Emilio Pozuelo Monfort wrote:
> > Yes, dpkg, apt-get, aptitude and synaptic all work perfectly fine.
> The debug command addresses my concerns here.
You know this command doesn't actually exist, righ
On Wed, Aug 12, 2009 at 11:17:55PM +0200, Joerg Jaspert wrote:
> First, the naming:
> It is indeed us Ftpmasters who want them named .ddeb. For two reasons -
> a simple one is that it makes the handling much easier, if you can match
> on *.ddeb$. Another one is that they aren't "real" debs like .de
Russ Allbery wrote:
> The only lingering concern that I have about a share is how it plays with
> the files installed on your system via package. Can gdb be pointed to
> multiple different debug information stores at different paths? Mounting
> a remote share over top of /usr/lib/debug obviously
ned up?
• if it doesn't keep them, doesn't this have the potential to waste
gigabytes of my monthly DSL bandwidth quota, since debugging
symbols can be huge and you might run gdb repeatedly on many
occasions?
With having actual debug packages installed, it's easy to know how
long they
Emilio Pozuelo Monfort writes:
> I've been playing with WebDAV, which is an extension to HTTP. So I guess
> that will work with firewalls?
Yes, it should.
The only lingering concern that I have about a share is how it plays with
the files installed on your system via package. Can gdb be pointe
Philipp Kern wrote:
> On 2009-08-13, Eugene V. Lyubimkin wrote:
>>> Maybe you should spend some time and read the thread before stating such
>>> things.
>> Really? So, they are already first-class deb packages?
>
> Maybe you should spend some time and read the thread before stating such
> thing
On 2009-08-13, Eugene V. Lyubimkin wrote:
>> Maybe you should spend some time and read the thread before stating such
>> things.
> Really? So, they are already first-class deb packages?
Maybe you should spend some time and read the thread before stating such things.
> What percent of their (and
ey can't be regular Debian packages.
> Anyway I don't care about one or many ddeb packages, convince the
> ftpmasters and I'll do one per binary package, resolving the build id
> file conflicts with replaces.
Excellent, thank you. That's certainly my intention.
>
Philipp Kern writes:
> And I have to agree with Emilio that I don't see the point of a 1:1
> relationship of ddeb to binary package just for the sake of library
> transitions. I wonder if we could just unpack the debugging build-id
> objects to some other location than globally and point gdb to
Emilio Pozuelo Monfort wrote:
> Eugene V. Lyubimkin wrote:
>> Hello thread! /me puts on a package manager developer hat.
>>
>> Sorry, I haven't read the whole thread, it's huge.
>>
>> I think that diversion of debug packages out of current deb format is a
one or many ddeb packages,
convince the ftpmasters and I'll do one per binary package, resolving the build
id file conflicts with replaces.
> The debug packages depend on the packages for which they have symbols,
> which solves the problem of not installing debug packages that both
>
On Thu, Aug 13 2009, Emilio Pozuelo Monfort wrote:
> Yes, dpkg, apt-get, aptitude and synaptic all work perfectly fine.
The debug command addresses my concerns here.
> As I've said, there will still be a debug archive. I don't see what's
> the problem with providing *both* an archive an
Eugene V. Lyubimkin wrote:
> Hello thread! /me puts on a package manager developer hat.
>
> Sorry, I haven't read the whole thread, it's huge.
>
> I think that diversion of debug packages out of current deb format is a
> completely wrong direction. Do you want to t
Hello thread! /me puts on a package manager developer hat.
Sorry, I haven't read the whole thread, it's huge.
I think that diversion of debug packages out of current deb format is a
completely wrong direction. Do you want to teach all tools that get some info
about Debian packages tha
Roger Leigh wrote:
> On Thu, Aug 13, 2009 at 02:58:45AM +0200, Emilio Pozuelo Monfort wrote:
>> Roger Leigh wrote:
>>> This fails to address the rather valid concern brought up about
>>> having different versions of libraries and binaries installed
>>> from the same source package. Having one .dde
Julien Cristau wrote:
> On Thu, Aug 13, 2009 at 02:58:45 +0200, Emilio Pozuelo Monfort wrote:
>
>> If that bothers you, you can use the share we plan to provide.
>>
> I'd like to still be able to debug offline, thank you very much. So far
> you've avoided answering the question, though: why one d
Manoj Srivastava wrote:
> On Wed, Aug 12 2009, Emilio Pozuelo Monfort wrote:
>
>
>> There will still be a repository with all the .ddebs.
>
> And aptitude and dpkg will know how to install ddebs, somehow?
> and synaptic, etc?
Yes, dpkg, apt-get, aptitude and synaptic all work perfectly
On 2009-08-13, Manoj Srivastava wrote:
>> Ah, and it looks like the automated crash reporting offers to download the
>> -dbgsym packages and install them.
> Reading the spec, it seems to me that the primary motivation was
> for users to provide crash dumps with bug reports, and not much s
Russ Allbery wrote:
> Hm, that's interesting, but I suspect that few enough of our users will be
> able to use such a thing that we shouldn't let that influence any other
> design choices. Most shares are not going to be able to be mounted
> through firewalls, for example, so that form of the debu
On 2009-08-13 11:32:17 +0800, Paul Wise wrote:
> Not having anything to do with Ubuntu, I don't know anything about the
> details, but they have had automatic debug packages and automated
> crash report stuff for quite a while, a couple of years IIRC. The
> specs for that are
On Wed, Aug 12 2009, Russ Allbery wrote:
> Paul Wise writes:
>
>> Not having anything to do with Ubuntu, I don't know anything about the
>> details, but they have had automatic debug packages and automated
>> crash report stuff for quite a while, a couple of years II
n see what protocols it's
> using?
Did ubuntu have to modify the default package manager (synaptic,
right?) in order to allow the user to install the ddebs locally? I
would be interested in the details of how to hook up to the debug
packages archive in Ubuntu (I shall try install
Paul Wise writes:
> Not having anything to do with Ubuntu, I don't know anything about the
> details, but they have had automatic debug packages and automated
> crash report stuff for quite a while, a couple of years IIRC. The
> specs for that are here:
>
> https://launchp
s it's
> using?
>
> Prior experience is *great*. We can learn from the experiences of Ubuntu.
Not having anything to do with Ubuntu, I don't know anything about the
details, but they have had automatic debug packages and automated
crash report stuff for quite a while, a couple of years
Paul Wise writes:
> On Thu, Aug 13, 2009 at 10:10 AM, Manoj Srivastava wrote:
>> I too am wondering if we should defer the polivy change until
>> the details get shaken out with a partial deployment of the scheme.
> Full deployment already happened (in Ubuntu).
As .ddebs? What's the po
On Thu, Aug 13, 2009 at 10:10 AM, Manoj Srivastava wrote:
> I too am wondering if we should defer the polivy change until
> the details get shaken out with a partial deployment of the scheme.
Full deployment already happened (in Ubuntu).
--
bye,
pabs
http://wiki.debian.org/PaulWise
-
On Wed, Aug 12 2009, Emilio Pozuelo Monfort wrote:
> There will still be a repository with all the .ddebs.
And aptitude and dpkg will know how to install ddebs, somehow?
and synaptic, etc?
> But also we will have a share that will ship all the debugging symbols
> in a build id file hie
s, for example, so that form of the debug symbols won't be
available to quite a few users.
Or maybe by "share" you meant something that was more like a file download
service over HTTP than, say, NFS?
> If you use this, you won't need to get a backtrace, realize you're
On Thu, Aug 13, 2009 at 02:58:45AM +0200, Emilio Pozuelo Monfort wrote:
> Roger Leigh wrote:
> > On Wed, Aug 12, 2009 at 11:17:55PM +0200, Joerg Jaspert wrote:
> >> Quantity of .ddebs:
> >> Usually there should only be one .ddeb per source. Of course there are
> >> always exceptions from the rule,
ly the current package in the archive, but maybe
the last three or whatever we can do), since build ids permit it.
With this in place, we can integrate reporting tools (bug-buddy, drkonqi,
apport) to use that service to magically provide meaningful bug reports with
complete backtraces.
If you use
On Thu, Aug 13, 2009 at 02:58:45 +0200, Emilio Pozuelo Monfort wrote:
> If that bothers you, you can use the share we plan to provide.
>
I'd like to still be able to debug offline, thank you very much. So far
you've avoided answering the question, though: why one ddeb per source
instead of per b
Emilio Pozuelo Monfort writes:
> Roger Leigh wrote:
>> This fails to address the rather valid concern brought up about having
>> different versions of libraries and binaries installed from the same
>> source package. Having one .ddeb per binary would solve this
>> elegantly.
> Except that in th
Roger Leigh wrote:
> On Wed, Aug 12, 2009 at 11:17:55PM +0200, Joerg Jaspert wrote:
>> Quantity of .ddebs:
>> Usually there should only be one .ddeb per source. Of course there are
>> always exceptions from the rule, so Maintainers may chose to have one
>> per binary package. This should only be ta
On Wed, Aug 12, 2009 at 11:17:55PM +0200, Joerg Jaspert wrote:
> Quantity of .ddebs:
> Usually there should only be one .ddeb per source. Of course there are
> always exceptions from the rule, so Maintainers may chose to have one
> per binary package. This should only be taken when the size of the
On 11826 March 1977, Emilio Pozuelo Monfort wrote:
> The proposal is (very briefly) to make dak accept .ddeb packages (containing
> debugging symbols using build-ids), and to then modify helper tools to
> automatically generate them and add them to the changes file. I've written
> down
> the deta
Hi!
On Tue, 2009-08-11 at 13:03:13 -0700, Russ Allbery wrote:
> Open questions:
> * Can we require a one-to-one correspondance between binary package names
> and debug package names that provide symbols for that binary package? I
> think we should; I think it would make the system more strai
Russ Allbery wrote:
> Josselin Mouette writes:
>> If we use build IDs (and this has quite some advantages, like being able
>> to do more than just dump the ddebs on a repository), this can lead to
>> having the same detached debugging symbols in two binary packages, since
>> sometimes a binary is
Josselin Mouette writes:
> Le mardi 11 août 2009 à 17:26 -0700, Russ Allbery a écrit :
>> I don't understand how what you say is related to what I said. How
>> does having them in a separate archive affect whether or not I have to
>> download a 50GB package to get debugging symbols for KDE? Whe
Le mardi 11 août 2009 à 17:26 -0700, Russ Allbery a écrit :
> > The main purpose of setting up an archive of debugging symbols is to be
> > able to use them transparently without installation, so that doesn’t
> > change much.
>
> I don't understand how what you say is related to what I said. How
Josselin Mouette writes:
> Le mardi 11 août 2009 à 16:13 -0700, Russ Allbery a écrit :
>> Without the symlink, they're not valid Debian packages. It seems like
>> a small price to pay for keeping them consistent with the rest of
>> Policy.
> The policy is just a document. The question is more a
Le mardi 11 août 2009 à 16:13 -0700, Russ Allbery a écrit :
> > Actually I don’t see the point in this symlink. It only makes things
> > more complicated, especially if there is no one-to-one mapping between
> > ddebs and debs.
>
> Without the symlink, they're not valid Debian packages. It seems
Josselin Mouette writes:
> Le mardi 11 août 2009 à 13:03 -0700, Russ Allbery a écrit :
>> * These packages are normal Debian packages with normal package metadata,
>> but will generally have a symlink in /usr/share/doc/ pointing
>> to the package for which they provide debugging information.
Le mardi 11 août 2009 à 13:03 -0700, Russ Allbery a écrit :
> * These packages are normal Debian packages with normal package metadata,
> but will generally have a symlink in /usr/share/doc/ pointing
> to the package for which they provide debugging information.
Actually I don’t see the point
Philipp Kern writes:
> On 2009-08-11, Russ Allbery wrote:
>>> If it's legal to ship debugging symbols for them, I can't see why we
>>> couldn't support them normally.
>> The point is that you can't do this with an archive area, at least
>> using the simple algorithm I proposed above.
> Well yo
["Followup-To:" header set to gmane.linux.debian.devel.general.]
On 2009-08-11, Russ Allbery wrote:
>> If it's legal to ship debugging symbols for them, I can't see why we
>> couldn't support them normally.
> The point is that you can't do this with an archive area, at least using
> the simple alg
debugging symbols will be put there. I'll try to automatize other
>> languages too, so that having full archive coverage is as simpler as
>> possible.
>
> Could you explain a bit more about what merits you see in creating
> something that we call a different type of pac
ke the system more straightforward.
>
> I guess the Packages file could grow a "Has-DDeb: yes" line (or the
> Sources file if we go for one ddeb per source package).
I suppose, but that seems unrelated. The debugging package archive or
archive area will have its own Pac
Russ Allbery wrote:
> Emilio Pozuelo Monfort writes:
>> Russ Allbery wrote:
>
>>> It sounds like listing them only in *.changes but not in *.dsc or
>>> debian/control may be the easiest approach.
>> Indeed, for the automatic-not-listed-in-debian-control ones. The others
>> would be listed everywh
Emilio Pozuelo Monfort writes:
> Russ Allbery wrote:
>> It sounds like listing them only in *.changes but not in *.dsc or
>> debian/control may be the easiest approach.
>
> Indeed, for the automatic-not-listed-in-debian-control ones. The others
> would be listed everywhere, but that is okay.
Yes
Russ Allbery wrote:
>> Having them in the Binary section in the .dsc and Binary and Description
>> in the .changes files would mean modifying
>> dpkg-buildpackage/dpkg-genchanges for ddebs not listed in
>> debian/control. However listing them in Files and Checksum-* in the
>> .changes requires no c
is suboptimal (the
former applies here).
>> >> Seems like if policy carves out a namespace for debug packages,
>> >> it would serve for both automatically generated and hand crafted debug
>> >> packages; and it is trivial for the automatic generation
Emilio Pozuelo Monfort writes:
> Manoj Srivastava wrote:
>> So I think at this point it is premature for policy to decide
>> one way or the other about debug symbol packages being mentioned in
>> the control file (and dsc and changes).
> They should be in the changes file so they are u
ether these packages will be
>> listed in debian/control in the source package, in Binary in the *.dsc
>> file, and in Binary/Files/Checksums-* in the *.changes file. And I don't
>> know the answer to those three questions from the discussion so far.
>
> He
On Tue, Aug 11, 2009 at 01:50:21PM -0500, Gunnar Wolf wrote:
> > I don't have a strong opinion on whether ddebs should be documented in
> > policy, but I certainly don't agree with requiring dpkg to understand them
> > as a prerequisite for implementing a general purpose, public archive for
> > au
Manoj Srivastava dijo [Tue, Aug 11, 2009 at 10:12:00AM -0500]:
> On Tue, Aug 11 2009, Roger Leigh wrote:
>
> > On Tue, Aug 11, 2009 at 01:40:20PM +, Sune Vuorela wrote:
> >> On 2009-08-11, Manoj Srivastava wrote:
> >> > So, we would still need to create "/usr/lib/debug/"
> >> > . /
http://lists.debian.org/debian-policy/2009/08/msg00044.html
That was not a question. But apparently, any statements you've made in
emails more than a day old are "strawmen" that you're not responsible for.
> >> Seems like if policy carves out a namespace f
ss when it comes to open source.
>>
>> Could you explain a bit more about what merits you see in creating
>> something that we call a different type of package rather than just
>> listing debug packages in debian/control and building them as we do now
>> and handling secti
Steve Langasek dijo [Sun, Aug 09, 2009 at 05:15:39PM -0700]:
> > If we are going to enshrine ddebs into policy, we might as well
> > teach dpkg about ddebs.
>
> I don't have a strong opinion on whether ddebs should be documented in
> policy, but I certainly don't agree with requiring dpkg
; debugging symbols will be put there. I'll try to automatize other
> > languages too, so that having full archive coverage is as simpler as
> > possible.
>
> Could you explain a bit more about what merits you see in creating
> something that we call a different type of pa
e package, in Binary in the *.dsc
> file, and in Binary/Files/Checksums-* in the *.changes file. And I don't
> know the answer to those three questions from the discussion so far.
Here is my take on this:
a) helper packages may be extended to created debug packages by
defaul
ies built with library
debugging support? Binaries built with more verbose trace information?
That seems like huge scope creep to me.
> 5) There may only be one ddeb per source package (if more where needed,
> we could consider it).
Why would we do this? Surely it makes more sense to have a o
Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Emilio Pozuelo Monfort wrote:
>> Manoj Srivastava wrote:
>>> Can you point ot me the disadvantage of continuing to use what
>>> dh_strip does now?
>> It can still be used, but you will miss the advantages of using build ids.
>
> I gu
On Tue, Aug 11 2009, Emilio Pozuelo Monfort wrote:
> Manoj Srivastava wrote:
>
>> OK, I guess that would work. But you still have the advantage,
>> using the current debug link mechanism, of looking to see if you have
>> debug symbols for a given executable/library easily, without havin
On Mon, Aug 10, 2009 at 03:59:22PM -0700, Steve Langasek wrote:
> On Mon, Aug 10, 2009 at 09:46:49PM +0100, Roger Leigh wrote:
> > Reading through this thread, I don't see a compelling reason for using
> > a .ddeb extension given that they are just regular .debs, nor for
> > keeping the packages se
On Tue, Aug 11, 2009 at 18:37:05 +0200, Emilio Pozuelo Monfort wrote:
> Manoj Srivastava wrote:
> > 2) These packages may just symlink
> > /usr/share/doc/${package name}-${debug suffix} to
> > /usr/share/doc/${package name}
> > (and of course, depend on ${package name}
>
> 5) There m
Manoj Srivastava wrote:
> Hi,
>
> All right. Having been educated about the new build-id
> mechanism, I think there is not reason for policy to prohibit either
> approach, or to settle on one or the other.
>
> To recap:
> 1) packages with detached debugging symbols should be na
Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Josselin Mouette wrote:
>
>> Le mardi 11 août 2009 à 10:11 -0500, Manoj Srivastava a écrit :
>>> Except you have not indicated how you (or debhelper) is going to
>>> intercept ld to add the requisite arguments.
>> http://lists.debian.org/debi
Hi,
All right. Having been educated about the new build-id
mechanism, I think there is not reason for policy to prohibit either
approach, or to settle on one or the other.
To recap:
1) packages with detached debugging symbols should be named
${package name}-${debug suffix}.
On Tue, Aug 11 2009, Josselin Mouette wrote:
> Le mardi 11 août 2009 à 10:11 -0500, Manoj Srivastava a écrit :
>> Except you have not indicated how you (or debhelper) is going to
>> intercept ld to add the requisite arguments.
>
> http://lists.debian.org/debian-devel-changes/2009/07/msg01
Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Josselin Mouette wrote:
>
>> Le mardi 11 août 2009 à 08:24 -0500, Manoj Srivastava a écrit :
>>> Hmm. I see very little benefit here. Firstly, to use build id,
>>> you have to intercept the upstream build system and add --build-id
>>> (and p
Le mardi 11 août 2009 à 10:39 -0500, Manoj Srivastava a écrit :
> However, if you do not use the build-id mechanism, and use what
> we currently use in dh_strip and friends, objcopy --add-gnu-debuglink
> adds information that gdb looks at to figure out where the debug
> symbols live -- a
Josselin Mouette wrote:
> Le mardi 11 août 2009 à 10:11 -0500, Manoj Srivastava a écrit :
>> Except you have not indicated how you (or debhelper) is going to
>> intercept ld to add the requisite arguments.
>
> http://lists.debian.org/debian-devel-changes/2009/07/msg01229.html
Also see ht
1 - 100 of 210 matches
Mail list logo
