-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Russ,
Of course, I am more of an outside observer than an active participant
in Policy, so take this with a grain of salt.
On 26/02/2012 21:44, Russ Allbery wrote:
> First, I plan on releasing 3.9.3.1 next week with only informative
> changes. I
Hi Mike,
On Wed, Dec 28, 2011 at 7:47 AM, Mike Gabriel <
mike.gabr...@das-netzwerkteam.de> wrote:
> I would love Debian to support this by setting a little signal which could
> be adding the license to common-licenses.
To be fair, I don't think that inclusion in common-licenses is what you
thin
Hi,
On Tue, Dec 27, 2011 at 10:05 AM, Mike Gabriel <
mike.gabr...@das-netzwerkteam.de> wrote:
However, I would love Debian to give a signal on A-GPL as for many
> server-side projects (CMS, Groupware, etc.) A-GPL from my perspective
> definitely is the license to be preferred. However, this is mo
Hi,
I will second Emilio's response here... In the Debian Perl Group, I
have been marked Uploader of many of our packages (though I'm not yet
a DD), since otherwise Lintian complains about it (with the exception
of the more recently introduced new Team Upload syntax).
I would suggest that anyone
Dear Debian dpkg Maintainers:
I believe that all control field names currently in use are restricted
to the ASCII character set.
Debian Policy currently specifies that the files are to be UTF-8
encoded, but does not mention whether any control field names could
be, in the future, encoded in anyth
Hi,
> I would like to propose the following extension to "5.6.23.", the
> "Homepage" header line:
>
> ---
> If no homepage exists, e.g. because the software is abandoned and
> vanished off the net, "None" can be specified.
> ---
While I see the point in having something like this, perhaps some
st
Russ,
Thanks very much for the thoughtful explanation. I'm glad that there
will be a warning in the next release so that we realize it's a bad
idea :)
Cheers,
Jonathan
On Sun, Jan 3, 2010 at 11:24 PM, Russ Allbery wrote:
> Jonathan Yu writes:
>
>> This is a stupid idea
While on principle I agree with Charles Plessy about the merits of
including this license despite not having the "critical mass" that
Debian would like, I understand the view of those in the policy team
and respect their decision.
For what it's worth, I've added a
machine-readable-copyright-format
Hi everyone:
I notice this has been discussed quite a bit previously (though
something like 18 months ago), and the general idea I have gathered
from reading is that the Artistic License, version 2.0 is not yet
popular enough to warrant inclusion in common-licenses.
As we're inching closer to Per
Hi Eugene:
On Sun, Aug 16, 2009 at 1:26 PM, Eugene V.
Lyubimkin wrote:
> Hello.
>
> The new Debian policy 3.8.3 allows the contents of 'Binary' field to span in
> .dsc file and .changes file. However, it's unclear (at least for me), does
> this change allow the spanning in debian/control file or n
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
Hi:
On Thu, Jul 23, 2009 at 10:27 AM, Julien Cristau wrote:
> On Thu, Jul 23, 2009 at 09:57:04 -0400, Jonathan Yu wrote:
>
>> Oh. Interesting. I was (clearly) unaware of that. How recently was
>> this? What was the reasoning behind it?
>
> I think this is the part wh
On Thu, Jul 23, 2009 at 7:14 AM, Steve Langasek wrote:
> On Sun, Jul 19, 2009 at 03:12:54PM -0400, Jonathan Yu wrote:
>
>> >From reading sections 5.6.1 and 5.6.7, the package name
>> conventions/restrictions are the exact same.
>
>> "Package names must cons
Hi:
>From reading sections 5.6.1 and 5.6.7, the package name
conventions/restrictions are the exact same.
"Package names must consist only of lower case letters (a-z), digits
(0-9), plus (+) and minus (-) signs, and periods (.). They must be at
least two characters long and must start with an alp
Hi:
This is a stupid idea, and I don't know any case where it might make
sense to do it, but it has occurred to me that Policy doesn't mention
anything explicitly forbidding it, as far as I can tell.
Lintian allows it through without warning about it. Presumably this is
because nobody has ever do
Hi everyone:
Hm, so I've come across another small issue. Most tarballs have a
directory inside with the same name (to prevent exploding tarballs),
which gets a bit extraneous to type:
Files: t/eg/AFS-2.4.0.tar.gz/AFS-2.4.0/src/ppport.h
It's also slightly different from directories -- t/eg/AFS-2
On Sat, Jul 4, 2009 at 5:08 PM, Russ Allbery wrote:
> Bill Allombert writes:
>
>> I tend to agree with you, but I think there is a more fundamental
>> issue: user-generated content should not be stored in /var and should
>> not created and removed by maintainer scripts. (In other word, clearly
>>
it never hurts to be prepared.
Thanks everyone. I look forward to seeing the new wording appear soon.
Cheers,
Jonathan
On Tue, Jun 30, 2009 at 12:30 AM, Manoj Srivastava wrote:
> On Mon, Jun 29 2009, Russ Allbery wrote:
>
>> Jonathan Yu writes:
>>
>>> Does the Debian P
On Wed, Jul 1, 2009 at 3:25 PM, Emilio Pozuelo Monfort wrote:
> 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 cro
Don:
I really like your solution. It's rather elegant.
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.
Later on I'll take a look a closer l
Steve:
On Tue, Jun 30, 2009 at 4:37 AM, Steve Langasek wrote:
> On Mon, Jun 29, 2009 at 11:55:29AM -0400, Jonathan Yu wrote:
>> For example, if an upstream module contains a Stuff.tar.gz, and that
>> file itself contains stuff that is all under the same license, but has
>>
a lawyer. Perhaps we can speak to debian-legal about this sort of
thing. I'm glad to see a bit of discussion around this happening,
maybe it's a minor TODO we can think about.
Cheers,
Jonathan
On Mon, Jun 29, 2009 at 6:53 PM, Steve Langasek wrote:
> On Mon, Jun 29, 2009 at 01:57:04P
icy List Contributors" or something.
Maybe it should be part of the Teams/Policy "constitution" that anyone
contributing to the Debian Policy Manual signs off copyright to the
SPI Inc.
On Mon, Jun 29, 2009 at 1:50 PM, Russ Allbery wrote:
> Jonathan Yu writes:
>
>> Does the
Hi:
Does the Debian Policy Manual's copyright information need to be updated?
Currently it says:
Copyright Notice
Copyright © 1996,1997,1998 Ian Jackson and Christian Schwarz.
But clearly the new contributors should have a copyright line as
well, indicating their contributions in the m
On Mon, Jun 29, 2009 at 12:47 PM, Russ Allbery wrote:
> Jonathan Yu writes:
>
>> I realize DEP5 and all of that stuff regarding a machine-readable
>> copyright isn't set yet.
>>
>> However, I've come across a case where tarballs contain files that
>>
Hi all:
I realize DEP5 and all of that stuff regarding a machine-readable
copyright isn't set yet.
However, I've come across a case where tarballs contain files that
have various copyrights, and I'm not sure how to represent them in
d/copyright.
For example, if an upstream module contains a Stuf
Jeremiah:
On that note, would you have some time (maybe later on) to work on
producing a simple "annotated Debian Policy" applet?
While a Wiki in itself might not be useful, Russ has mentioned that
perhaps there is room for an Annotated Policy Manual.
Importantly, though, we need to remind users
Russ:
On Fri, Jun 26, 2009 at 10:40 PM, Russ Allbery wrote:
> Jonathan Yu writes:
>
>> That is a very good point. I imagine that there are much more things
>> proposed than there are people to properly review them and 'vote' on
>> them. (well, to the extent t
Russ:
On Fri, Jun 26, 2009 at 2:14 PM, Russ Allbery wrote:
> Jonathan Yu writes:
>
>> I agree that Policy should be kept a closely reviewed thing. But maybe
>> we can have something like AnnoCPAN, where users are allowed to
>> provide /annotations/ inline with the actu
Russ and Steve:
Thank you both for your replies.
I'm going to have to spend some time considering what you have both
said, and try to devise a clever way of representing the platform
information. In terms of maintainability I don't think I have much of
a problem there, since I'm using a Perl scri
On Fri, Jun 26, 2009 at 1:00 PM, Russ Allbery wrote:
> Jeremiah Foster writes:
>
>> This line: "In all cases the part of the field contents on the same
>> line as the field name is empty." is not correct English syntax.
>
> There's arguably a missing comma, but I believe it's correct English
> syn
Hi all:
If the architecture-restricted dependency is part of a set of
alternatives using |, that alternative is ignored completely on
architectures that do not match the restriction. For example:
Build-Depends: foo [!i386] | bar [!amd64]
is equivalent to bar on the i386 architecture, to foo
Hi everyone:
I'm mailing this to both debian-policy and debian-devel, because I'd
like to get the perspective from both sides -- the policy one, and the
"in practice" thinking.
Currently architectures are defined as a string which contains two
parts, an operating system name, and a microprocessor
o see them deprecated in favour of something similar to the
arrangements you and Bill Allombert have mentioned.
On Wed, Jun 24, 2009 at 8:50 AM, Roger Leigh wrote:
> On Wed, Jun 24, 2009 at 01:44:10PM +0200, Bill Allombert wrote:
>> On Wed, Jun 24, 2009 at 04:22:48PM +1000, Ben Finney wrote:
>&
On Wed, Jun 24, 2009 at 12:02 AM, Russ Allbery wrote:
> Jonathan Yu writes:
>
>> I'm curious if I missed something in the policy manual that mentioned
>> paragraphs which are unknown. I find no mention of the Vcs-* fields
>> but I don't know if they're
Hi:
I'm curious if I missed something in the policy manual that mentioned
paragraphs which are unknown. I find no mention of the Vcs-* fields
but I don't know if they're supposed to just be copied as-is. I've
seen the stuff on X-Comments and all the rules for X[BS]*- stuff, but
not the Vcs- stuff
an be assumed to be Linux.
On Mon, Jun 22, 2009 at 12:48 PM, Jonathan Yu wrote:
> Hi:
>
> Debian Policy 11.1 states:
> "11.1 Architecture specification strings
>
> If a program needs to specify an architecture specification string in
> some place, it should select one of
Hi:
Debian Policy 11.1 states:
"11.1 Architecture specification strings
If a program needs to specify an architecture specification string in
some place, it should select one of the strings provided by
dpkg-architecture -L. The strings are in the format os-arch, though
the OS part is sometimes el
for field
values.
Cheers,
Jonathan
On Sat, Jun 20, 2009 at 3:14 PM, Jonathan Yu wrote:
> Hi everyone:
>
> I was reading the Debian Policy Manual 2.4, which discusses the
> various sections that packages may be classified as. However, I can't
> tell if section names should be lo
Hi everyone:
I was reading the Debian Policy Manual 2.4, which discusses the
various sections that packages may be classified as. However, I can't
tell if section names should be lowercase, or if they are
case-insensitive.
Presumably case shouldn't matter, but I think there should be
clarificati
Hi:
The other day I was packaging Module::CPANTS::Analyse, a Perl module.
As part of its tests, it includes a bunch of other distributions in
gzipped tarball format. However, as these included tarballs are
actually those of other distributions, their copyright is different.
Sure, that's fine.
So
Hi:
This is probably a stupid question, but...
On Tue, May 26, 2009 at 11:33 PM, Russ Allbery wrote:
> Currently, Policy's description of Architecture includes the statement:
>
> In the main debian/control file in the source package, or in the
> source package control file .dsc, one may sp
42 matches
Mail list logo
