Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status
8 views
Skip to first unread message
Raphael Hertzog
Jan 16, 2012, 6:20:01 AM1/16/12
to
Hello,
FTR given that I got no reports of problems with DEP-3, that it's already
well established, I just changed the state of the DEP-3 from CANDIDATE
to ACCEPTED.
Of course this does not mean that the DEP-3 can't be extended or improved
(in particular when it doesn't break backwards compatibility)
but it does mean that this format is ready for widespread usage. Use it to
document the patches that you add to Debian packages:
http://dep.debian.net/deps/dep3/
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012011611...@rivendell.home.ouaza.com
FTR given that I got no reports of problems with DEP-3, that it's already
well established, I just changed the state of the DEP-3 from CANDIDATE
to ACCEPTED.
Of course this does not mean that the DEP-3 can't be extended or improved
(in particular when it doesn't break backwards compatibility)
but it does mean that this format is ready for widespread usage. Use it to
document the patches that you add to Debian packages:
http://dep.debian.net/deps/dep3/
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012011611...@rivendell.home.ouaza.com
Bernd Zeimetz
Jan 16, 2012, 9:10:02 AM1/16/12
to
Hi,
> FTR given that I got no reports of problems with DEP-3, that it's already
> well established, I just changed the state of the DEP-3 from CANDIDATE
> to ACCEPTED.
just because that you didn't get any reports you should not set a status
to ACCEPTED. IMHO the driver of a DEP should not do that at all, at
least not without asking on common lists first. No reaction on your DEP
could just mean that people consider it as a waste of time or don't like
your format.
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F142F0...@bzed.de
> FTR given that I got no reports of problems with DEP-3, that it's already
> well established, I just changed the state of the DEP-3 from CANDIDATE
> to ACCEPTED.
to ACCEPTED. IMHO the driver of a DEP should not do that at all, at
least not without asking on common lists first. No reaction on your DEP
could just mean that people consider it as a waste of time or don't like
your format.
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jon Dowland
Jan 16, 2012, 10:00:03 AM1/16/12
to
On Mon, Jan 16, 2012 at 03:07:08PM +0100, Bernd Zeimetz wrote:
> just because that you didn't get any reports you should not set a status
> to ACCEPTED. IMHO the driver of a DEP should not do that at all, at
> least not without asking on common lists first. No reaction on your DEP
> could just mean that people consider it as a waste of time or don't like
> your format.
Who should have that authority, then? The DEP-0 proposers? Since the whole DEP
> just because that you didn't get any reports you should not set a status
> to ACCEPTED. IMHO the driver of a DEP should not do that at all, at
> least not without asking on common lists first. No reaction on your DEP
> could just mean that people consider it as a waste of time or don't like
> your format.
process itself is still in CANDIDATE, we could end up in an interesting
situation if/when it comes to migrate *that* to ACCEPTED ☺
DEP-0 merely says
> consensus exists that the implementation has been a success
Perhaps that needs unpacking.
--
Jon Dowland
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Raphael Hertzog
Jan 16, 2012, 10:00:03 AM1/16/12
to
Hi,
On Mon, 16 Jan 2012, Bernd Zeimetz wrote:
> just because that you didn't get any reports you should not set a status
> to ACCEPTED. IMHO the driver of a DEP should not do that at all, at
> least not without asking on common lists first. No reaction on your DEP
> could just mean that people consider it as a waste of time or don't like
> your format.
We did have lots of discussion when we were designing it. People commented
and reacted.
Remember that this format is there to help and is not mandatory (although
it's likely to be considered as a best practice in terms of packaging).
So if you find it a waste of time, ignore it.
But it's already widely used (I have used it for my own packages, Ubuntu
is recommending it too), it has been designed following an open process to
let everybody participate and ensure it fits as many scenario as possible.
It's lightweight and compatible with many of Git's convention.
And I have been asked about moving it to ACCEPTED by someone else already
(I think it was zack but I no longer remember). And the reason why I post
here is precisely so that people can object _if needed_.
So do you have a reason to object to the ACCEPTED status of this DEP
or was this pure rhetoric ?
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
On Mon, 16 Jan 2012, Bernd Zeimetz wrote:
> just because that you didn't get any reports you should not set a status
> to ACCEPTED. IMHO the driver of a DEP should not do that at all, at
> least not without asking on common lists first. No reaction on your DEP
> could just mean that people consider it as a waste of time or don't like
> your format.
and reacted.
Remember that this format is there to help and is not mandatory (although
it's likely to be considered as a best practice in terms of packaging).
So if you find it a waste of time, ignore it.
But it's already widely used (I have used it for my own packages, Ubuntu
is recommending it too), it has been designed following an open process to
let everybody participate and ensure it fits as many scenario as possible.
It's lightweight and compatible with many of Git's convention.
And I have been asked about moving it to ACCEPTED by someone else already
(I think it was zack but I no longer remember). And the reason why I post
here is precisely so that people can object _if needed_.
So do you have a reason to object to the ACCEPTED status of this DEP
or was this pure rhetoric ?
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012011614...@rivendell.home.ouaza.com
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stefano Zacchiroli
Jan 16, 2012, 10:10:02 AM1/16/12
to
On Mon, Jan 16, 2012 at 02:49:55PM +0000, Jon Dowland wrote:
> Who should have that authority, then? The DEP-0 proposers? Since the whole DEP
> process itself is still in CANDIDATE, we could end up in an interesting
> situation if/when it comes to migrate *that* to ACCEPTED ☺
>
> DEP-0 merely says
>
> > consensus exists that the implementation has been a success
>
> Perhaps that needs unpacking.
You're probably right ... but let's resist the temptation of caring more
> Who should have that authority, then? The DEP-0 proposers? Since the whole DEP
> process itself is still in CANDIDATE, we could end up in an interesting
> situation if/when it comes to migrate *that* to ACCEPTED ☺
>
> DEP-0 merely says
>
> > consensus exists that the implementation has been a success
>
> Perhaps that needs unpacking.
about processes than substance.
Does anyone have further comments about DEP-3? If so, please state
them. Otherwise, let's forget about the process details (no matter if
they could have been better or not) and rejoice for a nice standard way
of adding useful metadata to patches in the Debian archive.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences ...... http://upsilon.cc/zack ...... . . o
Debian Project Leader ....... @zack on identi.ca ....... o o o
« the first rule of tautology club is the first rule of tautology club »
Jonathan Wiltshire
Jan 16, 2012, 11:10:02 AM1/16/12
to
On 2012-01-16 15:02, Stefano Zacchiroli wrote:
> Does anyone have further comments about DEP-3? If so, please state
> them. Otherwise, let's forget about the process details (no matter
> if
> they could have been better or not) and rejoice for a nice standard
> way
> of adding useful metadata to patches in the Debian archive.
It is only a small thing but I did not realise DEP-3 was still a
> Does anyone have further comments about DEP-3? If so, please state
> them. Otherwise, let's forget about the process details (no matter
> if
> they could have been better or not) and rejoice for a nice standard
> way
> of adding useful metadata to patches in the Debian archive.
candidate or I would have spoken earlier. A CVE field, mandatory if a
CVE has been published for this patch and is the major component of this
patch, would allow easy tracing of patches back to CVE publications
later (for review perhaps, or by other distributions).
Such a field should probably be comma-separated if more than one CVE
identifier is relevant to the patch.
--
Jonathan Wiltshire j...@debian.org
Debian Developer http://people.debian.org/~jmw
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tanguy Ortolo
Jan 16, 2012, 11:50:02 AM1/16/12
to
Jonathan Wiltshire, 2012-01-16 17:01+0100:
are not the only security vulnerability database.
--
,--.
: /` ) Tanguy Ortolo <xmpp:tan...@ortolo.eu> <irc://irc.oftc.net/Tanguy>
| `-' Debian Developer
\_
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/jf1k4a$27a$1...@dough.gmane.org
> It is only a small thing but I did not realise DEP-3 was still a
> candidate or I would have spoken earlier. A CVE field, mandatory if a
> CVE has been published for this patch and is the major component of this
> patch, would allow easy tracing of patches back to CVE publications
> later (for review perhaps, or by other distributions).
Then it would be better to make it independant from CVE, since they
> candidate or I would have spoken earlier. A CVE field, mandatory if a
> CVE has been published for this patch and is the major component of this
> patch, would allow easy tracing of patches back to CVE publications
> later (for review perhaps, or by other distributions).
are not the only security vulnerability database.
--
,--.
: /` ) Tanguy Ortolo <xmpp:tan...@ortolo.eu> <irc://irc.oftc.net/Tanguy>
| `-' Debian Developer
\_
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jonathan Wiltshire
Jan 16, 2012, 12:00:02 PM1/16/12
to
On 2012-01-16 16:43, Tanguy Ortolo wrote:
> Jonathan Wiltshire, 2012-01-16 17:01+0100:
>> It is only a small thing but I did not realise DEP-3 was still a
>> candidate or I would have spoken earlier. A CVE field, mandatory if
>> a
>> CVE has been published for this patch and is the major component of
>> this
>> patch, would allow easy tracing of patches back to CVE publications
>> later (for review perhaps, or by other distributions).
>
> Then it would be better to make it independant from CVE, since they
> are not the only security vulnerability database.
Ack; but we (in the security team) only track CVE really. The Debian
> Jonathan Wiltshire, 2012-01-16 17:01+0100:
>> It is only a small thing but I did not realise DEP-3 was still a
>> candidate or I would have spoken earlier. A CVE field, mandatory if
>> a
>> CVE has been published for this patch and is the major component of
>> this
>> patch, would allow easy tracing of patches back to CVE publications
>> later (for review perhaps, or by other distributions).
>
> Then it would be better to make it independant from CVE, since they
> are not the only security vulnerability database.
bug number is useful but only within Debian, the CVE identifier is
cross-distribution.
--
Jonathan Wiltshire j...@debian.org
Debian Developer http://people.debian.org/~jmw
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2e6c5e69749b3b03...@hogwarts.powdarrmonkey.net
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve Langasek
Jan 16, 2012, 12:50:02 PM1/16/12
to
On Mon, Jan 16, 2012 at 12:14:26PM +0100, Raphael Hertzog wrote:
> FTR given that I got no reports of problems with DEP-3, that it's already
> well established, I just changed the state of the DEP-3 from CANDIDATE
> to ACCEPTED.
>
> Of course this does not mean that the DEP-3 can't be extended or improved
> (in particular when it doesn't break backwards compatibility)
> but it does mean that this format is ready for widespread usage. Use it to
> document the patches that you add to Debian packages:
> http://dep.debian.net/deps/dep3/
+1 for moving this to accepted.
> FTR given that I got no reports of problems with DEP-3, that it's already
> well established, I just changed the state of the DEP-3 from CANDIDATE
> to ACCEPTED.
>
> Of course this does not mean that the DEP-3 can't be extended or improved
> (in particular when it doesn't break backwards compatibility)
> but it does mean that this format is ready for widespread usage. Use it to
> document the patches that you add to Debian packages:
> http://dep.debian.net/deps/dep3/
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Mehdi Dogguy
Jan 16, 2012, 1:00:02 PM1/16/12
to
On 16/01/12 18:33, Thomas Goirand wrote:
>
> Also, does this mean that you've patched the policy, that lintian
> would soon more aggressively complain about lacks of patch comments,
> and that we'll have a new Standard-Version?
>
Lintian already complains when a quilt patch doesn't contain a
description, fwiw.
See http://lintian.debian.org/tags/quilt-patch-missing-description.html
Regards,
--
Mehdi
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F1464DF...@dogguy.org
>
> Also, does this mean that you've patched the policy, that lintian
> would soon more aggressively complain about lacks of patch comments,
> and that we'll have a new Standard-Version?
>
Lintian already complains when a quilt patch doesn't contain a
description, fwiw.
See http://lintian.debian.org/tags/quilt-patch-missing-description.html
Regards,
--
Mehdi
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Goirand
Jan 16, 2012, 1:00:02 PM1/16/12
to
On 01/16/2012 07:14 PM, Raphael Hertzog wrote:
> Hello,
>
> FTR given that I got no reports of problems with DEP-3, that it's already
> well established, I just changed the state of the DEP-3 from CANDIDATE
> to ACCEPTED.
>
> Of course this does not mean that the DEP-3 can't be extended or improved
> (in particular when it doesn't break backwards compatibility)
> but it does mean that this format is ready for widespread usage. Use it to
> document the patches that you add to Debian packages:
> http://dep.debian.net/deps/dep3/
>
> Cheers,
>
IMHO, that's a very good thing if we can improve Debian, and
> Hello,
>
> FTR given that I got no reports of problems with DEP-3, that it's already
> well established, I just changed the state of the DEP-3 from CANDIDATE
> to ACCEPTED.
>
> Of course this does not mean that the DEP-3 can't be extended or improved
> (in particular when it doesn't break backwards compatibility)
> but it does mean that this format is ready for widespread usage. Use it to
> document the patches that you add to Debian packages:
> http://dep.debian.net/deps/dep3/
>
> Cheers,
>
don't hold back proposals indefinitively, especially when most of
us are already implementing such DEP.
I'm really not sure what makes you authoritative for it though,
and I'd like to understand (which doesn't conflict with the fact
I'm happy dep3 is in state ACCEPTED, and that you decided to
do it!).
Also, does this mean that you've patched the policy, that lintian
would soon more aggressively complain about lacks of patch
comments, and that we'll have a new Standard-Version?
I'm already always uploading DEP5 compliant copyright files
myself, and I'd be happy to see it go in the policy. Having them
parsable is, IMHO, a very good thing, so that we can make
statistics about what license we have, and do all sorts of
incompatibility checks (like, who's using GPL and badly
mixing it with MPL or OpenSSL for example...).
Cheers,
Thomas
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jakub Wilk
Jan 16, 2012, 1:20:02 PM1/16/12
to
* Raphael Hertzog <her...@debian.org>, 2012-01-16, 12:14:
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012011618...@jwilk.net
>FTR given that I got no reports of problems with DEP-3, that it's
>already well established, I just changed the state of the DEP-3 from
>CANDIDATE to ACCEPTED.
Does a DEP-3 parser exist? And why not?
>already well established, I just changed the state of the DEP-3 from
>CANDIDATE to ACCEPTED.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ian Jackson
Jan 16, 2012, 1:30:02 PM1/16/12
to
Jon Dowland writes ("Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status"):
consensus has been achieved on a DEP.
If the dictator gets it wrong then insofar as a DEP is a technical
policy for Debian (which DEP-3 definitely is) the Technical Committee
could overrule the decision, as could a GR of course.
Ian.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20244.26459....@chiark.greenend.org.uk
> Who should have that authority, then? The DEP-0 proposers? Since
> the whole DEP process itself is still in CANDIDATE, we could end up
> in an interesting situation if/when it comes to migrate *that* to
> ACCEPTED ☺
I think the DPL should appoint a dictator who will rule on when
> the whole DEP process itself is still in CANDIDATE, we could end up
> in an interesting situation if/when it comes to migrate *that* to
> ACCEPTED ☺
consensus has been achieved on a DEP.
If the dictator gets it wrong then insofar as a DEP is a technical
policy for Debian (which DEP-3 definitely is) the Technical Committee
could overrule the decision, as could a GR of course.
Ian.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Raphael Hertzog
Jan 16, 2012, 3:00:01 PM1/16/12
to
On Tue, 17 Jan 2012, Thomas Goirand wrote:
> I'm really not sure what makes you authoritative for it though,
> and I'd like to understand (which doesn't conflict with the fact
> I'm happy dep3 is in state ACCEPTED, and that you decided to
> do it!).
I just did it as the DEP driver because I believe that there's a
> I'm really not sure what makes you authoritative for it though,
> and I'd like to understand (which doesn't conflict with the fact
> I'm happy dep3 is in state ACCEPTED, and that you decided to
> do it!).
consensus that the implementation has been a success and that's the
criteria set in DEP-0.
Since the goal was only to provide a format to standardize the
meta-information and that many people are successfully using this
format to document their patch, I think we can assert that the DEP
has been successful.
I have not counted how many patches embed those standardized fields so I
can't say how widely it is used but I know from the interaction with
various DD / teams that it's relatively well accepted (the quilt
maintainer even recently added a --dep3 option to "quilt header").
> Also, does this mean that you've patched the policy, that lintian
> would soon more aggressively complain about lacks of patch
> comments, and that we'll have a new Standard-Version?
recommendation in the developers-reference would be appropriate.
Lintian already recommends the usage of DEP3 in the long description of
the relevant "informative" tags it has:
http://lintian.debian.org/tags/dpatch-missing-description.html
http://lintian.debian.org/tags/quilt-patch-missing-description.html
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120116194...@rivendell.home.ouaza.com
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Goirand
Jan 16, 2012, 4:00:02 PM1/16/12
to
On 01/17/2012 01:56 AM, Mehdi Dogguy wrote:
> On 16/01/12 18:33, Thomas Goirand wrote:
>>
>> Also, does this mean that you've patched the policy, that lintian
>> would soon more aggressively complain about lacks of patch comments,
>> and that we'll have a new Standard-Version?
>>
>
> Lintian already complains when a quilt patch doesn't contain a
> description, fwiw.
I know that, but it's currently just warnings, not hard errors.
> On 16/01/12 18:33, Thomas Goirand wrote:
>>
>> Also, does this mean that you've patched the policy, that lintian
>> would soon more aggressively complain about lacks of patch comments,
>> and that we'll have a new Standard-Version?
>>
>
> Lintian already complains when a quilt patch doesn't contain a
> description, fwiw.
Thomas
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Goirand
Jan 16, 2012, 4:00:02 PM1/16/12
to
On 01/17/2012 01:44 AM, Steve Langasek wrote:
> On Mon, Jan 16, 2012 at 12:14:26PM +0100, Raphael Hertzog wrote:
>
>> FTR given that I got no reports of problems with DEP-3, that it's already
>> well established, I just changed the state of the DEP-3 from CANDIDATE
>> to ACCEPTED.
>>
>> Of course this does not mean that the DEP-3 can't be extended or improved
>> (in particular when it doesn't break backwards compatibility)
>> but it does mean that this format is ready for widespread usage. Use it to
>> document the patches that you add to Debian packages:
>> http://dep.debian.net/deps/dep3/
>>
> +1 for moving this to accepted.
>
Steve, since you're marked as "|Drivers" at:
> On Mon, Jan 16, 2012 at 12:14:26PM +0100, Raphael Hertzog wrote:
>
>> FTR given that I got no reports of problems with DEP-3, that it's already
>> well established, I just changed the state of the DEP-3 from CANDIDATE
>> to ACCEPTED.
>>
>> Of course this does not mean that the DEP-3 can't be extended or improved
>> (in particular when it doesn't break backwards compatibility)
>> but it does mean that this format is ready for widespread usage. Use it to
>> document the patches that you add to Debian packages:
>> http://dep.debian.net/deps/dep3/
>>
> +1 for moving this to accepted.
>
http://dep.debian.net/deps/dep5/
could you tell what's blocking DEP5 status from
switching to ACCEPTED? Are there any more ongoing
discussions on it?
Cheers,
Thomas
P.S: Hoping that Raphael wont mind too much that
I'm a bit hijacking his thread! :)
|
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Charles Plessy
Jan 16, 2012, 7:00:02 PM1/16/12
to
Le Mon, Jan 16, 2012 at 12:14:26PM +0100, Raphael Hertzog a écrit :
>
> FTR given that I got no reports of problems with DEP-3, that it's already
> well established, I just changed the state of the DEP-3 from CANDIDATE
> to ACCEPTED.
>
> Of course this does not mean that the DEP-3 can't be extended or improved
> (in particular when it doesn't break backwards compatibility)
> but it does mean that this format is ready for widespread usage. Use it to
> document the patches that you add to Debian packages:
> http://dep.debian.net/deps/dep3/
Bonjour Raphaël,
>
> FTR given that I got no reports of problems with DEP-3, that it's already
> well established, I just changed the state of the DEP-3 from CANDIDATE
> to ACCEPTED.
>
> Of course this does not mean that the DEP-3 can't be extended or improved
> (in particular when it doesn't break backwards compatibility)
> but it does mean that this format is ready for widespread usage. Use it to
> document the patches that you add to Debian packages:
> http://dep.debian.net/deps/dep3/
with my DEP admin hat on, I congratulate and thank you for homing this DEP
to completion.
In my understanding of the process, DEP 3 will not be changed anymore. The
format it defines has been implemented in different tools, and this is the
achievement of DEP 3. Modifications of the format are of course possible, as a
new DEP (taking as inspiration the RFCs 822, 2822 and then 5322), or outside
the DEP process.
Have a nice day,
--
Charles Plessy
Debian Enhancement Process team,
http://dep.debian.net
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
Jan 16, 2012, 8:40:02 PM1/16/12
to
Thomas Goirand <zi...@debian.org> writes:
> Also, does this mean that you've patched the policy, that lintian would
> soon more aggressively complain about lacks of patch comments, and that
> we'll have a new Standard-Version?
No. DEP-3 is an optional standard.
> Also, does this mean that you've patched the policy, that lintian would
> soon more aggressively complain about lacks of patch comments, and that
> we'll have a new Standard-Version?
I'm not sure if it should be incorporated into Policy or not. It's
probably not a bad idea, although we should deal with DEP-5 first and see
if that provides a reasonable precedent for how to do so.
> BTW, what's the status of DEP5?
detail provided to ensure that the results are interoperable, and I'd like
to see those concerns resolved before including it in Policy. (Which is
currently being worked on, as I understand it.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
Jan 17, 2012, 4:10:02 AM1/17/12
to
Le lundi 16 janvier 2012 à 18:07 +0000, Ian Jackson a écrit :
> I think the DPL should appoint a dictator who will rule on when
> consensus has been achieved on a DEP.
Seconded. The DEP process is missing a clear way to make a DEP change
> I think the DPL should appoint a dictator who will rule on when
> consensus has been achieved on a DEP.
state. With a single-person (or small team) responsibility, everything
should be clearer.
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bastien ROUCARIES
Jan 17, 2012, 6:30:01 AM1/17/12
to
On Mon, Jan 16, 2012 at 9:42 PM, Thomas Goirand <zi...@debian.org> wrote:
> On 01/17/2012 01:44 AM, Steve Langasek wrote:
>> On Mon, Jan 16, 2012 at 12:14:26PM +0100, Raphael Hertzog wrote:
>>
>>> FTR given that I got no reports of problems with DEP-3, that it's already
>>> well established, I just changed the state of the DEP-3 from CANDIDATE
>>> to ACCEPTED.
>>>
>>> Of course this does not mean that the DEP-3 can't be extended or improved
>>> (in particular when it doesn't break backwards compatibility)
>>> but it does mean that this format is ready for widespread usage. Use it to
>>> document the patches that you add to Debian packages:
>>> http://dep.debian.net/deps/dep3/
>>>
>> +1 for moving this to accepted.
>>
> Steve, since you're marked as "|Drivers" at:
> http://dep.debian.net/deps/dep5/
>
> could you tell what's blocking DEP5 status from
> switching to ACCEPTED? Are there any more ongoing
> discussions on it?
Yes one question do I need to document aclocal.m4 copyright patchwork ?
> On 01/17/2012 01:44 AM, Steve Langasek wrote:
>> On Mon, Jan 16, 2012 at 12:14:26PM +0100, Raphael Hertzog wrote:
>>
>>> FTR given that I got no reports of problems with DEP-3, that it's already
>>> well established, I just changed the state of the DEP-3 from CANDIDATE
>>> to ACCEPTED.
>>>
>>> Of course this does not mean that the DEP-3 can't be extended or improved
>>> (in particular when it doesn't break backwards compatibility)
>>> but it does mean that this format is ready for widespread usage. Use it to
>>> document the patches that you add to Debian packages:
>>> http://dep.debian.net/deps/dep3/
>>>
>> +1 for moving this to accepted.
>>
> Steve, since you're marked as "|Drivers" at:
> http://dep.debian.net/deps/dep5/
>
> could you tell what's blocking DEP5 status from
> switching to ACCEPTED? Are there any more ongoing
> discussions on it?
> Cheers,
>
> Thomas
>
> P.S: Hoping that Raphael wont mind too much that
> I'm a bit hijacking his thread! :)
>
> |
>
>
> --
> To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/4F148BAB...@debian.org
>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Simon McVittie
Jan 17, 2012, 6:40:01 AM1/17/12
to
On 16/01/12 16:01, Jonathan Wiltshire wrote:
> A CVE field, mandatory if a
> CVE has been published for this patch and is the major component of this
> patch, would allow easy tracing of patches back to CVE publications
> later (for review perhaps, or by other distributions).
I wonder whether CVE IDs are close enough to being a (limited-scope) bug
> A CVE field, mandatory if a
> CVE has been published for this patch and is the major component of this
> patch, would allow easy tracing of patches back to CVE publications
> later (for review perhaps, or by other distributions).
tracking system to treat them as such, analogous to Bug-Debian,
Bug-Fedora etc.; I've previously used "Bug-CVE: CVE-2011-xxxx" in
ioquake3, although I haven't been completely consistent about that.
(Also, a Bug-* line would ideally have a URI - is there a canonical URI
corresponding to each CVE ID, preferably one that doesn't still just say
"RESERVED" long after the embargo date?)
S
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jonathan Wiltshire
Jan 17, 2012, 6:50:01 AM1/17/12
to
On 2012-01-17 11:37, Simon McVittie wrote:
> On 16/01/12 16:01, Jonathan Wiltshire wrote:
>> A CVE field, mandatory if a
>> CVE has been published for this patch and is the major component of
>> this
>> patch, would allow easy tracing of patches back to CVE publications
>> later (for review perhaps, or by other distributions).
>
> I wonder whether CVE IDs are close enough to being a (limited-scope)
> bug tracking system to treat them as such, analogous to Bug-Debian,
> Bug-Fedora etc.; I've previously used "Bug-CVE: CVE-2011-xxxx" in
> ioquake3, although I haven't been completely consistent about that.
It *should* be the case that each CVE identifiers is unique to a
> On 16/01/12 16:01, Jonathan Wiltshire wrote:
>> A CVE field, mandatory if a
>> CVE has been published for this patch and is the major component of
>> this
>> patch, would allow easy tracing of patches back to CVE publications
>> later (for review perhaps, or by other distributions).
>
> I wonder whether CVE IDs are close enough to being a (limited-scope)
> bug tracking system to treat them as such, analogous to Bug-Debian,
> Bug-Fedora etc.; I've previously used "Bug-CVE: CVE-2011-xxxx" in
> ioquake3, although I haven't been completely consistent about that.
problem; occasionally they get revoked if a duplicate becomes apparent.
In rare cases they are disputed and marked as such.
> (Also, a Bug-* line would ideally have a URI - is there a canonical
> URI corresponding to each CVE ID, preferably one that doesn't still
> just say "RESERVED" long after the embargo date?)
http://security-tracker.debian.org/tracker/<CVEID>
https://bugzilla.redhat.com/show_bug.cgi?id=<CVEID>
Generally not so useful:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=<CVEID> (the official CVE
database)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=<CVEID>
--
Jonathan Wiltshire j...@debian.org
Debian Developer http://people.debian.org/~jmw
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/823bcc7d8ef2bcd0...@hogwarts.powdarrmonkey.net
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Charles Plessy
Jan 17, 2012, 7:00:02 AM1/17/12
to
Le Tue, Jan 17, 2012 at 12:07:54PM +0100, Bastien ROUCARIES a écrit :
>
> Yes one question do I need to document aclocal.m4 copyright patchwork ?
Dear Bastien,
>
> Yes one question do I need to document aclocal.m4 copyright patchwork ?
judging from the packages that are accepted in our archive, the empirical
answer is no. Nevertheless, the DEP 5 format and any free-form format let you
to document these files if you feel so.
I would love the answer to this question documented somewhere, but I think
that it would not belong to the DEP 5 document. If you would like, you
can send the question to the FTP Master team and CC the bug number #462996
(“Document requirements for copyright file.”).
Have a nice day,
--
Charles Plessy
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jonathan Nieder
Jan 17, 2012, 12:40:02 PM1/17/12
to
Charles Plessy wrote:
> I would love the answer to this question documented somewhere, but I think
> that it would not belong to the DEP 5 document. If you would like, you
> can send the question to the FTP Master team and CC the bug number #462996
> (“Document requirements for copyright file.”).
Or you could send a proposal to bug#462996 or another policy bug and
> I would love the answer to this question documented somewhere, but I think
> that it would not belong to the DEP 5 document. If you would like, you
> can send the question to the FTP Master team and CC the bug number #462996
> (“Document requirements for copyright file.”).
cc the FTP team as an affected party when it is time to build
consensus. After all, taking on the legal risk and administrative
burden of _carrying out_ the decision of whether packages are
appropriate for inclusion in the archive doesn't imply they have
volunteered to also do the difficult work of writing a complete and
unambiguous specification about it. Others can help them.
Hope that helps,
Jonathan
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
Jan 17, 2012, 1:00:02 PM1/17/12
to
Bastien ROUCARIES <roucarie...@gmail.com> writes:
> Yes one question do I need to document aclocal.m4 copyright patchwork ?
My take on this (but note that I'm not an ftpmaster):
> Yes one question do I need to document aclocal.m4 copyright patchwork ?
The debian/copyright file serves two separate purposes. First, it's
included in binary packages to provide our mandatory license and copyright
statements to comply with licenses and to communicate to users the
licensing of the work. Second, it's used by the ftpmaster team to review
the package licensing and ensure that it's okay for Debian to distribute
it.
For aclocal.m4 and other build system files, the binary packages are not
normally (there are some special cases) a derivative work of those files,
and therefore their licensing has no impact on the binary package.
There's therefore no need to document their licensing for the first
purpose, since the binary package is independent of them. Their licensing
may have to be documented for legal reasons in the source package, but for
legal compliance in the source package, the notices at the top of the
files are generally sufficient. And, more generally, upstream is
presumably already complying with the necessary license restrictions for
the source package and we therefore comply by redistributing the source
package verbatim (at least verbatim from the perspective of those
notices).
So, the remaining reason why one might document this is for the ftpmaster
review. However, 99% of aclocal.m4 files (and configure, and Makefile.in,
and so forth) in packages using Autotools have the same, boring license
which is known to be free and which doesn't require any review. So while
it's okay to document it (I do for my packages), it really isn't necessary
for the ftpmaster review and I think it can be safely omitted. *However*,
if aclocal.m4 *isn't* under the customary license and does have some sort
of unusual provision, then you should document it for the ftpmaster
review.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87ty3uc...@windlord.stanford.edu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Charles Plessy
Jan 17, 2012, 8:00:01 PM1/17/12
to
Dear FTP Masters,
in http://bugs.debian.org/462996, me and others have expressed
interest to have a written document that describes precisely
what the Debian copyright file must contain. Do you think it
is realisable, and if yes, how could we help you ? Would you
like to be submitted a draft ?
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
in http://bugs.debian.org/462996, me and others have expressed
interest to have a written document that describes precisely
what the Debian copyright file must contain. Do you think it
is realisable, and if yes, how could we help you ? Would you
like to be submitted a draft ?
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
Peter Miller
Jan 17, 2012, 9:20:01 PM1/17/12
to
On Wed, 2012-01-18 at 09:49 +0900, Charles Plessy wrote:
> interest to have a written document that describes precisely
> what the Debian copyright file must contain.
Are there any plans to write a tool to scan a project tree and generate
> interest to have a written document that describes precisely
> what the Debian copyright file must contain.
the DEP-5 debian/copyright file?
I am my own upstream for many projects, and some of them have thousands
of source files. There is no way I am going to write and maintain
debian/copyright in DEP-5 format by hand. I imagine that a similar
problem exists for DDs who package large upstream projects.
Without an automated tool, I will be ignoring the optional DEP-5 misery.
--
Peter Miller <peter.mi...@gmail.com>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1326852576.2413.37.camel@hawk
Russ Allbery
Jan 17, 2012, 9:30:02 PM1/17/12
to
Peter Miller <peter.mi...@gmail.com> writes:
> Are there any plans to write a tool to scan a project tree and generate
> the DEP-5 debian/copyright file?
> I am my own upstream for many projects, and some of them have thousands
> of source files. There is no way I am going to write and maintain
> debian/copyright in DEP-5 format by hand. I imagine that a similar
> problem exists for DDs who package large upstream projects.
> Without an automated tool, I will be ignoring the optional DEP-5 misery.
This objection makes me think that you believe that more information is
> Are there any plans to write a tool to scan a project tree and generate
> the DEP-5 debian/copyright file?
> I am my own upstream for many projects, and some of them have thousands
> of source files. There is no way I am going to write and maintain
> debian/copyright in DEP-5 format by hand. I imagine that a similar
> problem exists for DDs who package large upstream projects.
> Without an automated tool, I will be ignoring the optional DEP-5 misery.
required by the DEP-5 format than is in your existing debian/copyright
files. But the explicit intention of the DEP-5 format is to *not* say
that. It enables you to record additional information, but absolutely
does not require it. That's been the purpose of some recent discussions
about how to indicate a copyright and license for the entire package
without listing clauses for specific files, for example.
If there's anything about the current DEP-5 specification that gave you a
contrary impression, could you please point it out?
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/871uqxu...@windlord.stanford.edu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Erik de Castro Lopo
Jan 17, 2012, 10:10:01 PM1/17/12
to
Peter Miller wrote:
> On Wed, 2012-01-18 at 09:49 +0900, Charles Plessy wrote:
> > interest to have a written document that describes precisely
> > what the Debian copyright file must contain.
>
> Are there any plans to write a tool to scan a project tree and generate
> the DEP-5 debian/copyright file?
>
> I am my own upstream for many projects, and some of them have thousands
> of source files. There is no way I am going to write and maintain
> debian/copyright in DEP-5 format by hand. I imagine that a similar
> problem exists for DDs who package large upstream projects.
>
> Without an automated tool, I will be ignoring the optional DEP-5 misery.
I ran into that problem with the xmonad-contrib package recently (about
> On Wed, 2012-01-18 at 09:49 +0900, Charles Plessy wrote:
> > interest to have a written document that describes precisely
> > what the Debian copyright file must contain.
>
> Are there any plans to write a tool to scan a project tree and generate
> the DEP-5 debian/copyright file?
>
> I am my own upstream for many projects, and some of them have thousands
> of source files. There is no way I am going to write and maintain
> debian/copyright in DEP-5 format by hand. I imagine that a similar
> problem exists for DDs who package large upstream projects.
>
> Without an automated tool, I will be ignoring the optional DEP-5 misery.
200 contributors) and just used a bit it grep and awk.
However, it would nice if there was a tool that did this automagically.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Peter Miller
Jan 17, 2012, 10:50:02 PM1/17/12
to
On Tue, 2012-01-17 at 18:20 -0800, Russ Allbery wrote:
wildcards are permitted.
Each different copyright x license combination needs its own separate
entry.
Note that "Copyright (C) 2008 Peter Miller" is different than "Copyright
(C) 2011 Peter Miller" is different than "Copyright (C) 1991, 2012 Peter
Miller", so the cross product is going to be substantial for long lived
projects, even when the number of contributors is small.
Once the number of contributors rises "Copyright (C) 2008 Peter Miller,
plus Copyright (C) 2008 Fred Nurk" is different than "Copyright (C) 2008
Peter Miller" alone. This means the cross product is going to explode
faster.
But wait, there's more. A number of my projects have a subset of source
files from a second underlying project source with a compatible license
(GPL-to-GPL usually in my case) but they may have been GPL-v2+ and now I
have released them as GPL-v3+, so we have yet another source for a
larger license x copyright cross product.
I estimate that my older and larger projects are going to have
multi-megabyte debian/copyright files. Hopefully they will compress
well as they are going to be hugely (but not trivially) redundant.
Hence, I want an automated tool. It still gripes me that such a huge
file is unlikely to be used by, or useful to, anyone. And, if an
automated tool *can* do it, why have the file at all?
--
Peter Miller <pmi...@opensource.org.au>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1326858154.2413.50.camel@hawk
> Peter Miller <peter.mi...@gmail.com> writes:
>
> This objection makes me think that you believe that more information is
> required by the DEP-5 format than is in your existing debian/copyright
> files.
My understanding is that all project files are covered, although
>
> This objection makes me think that you believe that more information is
> required by the DEP-5 format than is in your existing debian/copyright
> files.
wildcards are permitted.
Each different copyright x license combination needs its own separate
entry.
Note that "Copyright (C) 2008 Peter Miller" is different than "Copyright
(C) 2011 Peter Miller" is different than "Copyright (C) 1991, 2012 Peter
Miller", so the cross product is going to be substantial for long lived
projects, even when the number of contributors is small.
Once the number of contributors rises "Copyright (C) 2008 Peter Miller,
plus Copyright (C) 2008 Fred Nurk" is different than "Copyright (C) 2008
Peter Miller" alone. This means the cross product is going to explode
faster.
But wait, there's more. A number of my projects have a subset of source
files from a second underlying project source with a compatible license
(GPL-to-GPL usually in my case) but they may have been GPL-v2+ and now I
have released them as GPL-v3+, so we have yet another source for a
larger license x copyright cross product.
I estimate that my older and larger projects are going to have
multi-megabyte debian/copyright files. Hopefully they will compress
well as they are going to be hugely (but not trivially) redundant.
Hence, I want an automated tool. It still gripes me that such a huge
file is unlikely to be used by, or useful to, anyone. And, if an
automated tool *can* do it, why have the file at all?
--
Peter Miller <pmi...@opensource.org.au>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
Jan 17, 2012, 11:10:01 PM1/17/12
to
Peter Miller <pmi...@opensource.org.au> writes:
> My understanding is that all project files are covered, although
> wildcards are permitted.
> Each different copyright x license combination needs its own separate
> entry.
I don't think this is the case. I see no reason why you couldn't just
> My understanding is that all project files are covered, although
> wildcards are permitted.
> Each different copyright x license combination needs its own separate
> entry.
have a Files: * stanza that lists the same information that you have in
debian/copyright already. I cared enough about that question that I
raised exactly that issue on debian-project, and that's *my* understanding
of the outcome at least.
I think this property is important, since if we require that people
document way more information than is currently documented (and clearly
currently isn't necessary) in order to use DEP-5, that will get in the way
of the benefits of DEP-5, namely machine-parseable license descriptions.
> Note that "Copyright (C) 2008 Peter Miller" is different than "Copyright
> (C) 2011 Peter Miller" is different than "Copyright (C) 1991, 2012 Peter
> Miller", so the cross product is going to be substantial for long lived
> projects, even when the number of contributors is small.
would be in favor of modifying it to make that clear if you could identify
the places where you got that mistaken impression.
> But wait, there's more. A number of my projects have a subset of source
> files from a second underlying project source with a compatible license
> (GPL-to-GPL usually in my case) but they may have been GPL-v2+ and now I
> have released them as GPL-v3+, so we have yet another source for a
> larger license x copyright cross product.
required to do is document the license under which you're distributing the
file. If everything is GPL-compatible, and you're therefore using the GPL
for everything, then one Files: * stanza specifying that license is all
that's required. In an ideal world, we'd have more because it would be
useful, but if nothing more is required by ftp-master now, I don't see any
reason why DEP-5 should change that.
> I estimate that my older and larger projects are going to have
> multi-megabyte debian/copyright files. Hopefully they will compress
> well as they are going to be hugely (but not trivially) redundant.
> Hence, I want an automated tool. It still gripes me that such a huge
> file is unlikely to be used by, or useful to, anyone. And, if an
> automated tool *can* do it, why have the file at all?
will help....
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87d3ahs...@windlord.stanford.edu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Chow Loong Jin
Jan 18, 2012, 3:10:01 AM1/18/12
to
On 18/01/2012 10:09, Peter Miller wrote:
> Are there any plans to write a tool to scan a project tree and generate
> the DEP-5 debian/copyright file?
I personally use:
> Are there any plans to write a tool to scan a project tree and generate
> the DEP-5 debian/copyright file?
$ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 > debian/copyright
And then manually modify debian/copyright to compress entries to satisfaction.
There's also a bug regarding merging the two scripts together:
<http://bugs.debian.org/472199>
--
Kind regards,
Loong Jin
Dominique Dumont
Jan 18, 2012, 4:50:03 AM1/18/12
to
Le Monday 16 January 2012 19:15:07, Jakub Wilk a écrit :
> Does a DEP-3 parser exist? And why not?
config-edit -appli dpkg (soon to become 'cme edit dpkg') is able to parse,
> Does a DEP-3 parser exist? And why not?
modify and save DEP-3 patches ( note that this command also deal with
debian/copyright, debian/control and some other debian files).
This command is part of libconfig-model-perl package
HTH
Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/
Dominique Dumont
Jan 18, 2012, 5:00:01 AM1/18/12
to
Le Wednesday 18 January 2012 09:03:14, Chow Loong Jin a écrit :
> I personally use:
> $ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 >
> debian/copyright
>
> And then manually modify debian/copyright to compress entries to
> satisfaction.
Oooh, that's a good one. I'll probably reuse all that stuff to propose a
> I personally use:
> $ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 >
> debian/copyright
>
> And then manually modify debian/copyright to compress entries to
> satisfaction.
default debian/copyright file with config-edit/soon-to-be-cme
Thanks
Simon Josefsson
Jan 18, 2012, 5:50:01 AM1/18/12
to
Russ Allbery <r...@debian.org> writes:
>> Note that "Copyright (C) 2008 Peter Miller" is different than "Copyright
>> (C) 2011 Peter Miller" is different than "Copyright (C) 1991, 2012 Peter
>> Miller", so the cross product is going to be substantial for long lived
>> projects, even when the number of contributors is small.
>
> I am absolutely certain that this is not the intention of DEP-5, and I
> would be in favor of modifying it to make that clear if you could identify
> the places where you got that mistaken impression.
I would support making this clearer by adding the example above to DEP5.
>> Note that "Copyright (C) 2008 Peter Miller" is different than "Copyright
>> (C) 2011 Peter Miller" is different than "Copyright (C) 1991, 2012 Peter
>> Miller", so the cross product is going to be substantial for long lived
>> projects, even when the number of contributors is small.
>
> I am absolutely certain that this is not the intention of DEP-5, and I
> would be in favor of modifying it to make that clear if you could identify
> the places where you got that mistaken impression.
When I have written DEP5 copyright files, I have been uncertain about
this aspect too, but I can't point to anything directly in the document
that gave me this impression (nor to anything that would have given me
the reversed impression). An example would probably have helped.
Thinking even further, maybe there should be a tutorial at the end of
DEP5 on how to convert an existing compliant debian/copyright file into
a DEP5-compliant debian/copyright file. As far as I understand from
this discussion, it would be sufficient to merely make it syntactically
conform to the DEP5 file format, typically by folding the old data under
a 'Files: *' header. If this is the case, and there is an example on
how to do it, this could trigger more DEP5 adoption.
/Simon
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Peter Miller
Jan 18, 2012, 5:50:02 AM1/18/12
to
On Wed, 2012-01-18 at 16:03 +0800, Chow Loong Jin wrote:
> $ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 > debian/copyright
That is just what I was looking for, although I doubt I'll be editing
> $ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 > debian/copyright
the output, just adding it to my build system, next to where I build the
Debian package for Continuous Integration (even though it's "upstream"
at that point).
I think this information should be highlighted in
http://dep.debian.net/deps/dep5/
--
Peter Miller <pmi...@opensource.org.au>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Peter Miller
Jan 18, 2012, 5:50:02 AM1/18/12
to
On Tue, 2012-01-17 at 20:01 -0800, Russ Allbery wrote:
> Peter Miller <pmi...@opensource.org.au> writes:
>
> > My understanding is that all project files are covered, although
> > wildcards are permitted.
>
> > Each different copyright x license combination needs its own separate
> > entry.
>
> I don't think this is the case. [...]
> Peter Miller <pmi...@opensource.org.au> writes:
>
> > My understanding is that all project files are covered, although
> > wildcards are permitted.
>
> > Each different copyright x license combination needs its own separate
> > entry.
>
> I am absolutely certain that this is not the intention of DEP-5, and I
> would be in favor of modifying it to make that clear if you could identify
> the places where you got that mistaken impression.
"Files paragraph (Repeatable)
"The declaration of copyright and license for files is done in
one or more paragraphs. In the simplest case, a single paragraph
can be used which applies to all files and lists all applicable
copyrights and licenses."
It says "all applicable copyrights and licenses". Note the "and". To
me, in a standards context, this means conjunction (logical and) not
disjunction (logical or).
If there was some other intent, the words don't say it. Note there are
*three* potentially ambiguous lists in that definition, they *all* need
to be disambiguated in the language of DEP-5.
Look at it from the other perspective:
(a) given filename X, what license(s) apply? Does DEP-5, by conflating
copyrights and licenses, risk returning too many licenses? inapplicable
licenses?
(b) given filename X, what copyright(s) apply? Does DEP-5, by
conflating copyrights and licenses, risk returning too many copyrights?
inapplicable copyrights?
One solution may be to separate it into two paragraphs, one for
applicable copyrights, and one for applicable licenses. That is, you
can have "Files:" && "Copyright:" || "Files:" && "License:", but you
can't have "Files:" && "Copyright:" && "License:"
While I'm banging on about semantics, when you are looking up a file by
name, is it the first file name pattern match that applies, or the last,
or do all of them? It doesn't say.
English is sloppy be default. Standards language should try very had
not to be, even optional standards.
--
Peter Miller <pmi...@opensource.org.au>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josue Abarca
Jan 18, 2012, 6:10:01 AM1/18/12
to
On Wed, Jan 18, 2012 at 09:36:07PM +1100, Peter Miller wrote:
> On Tue, 2012-01-17 at 20:01 -0800, Russ Allbery wrote:
> > Peter Miller <pmi...@opensource.org.au> writes:
...
> On Tue, 2012-01-17 at 20:01 -0800, Russ Allbery wrote:
> > Peter Miller <pmi...@opensource.org.au> writes:
> While I'm banging on about semantics, when you are looking up a file by
> name, is it the first file name pattern match that applies, or the last,
> or do all of them? It doesn't say.
...
> name, is it the first file name pattern match that applies, or the last,
> or do all of them? It doesn't say.
About this:
http://dep.debian.net/deps/dep5/#files-field
"Files
...
Multiple Files paragraphs are allowed. The last paragraph that
matches a particular file applies to it."
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Charles Plessy
Jan 18, 2012, 6:40:01 AM1/18/12
to
Le Wed, Jan 18, 2012 at 04:03:14PM +0800, Chow Loong Jin a écrit :
> On 18/01/2012 10:09, Peter Miller wrote:
> > Are there any plans to write a tool to scan a project tree and generate
> > the DEP-5 debian/copyright file?
>
> I personally use:
> $ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 > debian/copyright
>
> And then manually modify debian/copyright to compress entries to satisfaction.
Dear Peter and Chow,
> On 18/01/2012 10:09, Peter Miller wrote:
> > Are there any plans to write a tool to scan a project tree and generate
> > the DEP-5 debian/copyright file?
>
> I personally use:
> $ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 > debian/copyright
>
> And then manually modify debian/copyright to compress entries to satisfaction.
In my experience, licensecheck has false positives and false negatives. Please
be sure to validate its results with an independant method.
In my packaging workflow, I am usually taking the reverse approach as you do: I
generate the Debian copyright file by hand (guided by grep), and then confront
the result to the output of licensecheck.
This said, both ways are a matter of preference, as long as there is
proofreading.
The licensecheck to DEP 5 converter may also be even more useful if it could be
implemented as a lintian check, that would for instance verify that no new
license is missed when upgrading a package. Sometimes, non-free files try to
sneak in…
In the future, there will be a safe (but possibly time-consumming) way to
autogenerate a machine-readable Debian copyright file: exhaustively document
all the files following the SPDX standard, and then convert from this format.
See for instance Ubuntu's project on the matter.
https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-machine-readable-copyrights
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120118113...@merveille.plessy.net
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jonas Smedegaard
Jan 18, 2012, 7:00:02 AM1/18/12
to
On 12-01-18 at 08:31pm, Charles Plessy wrote:
> Le Wed, Jan 18, 2012 at 04:03:14PM +0800, Chow Loong Jin a écrit :
> > On 18/01/2012 10:09, Peter Miller wrote:
> > > Are there any plans to write a tool to scan a project tree and generate
> > > the DEP-5 debian/copyright file?
> >
> > I personally use:
> > $ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 > debian/copyright
> >
> > And then manually modify debian/copyright to compress entries to
> > satisfaction.
>
> Dear Peter and Chow,
>
> In my experience, licensecheck has false positives and false
> negatives. Please be sure to validate its results with an independant
> method.
Good point.
> Le Wed, Jan 18, 2012 at 04:03:14PM +0800, Chow Loong Jin a écrit :
> > On 18/01/2012 10:09, Peter Miller wrote:
> > > Are there any plans to write a tool to scan a project tree and generate
> > > the DEP-5 debian/copyright file?
> >
> > I personally use:
> > $ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 > debian/copyright
> >
> > And then manually modify debian/copyright to compress entries to
> > satisfaction.
>
> Dear Peter and Chow,
>
> In my experience, licensecheck has false positives and false
> negatives. Please be sure to validate its results with an independant
> method.
That's also the reason licensecheck2dep5 adds a FIXME to each and every
section of its output: Not to be trusted as-is - requires proofreading!
> The licensecheck to DEP 5 converter may also be even more useful if it
> could be implemented as a lintian check, that would for instance
> verify that no new license is missed when upgrading a package.
> Sometimes, non-free files try to sneak in…
Currently, licensecheck2dep5 when used with cdbs does something similar:
warns during build (not independently as lintian does) if an included
auto-generated file lacks entries from a freshly autogenerated one.
Yes, I really should do as promised in bug#472199 and integrate
licensecheck2dep5 with licensecheck itself to have more parts of its
functionality available independent from CDBS.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
Russ Allbery
Jan 18, 2012, 12:10:01 PM1/18/12
to
Pushing this towards debian-project, which is where the DEP-5 discussion
is supposed to happen.
Peter Miller <pmi...@opensource.org.au> writes:
> http://dep.debian.net/deps/dep5/
> "Files paragraph (Repeatable)
>
> "The declaration of copyright and license for files is done in
> one or more paragraphs. In the simplest case, a single paragraph
> can be used which applies to all files and lists all applicable
> copyrights and licenses."
> It says "all applicable copyrights and licenses". Note the "and". To
> me, in a standards context, this means conjunction (logical and) not
> disjunction (logical or).
So it sounds like we need to explicitly say that if there are files
Copyright 2010 and others Copyright 2009, you just write:
Copyright: 2009, 2010 whoever
and be done with it. This is one of those things that to me is "obvious,"
but apparently it's not that obvious so we should spell it out.
Furthermore, we should probably also say that if upstream has a general
copyright notice, it's not required to sort through every file and find
every other mention of a copyright holder (but we should be sure that
ftpmaster is okay with that, since on that front I've heard conflicting
things).
Similarly, if the licenses used by upstream on the files allow releasing
under some other license that's covering the work as a whole, we should
probably say that it's okay to just list the license under which
everything is being distributed (although it's probably ideal to document
the separate licenses).
> If there was some other intent, the words don't say it. Note there are
> *three* potentially ambiguous lists in that definition, they *all* need
> to be disambiguated in the language of DEP-5.
If you have those handy, could you mention where they are?
> Look at it from the other perspective:
> (a) given filename X, what license(s) apply? Does DEP-5, by conflating
> copyrights and licenses, risk returning too many licenses? inapplicable
> licenses?
The work as a whole is often distributed under some particular license,
with individual files under some other, compatible license. In that
situation, the most important thing to document is the license of the work
as a whole, since we know that we can deal with everything within that
work under that license and (most importantly) that's the license of the
resulting binaries.
Documenting the separate compatible licenses of individual files is useful
to people who want to separate the work, but is not nearly as important.
> (b) given filename X, what copyright(s) apply? Does DEP-5, by
> conflating copyrights and licenses, risk returning too many copyrights?
> inapplicable copyrights?
I don't think this is a good way to look at it, honestly. That's not why
we document copyrights; it's almost never important in copyright law to
get the exact list of copyright statements that apply to a specific file.
Collecting them and collapsing the years is de rigueur.
The main reason why we document the copyright notices is because many
licenses require them. The secondary reason is that if there are any
legal questions, those are the people who have to be asked. Neither of
those reasons require treating "Copyright 2009 foo" and "Copyright 2002,
2010 foo" as distinct strings.
> One solution may be to separate it into two paragraphs, one for
> applicable copyrights, and one for applicable licenses. That is, you
> can have "Files:" && "Copyright:" || "Files:" && "License:", but you
> can't have "Files:" && "Copyright:" && "License:"
I think this is way too much overhead. I'd rather just clarify the
wording to make it clear that you can do the, to me, obvious thing.
Incidentally, this conversation would be easier to have if you didn't come
across as quite this angry. No one involved in DEP-5 is trying to
strangle your kittens or torture your dog, I swear!
is supposed to happen.
Peter Miller <pmi...@opensource.org.au> writes:
> http://dep.debian.net/deps/dep5/
> "Files paragraph (Repeatable)
>
> "The declaration of copyright and license for files is done in
> one or more paragraphs. In the simplest case, a single paragraph
> can be used which applies to all files and lists all applicable
> copyrights and licenses."
> It says "all applicable copyrights and licenses". Note the "and". To
> me, in a standards context, this means conjunction (logical and) not
> disjunction (logical or).
Copyright 2010 and others Copyright 2009, you just write:
Copyright: 2009, 2010 whoever
and be done with it. This is one of those things that to me is "obvious,"
but apparently it's not that obvious so we should spell it out.
Furthermore, we should probably also say that if upstream has a general
copyright notice, it's not required to sort through every file and find
every other mention of a copyright holder (but we should be sure that
ftpmaster is okay with that, since on that front I've heard conflicting
things).
Similarly, if the licenses used by upstream on the files allow releasing
under some other license that's covering the work as a whole, we should
probably say that it's okay to just list the license under which
everything is being distributed (although it's probably ideal to document
the separate licenses).
> If there was some other intent, the words don't say it. Note there are
> *three* potentially ambiguous lists in that definition, they *all* need
> to be disambiguated in the language of DEP-5.
> Look at it from the other perspective:
> (a) given filename X, what license(s) apply? Does DEP-5, by conflating
> copyrights and licenses, risk returning too many licenses? inapplicable
> licenses?
with individual files under some other, compatible license. In that
situation, the most important thing to document is the license of the work
as a whole, since we know that we can deal with everything within that
work under that license and (most importantly) that's the license of the
resulting binaries.
Documenting the separate compatible licenses of individual files is useful
to people who want to separate the work, but is not nearly as important.
> (b) given filename X, what copyright(s) apply? Does DEP-5, by
> conflating copyrights and licenses, risk returning too many copyrights?
> inapplicable copyrights?
we document copyrights; it's almost never important in copyright law to
get the exact list of copyright statements that apply to a specific file.
Collecting them and collapsing the years is de rigueur.
The main reason why we document the copyright notices is because many
licenses require them. The secondary reason is that if there are any
legal questions, those are the people who have to be asked. Neither of
those reasons require treating "Copyright 2009 foo" and "Copyright 2002,
2010 foo" as distinct strings.
> One solution may be to separate it into two paragraphs, one for
> applicable copyrights, and one for applicable licenses. That is, you
> can have "Files:" && "Copyright:" || "Files:" && "License:", but you
> can't have "Files:" && "Copyright:" && "License:"
wording to make it clear that you can do the, to me, obvious thing.
Incidentally, this conversation would be easier to have if you didn't come
across as quite this angry. No one involved in DEP-5 is trying to
strangle your kittens or torture your dog, I swear!
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87ehuxrl...@windlord.stanford.edu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jakub Wilk
Jan 18, 2012, 12:50:02 PM1/18/12
to
* Dominique Dumont <d...@debian.org>, 2012-01-18, 10:41:
And how do I use this parser? I want something as simple as: for a given
patch, check if the header complies to DEP-3 and if it does, dump it in
some machine-readable format.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012011817...@jwilk.net
>>Does a DEP-3 parser exist? And why not?
>config-edit -appli dpkg (soon to become 'cme edit dpkg') is able to
>parse, modify and save DEP-3 patches ( note that this command also deal
>with debian/copyright, debian/control and some other debian files).
Huh? What has dpkg to do with DEP-3?
>config-edit -appli dpkg (soon to become 'cme edit dpkg') is able to
>parse, modify and save DEP-3 patches ( note that this command also deal
>with debian/copyright, debian/control and some other debian files).
And how do I use this parser? I want something as simple as: for a given
patch, check if the header complies to DEP-3 and if it does, dump it in
some machine-readable format.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stefano Zacchiroli
Jan 18, 2012, 1:20:03 PM1/18/12
to
On Tue, Jan 17, 2012 at 10:05:06AM +0100, Josselin Mouette wrote:
> Le lundi 16 janvier 2012 à 18:07 +0000, Ian Jackson a écrit :
> > I think the DPL should appoint a dictator who will rule on when
> > consensus has been achieved on a DEP.
(I originally interpreted this as being enclosed within <sarcasm> tags)
> Le lundi 16 janvier 2012 à 18:07 +0000, Ian Jackson a écrit :
> > I think the DPL should appoint a dictator who will rule on when
> > consensus has been achieved on a DEP.
> Seconded. The DEP process is missing a clear way to make a DEP change
> state. With a single-person (or small team) responsibility, everything
> should be clearer.
gives more power to anyone. It was just a device to keep track of a
discussion that was already happening, document it in some durable form,
and monitor its status. It's not like that the person with the power of
marking a DEP as "ACCEPTED" has the power of creating the corresponding
consensus.
Consensus should exist by itself, ditto for an implementation, and then
the corresponding DEP could be marked ACCEPTED. If that happens too
soon, no big deal, it's in a VCS, we can revert the commit. Some people
might be fooled in the interim in believing something is "more standard"
than how much it actual is, but the same could have happened to anyone
looking at the archive of some discussion (i.e. without DEP).
If a DEP is in strict need of a formal rubber stamp of standardization,
then its "implementation" should probably correspond to formal
integration into policy (as, IIRC, it is the case for DEP-5).
The above notwithstanding, we can probably learn from this thread that,
for the future, it would help to first announce "I'm about to mark
DEP-$x as ACCEPTED" and then doing that. I personally don't think it is
a big deal, but given that others disagree, ... why not.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences ...... http://upsilon.cc/zack ...... . . o
Debian Project Leader ....... @zack on identi.ca ....... o o o
« the first rule of tautology club is the first rule of tautology club »
Dominique Dumont
Jan 18, 2012, 1:40:03 PM1/18/12
to
Le Wednesday 18 January 2012 18:41:44, Jakub Wilk a écrit :
> >config-edit -appli dpkg (soon to become 'cme edit dpkg') is able to
> >parse, modify and save DEP-3 patches ( note that this command also deal
> >with debian/copyright, debian/control and some other debian files).
>
> Huh? What has dpkg to do with DEP-3?
This command is designed to help debian packager do their job, i.e editing
> >config-edit -appli dpkg (soon to become 'cme edit dpkg') is able to
> >parse, modify and save DEP-3 patches ( note that this command also deal
> >with debian/copyright, debian/control and some other debian files).
>
> Huh? What has dpkg to do with DEP-3?
debian package files, including debian/patches in DEP-3 format.
> And how do I use this parser? I want something as simple as: for a given
> patch, check if the header complies to DEP-3 and if it does, dump it in
> some machine-readable format.
files editor.
I guess that config-edit could be slightly modified to be applied to
individual package files. In check only mode, it should be able to
validate the DEP-3 patches and issues error or warning in case of trouble.
Even if Config::Model does not really qualify as simple, would that
interest you ? ( then we could work out the "dump it in some
machine-readable format" part )
If not, feel free to reuse the parser code [1]
All the best
Dominique
[1] https://metacpan.org/source/DDUMONT/Config-Model-1.265/lib/Config/Model/Backend/Debian/Dpkg/Patch.pm
Jakub Wilk
Jan 18, 2012, 2:20:02 PM1/18/12
to
* Dominique Dumont <domi....@free.fr>, 2012-01-18, 19:37:
>https://metacpan.org/source/DDUMONT/Config-Model-1.265/lib/Config/Model/Backend/Debian/Dpkg/Patch.pm
Judging by a quick look, it doesn't support dpatch patches[0] or
pseudo-headers[0][1].
[0] Don't ask what are these "features" good for. But they are in the
specification.
[1] Also don't ask me how to unambiguously tell where the pseudo-header
starts.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012011819...@jwilk.net
>https://metacpan.org/source/DDUMONT/Config-Model-1.265/lib/Config/Model/Backend/Debian/Dpkg/Patch.pm
Judging by a quick look, it doesn't support dpatch patches[0] or
pseudo-headers[0][1].
[0] Don't ask what are these "features" good for. But they are in the
specification.
[1] Also don't ask me how to unambiguously tell where the pseudo-header
starts.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Fernando Lemos
Jan 18, 2012, 4:10:02 PM1/18/12
to
On Wed, Jan 18, 2012 at 4:37 PM, Dominique Dumont <domi....@free.fr> wrote:
> Le Wednesday 18 January 2012 18:41:44, Jakub Wilk a écrit :
>> And how do I use this parser? I want something as simple as: for a given
>> patch, check if the header complies to DEP-3 and if it does, dump it in
>> some machine-readable format.
>
> Currently, it cannot be used outside of the more general debian package
> files editor.
You can use "dpkg-copyright" instead of "dpkg", though:
> Le Wednesday 18 January 2012 18:41:44, Jakub Wilk a écrit :
>> And how do I use this parser? I want something as simple as: for a given
>> patch, check if the header complies to DEP-3 and if it does, dump it in
>> some machine-readable format.
>
> Currently, it cannot be used outside of the more general debian package
> files editor.
http://search.cpan.org/~ddumont/Config-Model-1.265/lib/Config/Model/models/Debian/Dpkg/Copyright.pod
Regards,
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Charles Plessy
Jan 18, 2012, 8:00:02 PM1/18/12
to
Le Wed, Jan 18, 2012 at 07:13:34PM +0100, Stefano Zacchiroli a écrit :
>
> The above notwithstanding, we can probably learn from this thread that,
> for the future, it would help to first announce "I'm about to mark
> DEP-$x as ACCEPTED" and then doing that. I personally don't think it is
> a big deal, but given that others disagree, ... why not.
Dear Stefano and everybody,
>
> The above notwithstanding, we can probably learn from this thread that,
> for the future, it would help to first announce "I'm about to mark
> DEP-$x as ACCEPTED" and then doing that. I personally don't think it is
> a big deal, but given that others disagree, ... why not.
this is probably the occasion for me to remind that I posted such a message for
DEP 5 last December, and that I have not read disagreements.
http://lists.debian.org/debian-project/2011/12/msg00011.html
While I wrote “in two weeks” at that time, it would have fell on the 24th,
which in retrospect I felt was not appropriate. Now that I have almost resumed
my routine activities, I am ready to keep my promise, probably next week.
I do not intend to push a document on which persons disagree, so please, if you
think that there are serious problems with the current wording DEP 5, or if you
found an important bug in its syntax, report it to the BTS.
More than one year ago, Lars announced on debian-devel-announce “DEP5:
CANDIDATE and ready for use in squeeze+1”. Let's make sure it happens.
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120119005...@merveille.plessy.net
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
Jan 18, 2012, 9:20:01 PM1/18/12
to
Charles Plessy <ple...@debian.org> writes:
> I do not intend to push a document on which persons disagree, so please,
> if you think that there are serious problems with the current wording
> DEP 5, or if you found an important bug in its syntax, report it to the
> BTS.
I reported what I think are problems with the current wording just now to
> I do not intend to push a document on which persons disagree, so please,
> if you think that there are serious problems with the current wording
> DEP 5, or if you found an important bug in its syntax, report it to the
> BTS.
debian-policy, and yes, I believe that should block marking it as
ACCEPTED.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87boq0v...@windlord.stanford.edu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
Jan 19, 2012, 11:40:02 AM1/19/12
to
Le mercredi 18 janvier 2012 à 19:13 +0100, Stefano Zacchiroli a écrit :
> I'm not sure I see the point. DEP was never meant to be a device that
> gives more power to anyone. It was just a device to keep track of a
> discussion that was already happening, document it in some durable form,
> and monitor its status. It's not like that the person with the power of
> marking a DEP as "ACCEPTED" has the power of creating the corresponding
> consensus.
“Dictator” is probably a bad term. See this as a chairman. Someone who
> I'm not sure I see the point. DEP was never meant to be a device that
> gives more power to anyone. It was just a device to keep track of a
> discussion that was already happening, document it in some durable form,
> and monitor its status. It's not like that the person with the power of
> marking a DEP as "ACCEPTED" has the power of creating the corresponding
> consensus.
can judge when consensus has been reached, and mark a DEP as accepted.
This would avoid the countless and boring nitpicks by people who still
want to discuss after the consensus has been reached.
> Consensus should exist by itself, ditto for an implementation, and then
> the corresponding DEP could be marked ACCEPTED.
majority, who will refrain from using a DEP until it is marked as
accepted.
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lars Wirzenius
Jan 19, 2012, 12:30:03 PM1/19/12
to
On Thu, Jan 19, 2012 at 05:36:00PM +0100, Josselin Mouette wrote:
> “Dictator” is probably a bad term. See this as a chairman. Someone who
> can judge when consensus has been reached, and mark a DEP as accepted.
> This would avoid the countless and boring nitpicks by people who still
> want to discuss after the consensus has been reached.
DEP0 calls these people drivers. Their job is to determine when a rough
> “Dictator” is probably a bad term. See this as a chairman. Someone who
> can judge when consensus has been reached, and mark a DEP as accepted.
> This would avoid the countless and boring nitpicks by people who still
> want to discuss after the consensus has been reached.
consensus has been reached.
--
Freedom-based blog/wiki/web hosting: http://www.branchable.com/
Russ Allbery
Jan 19, 2012, 12:40:02 PM1/19/12
to
Lars Wirzenius <l...@liw.fi> writes:
> On Thu, Jan 19, 2012 at 05:36:00PM +0100, Josselin Mouette wrote:
>> “Dictator” is probably a bad term. See this as a chairman. Someone who
>> can judge when consensus has been reached, and mark a DEP as accepted.
>> This would avoid the countless and boring nitpicks by people who still
>> want to discuss after the consensus has been reached.
> DEP0 calls these people drivers. Their job is to determine when a rough
> consensus has been reached.
I think the concern that people have here (and I'm not sure yet whether it
> On Thu, Jan 19, 2012 at 05:36:00PM +0100, Josselin Mouette wrote:
>> “Dictator” is probably a bad term. See this as a chairman. Someone who
>> can judge when consensus has been reached, and mark a DEP as accepted.
>> This would avoid the countless and boring nitpicks by people who still
>> want to discuss after the consensus has been reached.
> DEP0 calls these people drivers. Their job is to determine when a rough
> consensus has been reached.
is enough of a concern to warrant creating more administration) is that
the DEP driver is almost certainly going to have a vested interest in the
DEP reaching consensus (otherwise they wouldn't have volunteered to drive
it in the first place), and therefore isn't a great choice for an
impartial judge of consensus if there's some dispute.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87d3aff...@windlord.stanford.edu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lars Wirzenius
Jan 19, 2012, 3:30:02 PM1/19/12
to
On Thu, Jan 19, 2012 at 09:38:29AM -0800, Russ Allbery wrote:
> Lars Wirzenius <l...@liw.fi> writes:
> > On Thu, Jan 19, 2012 at 05:36:00PM +0100, Josselin Mouette wrote:
>
> >> “Dictator” is probably a bad term. See this as a chairman. Someone who
> >> can judge when consensus has been reached, and mark a DEP as accepted.
> >> This would avoid the countless and boring nitpicks by people who still
> >> want to discuss after the consensus has been reached.
>
> > DEP0 calls these people drivers. Their job is to determine when a rough
> > consensus has been reached.
>
> I think the concern that people have here (and I'm not sure yet whether it
> is enough of a concern to warrant creating more administration) is that
> the DEP driver is almost certainly going to have a vested interest in the
> DEP reaching consensus (otherwise they wouldn't have volunteered to drive
> it in the first place), and therefore isn't a great choice for an
> impartial judge of consensus if there's some dispute.
Other people can also be impartial. We don't need an appointed
> Lars Wirzenius <l...@liw.fi> writes:
> > On Thu, Jan 19, 2012 at 05:36:00PM +0100, Josselin Mouette wrote:
>
> >> “Dictator” is probably a bad term. See this as a chairman. Someone who
> >> can judge when consensus has been reached, and mark a DEP as accepted.
> >> This would avoid the countless and boring nitpicks by people who still
> >> want to discuss after the consensus has been reached.
>
> > DEP0 calls these people drivers. Their job is to determine when a rough
> > consensus has been reached.
>
> I think the concern that people have here (and I'm not sure yet whether it
> is enough of a concern to warrant creating more administration) is that
> the DEP driver is almost certainly going to have a vested interest in the
> DEP reaching consensus (otherwise they wouldn't have volunteered to drive
> it in the first place), and therefore isn't a great choice for an
> impartial judge of consensus if there's some dispute.
impartial judge: if the driver declares a consensus, I'm sure
those who disagree will say so. Furthermore: YAGNI. Let's not
solve problems in the DEP process until and unless we have them,
particularly not by making it more bureaucratic and heavy.
Charles Plessy
Jan 19, 2012, 8:00:02 PM1/19/12
to
Le Thu, Jan 19, 2012 at 09:38:29AM -0800, Russ Allbery a écrit :
>
> I think the concern that people have here (and I'm not sure yet whether it
> is enough of a concern to warrant creating more administration) is that
> the DEP driver is almost certainly going to have a vested interest in the
> DEP reaching consensus (otherwise they wouldn't have volunteered to drive
> it in the first place), and therefore isn't a great choice for an
> impartial judge of consensus if there's some dispute.
Hi Russ,
>
> I think the concern that people have here (and I'm not sure yet whether it
> is enough of a concern to warrant creating more administration) is that
> the DEP driver is almost certainly going to have a vested interest in the
> DEP reaching consensus (otherwise they wouldn't have volunteered to drive
> it in the first place), and therefore isn't a great choice for an
> impartial judge of consensus if there's some dispute.
judging by the current status list DEPs, the problem is more stalling than
accepting them too early. I admit that as DEP admins, we have not done a good
job at pinging DEP drivers. Because of the current confusion of roles on DEP
5, that I push as a driver, I am waiting for its completion before pinging
other DEPs as admin.
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120120005...@merveille.plessy.net
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Charles Plessy
Jan 19, 2012, 8:10:02 PM1/19/12
to
Le Wed, Jan 18, 2012 at 06:13:05PM -0800, Russ Allbery a écrit :
> Charles Plessy <ple...@debian.org> writes:
>
> > I do not intend to push a document on which persons disagree, so please,
> > if you think that there are serious problems with the current wording
> > DEP 5, or if you found an important bug in its syntax, report it to the
> > BTS.
>
> I reported what I think are problems with the current wording just now to
> debian-policy, and yes, I believe that should block marking it as
> ACCEPTED.
Thanks Russ.
> Charles Plessy <ple...@debian.org> writes:
>
> > I do not intend to push a document on which persons disagree, so please,
> > if you think that there are serious problems with the current wording
> > DEP 5, or if you found an important bug in its syntax, report it to the
> > BTS.
>
> I reported what I think are problems with the current wording just now to
> debian-policy, and yes, I believe that should block marking it as
> ACCEPTED.
I found your arguments convincing (in <8739bcv...@windlord.stanford.edu>
sent on debian-project, not -policy). If you do not mind, I will be a bit
formal and forward them to the BTS. Let's make sure to be clear that DEP 5
does not require to document more than the current practice.
Thank you as well for framing clearly the questions to the FTP Masters.
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120120010...@merveille.plessy.net
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lars Wirzenius
Jan 20, 2012, 4:20:01 AM1/20/12
to
On Fri, Jan 20, 2012 at 09:58:11AM +0900, Charles Plessy wrote:
> judging by the current status list DEPs, the problem is more stalling than
> accepting them too early. I admit that as DEP admins, we have not done a good
> job at pinging DEP drivers. Because of the current confusion of roles on DEP
> 5, that I push as a driver, I am waiting for its completion before pinging
> other DEPs as admin.
You're not the DEP5 driver, Steve is; I don't think there's any confusion about
> judging by the current status list DEPs, the problem is more stalling than
> accepting them too early. I admit that as DEP admins, we have not done a good
> job at pinging DEP drivers. Because of the current confusion of roles on DEP
> 5, that I push as a driver, I am waiting for its completion before pinging
> other DEPs as admin.
that. I've effectively stepped down from drivership a year ago, and I'm
happy to make it official if the process is going to drag on a lot longer.
None of that should have any effect on you asking drivers of stalled DEPs
what the status and future of their DEPs is. Or anyone else for that matter.
Charles Plessy
Feb 1, 2012, 10:20:02 AM2/1/12
to
Le Fri, Jan 20, 2012 at 09:12:16AM +0000, Lars Wirzenius a écrit :
>
> You're not the DEP5 driver
Hi Lars and everybody,
>
> You're not the DEP5 driver
I am driving this DEP and re-listed myself at a driver to mark that fact.
To summarise:
- The original idea, from Sam Hocevar, was posted on this list on August 4,
2007.
- A draft was written collaboratively on the wiki until March 2009, in
which I had my share of contributions.
- I do not remember who was the first to suggest to make a DEP out of it, but
please note revision 294: I am the one to propose it in the wiki page.
- The DEP was started in private, motivated in part by Ubuntu's agenda. It
was a terrible mistake for me to accept this, as it resulting in purging
and demotivating most of the original contributors. Nevertheless, I did
a large—or perhaps the largest—share of that work in that phase.
- The DEP continued in public, and the only moment where I gave up driving
this project was when you stepped in. It made tremendous progresses under
your direction; unfortunately you stepped down in the last mile. I dare saying
that I contributed a lot. Among other things did the conversion to DocBook
which has let the DEP enter in the debian-policy package, and made sure that
the DEP's license short names are compatible with SPDX.
- In a further phase, I organised the work through the BTS. Consensus
was reached and the DEP was updated accordingly. I also coordinated
the publication of the DEP on www.debian.org. At the next upload
of the debian-policy package, the DEP will be on line at its canonical
URL: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
- In this final phase, I am making sure that there is no objection anymore to
the release. And I will not let the momentum slip for one more year.
More importantly than the procedural details: I have followed the work
from its beginning, made sure that no contribution was ignored, and that
most questions were answered. To the best of my free time, I made sure
that past discussions were not forgotten and taken into account when
the same questions were asked over and over the years.
This is what I expect from a driver: being the memory of the project, keeping
momentum, and making consensus on the final document. I am driving this DEP.
One can argue forever on this, but please let me suggest that the best way
to close the debate is to finish that work.
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages