On Mon, Oct 13, 2014 at 07:30:43PM +0100, Jonathan Dowland wrote:
> I think we should clearly indicate where GRs should be announced.
> ("Should", I suppose I'm arguing, not "must").
I think we don't need to name the place in the constitution. I don't
think we need a hard rule about where the anno
On Tue, Oct 14, 2014 at 09:17:27AM +0200, Kurt Roeckx wrote:
> If on -vote the required amount of seconds have been reached, I
> will announce that the GR process has been sarted on
> debian-devel-announce.
Sure, and that's excellent. It would, though, in my opinion to be good
to announce the prop
On Sat, May 21, 2016 at 02:07:53PM +0800, Paul Wise wrote:
> On Fri, May 20, 2016 at 1:34 PM, Vincent Bernat wrote:
>
> > Totally agree. Our standards are far too high for many upstreams.
>
> I don't understand the disconnect here. Are upstreams not interested
> in software quality to the extent
On Sat, May 21, 2016 at 10:07:43AM +0200, Martin Steigerwald wrote:
> I wonder about a landing page for upstreams interested in working with the
> Debian project to provide packages within the official Debian repos.
Is https://wiki.debian.org/UpstreamGuide the kind of page you mean? It
is not nec
On Mon, Jul 18, 2016 at 01:47:19PM +0100, Ian Jackson wrote:
> We also need to understand why people use -private when perhaps they
> ought not. One reason is that -private has a better signal to noise
> ratio than -devel or -project, and therefore people pay more attention
> to it.
I'm sorry to
On Thu, Oct 06, 2016 at 10:27:58PM +0200, Frederique wrote:
> What has to be done to get Jitsi pushed through to testing to have it Debian
> 9 stable?
It's not in Debian testing, because of reasons shown at
https://qa.debian.org/excuses.php?package=jitsi, and you should help
the Jitsi packaging te
We've had the "strong package ownership" concept be a problem in
various ways. Many years ago people were afraid of making NMUs to fix
bugs, even RC bugs, and I started the
https://wiki.debian.org/LowThresholdNmu page. It's got over 300
maintainers now, and NMUs are quite normal, though I suspect z
On Mon, Dec 05, 2016 at 08:02:27PM +0100, Laura Arjona Reina wrote:
> I have just created the page:
>
> https://wiki.debian.org/LowThresholdAdoption
>
> and added myself to the list.
I've added myself to the list.
--
I want to build worthwhile things that might last. --joeyh
signature.asc
De
On Tue, Dec 06, 2016 at 03:50:12PM +0100, Johannes Schauer wrote:
> Actually, this is a great argument for why this information should be in a
> deb822 field in the source package itself.
FWIW, I think this is the kind of information that should be kept out
of the source package, since changing it
On Tue, Dec 06, 2016 at 04:15:22PM +0100, Johannes Schauer wrote:
> why would it be important to change that kind of information for a package in
> stable? The audience interested in this field is interested in uploads to
> unstable, so is it not sufficient if the information is up-to-date there?
On Sat, Mar 11, 2017 at 12:50:19AM +0100, Guillem Jover wrote:
> The truth is that even though the constitution grants _some_ powers to
> the DPL, they are in general not used, because IMO the project would
> not see those actions with good eyes.
I'm not sure I agree with that. DPL powers include
On Sat, Mar 11, 2017 at 03:46:41PM +0100, Guillem Jover wrote:
> From the current list of powers in the consitution §5.1.1—§5.1.5 are
> IMO the strongest powers, and they are either very very seldomly used
> or when used they are pretty much a rubber stamp. Whenever a DPL has
> tried to be more pro
The meta issue here is who decides policy for Planet Debian, and how
that is done. This is important for the current case as well: the
controversial blog post is dates March 30, the change to require
suitability for 12-year-olds is from March 31, and the wiki change was
made by the author of the bl
On Thu, Apr 06, 2017 at 01:30:19PM +0200, alberto fuentes wrote:
> It comes down to know if planet is about debian or about debian developers
From https://wiki.debian.org/PlanetDebian:
What Can I Post On Planet?
Planet Debian aims to aggregate the blog posts of people who are
acti
On Sun, Apr 30, 2017 at 09:37:11PM +0200, Daniel Pocock wrote:
> "Non-profit" means that Debian does not distribute surplus profits back
> to people such as shareholders. It does not mean that Debian can not
> make a profit on the sale of a t-shirt, as long as that profit is
> re-invested in the o
On Tue, May 16, 2017 at 03:59:18AM +0530, shirish शिरीष wrote:
> while it was primarily targeted towards Windows machines, maybe we
> could tailor a response which shows how Debian is more secure and
> possibilities of such infections are low/non-existent .
Others have commented (correctly, I thin
On Thu, Dec 07, 2017 at 01:59:16PM +, Holger Levsen wrote:
> On Thu, Dec 07, 2017 at 01:52:07PM +, Ian Jackson wrote:
> > Furthermore, this "file is dangerous" attribute ought to be copied
> > much more.
>
> no, it ought to be the default. all files should be considered harmful,
> unless t
On Wed, 2018-04-18 at 13:41 +0100, Martín Ferrari wrote:
> I believe that a-h is the natural starting point for dealing with these
> issues.
Most of the problems being discussed right now, and in general, seem
to be of the sort where feelings are hurt, but harassment isn't
happening. The situation
On Wed, 2018-04-18 at 15:51 +0100, Ian Jackson wrote:
> Lars Wirzenius writes ("Re: Conflict escalation and discipline"):
> > Most of the problems being discussed right now, and in general, seem
> > to be of the sort where feelings are hurt, but harassment isn't
>
On Wed, 2018-04-18 at 17:17 +0100, Ian Jackson wrote:
> Lars Wirzenius writes ("Re: Conflict escalation and discipline"):
> > "Debian emotional support group", maybe.
>
> I find this suggestion very surprising, possibly even insulting. At
> the very least
I gave a talk[0] at Debconf10 about my experiences switching from
being a Debian developer to being an upstream developer.
As part of that talk I suggested two things:
* a guide or checklist for upstreams so they know how do things so their
software is easier for distributions to package
* a co
On ke, 2010-08-11 at 10:29 +0900, Charles Plessy wrote:
> Do you know about http://wiki.debian.org/GettingPackaged ? It looks like there
> are many overlaps between this page and the one you created…
Thanks, Charles, for pointing that out. That page does, indeed, have
much overlap with my Upstream
The effort to get a machine-readable format for debian/copyright
has been going on for some years now. I think it is time to get it
done. To help with this, I am joining Steve Langasek as a driver
for DEP-5[0].
[0] http://dep.debian.net/deps/dep5/
The story so far, in a very rough summary:
On to, 2010-08-12 at 13:58 +0900, Charles Plessy wrote:
> Stefano, as admin of the DEP Alioth project (I think that the others retired),
> would you agree to create a dedicated mailing list for DEP-5? I volunteer for
> the mailman administration, and for taking the responsibility that no major
> ch
On to, 2010-08-12 at 14:59 +0200, Bernd Zeimetz wrote:
> On 08/12/2010 02:45 PM, Lars Wirzenius wrote:
> > It would be good to have DEP-5 done quite early in the squeeze+1
> > development cycle to give as much time as possible for adoption.
>
> A few comments:
> - Pers
On pe, 2010-08-13 at 09:08 +1000, Craig Small wrote:
> I tried to use it once on one program and just ditched it. It only made
> it more difficult for me and for anyone who read it.
That would indicate there is a bug in the DEP-5 spec. It is, in my very
non-humble opinion, not acceptable for DEP-5
On to, 2010-08-12 at 10:32 -0700, Don Armstrong wrote:
> It would also be nice to take a hard look at the SPDX format,[1] adopt
> any good ideas from it, and try to make sure that the resultant DEP-5
> can be translated into SPDX, and vice versa. [There's no reason for us
> to do all of the hard wo
On to, 2010-08-12 at 17:14 -0700, Russ Allbery wrote:
> As mentioned in the other thread, one goal for DEP-5 for me is to make the
> format sufficiently rich to allow me to use it for the upstream LICENSE
> file. Towards that end, I have three changes I'd like to have.
Thanks, that's an interesti
On pe, 2010-08-13 at 09:57 +0900, Charles Plessy wrote:
> The “paragraph” format that is popular in Debian control files does not allow
> the use of free comments. [- - -]
...
> I propose to use a simpler format, that is trivial to parse:
Having debian/copyright use the same file format as debian/
On to, 2010-08-12 at 22:28 -0700, Russ Allbery wrote:
> Lars Wirzenius writes:
> > On to, 2010-08-12 at 17:14 -0700, Russ Allbery wrote:
>
> >> * An additional section with the same syntax as the Files section but with
> >> no Files field that would be used for do
On pe, 2010-08-13 at 08:00 +, Sune Vuorela wrote:
> On 2010-08-12, Lars Wirzenius wrote:
> > * Various things are easier if debian/copyright can be parsed and
> > interpreted by software, rather than being free-form text. For
> > example, answering questions like &quo
On pe, 2010-08-13 at 08:04 +, Sune Vuorela wrote:
> On 2010-08-13, Lars Wirzenius wrote:
> > On pe, 2010-08-13 at 09:08 +1000, Craig Small wrote:
> >> I tried to use it once on one program and just ditched it. It only made
> >> it more difficult for me and for anyon
On pe, 2010-08-13 at 11:39 -0400, Joey Hess wrote:
> However, there is a big, big problem with DEP-5, and it is named
> /usr/share/doc/chromium-browser/copyright. It is 1.3 mb in size (out of
> a 25 mb package), and completely unreadable and unusable. It appears to
> be machine generated, and is fu
On pe, 2010-08-13 at 09:49 -0700, Russ Allbery wrote:
> My opinion on this is that using # as a comment marker is already a
> diversion from RFC 5322 and I was surprised that dpkg had support for it.
> If we want this to be used outside of Debian, sticking strictly to the
> syntax for RFC 5322 head
On pe, 2010-08-13 at 17:11 -0700, Russ Allbery wrote:
> I would read "approval" in this context as approval by all the people who
> are interested in using something like DEP-5. In other words, consensus
> that, should one want to do this sort of thing, this is the way in which
> we're going to do
One more piece of meta:
We the drivers are now using the wiki page[0] to track outstanding
issues, in the interest of transparency. We'll be updating it as we go
along.
Further, in order to avoid having everything discussed at the same time,
I think it would be good to discuss one or two things a
On la, 2010-08-14 at 11:29 +0900, Charles Plessy wrote:
> Renaming the Format-Specification field:
This seems like a completely noncontroversial suggestion. The only
reason to avoid doing it is to avoid having to fix all the existing
files, but since they need to be fixed for other things anyway,
On pe, 2010-08-13 at 20:43 -0700, Russ Allbery wrote:
> Am I missing some other Debian document somewhere that says we should be
> providing upstream contact information in debian/copyright? I realize
> that lots of people do this, but it's not at all clear to me that it makes
> sense to put that
On la, 2010-08-14 at 14:15 +0900, Charles Plessy wrote:
> Where is this bzr repository
http://bzr.debian.org/dep/dep5/trunk/
I don't know bzr.debian.org provides a web interface. I will, however,
make the latest revision be automatically published so everyone can view
it without having to check o
On la, 2010-08-14 at 10:04 -0700, Russ Allbery wrote:
> Steve Langasek writes:
...
> How about this (written without looking at the detailed wording of the
> document, so may need some massaging to fit into the flow):
FWIW, I like Steve's patch and Russ's addition to it. Anyone object to
them?
On la, 2010-08-14 at 11:18 -0400, gregor herrmann wrote:
> I remember CPAN maintainers (sic!) being interested in the status of
> their modules in Debian.
> Without a Maintainer (or whatever) field in d/copyright (or somewhere
> else but I don't know a better place) we are not able to provide a
> m
On la, 2010-08-14 at 11:54 -0400, Joey Hess wrote:
> Similarly, the Name field is not data that policy requires be in
> debian/copyright. On my latest read of DEP5, I thought this was
> completly redundant with the already redundant source package name in
> the changelog, control file, etc.
There'
On la, 2010-08-14 at 10:16 -0700, Russ Allbery wrote:
> Proliferation of file formats is a bug, not a feature, when you're trying
> to make things readable by software.
Indeed.
> I believe most of these issues are already addressed by referring to the
> syntax description in Policy with the excep
On la, 2010-08-14 at 19:56 +0200, Tollef Fog Heen wrote:
> ]] Lars Wirzenius
>
> | On la, 2010-08-14 at 14:15 +0900, Charles Plessy wrote:
> | > Where is this bzr repository
> |
> | http://bzr.debian.org/dep/dep5/trunk/
> |
> | I don't know bzr.debian.org
On la, 2010-08-14 at 16:58 +0900, Charles Plessy wrote:
> After looking at http://spdx.org/licenses/, I realise that the very
> existence of a license list in DEP-5 is in question (not in this thread).
> However, since I had a version of the DEP with a more comprehensive use
> of web links for lice
On la, 2010-08-14 at 15:05 -0400, Joey Hess wrote:
> Lars Wirzenius wrote:
> > -The `debian/copyright` file must be machine-interpretable, yet
> > -human-readable, while communicating all mandated upstream information,
> > -copyright notices and licensing details.
>
> T
On su, 2010-08-15 at 13:55 +0800, Paul Wise wrote:
> That sounds like a good idea. As long as I would not be alone, I would
> be willing to join such a list and answer questions from our
> upstreams.
That's two of us. Anyone else who'd like to help?
Two is enough to kick this off, though. I'll as
On la, 2010-08-14 at 21:39 -0700, Russ Allbery wrote:
> This raises something else I was thinking about. I believe that technical
> DEPs, if adopted, should move into the debian-policy package for further
> maintenance.
I agree with this, with both my DEP-5 and DEP-0 hats on. (It's cold in
Wellin
On su, 2010-08-15 at 01:32 -0700, Steve Langasek wrote:
> That seems sensible to me. I think it will require some significant
> restructuring of the text, to declare the License and Copyright fields in
> advance of references to them in the discussion of the header stanza, so
> maybe we should pos
On su, 2010-08-15 at 16:01 +0900, Charles Plessy wrote:
> I attached three consecutive patches, that I think reflect our current
> discussion.
>
> - The first one is just a re-iteration of Lars' patch, in
>which I added the title of §5.1, and the version of the current Policy.
Your patch als
On ma, 2010-08-16 at 12:34 +0900, Charles Plessy wrote:
> Give me a break, please.
Let's give everyone a break. DEP-5 has a long, complicated history, and
various people's feelings or egos have been bruised over time. It would
be good to avoid doing any more of that. The current hectic pace isn't
On su, 2010-08-15 at 06:25 +1200, Lars Wirzenius wrote:
> So we have at least three suggestions on the table now:
>
> 1. Rename Maintainer: to Contact:
> 2. Rename Maintainer: to Upstream-Contact: and Name: to Upstream-Name:
> 3. Drop both Maintainer: and Name: completely, even as
There would seem to be at least a rough consensus that DEP-5 should
follow Policy 5.1 on control file syntax. The open question how to
specify that: it is my understanding that most people favor just
referring to the relevant Policy section and not duplicate things in
DEP-5, but since that is also
On su, 2010-08-15 at 12:48 -0700, Russ Allbery wrote:
> Uh, kind of. It's always *possible* to do that, but that can turn into a
> more complex way of expressing which files are involved in an exception
> with overrides. Consider:
>
> Files: *
> License: BSD
>
> Files: extra/* !extra/foo.[ch]
>
On ma, 2010-08-16 at 16:19 +1200, Lars Wirzenius wrote:
> * a 24-hour moratorium on posting about DEP-5 at all
That went well. Thank you everyone for giving space to breathe.
> * after that is over, not discussing every possible topic at once, just
> a couple at a time
I've co
On ti, 2010-08-17 at 18:24 -0700, Russ Allbery wrote:
> Those exchanges aren't the actual license or copyright information, which
> can still be stated in a structured form. They're usually just defenses
> of why thet claimed license information is what it is (when it may, for
> example, contradic
On to, 2010-08-19 at 10:31 +0900, Charles Plessy wrote:
> my presonal point of view about fields in this DEP is that they should be
> required only if they are strictly necessary, and mentionned as optional only
> if there is a reasonable plan to parse and exploit the data.
>
> I am not aware of
On to, 2010-08-19 at 06:56 +0200, gregor herrmann wrote:
> A structured field makes it easier to parse; but as I said earlier, if
> we decide to keep (and at some point use) them we still can do so, if
> additional fields are allowed.
There was a little bit of discussion on #debian-perl about this
On pe, 2010-08-20 at 14:55 +0200, Stefano Zacchiroli wrote:
> Now, I've no idea if the above would be appropriate for the upstream
> front desk or not. I leave it up to you to decide whether it's worth
> trying or not.
I think a debian-upstre...@lists.debian.org mailing list, open to
everyone and
On pe, 2010-08-20 at 16:52 -0700, Steve Langasek wrote:
> The fact that we're both expressing this in terms of "preference" means, I
> think, both that this doesn't meet Lars's "wave of opposition" standard and
> that we're not definitely in bikeshed territory. :) I support Lars in
> deciding this
On pe, 2010-08-20 at 17:05 -0700, Russ Allbery wrote:
> I think a better approach would be to, once the document has settled down,
> publish it with a version number and give that version of the document a
> permanent URL. So, for instance, we would publish DEP-5 1.0 and give it a
> URL something
On la, 2010-08-21 at 20:32 +1200, Lars Wirzenius wrote:
> I'm OK with saying that multiline fields should use the Description
> markup, especially noting Charles's point about only using the long
> description part, when appropriate. This simplifies things quite a lot.
> I&#x
On la, 2010-08-21 at 01:58 -0700, Russ Allbery wrote:
> > How would that tie in with updating it via the normal policy process? I
> > thought we'd keep the file in the debian-policy package for future
> > updates.
>
> I was assuming that's how we'd get to a 1.1 version. I haven't read DEP-0
> rec
On la, 2010-08-21 at 02:15 -0700, Russ Allbery wrote:
> What happens when the copyright statement is longer than a line? I have a
> bunch of those, such as:
Good point. I see at least thw following possible solutions:
* Keep one line per copyright statement, but make the lines be long.
(This is
On la, 2010-08-21 at 15:47 +0300, George Danchev wrote:
> I just wonder what this list would be meant to serves which can't be deemed
> suitable for -mentors. Many upstreams (regardless they have any preliminary
> packages of their software or not) already use -mentors for entering Debian
> one
On la, 2010-08-21 at 08:32 -0400, Stephen Leake wrote:
> Lars Wirzenius writes:
>
> > Files has a list
> > of values (currently comma-separated, but I propose to make it
> > white-space separated),
>
> File names can have spaces. Not common, but possible. I gues
On su, 2010-08-22 at 08:00 +1000, Ben Finney wrote:
> Could we take advantage of the natural “©” marker to indicate each
> copyright statement?
That's an interesting idea, but would people in general find it easy or
difficult to write that character? (I'd have to copy-paste it, for
instance, since
On la, 2010-08-21 at 16:41 -0700, Russ Allbery wrote:
> Ideally, I'd like to just copy and paste upstream's copyright statements
> into debian/copyright and maybe do some compaction, which leads me to
> prefer a free-form field. Do we think that people are going to want to
> parse and extract indi
On la, 2010-08-21 at 22:30 -0700, Manoj Srivastava wrote:
> Can't we just "fold" long copyright header fields similarly?
The issue is that one Copyright field (or header) will contain many
copyright statements, and if we want to automatically parse those, we
need a way to see where a new o
On su, 2010-08-22 at 16:12 +0900, Charles Plessy wrote:
> I also feel a contradiction to call ‘free-form’ some text that is formatted
> according to some markup rules, even if they are simple. I propose to replace
> instances like:
>
> Free-form text formatted like package long descriptions
>
>
I've attached the current diff for the general file syntax changes.
=== modified file 'dep5.mdwn'
--- dep5.mdwn 2010-08-21 09:05:12 +
+++ dep5.mdwn 2010-08-22 22:08:51 +
@@ -76,7 +76,7 @@
* Single-line values.
* White space separated lists.
* Line based lists.
-* Free-form text formatted
e: 2010-08-23
Drivers: Steve Langasek ,
Lars Wirzenius
URL: http://dep.debian.net/deps/dep5
@@ -70,6 +70,36 @@
<http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-controlsyntax>
for details.
+There are four kinds values for fields. Each field specifies which
+kind is all
On su, 2010-08-22 at 23:36 -0300, Valessio S Brito wrote:
> The proposal is to have something similar to http://webchat.freenode.net/
>
> Using cgiirc on webchat.debian.org or irc.debian.org or .net
The one place I know that advertises a web IRC gateway is the Koha
project (http://koha-community.
On ma, 2010-08-23 at 14:50 +1200, Lars Wirzenius wrote:
> On su, 2010-08-22 at 15:24 -0700, Russ Allbery wrote:
> > It's... okay. It's a little strange, but I don't think it would be
> > confusing since it is a summary of the license text in a machine-readable
&g
The Files field needs to specify patterns on filenames. We need to
specify how to do that.
The spec draft currently has this text (plus some examples):
### Files
Format
The **`Files`** field contains a list of comma-separated patterns
Files: f
The Comment field has been suggested for DEP-5.
There is a pretty clear consensus that we want it. Thus, I propose this
to be added to the section explaining fields in the header (the
paragraph with Format etc):
* **`Comment`**
* Optional
* Single occurrence per par
On ke, 2010-08-25 at 14:07 -0700, Russ Allbery wrote:
> Looks fine to me, although as a very minor point I'd replace Debian
> ftpmaster team with upstream, since that's the more typical case.
Fair enough. Done.
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject o
On to, 2010-08-26 at 09:21 +0900, Charles Plessy wrote:
> Common comments come on.
Heh.
> - Will paragraphs that contain only a Comment field be valid ?
Each paragraph is either a header (Format required), file license
specification (Files required), or stand-alone license description
(License
On to, 2010-08-26 at 08:39 +0900, Charles Plessy wrote:
> Adding an exclusion syntax with ‘!’ has some use, but it would be to the
> expense of being able to paste the field's value, and between the two I prefer
> being able to paste.
I, on the other hand, would prefer to have exclusion syntax, to
On to, 2010-08-26 at 17:31 +0200, gregor herrmann wrote:
> On Thu, 26 Aug 2010 17:19:21 +0200, Jonas Smedegaard wrote:
> > I discovered at some point that all entries need a trailing ./ -
> > e.g. debian/control is not valid - it needs to be expressed
> > ./debian/control
>
> Oops, that means that
On to, 2010-08-26 at 08:57 +1200, Lars Wirzenius wrote:
> Comments on Comment?
>From the absence of further comments I assume there is consensus. If
I've overlooked anything, please tell me. Attached is the diff of the
changes I'm merging into the master draft.
=== modified
On to, 2010-08-26 at 08:43 +1200, Lars Wirzenius wrote:
> The Files field needs to specify patterns on filenames. We need to
> specify how to do that.
Here is my understanding of the current situation:
* There is no particular consensus on filename patterns.
* Charles suggests a very
I have just committed the change below to disallow alternative syntaxes
for DEP-5, since having, say, YAML in addition to RFC-822 style headers
is silly. I did not discuss this beforehand since I do not expect anyone
objecting to it at this stage of the DEP. It might have been relevant
early on in
Given the large number of people who have worked on DEP-5 over the
years, a section acknowledging their work would be a good idea, I think.
Below is a start of one. Could someone who's been involved with this
longer than I have make a list of missing people?
=== modified file 'dep5.mdwn'
--- dep5.
On ke, 2010-09-01 at 19:27 +0300, Andrei Popescu wrote:
> Unless you consider it's necessary to be a DD for this I could join as
> well. After all, I spend *a lot* of time reading Debian mailing lists
> and I have become familiar with a lot of processes. It's time I put this
> to some good use :
On ti, 2010-08-31 at 11:10 +0200, Bernd Zeimetz wrote:
> + Larz Wirzenius
>
> Don't forgot yourself! :)
Done. If anyone remembers anyone else who should be added, please tell
me, and I'll add them.
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscri
On la, 2010-08-28 at 19:51 +1200, Lars Wirzenius wrote:
> To make this go forward, I suggest that we adopt Charles's suggestion of
> very simple globbing, since that's going to be compatible with more
> powerful syntaxes if we want to adopt those later. Further, I suggest we
&g
8 +
+++ dep5.mdwn 2010-09-07 05:46:26 +
@@ -1,20 +1,20 @@
[[!meta title="DEP-5: Machine-readable debian/copyright"]]
- Title: Machine-readable debian/copyright
- DEP: 5
- State: DRAFT
- Date: 2010-08-23
- Drivers: Steve Langasek ,
- Lars Wirzenius
- URL: http://dep.debian.
On ti, 2010-09-07 at 13:28 +0200, Jonas Smedegaard wrote:
> Do anyone else feel that I should be mentioned?
I do. Added.
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian
On ti, 2010-09-07 at 06:24 +0100, Lars Wirzenius wrote:
> Nobody has commented on this in any way, so I assume I am still perfect
> and everything I say is flawless. I am attaching a proposed patch to
> rewrite the filename pattern section. Unless there are objections within
> a coupl
The current DEP5 draft says:
* **`Files`**
* Required for all but the first paragraph.
If omitted from the first paragraph,
this is equivalent to a value of '*'.
* Syntax: white space separated list
* List of patterns indicating files covered by the license
and copyright s
The current DEP5 draft has this paragraph:
For a ''non-free'' package to be autobuilt, `debian/copyright` must
contain an
explanation that autobuilding is not forbidden (see
[20061129152824.gt2...@mails.so.argh.org](http://lists.debian.org/msgid-search/2
006112915
>From the DEP5 wiki page:
Dev-ref §6.7.8.2 recommends that if you have to repackage the original
source, that the transformations that are performed be recorded in
debian/copyright. While there was recently some discussion on d-devel
about whether repackaging just to remove distributable-but-not-d
On ma, 2010-09-13 at 23:22 +0900, Charles Plessy wrote:
> Le Mon, Sep 13, 2010 at 02:47:13PM +0100, Lars Wirzenius a écrit :
> >
> > That took more than a couple of days, but I've now merged the changes
> > and pushed them out to the bzr trunk.
>
> Hi Lars, and
On ma, 2010-09-13 at 16:58 +0200, Jonas Smedegaard wrote:
> It makes good sense to me that we (continue to) track stripped files at
> the same place as distributed files.
On the other hand, I don't see the point of using debian/copyright to
document copyright information of files that are not par
On ma, 2010-09-13 at 09:06 -0700, Manoj Srivastava wrote:
> Currently, one only needs to list the copyrights in the package,
> without specifying which file each copyright applies to. How is that
> specified in DEP5 format? Implying that all copyright notices apply to
> all files would
On ma, 2010-09-13 at 14:54 -0700, Russ Allbery wrote:
> There should still be an explanation in debian/copyright of what that
> script does, since that's the Policy-required location for specifying
> where the upstream source came from.
Oh, I thought only devref was requiring that to be in debian/
On ti, 2010-09-14 at 00:07 +0100, Stuart Prescott wrote:
> Personally, I'd like a nice machine-readable list of files/dirs/globs that
> should be removed from the tarball. I'd like it to be kept in a canonical
> location in the source tarball (debian/copyright, perhaps?)
This all sounds good, with
On ti, 2010-09-14 at 17:35 -0700, Russ Allbery wrote:
> Jonas Smedegaard writes:
>
> > Makes sense to me.
>
> > Let's define only a single free-form field in the header section now.
>
> > I suggest it then be a field specifically for notes regarding source not
> > being "pristine" in the sense
On ke, 2010-09-15 at 10:22 +0200, Joerg Jaspert wrote:
> I, using my FTPMaster hat, do care a lot that we do not get
> $whateveritsname with upload rights that never ever had to show at least
> the basic understanding of packaging work. Looking at all the errors
> existing Developers do, even longs
1 - 100 of 300 matches
Mail list logo
