On 2009-08-10, Manoj Srivastava sriva...@debian.org wrote:
On Mon, Aug 10 2009, Sune Vuorela wrote:
On 2009-08-10, Manoj Srivastava sriva...@debian.org wrote:
I would also add that the debug symbols should live in
/usr/lib/debug/ . /full/path/to/lib_or_binary, blessing the current
On Tue, Aug 11 2009, Sune Vuorela wrote:
On 2009-08-10, Manoj Srivastava sriva...@debian.org wrote:
On Mon, Aug 10 2009, Sune Vuorela wrote:
On 2009-08-10, Manoj Srivastava sriva...@debian.org wrote:
I would also add that the debug symbols should live in
/usr/lib/debug/ .
On Fri, Aug 07, 2009 at 03:37:56PM -0700, Russ Allbery wrote:
Sven Joachim svenj...@gmx.de writes:
Section 12.2, Info documents, contains outdated information. Nowadays
info files are installed via a dpkg trigger provided by the install-info
package, and maintainer scripts should not
On 2009-08-11, Manoj Srivastava sriva...@debian.org 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
On Tue, Aug 11, 2009 at 01:40:20PM +, Sune Vuorela wrote:
On 2009-08-11, Manoj Srivastava sriva...@debian.org 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
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 letting
On Tue, Aug 11 2009, Sune Vuorela wrote:
On 2009-08-11, Manoj Srivastava sriva...@debian.org 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,
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
: :' :
`.
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 the
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) option to
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
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 -- and
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 perhaps the
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.
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
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.
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 named
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 may only be
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 separate
On Tue, 11 Aug 2009, Bill Allombert wrote:
1) As written, the policy change induce maintainers to make changes to their
packages that will cause them to have a bug. This is not acceptable.
2) As discussed previously, there are ways to tweak the process to
avoid this bug while keeping the
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 having to
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 guess I was
Emilio Pozuelo Monfort poch...@gmail.com 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
Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes:
1) As written, the policy change induce maintainers to make changes to
their packages that will cause them to have a bug. This is not
acceptable.
2) As discussed previously, there are ways to tweak the process to avoid
this bug while
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 put
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 to
On Tue, Aug 11, 2009 at 2:45 PM, Gunnar Wolfgw...@gwolf.org 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
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, there
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
On Tue, Aug 11 2009, Russ Allbery wrote:
Emilio Pozuelo Monfort poch...@gmail.com 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
Manoj Srivastava wrote:
On Tue, Aug 11 2009, Russ Allbery wrote:
Emilio Pozuelo Monfort poch...@gmail.com writes:
Manoj Srivastava wrote:
To recap:
1) packages with detached debugging symbols should be named
${package name}-${debug suffix}. As a corollary, no ordinary
Emilio Pozuelo Monfort poch...@gmail.com 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
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 changes if
Emilio Pozuelo Monfort poch...@gmail.com 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
Russ Allbery wrote:
Emilio Pozuelo Monfort poch...@gmail.com 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
Hi,
The TC has decided on the following resolution for the group staff issue:
| 2. Decide to change the default so that /usr/local is not writeable by
| group staff anymore. This change should only be implemented after an
| appropriate transition plan exists which enables system
Emilio Pozuelo Monfort poch...@gmail.com writes:
Russ Allbery wrote:
* These packages are normal Debian packages with normal package metadata,
but will generally have a symlink in /usr/share/doc/package pointing
to the package for which they provide debugging information.
We haven't
Russ Allbery wrote:
Emilio Pozuelo Monfort poch...@gmail.com 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
[Followup-To: header set to gmane.linux.debian.devel.general.]
On 2009-08-11, Russ Allbery r...@debian.org 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
Thijs Kinkhorst th...@debian.org writes:
The TC has decided on the following resolution for the group staff issue:
| 2. Decide to change the default so that /usr/local is not writeable by
| group staff anymore. This change should only be implemented after an
| appropriate transition plan
Philipp Kern tr...@philkern.de writes:
On 2009-08-11, Russ Allbery r...@debian.org 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
Could we please move the default to 755, not 2775, like every other
normal directory in Debian? There is little point in keeping those
directories world-writable if they stop being owned by group staff.
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of
On Tue, August 11, 2009 22:53, Russ Allbery wrote:
Thijs Kinkhorst th...@debian.org writes:
The TC has decided on the following resolution for the group staff
issue:
| 2. Decide to change the default so that /usr/local is not writeable
by | group staff anymore. This change should only be
Thijs Kinkhorst th...@debian.org writes:
I'm not sure it's entirely equivalent, as the directory in the new
situation would be owned by group 0 / root. This is clearly a special
group just as user root is a special user; much more clearly than staff
would be.
Hm, it is? I don't know of
On Tue, August 11, 2009 23:22, Russ Allbery wrote:
Thijs Kinkhorst th...@debian.org writes:
I'm not sure it's entirely equivalent, as the directory in the new
situation would be owned by group 0 / root. This is clearly a special
group just as user root is a special user; much more clearly
On Tue, Aug 11, 2009 at 06:54:12PM +0200, Raphael Hertzog wrote:
On Tue, 11 Aug 2009, Bill Allombert wrote:
1) As written, the policy change induce maintainers to make changes to their
packages that will cause them to have a bug. This is not acceptable.
2) As discussed previously, there
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/package pointing
to the package for which they provide debugging information.
Actually I don’t see the
On Tue, 11 Aug 2009, Santiago Vila wrote:
Could we please move the default to 755, not 2775, like every other
normal directory in Debian? There is little point in keeping those
directories world-writable if they stop being owned by group staff.
The group for the directories can still be staff,
Josselin Mouette j...@debian.org 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/package pointing
to the package for which they provide
On Tue, Aug 11 2009, Russ Allbery wrote:
Josselin Mouette j...@debian.org writes:
Le mardi 11 août 2009 à 13:03 -0700, Russ Allbery a écrit :
* What about contrib and non-free packages? Do they just lose here?
How about yes?
I'm okay with that as an answer. I just want to document it if
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 like a
Manoj Srivastava sriva...@debian.org writes:
So policy is going to prohibit contrib or non-free packages
with debugging symbols (or, at least, debug packages that may use the
common nomenclature)? This seems kinda drastic. So the packages with
debug symbols from those sources will
Josselin Mouette j...@debian.org 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
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 does
Josselin Mouette j...@debian.org 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
55 matches
Mail list logo
