> * 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 21st until
> > the 27th o
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.
> A prerequisite to automatically add deb
* 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 architectures
is to chang
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
On Thu, Aug 13, 2009 at 02:08:58PM -0700, Russ Allbery wrote:
> 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
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
Emilio Pozuelo Monfort writes:
> Russ Allbery wrote:
>> https://wiki.ubuntu.com/AptElfDebugSymbols is the specification. It
>> does use *.ddeb. There isn't any clear statement about how *.ddeb
>> packages differ from *.deb packages. It looks like, by and large, they
>> don't, except they may n
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
>> completely wrong direction. Do you want
Russ Allbery wrote:
> https://wiki.ubuntu.com/AptElfDebugSymbols is the specification. It does
> use *.ddeb. There isn't any clear statement about how *.ddeb packages
> differ from *.deb packages. It looks like, by and large, they don't,
> except they may not need to contain the same set of thin
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 teach all tools that get some inf
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 that there is n
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 here:
>
> https://lau
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 IIRC. The
>> specs for that are
On Wed, Aug 12 2009, Russ Allbery wrote:
> 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 al
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://launchpad.net/ubuntu/+spec/apt-
On Thu, Aug 13, 2009 at 11:25 AM, Russ Allbery wrote:
> As .ddebs? What's the policy about what can go in them and how are they
> integrated with the packaging tools? And could you point me at the Ubuntu
> share for the debugging information so that I can see what protocols it's
> using?
>
> Pri
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
Emilio Pozuelo Monfort writes:
> Russ Allbery wrote:
>>> Except that in that case, the old library will be NBS and thus I see
>>> no point why you would want to keep it installed. The only reason
>>> would be if it was meant to stay around, but in that case I'm sure the
>>> source package names w
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,
Russ Allbery wrote:
> 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
>>> el
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
Russ Allbery wrote:
> Emilio Pozuelo Monfort writes:
>
>> You can build a .ddeb manually, yes. However for some cases
>> (e.g. packages using debhelper and building ELF binaries) a .ddeb will
>> be automatically created (if none is created manually) and detached
>> debugging symbols will be put t
Emilio Pozuelo Monfort writes:
> Russ Allbery wrote:
>> * 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.
> We haven't agreed on whether th
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
On Tue, Aug 11 2009, Steve Langasek wrote:
> But if this is all the more respect you have for your fellow (TC
> members|DDs|human beings), O Peerless and Saintly Policy Editor, then
> perhaps the project should reconsider whether that's a position you should
> hold.
The -vote list is ->
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
Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Russ Allbery wrote:
>
>> Emilio Pozuelo Monfort writes:
>>> Manoj Srivastava wrote:
To recap:
1) packages with detached debugging symbols should be named
${package name}-${debug suffix}. As a corollary, no ordinary
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/"
> >> > . /
On Mon, Aug 10, 2009 at 06:06:37PM -0500, Manoj Srivastava wrote:
> >> So, please keep heckling from the peanut gallery to a minimum,
> >> please, and assume that policy editors have a modicum of sense when
> >> dealing with their role duties.
> > If you were showing a modicum of sense,
On Tue, Aug 11, 2009 at 2:45 PM, Gunnar Wolf wrote:
> Russ Allbery dijo [Sat, Aug 08, 2009 at 05:51:33PM -0700]:
>> > You can build a .ddeb manually, yes. However for some cases
>> > (e.g. packages using debhelper and building ELF binaries) a .ddeb will
>> > be automatically created (if none is cre
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
Russ Allbery dijo [Sat, Aug 08, 2009 at 05:51:33PM -0700]:
> > You can build a .ddeb manually, yes. However for some cases
> > (e.g. packages using debhelper and building ELF binaries) a .ddeb will
> > be automatically created (if none is created manually) and detached
> > debugging symbols will be
On Tue, Aug 11 2009, Russ Allbery wrote:
> Emilio Pozuelo Monfort writes:
>> Manoj Srivastava wrote:
>
>>> To recap:
>>> 1) packages with detached debugging symbols should be named
>>> ${package name}-${debug suffix}. As a corollary, no ordinary
>>> packages names may end in ${d
Emilio Pozuelo Monfort writes:
> Manoj Srivastava wrote:
>> To recap:
>> 1) packages with detached debugging symbols should be named
>> ${package name}-${debug suffix}. As a corollary, no ordinary
>> packages names may end in ${debug suffix}.
> They may be automatically created
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
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 perhaps the --build-id-style) opt
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 separate from the main archive (if the size of
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
--
.''`. Josselin Mouette
: :' :
`.
On Tue, Aug 11 2009, Sune Vuorela wrote:
> On 2009-08-11, Manoj Srivastava wrote:
>> 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 perhaps the --build-id-style) option to ld, instead of the cu
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/"
>> > . /full/path/to/lib_or_binary/ in either case, and instead of the
>>
>> no. i
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 perhaps the --build-id-style) option to ld, instead of the current
> method of lett
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/"
> > . /full/path/to/lib_or_binary/ in either case, and instead of the
>
> no. it would be /usr/lib/debug/.build-id/NN/NN.de
On 2009-08-11, Manoj Srivastava wrote:
> 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 perhaps the --build-id-style) option to ld, instead of the current
> method of letting the upstream build h
On Tue, Aug 11 2009, Sune Vuorela wrote:
> On 2009-08-10, Manoj Srivastava wrote:
>> On Mon, Aug 10 2009, Sune Vuorela wrote:
>>
>>> On 2009-08-10, Manoj Srivastava wrote:
I would also add that the debug symbols should live in
"/usr/lib/debug/" . /full/path/to/lib_or_binary, b
On 2009-08-10, Manoj Srivastava wrote:
> On Mon, Aug 10 2009, Sune Vuorela wrote:
>
>> On 2009-08-10, Manoj Srivastava wrote:
>>> I would also add that the debug symbols should live in
>>> "/usr/lib/debug/" . /full/path/to/lib_or_binary, blessing the current
>>> practice.
>>
>> You are
On Mon, Aug 10 2009, Steve Langasek wrote:
> On Mon, Aug 10, 2009 at 11:17:45AM -0500, Manoj Srivastava wrote:
>> > There is a namespace issue here, that falls in scope for Policy because it
>> > impacts interoperability; if there are going to be limits placed on the
>> > names of packages in the
On Mon, Aug 10 2009, Sune Vuorela wrote:
> On 2009-08-10, Manoj Srivastava wrote:
>> I would also add that the debug symbols should live in
>> "/usr/lib/debug/" . /full/path/to/lib_or_binary, blessing the current
>> practice.
>
> You are missing the new features of build-id as written e
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 separate from the main archive (if the size of the
> Packages file is an i
On Mon, Aug 10, 2009 at 11:20:17AM -0500, Manoj Srivastava wrote:
> >> Or even just -dbg, since aren't the existing debug packages basically
> >> .ddebs, modulo bugs?
> > There are a few significant exceptions, such as libc6-dbg and libqt4-dbg,
> > where the packages contain complete alternate deb
On Mon, Aug 10, 2009 at 11:17:45AM -0500, Manoj Srivastava wrote:
> > There is a namespace issue here, that falls in scope for Policy because it
> > impacts interoperability; if there are going to be limits placed on the
> > names of packages in the main archive, that almost certainly *does* belong
1 - 100 of 152 matches
Mail list logo
