On Tue, 27 Oct 2015 10:06:50 +0100 Ansgar Burchardt wrote:
> Hi,
>
> I suggest to change
>
> | If there are development files associated with a shared
> | library, the source package needs to generate a binary
> | development package named librarynamesoversion-dev, or if you
> | prefer only to s
Hi,
On 15/06/11 13:33, Michael Prokop wrote:
> I don't mean to nit-pick but I just had a discussion with some DDs
> about who should be really listed in the Uploaders field: a) people
> with Upload *permissions* [DMs/DDs] and therefore actually uploading
> the package (if not being the maintainer
On 19/05/11 19:30, Russ Allbery wrote:
> I think it's going to be very difficult to do this through Policy. This
> would mean Debian-specific patches to a *LOT* of software. Usually we
> only put things like this into Policy once they're almost entirely
> adopted already, to clean up the straggle
On 11/09/10 15:50, Charles Plessy wrote:
> Subject: [PATCH] Documents the DM-Upload-Allowed field, Closes: #588014.
> + id="f-Dm-Upload-Allowed"Dm-Upload-Allowed
> + id="f-Dm-Upload-Allowed"Dm-Upload-Allowed
> +
> + Dm-Upload-Allowed
> + experimental must include the field "DM-Upload-Allowed
On 28/08/10 02:16, Charles Plessy wrote:
> By the way, wouldn't mime-support be a good candidate for declaring dpkg
> triggers?
I've just reported bug #594915 about that.
Regards,
Emilio
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble
On 23/07/10 04:09, Charles Plessy wrote:
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -1636,7 +1636,15 @@
> The maintainer name and email address used in the changelog
> should be the details of the person uploading this
> version. They are not necessarily those of the
> -
On 20/07/10 18:40, Russ Allbery wrote:
> Emilio Pozuelo Monfort writes:
>> Would this be worth a lintian warning? I've tried to remove .la files
>> from quite a few GNOME packages but I couldn't because there were other
>> packages' .la files referencing them
On 20/07/10 02:43, Russ Allbery wrote:
> 10.2
> Libtool `.la' files should not be installed for public libraries.
> If they're required (for `libltdl', for instance), the
> `dependency_libs' setting should be emptied. Library packages
> historically inc
On 19/07/10 22:22, Neil Williams wrote:
> This sentence in Policy 2.5 is too prohibitive:
> "Systems with only the required packages are probably unusable, but they
> do have enough functionality to allow the sysadmin to boot and install
> more software."
> I have many systems with only Priority:
Hi,
On 19/07/10 18:49, Russ Allbery wrote:
> Now that the terminology is in, the patch to address the normative issue
> in this bug is short and simple. Objections or seconds?
>
> diff --git a/policy.sgml b/policy.sgml
> index c0415c1..9aca16c 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@
Hi,
On 19/07/10 18:34, Russ Allbery wrote:
> diff --git a/policy.sgml b/policy.sgml
> index 6943397..3a70475 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -5389,6 +5389,14 @@ Replaces: mail-transport-agent
> (ld) when compiling packages, as it will only look for
> libgdbm.so when
On 19/07/10 07:20, Charles Plessy wrote:
> Package: debian-policy
> Version: 3.9.0.0
> Severity: wishlist
> Tags: patch
>
> Dear all,
>
> during the discussion about team uploads (http://wiki.debian.org/TeamUpload),
> it was proposed to send a patch to the Policy, to include a footnotes that
> re
Hi,
On 19/07/10 10:03, Charles Plessy wrote:
> Package: debian-policy
> Version: 3.9.0.0
> Severity: normal
> Tags: patch
>
> Dear all,
>
> as promised one year and a half ago
> (http://lists.debian.org/20090201011604.GF13843%40kunpuu.plessy.org), here is
> a
> patch that removes the mention of
Hi,
On 13/07/10 04:11, Russ Allbery wrote:
> Russ Allbery writes:
>
>> There was a lot of background information missing from Policy, which in
>> my opinion made it unnecessarily difficult to understand the motivation
>> and implications of the various Policy requirements. Here's a first
>> dra
Hi,
On 13/07/10 04:15, Russ Allbery wrote:
> Steve Langasek writes:
>
>> Moving this out of a footnote into the body of policy would probably make
>> this hang together better. Perhaps:
>
>> If the maintainer of a package no longer has time or desire to maintain a
>> package, it will be or
Hi,
On 04/07/10 02:40, Russ Allbery wrote:
> Russ Allbery writes:
>
>> Lintian has several checks for the control files included in a binary
>> package, but so far as I can tell, there is no general discussion in
>> Policy right now about these files or any restrictions on them. This
>> seems l
On 18/07/10 03:36, Russ Allbery wrote:
> Joey Hess writes:
>> Jérôme Marant wrote:
>>> Joey Hess writes:
>
editor(1) and pager(1) and www-browser(1) are already provided by at
least some apternatives for those programs. If this is really a
problem, which I don't think it is. Inste
On 22/06/10 19:26, Russ Allbery wrote:
> Charles, are you happy with those changes? Everyone else, objections or
> seconds?
>
> diff --git a/policy.sgml b/policy.sgml
> index d489738..77850d6 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -2595,15 +2595,21 @@ Package: libc6
> Debian ch
On 14/06/10 12:55, Santiago Vila wrote:
> I assume we will have to wait some time before we can remove the
> license itself from base-files (i.e. until all packages stop
> referencing the file).
Yes, that would be step 3 in Russ' plan.
Cheers,
Emilio
--
To UNSUBSCRIBE, email to debian-policy-
On 14/06/10 04:00, Russ Allbery wrote:
> Objections or seconds?
>
> diff --git a/policy.sgml b/policy.sgml
> index df6ae89..5a76cf3 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -2672,7 +2672,7 @@ Package: libc6
>
>
> The package maintainer's name and email address. The
On 12/06/10 19:35, Russ Allbery wrote:
> Hm, actually, better (slightly less awkward, I think):
>
> A paragraph must not contain more than one instance of a particular
> field name.
Seconded as well.
Emilio
signature.asc
Description: OpenPGP digital signature
On 12/06/10 22:29, Russ Allbery wrote:
> Objections or seconds?
>
> diff --git a/policy.sgml b/policy.sgml
> index 720150d..23a8c90 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -2488,8 +2488,6 @@ Package: libc6
> The syntax and semantics of the fields are described below.
>
>
On 12/06/10 11:18, Charles Plessy wrote:
> as a non-native speaker, I have difficulties with the use of 'may' in your
> patch: if fields may be unique, they also may be not unique, so what is the
> message in this sentence? It does not give me the impression that the goal
> is to discourage the use
Hi,
On 11/06/10 18:58, Russ Allbery wrote:
> dpkg-dev checks this at build time, so this definitely seems to be the
> right move. Here is a patch.
>
> Objections or seconds?
>
> diff --git a/policy.sgml b/policy.sgml
> index 87b9795..99ab0ff 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -
On 10/06/10 22:13, Russ Allbery wrote:
> I therefore propose proceeding as follows:
>
> 1. Add a new Lintian warning asking people to stop using the
>common-licenses link for the BSD license and instead include the
>license directly in debian/copyright. As we've discussed in the past,
>
On 09/06/10 18:55, David Martínez Moreno wrote:
> Package: developers-reference
> Severity: normal
>
> In the section 4.8 you can read:
>
> ...accessible at http://incoming.debian.org/ until it is really installed in
> the Debian archive. This happens only once a day...
>
> The dins
On 03/06/10 03:44, Russ Allbery wrote:
> Adam C Powell IV writes:
>> That would make the name different from what's in my GPG key, but I
>> suppose I could add an additional name to the key... Note my email From
>> address doesn't have the comma or full stop, because I find the quotes
>> aestheti
Hi,
Russ Allbery wrote:
> Here is an updated version of the patch that corrects or clarifies a few
> other places in Policy.
I like the patch in general. I have a couple of comments though:
>
> - Every package must be accompanied by a verbatim copy of its
> - copyright and dis
Hi,
Charles Plessy wrote:
> The proposed patch puts additional constraints on the packages, that would
> make
> more difficult refactor later the Policy towards make a clearer abstraction of
> the build interface (which I think is desirable), by for instance speficying
> that debian/rules is an e
Since I guess given the new process discussed in debian-devel we need to second
developers-reference changes too, let me be the first one to do so :)
Pini wrote:
> Hi,
>
> Section 3.7 of Developers' Reference lists the steps to retire from
> the Debian project.
>
> I suggest to insert, in second
Emilio Pozuelo Monfort wrote:
> Given the recent thread in debian-devel[1], I think we should document in
> policy that packages that are not tightly related to Debian shouldn't be
> native.
So to move this on, how about only "recommending" it? Wouter, would you be happy
Package: debian-policy
Version: 3.8.3.0
Severity: wishlist
Hi,
Given the recent thread in debian-devel[1], I think we should document in
policy that packages that are not tightly related to Debian shouldn't be
native.
The motivations for discouraging native packages not Debian specific are
that
Russ Allbery wrote:
> I don't know if we should include CDBS's basic patch system as well.
If you create a list of what doesn't need a README.source, sure.
Emilio
signature.asc
Description: OpenPGP digital signature
Chris Lamb wrote:
> Package: debian-policy
> Version: 3.8.3.0
>
> Hi Policy hackers.
>
> I feel there is a problem with §4.14 ("Source package handling:
> debian/README.source") that is a little harmful at present.
>
> Basically, I feel that assuming that all packages that use a patch system
> r
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
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, aptitu
Josselin Mouette wrote:
> Hi,
>
> the question in the subject may sound a bit naive, but I’m starting to
> wonder why we still set the Standards-Version in package control files.
>
> AIUI, this header is here to indicate which version of the policy the
> package is supposed to conform to. This wa
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
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
>>
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
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
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
>>>> ${p
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 o
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
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
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
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
Manoj Srivastava wrote:
> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
>> I've documented the .ddeb format in the wiki page [1] ("DDeb Format",
>> which is short since the format is basically that of .debs). Do we
>> really need this to be documented in
[ Moving to debian-policy ]
Manoj Srivastava wrote:
> On Fri, Jul 31 2009, Emilio Pozuelo Monfort wrote:
>
>> Manoj Srivastava wrote:
>>> We do not want to have different helper package start inventing
>>> a helper specific way of building ddebs, with n
Hi,
Russ Allbery wrote:
> Sorry about the delay in dealing with this. I've now committed:
>
>
> Installed-Size
>
>
> This field appears in the control files of binary packages,
> and in the Packages files. It gives an
> estimation the total
Jonathan Yu wrote:
> I guess it is possible we run into some messed up corner case where a
> directory has the same name as the tarball, but I'm hoping that never
> happens, and I suppose we'll cross that river when we get there.
That's not technically possible, is it?
signature.asc
Description
Giacomo A. Catenazzi wrote:
> I would change:
> "It gives the total amount of disk space required to install the named
> package."
> to
> "It gives an indicative amount of disk space required to install the
> named package."
> because the field cannot give the real required disk space:
> - (we real
Russ Allbery wrote:
> Joerg Jaspert writes:
>
>> Also, keep in mind what Mark wrote elsewhere. He asked the DPL to let
>> SPI get us some lawyers input on the question. Thats probably the best
>> course.
>
> Yes. I'm wholeheartedly in favor of this, and I think we should hold any
> resolution o
Russ Allbery wrote:
> So then, to answer Don's original question, I think the use case is "know
> the license of the package in more detail than what is guaranteed by the
> DFSG." Which is basically what you said.
We provide the full license text in debian/copyright, or alternatively, point to
a
Ben Finney wrote:
> Don Armstrong writes:
>> 6) Documentation for users about usability of packages in non-free
>> (IE, non-commercial, non-modifiable, etc.)
>
> Why restrict this point to non-free?
Because anything in main complies to the DFSG and thus doesn't need any further
explanations. If
Kalle Kivimaa wrote:
> Russ Allbery writes:
>> started experimenting with the new copyright file format, I never
>> documented the license or copyright information for any of the
>> Autotools-generated files, and I never heard a peep of concern about
>> that.)
>
> Currently the ftpmasters don't r
Loïc Minier wrote:
> On Wed, Mar 18, 2009, Raphael Hertzog wrote:
>> I also included DEB_VENDOR in the set of variables. This variable is not
>> used currently (as I just introduced it with dpkg 1.15.0) but I expect it
>> to become more used in the future for things like this:
>> - enable additiona
Greetings from this new -policy subscriber!
Russ Allbery wrote:
> @@ -4188,6 +4188,22 @@ Build-Depends-Indep: texinfo
> Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
>hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
>
> + requires kernel-headers-2.2.0 on all architectures
59 matches
Mail list logo
