Re: The proper place to announce GRs (was Re: piece of mind (Re: Moderated posts?))

[Lars Wirzenius]

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 announcement happens.

I do, however, think it would be good to announce all proposed GRs on
debian-devel-announce and debian-vote, with Reply-To to debian-vote.
This would ensure all DDs hear about every proposed GR. There's not
enough of them to cause a lot of d-d-a traffic. If the proposer of a
GR forgets to do that, the secretary or some other DD could do it for
them.

-- 
http://gtdfh.branchable.com/ -- GTD for hackers
http://obnam.org/ -- HAVE YOU BACKED UP TODAY?


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141013193235.gf21...@exolobe1.liw.fi

Re: The proper place to announce GRs (was Re: piece of mind (Re: Moderated posts?))

[Lars Wirzenius]

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 proposed GRs even before the required number of
seconds is reached, to make it easier for those interested in the
topic to hear about them. That should, of course, be done by those
proposing the GR, and debian-devel-announce is, I think, already an
acceptable place for them.

-- 
http://gtdfh.branchable.com/ -- GTD for hackers
http://obnam.org/ -- HAVE YOU BACKED UP TODAY?


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141014075419.gg21...@exolobe1.liw.fi

Re: third-party packages adding apt sources

[Lars Wirzenius]

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 we are?

I don't think it's that upstreams aren't interested in quality, but
that Debian and (some) upstreams have different opinions on what
aspects of quality are more important.

* Debian: don't embed copies of libraries you use. It makes it harder
  to do security updates in the libraries, makes it harder to use the
  libraries on their own, and makes the Debian package archive
  unnecessarily larger.

  Some upstreams: we embed copies of libraries. It makes it easier to
  install our software, and guarantees us that the library doesn't
  change from underneath us, and that means we don't need to support
  many versions of the library. We're an active project, and if a
  library needs a security update, we do it quickly.

* Debian: it's important to follow Debian Policy and the Debian
  workflow of uploading to unstable and letting packages flow from
  there to testing and stable, if they don't have bad bugs. There's
  thousands of people making packages and things will break if they
  all do the same thing differently.

  Some upstreams: it's OK to cut some corners and do things simply. We
  care about getting the software into the hands of its users as soon
  as possible, and we also don't have a lot of time to spend on
  packaging. From our point of view, packaging is a necessary evil
  that is much too difficult and takes much too much time from us.
  That's effort we could spend on making the software better instead.

* Debian: it's important to have package versions that can be
  supported for many years. We produce a release every two years, and
  support it for at least three, and more if one counts the LTS
  project. Software that changes a lot, or that has an API that
  changes a lot, or that doesn't separate security updates and
  backport those to the version included in a Debian release, make
  this harder for us. We can't generally update to a new upstream
  release whenever there is a security problem, as it would negate the
  point of making Debian releases. For example, the new upstream
  version might require entirely new forests of dependencies, or newer
  versions of dependencies, all the way down to the kernel. For some
  packages that we deem sufficiently important to our users, we deal
  with that, but it is not something that generalises to all packages.

  Some upstreams: we don't support our old releases. We have only so
  much time to spend on this software, and supporting old releases
  would take a lot of effort we don't have time for. That's why we
  embed most of our dependencies into the installation packages we
  make, so that they can be installed onto the Debian releases, even
  if we decide to require more dependencies, or newer versions of
  them.

Et cetera. Debian has one set of quality factors it particularly cares
about, and some upstreams think differently.

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh


signature.asc
Description: PGP signature

Re: third-party packages adding apt sources

[Lars Wirzenius]

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 necessarily well known.

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh


signature.asc
Description: PGP signature

Re: Publicly-readable list for only DDs and DMs to post to

[Lars Wirzenius]

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 be so negative, but I'm afraid I have to say that I
object to the suggestion of creating a members-only mailing list. It
creates another barrier to participation in Debian at a time when we
should be tearing them down.

The solution to low signal to noise ratios on our "big" lists (-devel,
-project, -vote) can't be creating more and more lists. We should
improve the ratio instead by using working techniques. Let's not
forget that it isn't always non-members who bring down the ratio.

Years ago, Ubuntu split their development mailing list into an open
list and one where posting was allowed for Ubuntu members only. I
don't know if that's still the case, but in about 2007-2009 it didn't
seem to me that it worked very well.

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh


signature.asc
Description: PGP signature

Re: Urgent call to get Jitsi in Debian 9

[Lars Wirzenius]

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 team fix those reasons.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Replace the TC power to depose maintainers [and 1 more messages]

[Lars Wirzenius]

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 zack's
NMU campaigning helped more.

I suggest a lighter approach than a GR for eroding the strong package
ownership further is to start another page, "LowThresholdHijack" or
something, listing maintainers who are OK if someone hijacks their
package if the maintainer isn't taking good care of it. Would anyone
else than I put themselves on that new page? (If you would, start the
page on the wiki and announce it on this thread, and I'll add myself.)

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Replace the TC power to depose maintainers [and 1 more messages]

[Lars Wirzenius]

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
Description: PGP signature

Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers)

[Lars Wirzenius]

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 would require an upload and
that's not going to happen for stable. I'd prefer such information be
kept somewhere it's easy to change.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers)

[Lars Wirzenius]

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?

For example, there's corner cases that get tricky. A package might
only be in stable, but the maintainer wants to declare it as
LowThresholdAdoptable. That would require an upload to unstable only
to change that bit of metadata. Or Debian might be in a freeze, and
uploading a new package version would be frowned upon.

It's a lot simpler to keep this metadata outside source package.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Let's make Debian DPLess!?

[Lars Wirzenius]

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 delegation and
deciding how to spend project money. I'd say it's pretty
uncontroversial that we want those things to happen. What powers
specifically do you see that the project would prefer the DPL not use?

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Let's make Debian DPLess!?

[Lars Wirzenius]

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 proactive the project has been mired in controversy.

I disagree on this. It's true we rarely have trouble with regards to,
say, delegations, but it's taken a whole lot of effort to get here. In
my opinion, it's a good thing to have someone whose responsibility it
is to sort things out in case we ever do have have trouble again. Thus
I think it'd be a mistake to get rid of the position we have with that
responsibility.

> Every and each year we have these pharaonic platforms where the
> candidates present all those grandiose pyramid plans. Those never happen.
> But I guess it's more interesting than writting a platform that states:
> 
>   * Will rubber-stamp delegations.
>   * Will be an ambassador for the project.
>   * Will be a minister of finances for minutia.

If grandiose platforms are a problem, by all means fix that. As it
happens, I think I agree (assuming I understand what you mean). Which
is why I wrote a "not platform" along non-grandiose lines some time
ago.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Inappropriate content on planet.debian.org and need of evolution of documentation and CoC

[Lars Wirzenius]

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 blog post. I'm not aware of any public
discussion of the change, before the change happened, but perhaps I've
just found it.

I admit I have a hard time trusting a policy defined in a wiki page
that anyone can change.

It seems quite weird to me to apply the DebConf Code of Conduct to
Planet Debian. I don't who said what to whom, when, or how, to make
that be the conclusion. It would be good, I think, to have policy
discssions on public mailing lists.

I don't currently have a comment on the suitability for Planet Debian
of the post in question. Russ raises excellent points.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Inappropriate content on planet.debian.org and need of evolution of documentation and CoC

[Lars Wirzenius]

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
 active in Debian and not only to aggregate the blog posts about
 Debian. The point is to provide a window into the community
 itself. Posts that are about Debian are a great idea and some
 people will choose to only syndicate "on topic" posts. But other
 posts are also welcome! We want to learn about the people, their
 life, opinions (even political) and doings.

In short, it's about Debian contributors, not just Debian. Based on my
memory, it has always been that way.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: producing, distributing, storing Debian t-shirts

[Lars Wirzenius]

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 organization.

This will be highly dependent on the local laws for whatever trusted
organisation the proxies it for Debian.

On the other hand, I at least would prefer if Debian didn't put in
money to have a stock of merchandise. Merchandise seems to happen
anyway.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: should debian comment about the recent 'ransomware' malware.

[Lars Wirzenius]

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 think) that making security claims
like that is not factually correct.

My take on this is that verbally attacking ("flaming") other systems
is bad form and we should avoid that. Gloating over problems in
Windows counts as verbally attacking them. It makes us look like
poopheads and doesn't have any benefits for us. Let's not.

Tearing down others doesn't make Debian better. Let's stick to being
positive and constructive and to making Debian better together.

We, the Debian project, don't need to make a statement on Wcry at all.
If we were to do so, it should be something that helps victims, or
those in danger of becoming victims, of this non-verbal attack. Maybe
something along the lines of keeping one's systems up to date with
security updates, and having good, secure backups that an attacker
can't destroy. But that advice is already being given by numerous
others so I'm sure it's worth Debian doing it too, if for no other
reason that very few Windows users pay any attention to Debian.

(I wrote an article on Linux advocacy 20 years ago. Things haven't
changed radically since. http://liw.fi/advocating-linux/)

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Automatic downloading of non-free software by stuff in main

[Lars Wirzenius]

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 tagged otherwise.

All files _should_ be considered potentially harmful. Even if tagged
safe. A previously-safe file might become harmful because it happens
to trigger a newly found security bug. Possibly a newly found security
bug that did not exist when the file was tagged safe.

In my opinion, tagging files safe or harmful is not a winning
strategy. I don't think it gives enough benefit to be worth it, and it
doesn't seem to me it actually protects our users very much. An xattrs
tag, in particular, gets lost so very easily, and having it applied
inconsistently means there's a lot of ways in which any protection
based on such a tag gets accidentally or intentionally circumvented.
If we have a "this is safe" tag, instead of "this may be harmful",
then that's also going to get lost often, leading to users getting
annoyed by unintended security warnings all the time.

Obviously it's possible to handle this by treating it as a by every
time a file is copied without its xattr flag. But even from limited
experience, that's going to be a very large number of bugs. If my
security depends on all programs individually doing all the right
things, I won't be feeling very secure.

I don't have a good solution, but I suspect something like QubesOS may
be the way forward. In other worse, isolate all processes into
containers (or virtual machines) of some sort and arrange it so that
this doesn't become too cumbersome to the user. (Disclaimer: I haven't
had time to actually try QubesOS myself, yet.)

The advantage of that approach is that the security gets centralised
into fewer system components. It's less important that, say, Firefox
is secure, if it can't be exploited to do bad things, if the container
stops Firefox from deleting or modifying local files, or making
unexpected network connections, or using too much RAM or CPU or other
local resources. (I'm describing an ideal here, not the state of
current technology.)

-- 
I want to build worthwhile things that might last. --joeyh

Re: Conflict escalation and discipline

[Lars Wirzenius]

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 situations seem to be "A did something, and B was
offended, how do we get A and B to understand each other, and resolve
any conflict, and get A and B to collaborate in the future?".

This implies to me that, at the least, "anti-harassment" is the wrong
name for a team that deals with this.


signature.asc
Description: This is a digitally signed message part

Re: Conflict escalation and discipline

[Lars Wirzenius]

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
> > happening. The situations seem to be "A did something, and B was
> > offended, how do we get A and B to understand each other, and resolve
> > any conflict, and get A and B to collaborate in the future?".
> > 
> > This implies to me that, at the least, "anti-harassment" is the wrong
> > name for a team that deals with this.
> 
> That's certainly true.  I thought of these ideas:

"Debian emotional support group", maybe.

But maybe wait with the naming until there's a clear description of
what the group is reponsible for.


signature.asc
Description: This is a digitally signed message part

Re: Conflict escalation and discipline

[Lars Wirzenius]

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 need to be much clearer.

Insulting? *sigh*

> This group would:
> 
>  * Receive reports of bad behaviour on the part of Debian
>contributors, in whatever forum or venue including in person.

You're seem to be talking about something entirely different than what I had in 
mind. You're also proposing something that I find patronising
and sorely lacking in oversight.
> 

signature.asc
Description: This is a digitally signed message part

Upstream guide and front desk

[Lars Wirzenius]

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 contact point within Debian for upstreams to use

For the first thing, I have started a wiki page[1], and seeded it with
points from my talk. I hereby declare it to be the ultimate truth,
absolutely correct, and forever final. (That should be challenge enough
to get people to update it with new ideas, and fixes.)

For the second thing, I propose an "upstream front desk" of some sort.
Stefano, in his role as the DPL, agreed that it would be good. The UFD
would be the point of first contact for new upstreams, and would guide
them to the right people in Debian to help them with the packaging of
the upstream software. They could also help upstreams later, if there
are problems in their relationship with Debian, e.g., the volunteer Debian
package maintainer goes missing.

I am not sure what the best way to implement the UFD would be. Perhaps
a mailing list (debian-upstream?) with a few volunteers would be a good 
start? If this gets created, I'll join. Anyone else like to help with 
that?

[0] http://liw.fi/swimming-upstream/
[1] http://wiki.debian.org/UpstreamGuide


-- 
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.org/1281489432.2264.10.ca...@havelock

Re: Upstream guide and front desk

[Lars Wirzenius]

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 UpstreamGuide page. They should be merged -- and
since UpstreamGuide is newer, it should be merged into GettingPackaged.
Maintenance and improvement of the page, and making sure all relevant
parties know about it, would be another task of the upstream front desk,
I think.



-- 
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.org/1281490749.2264.13.ca...@havelock

DEP-5 meta: New co-driver; current issues

[Lars Wirzenius]

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:

* 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 "what stuff is GPLv2 only,
  and therefore incompatible with GPLv3?".
* Started on the wiki in 2007, just over three years ago. Now
  using the DEP process. Many people have participated in the
  discussions.
* Quite a number of packages already use some variant of the DEP-5
  format. There's no goal to make using it mandatory, however.
  (Compare with debhelper: almost all packages use it, but it's
  entirely optional.)
* Most of the spec seems reasonably stable, some details need to be
  fixed.
  
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.

The current outstanding issues I am aware of:

* a "Comment" field would be good
* license shortnames/keywords: the set of keywords probably needs work,
  and hopefully can be compatible with what other projects use; the
  current thread on the meaning of "public domain" is part of this
* file globbing syntax
* clarify the text so it's clear DEP-5 won't require more precision
  than is currently needed

If there's more issues, please raise them. I will be be starting
separate threads on the above topics later (in other words, please
don't discuss these topics in this thread, only the meta stuff).

My role as driver is not to make decisions, but to guide the 
discussions, and update the DEP-5 document based on the consensus
of the discussions. In a bikeshedding situation, however, I will use
editorial control and pick a winner in order to guide the
discussion to more productive topics. (In other words, the more
you bikeshed, to more power I get.)

I am aiming for the following workflow:

* We discuss, on debian-project, whatever issues need discussing.
* I and Steve update the DEP-5 draft, and post a diff.
* If there is something else to discuss on that topic, we do that,
  otherwise we move on to the next one.

It was just suggested we move the DEP-5 discussions off debian-project.
I think that would be a mistake. This is something that affects the
project as a whole, and should therefore be easy for the whole project
to follow, now and in the future via the list archives. If we keep 
"DEP-5" in the subject, it'll be easy to filter away for those 
uninterested. If we build DEP-5 outside the normal project structures,
we'll just have to re-discuss it when it's time to approve it, so it's
better to have the discussion just once.

Uh, this e-mail became longer than intended. Thanks for reading this
far. Let's get this thing done and out and finished and over with.


-- 
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.org/1281617130.2264.35.ca...@havelock

Re: Moving discussions about DEP-5 details to another list. (Was Re: DEP-5 and public domain)

[Lars Wirzenius]

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
> changes are discussed there instead of on debian-project.
> 
> Alternatively, we could use an existing list, for instance debian-legal.

I'm un-retiring, and also becoming a co-driver for DEP-5, in order to
get it finished reasonably soon. See the "meta" e-mail I just sent out
to -project.

For what it's worth, I am opposed to a DEP-5 specific mailing list. See
my other e-mail for reasons.



-- 
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.org/1281617469.2264.38.ca...@havelock

Re: DEP-5 meta: New co-driver; current issues

[Lars Wirzenius]

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:
> - Personally I find the format unnecessarily complicated and much more 
> annoying
> to use than writing a normal debian/copyright file, especially for complicated
> cases.

You're not required to use it. If you want to improve the format, please
make concrete proposals, or at least explain why it is complicated and
annoying. (If you've already done so, a URL will be sufficient. I do
not, unfortunately, have the time to re-read three years worth of old
discussions about this.)

> - Migrating all packages to the new format is an insane task which would take 
> a
> *long* time and a lot of work.

There is no goal to migrate all packages. That's a strawman.

> - Instead of writing such files (and keeping them updated), we should put more
> energy into doing this task automatically.

It is obviously true that it would be good to make all of this reliably
automated. However, even when that is done, it's useful to have things
in one place in a Debian package, i.e. debian/copyright, and it'll still
be useful for that place to be machine parseable.

More importantly, making debian/copyright be machine parseable provides
some immediate benefits, without having to wait for a solution to the
big, difficult problem.



-- 
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.org/1281619632.2264.65.ca...@havelock

Re: DEP-5 meta: New co-driver; current issues

[Lars Wirzenius]

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 to make it harder to
maintain debian/copyright in DEP-5 format than as a free-form one,
except for minimal markup. It seems that the process so far has created
an impression that a DEP-5 file should be incredibly specific and
detailed, and we'll have to fix that.

> You really need to stop and think what is this for?  What information is
> important to have and what can be found in the source files later if 
> someone really cares.

The answer (obviously to me, but not so obviously to others) is that it
should have the same information as a free-form copyright file, at the
same precision as the free-form file would have, while allowing more
precision for those who want provide it.

> My suggestions:
>   * Split out the authors and the copyright dates into one chunk.  The
> fact that fileA is copyright 2005 Joe and fileB is copyright 2006
> Fred and then fileC is copyright 2006 both of this is completely 
> irrelevant for most people, just that Joe and Fred have copyright 
> of some parts of the package is enough.

Files: *
Copyright: 2005-2006, Joe
   2006, Fred

But I'll bring this up later in a separate thread, since there is a
detail that may need discussing.

>   * Make it possible to say "this package is licensed under foo 
> except fileA which is licensed under bar"

Files: *
License: foo

Files: fileA
License: bar

> > More importantly, making debian/copyright be machine parseable provides
> > some immediate benefits, without having to wait for a solution to the
> > big, difficult problem.
> What are these benefits?

>From me initial mail in this thread: 'For example, answering questions
like "what stuff is GPLv2 only, and therefore incompatible with
GPLv3?".' (With 'stuff' being 'package', and not 'file'.)


-- 
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.org/1281658184.2264.115.ca...@havelock

Re: DEP-5 meta: New co-driver; current issues

[Lars Wirzenius]

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 work of copyright and license auditing and
> verification when we can colaborate with the work of others.]

I've had a look at one version of the SPDX draft, and I agree that it's
good to ensure convertability. SPDX has different goals from
debian/copyright, and seems to be even more verbose than DEP-5 (they
have no globbing, each file is listed separately), so using the exact
same format probably isn't sensible. But convertability from one format
to the other would be nice, and should not be excessively hard, either.


-- 
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.org/1281672312.2264.134.ca...@havelock

Re: DEP-5: additional requirements to use with upstream

[Lars Wirzenius]

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 interesting use case for the file format, and I'm glad
you brought it up.

> * An additional section with the same syntax as the Files section but with
>   no Files field that would be used for documenting the copyright of the
>   distribution as a whole.  (In US law, this is called a compilation
>   copyright.)  This is not the same thing as a Files: * section, which
>   would specify a default copyright and license for any individual file
>   that doesn't have other information.  In some edge cases, the
>   compilation copyright and license can be different than the copyright
>   and license of any individual file in the distribution.

I am uncomfortable signalling compilation copyright just with the
absence of a Files: field. It seems to error prone to me. It would be
better to be explicit, I think. What would be a good way of being
explicit in this case?

> * A comment field in the header section into which I can put statements
>   like:
> 
> All individual files with no other license statement are released
> under this license.  Some files have additional copyright dates from
> earlier releases or may be owned by other copyright holders as noted
> in those files.  Some files are individually released under different
> licenses, all of which are compatible with the above general package
> license.

Would a generic multi-line Comment: field be sufficient?

> * An origin field in the files section where I can note the origin of that
>   set of files.  For example, my packages contain some files copied from
>   GNU Libtool, and I currently say that in the LICENSE file.  I don't want
>   to lose that information.  This use case could be served by just
>   allowing a comment field in the files section, I suppose, and that may
>   be a better approach since it's more general.

Perhaps it'd be sufficient to stick to a generic Comment: field for now,
until there's some experience to see what other new fields are useful in
the real world. This would be my personal preference.

If others think an Origin: field would be good to have, I'll add it, my
job as DEP driver is to record consensus. Can you suggest a wording?
What do others think? Anyone for or against and Origin: field?


-- 
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.org/1281676915.2264.154.ca...@havelock

Re: DEP-5 meta: New co-driver; current issues

[Lars Wirzenius]

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/control would
seem to me to be a plus. People are already used to writing in that
format, and there are parser implementations for the format, so it's a
very convenient one to use. The format even allows using '#' for
comments. Therefore it is my personal opinion that we should stick to
this.

However, as DEP-5 driver, I will record any consensus that emerges. If
there is wide support for Charles's new format, I'll modify DEP-5 to use
that. So if you support it, please speak up now. (Until and unless a
consensus in favor of the new syntax is clear, I will assume the
consensus is for the syntax in the current revision of the
specification.)

> On the other hand, it was noted by Don yesterday and by Steve in December that
> other projects, in particular Fedora, also use short names. I think that it
> important that we converge on a common set. I proposed in December to contact
> Fedora, but did not get positive answers on debian-project. I volunteer again
> to contact Fedora and the Linux Foundation as a DEP driver, to propose them
> to use a common set.

The SPDX people are collaboration with other projects, including Fedora,
on this right now. Steve and I discussed it and he'll join the SPDX
mailing list to represent us, and will relay any concerns and updates.
(I don't know if the SPDX list is public. I hope it is. If someone can
find out and post a URL to their list archive, it would be a good
thing.)

Personal opinion: mostly the license shortnames should just require
agreeing what they are for each of the most common licenses, and it
doesn't really matter what the exact string for each one is. I'm OK with
anything that is unambiguous. I would like to see us avoid painting this
bikeshed as much as possible.

> Unbranding
> --
> 
> To my knowledge, you were the first to suggest this. 

I can't remember what this is about. Can you refresh our memories?

> I am running out of time, but that is already a couple of things to discuss.

I have not commented on most of your topics, because I have no opinion
on most of them. If others comment and there's a consensus for the
changes you propose, I'll edit the spec accordingly.


-- 
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.org/1281678216.2264.170.ca...@havelock

Re: DEP-5: additional requirements to use with upstream

[Lars Wirzenius]

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 documenting the copyright of the
> >>   distribution as a whole.  (In US law, this is called a compilation
> >>   copyright.)  This is not the same thing as a Files: * section, which
> >>   would specify a default copyright and license for any individual file
> >>   that doesn't have other information.  In some edge cases, the
> >>   compilation copyright and license can be different than the copyright
> >>   and license of any individual file in the distribution.
> 
> > I am uncomfortable signalling compilation copyright just with the
> > absence of a Files: field. It seems to error prone to me. It would be
> > better to be explicit, I think. What would be a good way of being
> > explicit in this case?
> 
> Maybe allow Copyright and License fields in the header?  This would also
> has the advantage of being the way, in DEP-5, to do what several people
> are asking for and just state the license for the whole package without
> enumerating files, equivalent to what they're doing without DEP-5 now.
> (This differs from a Files: * block in that the latter makes specific
> claims about individual files, whereas the general copyright and license
> statement does not and has the same granularity as most upstream license
> declarations.)

This sounds good to me. Does anyone object?



-- 
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.org/1281678321.2264.171.ca...@havelock

Re: DEP-5 meta: New co-driver; current issues

[Lars Wirzenius]

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 "what stuff is GPLv2 only,
> >   and therefore incompatible with GPLv3?".
> 
> This is quite useless as long as we are making copyright files for
> sourcefiles.

I believe debian/copyright is supposed to cover both source and binary
packages, so I think your premise is invalid. However, let's assume it
is valid. Even so, I don't think it is useless to have debian/copyright
machine parseable, even if it does not solve all problems. Having a
partial solution is already better than nothing, since it will make it
easier to find the cases where manual inspection will be needed.

For example, in the example you gave, it is helpful to get a list of the
packages where there might be a problem, and exclude the majority of
packages where there is obviously no problem with license compatibility.
Without automation, manual inspection is going to be necessary for all
packages, and that's a lot of work.

Now, obviously there are already tools that use pattern matching and
other heuristics to figure out the licenses for each package. The point
of DEP-5 is to reduce the guessing, and make it easier to automate
things. It will not be a complete solution, but if it gets adopted, it
will help.

I like the comparison with debhelper. It also does not solve the entire
problem (though dh comes close), and we can't ever make it mandatory,
but even so, it makes everyone's life quite a lot easier. For some
people, for whatever reason, it doesn't help enough to warrant the
effort to convert to it, so they don't, and that's fine, too.

And I think that's just about enough from me on the topic of justifying
the point of making debian/copyright machine readable.


-- 
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.org/1281721952.2017.31.ca...@havelock

Re: DEP-5 meta: New co-driver; current issues

[Lars Wirzenius]

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 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 to make it harder to
> > maintain debian/copyright in DEP-5 format than as a free-form one,
> > except for minimal markup. It seems that the process so far has created
> 
> I like to offer people to try to do a DEP-5 based copyright file for
> e.g. src:kdebase-workspace, even the overhead from 'minimal markup' is
> actually ending up as quite a big thing.

Here's a quick-and-dirty conversion to DEP-5, which took about an hour
to do, using regular expression search&replace, the vi "." command, plus
manual editing:

http://files.liw.fi/dep5-long-example.txt

Some statistics:

  originaldep5
  bytes   64053   38853
  words   70983363
  lines   17961100

The DEP-5 version is shorter, without (I think) sacrificing precision.
It saves space by avoiding repeating boilerplate text such as "The full
text of the GNU General Public License version 2 is available on Debian
systems in /usr/share/common-licenses/GPL-2." every time the license is
used for a module.

Now, I admit that my DEP-5 version is a) quite dirtily created b) in
need of review and c) certainly incorrect. I did not, for example,
bother to fix up all lists of file specification to handle exceptions. 

I claim, however, that DEP-5 is not going to make it larger.

The original file already had some markup, using some markup language
(not sure which, but similar in spirit to resturctured text and
markdown, and it might have been one of them). Also, there was something
that looked like markup for lists of files. You might be able to write a
script to convert from your markup to the DEP-5 one.

Whether you want to do that or not is of course up to you. Whether you
want to use DEP-5 or not is up to you. I don't care. To me, this idea
that DEP-5 has a massive over head now a equestrian zombie.


-- 
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.org/1281726663.2017.44.ca...@havelock

Re: DEP-5 meta: New co-driver; current issues

[Lars Wirzenius]

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 full of redundancies and useless
> information. (So I am very skeptical of claims that we should
> machine-generate copyright files.) It could probably be replaced by a
> hand-written file of about 20k. IMHO, we should not allow such
> unnecessarily complicated copyright files in Debian.

Ouch. Yes, the chromium-browser debian/copyright file does not seem sane
to me. If an automatic tool is used to generate it, it should take care
to minimize the size, right now there is a lot of duplication there, and
that's silly.

I doubt that is fixable in DEP-5, though. If they didn't use a
machine-parseable format, the could just generate a similar free-form
file, with the same amount of repetition.

(The root problem seems to me to be that chromium-browser is an
aggregation of a large amount of code from other projects. I don't think
that's a sustainable way of developing software in the long run. It
might work for one project at a time, but it harms the ecosystem.)


-- 
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.org/1281727355.2017.47.ca...@havelock

Re: DEP-5: additional requirements to use with upstream

[Lars Wirzenius]

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 headers seems like a good idea to me since we're
> staying with a format with known parsers.

I think I agree with Russ on this one. I'll propose a Comment: field
later.


-- 
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.org/1281727489.2017.48.ca...@havelock

Re: DEP-5 meta: New co-driver; current issues

[Lars Wirzenius]

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 it, with explicit acknowledgement that some people
> aren't interested in doing this sort of thing at all.

That is exactly right.


-- 
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.org/1281758868.5840.13.ca...@havelock

Re: DEP-5 meta: New co-driver; current issues

[Lars Wirzenius]

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 at a time. I'll
raise the next topic whenever discussion dies on the previous one. Or
someone else will, that's obviously fine.

[0] http://wiki.debian.org/Proposals/CopyrightFormat


-- 
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.org/1281759357.5840.17.ca...@havelock

Re: [DEP-5] [patch] Renaming the Format-Specification field to ‘Format’.

[Lars Wirzenius]

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, and this
is easily scriptable, I think we can ignore that.

Does anyone oppose this change? If not, I'll apply the patch on about
Monday (NZ time), and if someone opposes it later, I can always revert
it.



-- 
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.org/1281759570.5840.21.ca...@havelock

Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’

[Lars Wirzenius]

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 information in debian/copyright as opposed to one of the
> many other places we could store such information.  For example, upstream
> usually provides much more complete contact information including
> preferred methods of contact and related information, in a README file
> that we would normally install with the package documentation.

There's also the Homapage: field in the package description.

I don't have a use case for a Maintainer/Contact field in
debian/copyright. Can anyone bring one up?



-- 
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.org/1281759939.5840.23.ca...@havelock

Re: VCS issues ( Re: [DEP-5] [patch] Renaming the Format-Specification field to ‘Format’. )

[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 provides a web interface. I will, however,
make the latest revision be automatically published so everyone can view
it without having to check out via bzr.

I also disagree with Steve on this: it doesn't matter all that much
whether you base a patch on the version in svn, or wherever, as long as
it's clear what is being changed. You don't even need to provide a
patch, you can just provide a new wording, and I'll edit things into the
file manually.

Now, can we please stop displaying our bruised egos and get on with
fixing the spec?



-- 
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.org/1281763378.5840.31.ca...@havelock

Re: DEP-5: clarify batching of copyrights, licenses in a single stanza

[Lars Wirzenius]

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?



-- 
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.org/1281809365.5840.51.ca...@havelock

Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’

[Lars Wirzenius]

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
> mapping for that.

Would the Homepage: field that points at the module's CPAN page be good
enough?

On the other hand, the field currently known as Maintainer: is already
optional, so it's OK to leave it out, and when it's useful to, say,
pkg-perl, it can be added. Russ, since you objected to it, what do you
think?

About renaming it: I feel it would be better to be explicit that it's an
upstream thing. Thus, Upstream-Maintainer or Upstream-Contact, and
perhaps also renaming Name: to Upstream-Name: at the same time. What do
others think?



-- 
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.org/1281809881.5840.58.ca...@havelock

Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’

[Lars Wirzenius]

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's a number of cases where the Debian source package name differs
from the name upstream uses. For example, Iceweasel. On the other hand,
is it useful to track that? Perhaps not.

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 optional fields

All three seem to have reasonable justifications. I'd like to see if we
have a rough consensus favoring one of them. Can we see a show of hands,
please? (If we don't, I'll have choose myself, and then it'll be 3.)



-- 
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.org/1281810359.5840.65.ca...@havelock

Re: [DEP-5] [patch] Syntax of the files.

[Lars Wirzenius]

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 exception of:

Right. It is my understanding that the rough consensus is in favor of
using the same syntax as for Debian control files in general (with
Charles perhaps the only dissenting voice), so I propose the following
attached patch to replace the "Compatibility and Human-Readability"
section with a new short section referencing policy 5.1. (The existing
section is giving requirements for the syntax of the file, such as
human-readability, which was appropriate at the beginning of the
development of the spec, but I think we don't need that in the spec
anymore.)

Does anyone oppose this?

=== modified file 'dep5.mdwn'
--- dep5.mdwn	2010-08-13 05:09:06 +
+++ dep5.mdwn	2010-08-14 18:39:15 +
@@ -54,17 +54,12 @@
 they have a problem with, even if the licenses are DFSG-free. For
 example, the Affero GPL.
 
-# Compatibility and Human-Readability
-The file must be encoded as UTF-8 and strictly formatted as a superset
-of RFC2822 including significant newlines. Free-form text is not
-allowed.
-
-The `debian/copyright` file must be machine-interpretable, yet
-human-readable, while communicating all mandated upstream information,
-copyright notices and licensing details.
-
-For the sake of human-readability this proposal avoids any complex field
-names or syntax rules.
+# File syntax
+
+The syntax of the file is the same as for other Debian control files,
+as specified in section 5.1 of the Debian Policy Manual.
+See 
+for details.
 
 # Implementation
 ## Sections

Re: VCS issues ( Re: [DEP-5] [patch] Renaming the Format-Specification field to ‘Format’. )

[Lars Wirzenius]

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 provides a web interface. I will, however,
> | make the latest revision be automatically published so everyone can view
> | it without having to check out via bzr.
> 
> It does, look at http://bzr.debian.org/loggerhead/dep/dep5/trunk/files

Cool! Then I don't think I'll spend effort on setting up a bzr hook to
automatically publish the file, even if loggerhead only gives access to
the raw markdown text. Markdown is supposedly easy to read (like plain
text). When we push changes from bzr to svn, for the official DEP
website, the HTML version will get generated anyway, and that's the
version people who implement DEP-5 should be looking at. The bzr version
is just a glorified shared editing system.



-- 
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.org/1281811850.5840.83.ca...@havelock

Re: [DEP-5] [patch] License table: more links and licenses.

[Lars Wirzenius]

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 licenses, I propose the attached patch anyway.

Actually, I am starting to think that maintaining a long list of license
shortnames in DEP-5, many of which refer to rarely used licenses, is
perhaps too much effort. Since the list really should be shared with
other projects (SPDX and Fedora especially), it would perhaps make most
sense to refer to it instead of incorporating it in the spec.

I would, however, keep a short list of shortnames for the versioned
licenses in /usr/share/common-licenses (excluding BSD, plain GFDL, plain
GPL, plain LGPL, plain Artistic): Apache-2.0, GFDL-1.2, GFDL-1.3, GPL-1,
GPL-2, GPL-3, LGPL-2, LGPL-2.1, LGPL-3.

What do others think?


-- 
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.org/1281813409.5840.96.ca...@havelock

Re: [DEP-5] [patch] Syntax of the files.

[Lars Wirzenius]

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.
> 
> The rest is good, but I like that paragraph.

I've resurrected that paragraph. New patch attached.
=== modified file 'dep5.mdwn'
--- dep5.mdwn	2010-08-13 05:09:06 +
+++ dep5.mdwn	2010-08-14 19:42:38 +
@@ -54,17 +54,16 @@
 they have a problem with, even if the licenses are DFSG-free. For
 example, the Affero GPL.
 
-# Compatibility and Human-Readability
-The file must be encoded as UTF-8 and strictly formatted as a superset
-of RFC2822 including significant newlines. Free-form text is not
-allowed.
+# File syntax
 
 The `debian/copyright` file must be machine-interpretable, yet
 human-readable, while communicating all mandated upstream information,
 copyright notices and licensing details.
 
-For the sake of human-readability this proposal avoids any complex field
-names or syntax rules.
+The syntax of the file is the same as for other Debian control files,
+as specified in section 5.1 of the Debian Policy Manual.
+See <http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-controlsyntax>
+for details.
 
 # Implementation
 ## Sections

Re: Upstream guide and front desk

[Lars Wirzenius]

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 ask the DPL to take the
next step.



-- 
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.org/1281888502.5840.116.ca...@havelock

Re: [DEP-5] [patch] Syntax of the files.

[Lars Wirzenius]

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
Wellington, so two hats is appropriate.)

> > 2) The Policy does not describe the DEP syntax for escaping empty lines.
> 
> > Policy §5.1 does not describe the mechanism of using a space plus a dot
> > to escape empty lines in field values, but we can not refer simply to
> > §5.6.13 (Description) because the DEP-5 License field is verbatim,
> > whereas the debian/control Description filed requires an additional
> > space to signal verbatim sections.
> 
> Yes, this should be described in DEP-5.

I propose, in the description of the License field:

* Remaining lines: Each non-empty line of the license text
should be prefixed by a single space or TAB character. Empty
lines should be replaced with a line consisting of a space or
TAB followed by a period. (Empty lines lines contain nothing, or
only whitespace
characters.) If a debian/copyright file is formatted for
display, the license text is not expected to be word-wrapped,
but displayed as if it were program code, so that license text
that uses one of the many conventions for plain text formatting
will display OK.



-- 
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.org/1281892127.5840.187.ca...@havelock

Re: DEP-5: additional requirements to use with upstream

[Lars Wirzenius]

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 postpone the implementation of this change until we've
> cleared a few of the other issues?

I'm fine with postponing the implementation.



-- 
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.org/1281892395.5840.198.ca...@havelock

Re: [DEP-5] [re-patch] Syntax of the files.

[Lars Wirzenius]

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 also refers to a specific Policy Manual version, which I
think is inappropriate (read: results in unnecessary work). If the
Policy Manual changes here, the DEP-5 specification needs to change at
the same time. Russ's suggestion of maintaining the approved DEP-5 spec
in the Policy Manual source tree, using the same change process, solves
that problem.

(Your patch also claims to add a URL, which my patch already did.)

>  - The second replaces stanza by paragraph.

For these kinds of search+replace things, it's easier for me to just say
to do that than to provide a patch I need to proofread. I've done the
replacement and pushed the change.

>  - The third explains how empty lines are escaped in field values.

You say:

In field values, lines containing a single space followed by a
single full stop character are replaced by an empty line. The
first space or tabulation is ignored.

Why would a TAB+period not be acceptable for escaping an empty line?



-- 
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.org/1281892510.5840.200.ca...@havelock

Re: [OT] Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’

[Lars Wirzenius]

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
helping. So, in all seriousness, I propose:

* a 24-hour moratorium on posting about DEP-5 at all
* after that is over, not discussing every possible topic at once, just
a couple at a time

Now, I have no authority or power to enforce either of the above. And
that's not the point. This is an attempt to force people to do anything.
This is an appeal to sensible adults to take a step back, to take a deep
breath, and to calm down. I could do with some of that myself.


-- 
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.org/1281932372.12989.58.ca...@havelock

Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’

[Lars Wirzenius]

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 optional fields
> 
> All three seem to have reasonable justifications. I'd like to see if we
> have a rough consensus favoring one of them. Can we see a show of hands,
> please? (If we don't, I'll have choose myself, and then it'll be 3.)

It's my assessment that the rough consensus is in favor of either 2 or
3, with 3 getting more explicit votes, but 2 not getting any resistance,
and having the justification that it's useful to a number of people.
Thus, I will modify the spec to implement option 2.

If there are objections to this, I'll be happy to revert the change
until they're discussed.


-- 
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.org/1282075868.12989.122.ca...@havelock

DEP-5: general file syntax

[Lars Wirzenius]

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 my strong preference, I want to be
careful.

Here's my current suggestion:

* We refer to Policy 5.1 by section number, section title, and URL. I
don't think the policy version is necessary: if they make incompatible
changes, then all Debian control files will potentially break, and DEP-5
copyright files are no exception. Including the 5.1 section verbatim in
DEP-5, on the other hand, results in duplication, which is likely to
result in divergence between the policy and DEP-5.

* We add to DEP-5 details of how to handle values of multiline fields.
We can discuss exact wording of that later (see below), if we can get
consensus on the overall topic of file syntax.

* Once DEP-5 is accepted, we move it into the debian-policy package; it
will then be maintained via the normal policy amendment process on the
debian-policy mailing list. If section 5.1 changes (including just
number), the DEP-5 spec shall be changed at the same time.

* We specify the debian/control Format: field to include an identifier
that is not dependent on the DEP-5 URL. Currently, the spec includes a
URL to the specific version of itself; this is obviously problematic. I
suggest we change it by having two "words" in the Format: value: an
unversioned URL to the spec (currently to the DEP site, but later to the
debian-policy site), and a date.

Comments on the above? The rest of this e-mail proposes a specific way
of handling multiline values.

 - - -

On to fields with multiline values. Well, every field can have
multi-line values, but the generic rules suffice for most of them. There
are three important details here: for specific fields, are newlines
significant, can word-wrapping happen, and how empty lines are handled.

For License, the text in the field (except the first line) should
probably not be word-wrapped, newlines are significant, and definitely
empty lines need to be handled in some way. The reason word-wrapping
shouldn't happen is that in many cases upstream licenses use ad hoc
plain text formatting conventions, such as bulleted lists, and any word
wrapping will mess that up. There is already rough consensus on how to
handle empty line markup (read: same as Description in debian/control).

For Disclaimer, and Comment if we add that, it might be helpful to have
empty lines, but word-wrapping is definitely needed. Newlines are not
significant.

For simplicity, I will introduce a new term, "desc-escape". This refers
to the escaping of content similar to the way Description does it in
debian/control: each line is prefixed with a space, except empty lines
are replaced with a space and period. The Policy's specification is not
usable for this, I think, because it goes much further than what DEP-5
needs.

Note that I've dropped the possibility of prefixing escaped lines with a
TAB character. It is a needless difference from Description, and would
complicate parsers.

So there are three cases:

* License: newlines are significant, no word-wrapping, desc-escape is
used.
* Disclaimer (and Comment in the future): newlines are not significant,
word-wrapping is OK, desc-escape is used.
* Everything else: newlines are not significant, word-wrapping is OK,
desc-escape is not used. Normal RFC822-style handling of line
continuations applies.

In other words, for Disclaimer, a formatter would un-escape (remove
leading space, replace lines with just period with empty ones), then
split the resulting text into paragraphs at empty lines, and format
those paragraphs in whatever manner it sees fit.

I echo Charles's suggestion that we specify the way escaping is done in
the section that describes the overall syntax, and then specify for each
field if they use desc-escape or not, whether newlines are significant
or not, whether the content can be word-wrapped or not.

Comments on this part? I haven't got specific wording changes to suggest
yet, I want to know if this approach is acceptable first, before we
spend time on wording details.


-- 
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.org/1282080573.12989.179.ca...@havelock

Re: DEP-5: file globbing

[Lars Wirzenius]

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]
> License: GPL
> 
> Without an exclusion syntax, you now have to reiterate the Files: * stanza
> in an additional specific stanza for Files: extra/foo.[ch].  I don't know
> if the additional complexity is worth it, but it does address a problem.

When I did the experimental conversion of the kdebase-workspace
debian/copyright file to DEP-5, I ran into this several times. It would,
I think, be worthwhile to have an exclusion pattern for Files.



-- 
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.org/1282080907.12989.184.ca...@havelock

Re: [OT] Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’

[Lars Wirzenius]

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 commented on two topics (general file syntax, in a new thread, and
globbing syntax in the existing one). I would find it practical if we
could stick to those for now, unless there is something urgent. This
way, I think we can more easily keep track of what's going on, and this
will help build consensus much faster.



-- 
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.org/1282081184.12989.188.ca...@havelock

Re: DEP-5: general file syntax

[Lars Wirzenius]

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, contradict or supplement information included in the source
> files).

Hmm. If the e-mails (or whatever) modify or clarify the license, should
not the e-mails be considered part of the license information?

License: other
 This software is released under the GPLv2 blahblah.
 .
 From: Upstream Author 
 Message-Id: 
 Date: Mon, Apr 01 2010 04:01:00 +0401
 Subject: License clarification
 .
 When I say GPL I actually mean LGPL, sorry about that.

If the e-mail is just a clarification to the license and does not modify
it, then I guess License is not the right place. Rather than munge it
into Comment, I guess we need a new field. However, how often do these
things happen? If it is very rarely, we could just live with appending
them to License.

Having part of the file be non-machine-readable might be an option, but
I have the feeling that for large debian/copyright files, it'd be easier
to have these e-mails near the paragraphs that concern them, otherwise
it'll get too difficult to keep track of things. So a structured
approach would be my preference here.


-- 
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.org/1282108302.12989.199.ca...@havelock

Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’

[Lars Wirzenius]

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 a requirement from the Policy or Joerg's message on
> debian-devel-announce in March 2006 for listing the package name in
> debian/copyright. Similarly, although it is required to list all authors of a
> packaged work, there is no requirement to list the upstream maintainer.
> Therefore, I think that the fields should be optional if they are not removed.

I don't think they're required by Policy or the ftpmasters. At least the
pkg-perl team is using Maintainer/Upstream-Contact. I don't think they
use Name/Upstream-Name. It's reasonable to expect the package
description to mention the upstream name if it differs from the Debian
package name, and that would make Upstream-Name somewhat unnecessary.

If pkg-perl, and perhaps others, are going to be using a field to keep
track of the upstream contact information anyway, it makes sense to have
a standard way of doing that. So I'd like to keep Upstream-Contact.

Anyone else have an opinion on this? That is, should we drop
Upstream-Name or not? Anyone opposed to keeping Upstream-Contact?

(The fields will, obviously, be optional, if we keep them in the spec.)


-- 
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.org/1282188247.12989.242.ca...@havelock

Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’

[Lars Wirzenius]

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.
Summary, if I understood correctly: pkg-perl would like to use
Upstream-Name to more reliably connect a CPAN module and its Debian
package (Homepage does not always point at the CPAN page), and
Upstream-Contact to more easily connect a Debian package of a CPAN
module with its author.

I can imagine Python modules, and other such sets of modules, might want
to do the same thing. These sets of modules have naming schemes, but
they are not always 100% accurate.

Now, it is certainly true that these are convenience fields, not
strictly required by Policy or ftpmaster, but nevertheless interesting
to a bunch of people. Thus it makes sense to me to standardize the name
rather than everyone invent their own. The compromise between strict
minimalism and overall convenience, if you will.

I therefore intend to keep the fields in the spec, unless there's a wave
of opposition. I hope that this is acceptable. (The volume of DEP-5
discussion dropped to low enough that it's getting hard to measure
consensus. :)


-- 
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.org/1282256623.12989.256.ca...@havelock

Re: Upstream guide and front desk

[Lars Wirzenius]

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 archived publically, would be best. An alias
upstre...@debian.org could point to it, but I have no opinion on that.

Anyone opposed to the mailing list? Shall I go and request one?

> No matter the technical solution, once it is done, we absolutely need to
> send out a Debian News item / press release about that. It is our best
> chance to increase awareness of the initiative within upstreams.

Absolutely.



-- 
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.org/1282334011.12989.263.ca...@havelock

Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’

[Lars Wirzenius]

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 question one way or the other so we can move on.

Well, this is hard. There's no clear consensus, so ideally we would
continue discussion, but this is really a pretty small point, so I'll
force a decision: I'll keep the Upstream-Contact and Upstream-Name
fields in the spec. 

This will either let us move on to other things, or provoke a wave of
opposition, giving me sufficient reason to remove them from the spec,
and letting us move on to other things.

(Machiavelli was my pupil. All that he wrote in his little booklet he
learned from the masterly way I direct Debian discussions.)


-- 
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.org/1282378642.12989.299.ca...@havelock

Re: DEP-5: general file syntax

[Lars Wirzenius]

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 like http://dep.debian.net/DEP-5/1.0 at which it would
> always be found.  If we publish a new version of the document, the new
> version would be put at http://dep.debian.net/DEP-5/1.1, but the old
> version wouldn't be changed.

DEPs are not supposed to change after they're approved, so it should be
a new DEP rather than DEP-5/1.1, but that's a trivial detail.

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.

> Note that you should say that explicitly, since in the control file format
> not every field is multi-line (the default is that a field may not be
> multi-line).

ACK.

> I think we could merge all three of these into the same case by using the
> Description syntax, with the note that blank lines don't really make sense
> in some fields.  (So, I guess, merge them into two cases.)

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'll word a concrete patch to propose.


-- 
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.org/1282379544.12989.309.ca...@havelock

Re: DEP-5: general file syntax

[Lars Wirzenius]

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'll word a concrete patch to propose.

While wording this, I realized that we have more cases: Files has a list
of values (currently comma-separated, but I propose to make it
white-space separated), and Copyright and maybe other fields have a list
of values one per line. I took the liberty of taking this into account. 

The relevant new text in the file syntax section:

There are four kinds values for fields. Each field specifies which
kind is allowed.

* Single-line values.
* White space separated lists.
* Line based lists.
* Free-form text formatted like package long descriptions.

A single-line value means that the whole value of a field must fit on
a single line. For example, the `Format` field has a single line value
specifying the version of the machine-readable format that is used.

A white space separated list means that the field value may be on one
line or many, but values in the list are separated by one or more
white space characters (including space, TAB, and newline). For
example, the `Files` field has a list of filename patterns.

Another kind of list value has one value per line. For example,
`Copyright` can list many copyright statements, one per line.

Free-form text is formatted the same as the long description in
a package's `Description` field, possibly also using the first
field in a special way, like `Description` uses it for the
short description.
See section 5.6.13, "Description", at

<http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description>
for details.
For example, `Disclaimer` has no special first line, whereas
`License` does.

I'm attaching the exact diff, which lists the type of value for each
field.

Comments?
=== modified file 'dep5.mdwn'
--- dep5.mdwn	2010-08-17 20:47:26 +
+++ dep5.mdwn	2010-08-21 09:04:06 +
@@ -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 allowed.
+
+* Single-line values.
+* White space separated lists.
+* Line based lists.
+* Free-form text formatted like package long descriptions.
+
+A single-line value means that the whole value of a field must fit on
+a single line. For example, the `Format` field has a single line value
+specifying the version of the machine-readable format that is used.
+
+A white space separated list means that the field value may be on one
+line or many, but values in the list are separated by one or more
+white space characters (including space, TAB, and newline). For
+example, the `Files` field has a list of filename patterns.
+
+Another kind of list value has one value per line. For example,
+`Copyright` can list many copyright statements, one per line.
+
+Free-form text is formatted the same as the long description in
+a package's `Description` field, possibly also using the first
+field in a special way, like `Description` uses it for the
+short description.
+See section 5.6.13, "Description", at
+<http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description>
+for details.
+For example, `Disclaimer` has no special first line, whereas
+`License` does.
+
 # Implementation
 ## Sections
 ### Header Section (Once)
@@ -77,6 +107,7 @@
  * **`Format`**
* Required
* Single occurrence
+   * Value: single line
* Syntax: URI of the format specification, such as:
  * http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=REVISION
  * Note that the unwieldy length of the URL should be solved in
@@ -86,12 +117,14 @@
  * **`Upstream-Name`**
* Optional
* Single occurrence
+   * Value: single line
* Syntax: Single line (in most cases a single word),
  containing the name upstream uses for the software.
 
  * **`Upstream-Contact`**
* Optional
* Single occurrence
+   * Value: line based list
* Syntax: Line(s) containing the preferred address(es) to reach 
  the upstream project. May be free-form text, but by convention
  will usually be written as a list of RFC2822 addresses or URIs.
@@ -99,13 +132,15 @@
  * **`Source`**
* Optional
* Single occurrence
+   * Value: single line
* Syntax: One or more URIs, one per line, indicating the primary
  point of distribution of the software.
 
  * **`Disclaimer`**
* Optional
* Single occurrence
-   * Syntax: Free-form text. On Debian systems

Re: DEP-5: general file syntax

[Lars Wirzenius]

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
> recently, though, so I guess I have a poor grasp of how this is supposed
> to work.  I'll go review it.  If we pick up the files in debian-policy,
> then wherever we publish them from should really publish the versions from
> the debian-policy package.

I was assuming we'd have the current official version be in the
debian-policy package, and published at http://www.debian.org/doc/ or
http://www.debian.org/doc/debian-policy/ rather than on dep.debian.net.
The final version of DEP-5 would have a pointer to the version in
debian-policy. That's why I'm having such as bad time figuring out how
to put the version in the URL. 

However, it now strikes me that the filename in debian-policy can just
have the version number. So the filename would start out as
copyright-format-1.0.txt, and when it changes, the the filename changes
to copyright-format-1.1.txt. Does that sound reasonable?

The URL for Format would then be something like

http://www.debian.org/doc/packaging-manuals/copyright-format-1.0.html

That's a bit long, perhaps.

Having an updated DEP-5 be generated from debian-policy on
dep.debian.net, when DEP is not used to update it, seems unpleasantly
complicated to me.


-- 
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.org/1282382283.12989.320.ca...@havelock

Re: DEP-5: general file syntax

[Lars Wirzenius]

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 what we have now.)
* Have one copyright statement per Copyright field, and have multiple
instances of the field.
* Just make it all be free-form text, disabling any automatic parsing of
the Copyright field.

> Note that the FSF lawyer told them not to use ranges in copyright 
> dates,

For actively maintained software, this is going to get really hard to
read in a millennium or two.


-- 
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.org/1282382607.12989.324.ca...@havelock

Re: Upstream guide and front desk

[Lars Wirzenius]

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 way or another. It might be that too much separation might accidently 
> introduce some confusion amongst the targeted consumers. I'm not opposing to 
> a 
> yet another mailing list per se, so please decipher that more like a 
> question, 
> rather than objection.

debian-mentors is an excellent list for an upstream to participate in if
they have a package, or are making one, and need help with that. For
many upstreams, that's not the first thing they need: they might only
have just heard of Debian, and making a package is much further down the
road. Some possible questions:

* "We heard about Debian, and are wondering if it would be a good idea
to have our software included."

* "People tell us Debian does not want our software, because it is hard
to maintain. What's up with that? With whom should we talk about these
issues?"

* "There's an old version of our software in Debian, and we are tired of
supporting it. What should we do to get it removed?"

* "We'd like our software included in Debian. We don't know anything
about packaging. Where can we learn more about this?"

* "The Debian developer who maintained packages of our software in
Debian has disappeared. Do you know how to contact them? Or can you help
us find someone else?"

These are the kinds of questions that upstreams who are not already
closely involved with Debian have.

The point of the upstream front desk is not to replace existing
communication channels, but to make sure there's a single easy way for
upstreams to get in touch with Debian. The upstream front desk can then
direct them to the relevant people, or the appropriate documentation.

My interest in this stems from being retired from Debian for about a
year and spending some time upstream. I experienced a little bit how
hard it can be to approach a large project like Debian, even when Debian
has extensive documentation on various web sites and wikis, plus lots of
mailing lists, IRC channels, web forums, and other places for
discussions. Or perhaps that's part of the difficulty: there's so much
available that it's hard to get started.

I don't know if having an upstream front desk will solve this, but I
expect it will be helpful. If not, we can decide it's a failed
experiment and end it.

Here's what I'm hoping will happen:

* We get more motivated, committed upstreams involved with Debian.

* More upstreams understand how to make software that is easy to
integrate into a Linux distribution.

For the latter, the wiki page is an excellent resource, and the more
ways we have of getting upstream developers to read it, the better.


-- 
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.org/1282424023.12989.353.ca...@havelock

Re: DEP-5: general file syntax

[Lars Wirzenius]

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 guess such file
> names would need to be quoted?

The Files field globbing syntax will need a way of dealing with that,
you're quite right. I hope to have that discussion later, separate from
the general file syntax.


-- 
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.org/1282424119.12989.354.ca...@havelock

Re: DEP-5: Structure for multiple copyright statements (was: DEP-5: general file syntax)

[Lars Wirzenius]

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 my keymap does not seem to have a binding for it.)

The word "Copyright" or the ASCII-art "(C)" might be substituted.

> Copyright:
> © 1995, 1997, 1998, 1999, 2002, 2003, 2004, 2006, 2009 Beatrice
> Bar 
> © 2008, 2010 Barry Baz 

What do others think?

If I was writing a parser, I'd rather have the simplicity of long lines,
but then I'm lazy. If I was writing DEP-5 files, I am not sure what I
would prefer, but I know I would hate filling out the copyright fields
in any case, since it's boring, repetitive work.


-- 
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.org/1282433814.12989.361.ca...@havelock

Re: DEP-5: Structure for multiple copyright statements

[Lars Wirzenius]

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 individual copyright holders for some reason?  If so, we
> would need to standardize the format quite a bit, and I'm not sure it's
> worth it.

If it was easy, I might be interested in analyzing the years indicated
for copyrights, so I could write a little tool to notify me when things
fall out of copyright.

Oh, wait, I was living in a fantasy world for a while, one in which
copyrights actually expire.

Now that I'm awake, I'm happy to keep it free-form, at least for now. If
it turns out to be useful later, we can specify a more strict format.

(I will now go live in another fantasy world, one in which there is a
markup language for copyright statements and licenses which upstreams
regularly use.)


-- 
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.org/1282434506.12989.367.ca...@havelock

Re: DEP-5: general file syntax

[Lars Wirzenius]

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 one starts.

However, since there seems to be no current plans to parse copyright
statements out of the Copyright field, I think we can forget this issue,
at least for now, and leave it for later generations to solve, if they
start caring.


-- 
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.org/1282514128.12989.386.ca...@havelock

Re: DEP-5: general file syntax

[Lars Wirzenius]

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
> 
> by:
> 
>   Formatted text like package long descriptions

ACK, done.

> All in all, I would recommend to make these fields free-form. Packaging teams
> that would like to use a more specialised syntax can add their own local
> policies on top of the DEP.

I disagree with this: I think a line-based list is perfectly fine for
Upstream-Contact. Does anyone else have an opinion?

> > @@ -99,13 +132,15 @@
> >   * **`Source`**
> > * Optional
> > * Single occurrence
> > +   * Value: single line
> > * Syntax: One or more URIs, one per line, indicating the primary
> >   point of distribution of the software.
> 
> Since the syntax allows multiple URIs, and since the URIs may be long, I think
> that allowing newlines in the field will make it more readable. for instance 
> by
> making it free-form (not formatted, see below).

Actually, I think I made a mistake: I think Source should be a
line-based list. This will make it easier for parsers to extract the
URIs.

Splitting a URI to two physical lines seems to me a bad idea, and messes
up URI parsing in too many contexts. (The real fix is to get upstream to
not have excessively long URIs, but that's hard to fix.)

> If the extended description finally requires double space for verbatim 
> display,
> then how abould calling the ‘special first line’ synopsis, to be closer to the
> vocabulary used in the specification of the Description field ? 

Could some English experts weigh in whether the word synopsis is a good
way to describe the list of license short names?


-- 
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.org/1282514846.12989.396.ca...@havelock

Re: DEP-5: general file syntax

[Lars Wirzenius]

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 like package long descriptions.
+* Text formatted like package long descriptions.
 
 A single-line value means that the whole value of a field must fit on
 a single line. For example, the `Format` field has a single line value
@@ -90,7 +90,7 @@
 Another kind of list value has one value per line. For example,
 `Copyright` can list many copyright statements, one per line.
 
-Free-form text is formatted the same as the long description in
+Formatted text fields use the same rules as the long description in
 a package's `Description` field, possibly also using the first
 field in a special way, like `Description` uses it for the
 short description.
@@ -132,14 +132,14 @@
  * **`Source`**
* Optional
* Single occurrence
-   * Value: single line
-   * Syntax: One or more URIs, one per line, indicating the primary
- point of distribution of the software.
+   * Value: line based list
+   * Syntax: One or more URIs, indicating the primary
+ points of distribution of the software.
 
  * **`Disclaimer`**
* Optional
* Single occurrence
-   * Value: free-form text, no special first line
+   * Value: formatted text, no special first line
* Syntax: On Debian systems, this field can be
  used in the case of non-free and contrib packages (see [Policy
  12.5](
@@ -183,7 +183,7 @@
  * **`License`**
* Licensing terms for the files listed in **`Files`** field for this section
* Required
-   * Value: free-form text, with special first line
+   * Value: formatted text, with special first line
* Syntax:
  * First line: an abbreviated name for the license (see *Short names*
section for a list of standard abbreviations). If empty, it is

Re: DEP-5: general file syntax

[Lars Wirzenius]

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
> format, in essence.

ACK, you and Ben have assured me that it is acceptable, and I've changed
the spec draft. Latest diff attached.
=== modified file 'dep5.mdwn'
--- dep5.mdwn	2010-08-17 20:47:26 +
+++ dep5.mdwn	2010-08-23 02:47:59 +
@@ -3,7 +3,7 @@
 	Title: Machine-readable debian/copyright
 	DEP: 5
 	State: DRAFT
-	Date: 2010-08-18
+	Date: 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 allowed.
+
+* Single-line values.
+* White space separated lists.
+* Line based lists.
+* Text formatted like package long descriptions.
+
+A single-line value means that the whole value of a field must fit on
+a single line. For example, the `Format` field has a single line value
+specifying the version of the machine-readable format that is used.
+
+A white space separated list means that the field value may be on one
+line or many, but values in the list are separated by one or more
+white space characters (including space, TAB, and newline). For
+example, the `Files` field has a list of filename patterns.
+
+Another kind of list value has one value per line. For example,
+`Copyright` can list many copyright statements, one per line.
+
+Formatted text fields use the same rules as the long description in
+a package's `Description` field, possibly also using the first
+line as a synopsis, like `Description` uses it for the
+short description.
+See section 5.6.13, "Description", at
+<http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description>
+for details.
+For example, `Disclaimer` has no special first line, whereas
+`License` does.
+
 # Implementation
 ## Sections
 ### Header Section (Once)
@@ -77,6 +107,7 @@
  * **`Format`**
* Required
* Single occurrence
+   * Value: single line
* Syntax: URI of the format specification, such as:
  * http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=REVISION
  * Note that the unwieldy length of the URL should be solved in
@@ -86,12 +117,14 @@
  * **`Upstream-Name`**
* Optional
* Single occurrence
+   * Value: single line
* Syntax: Single line (in most cases a single word),
  containing the name upstream uses for the software.
 
  * **`Upstream-Contact`**
* Optional
* Single occurrence
+   * Value: line based list
* Syntax: Line(s) containing the preferred address(es) to reach 
  the upstream project. May be free-form text, but by convention
  will usually be written as a list of RFC2822 addresses or URIs.
@@ -99,13 +132,15 @@
  * **`Source`**
* Optional
* Single occurrence
-   * Syntax: One or more URIs, one per line, indicating the primary
- point of distribution of the software.
+   * Value: line based list
+   * Syntax: One or more URIs, indicating the primary
+ points of distribution of the software.
 
  * **`Disclaimer`**
* Optional
* Single occurrence
-   * Syntax: Free-form text. On Debian systems, this field can be
+   * Value: formatted text, no synopsis
+   * Syntax: On Debian systems, this field can be
  used in the case of non-free and contrib packages (see [Policy
  12.5](
  http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile))
@@ -132,13 +167,15 @@
* Required for all but the first paragraph.
  If omitted from the first paragraph,
  this is equivalent to a value of '*'.
+   * Value: white space separated list
* Syntax: List of patterns indicating files covered by the license
  and copyright specified in this paragraph.  See "File patterns" below.
 
  * **`Copyright`**
* Required
-   * Syntax: one or more free-form copyright statement(s) that apply to
- the files matched by the above pattern.
+   * Value: line based list
+   * Syntax: one or more free-form copyright statement(s), one per line,
+ that apply to the files matched by the above pattern.
  * Example value: 2008, John Q. Holder 
  * If a work has no copyright holder (i.e., it is in the public
domain), that information should be recorded here.
@@ -146,6 +183,7 @@
  * **`License`**
* Licensing terms for the files listed in **`Files`** field for this section
* Required
+   * Value: formatted text, with synopsis
* Syntax:
  * First line: an abbreviated name for the license (see *Short names*
section for a list of standard abbreviations). If empty, it is

Re: webchat/cgiirc on irc.debian.org

[Lars Wirzenius]

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.org/). I asked on their IRC channel, and
their experiences have been quite positive.

The least sophisticated people are unlikely to have much experience IRC,
and probably won't have an IRC client installed, so having a web IRC
client will make it easier for them to get help.

I'm afraid I have idea what it would take to set this up and operate it,
though. Does a free software implementation exist?


-- 
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.org/1282533528.12989.433.ca...@havelock

Re: DEP-5: general file syntax

[Lars Wirzenius]

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
> > format, in essence.
> 
> ACK, you and Ben have assured me that it is acceptable, and I've changed
> the spec draft. Latest diff attached.

There hasn't been any further suggestions to this diff, so I'll apply it
to the bzr trunk and we can move to the next topic.


-- 
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.org/1282767798.2242.22.ca...@havelock

DEP-5: Files field and filename patterns

[Lars Wirzenius]

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: foo.c, bar.*, baz.[ch]

File names containing spaces or commas should be put within double
quotes. The backslash character is an escaping character, be it inside
or outside double quotes:

Files: "Program Files/*", manual[english].txt

 Syntax
Patterns are handled as by the `find` utility's `-name` option.  
Patterns
containing a path separator ("/") are handled as by the `find` utility's
`-path` option.

[examples removed]

It is quite common for a work to have files with copyright held by
different parties and received under different licenses. To accommodate
this, **multiple paragraphs are allowed with different `Files`
declarations**.

However it makes for easier reading if the copyright file lists the
"main" license first: the one matching the "top level" of the work, with
others listed as exceptions. To allow this, the following precedence
rule applies for matching files: **If multiple `Files` declarations
match the same file, then only the last match counts.**

As a result, it is recommended for clarity that the paragraphs appear in
order from most general (e.g. `Files: *`) first, through to most
specific. In the following example, the file `getopt.c` matches both
`Files: *` and `Files: getopt.*`; only the last match counts, so
the file `getopt.c` has the license declaration `License: BSD`.

[example removed]

Russ suggested using the same patterns as git does in the .gitignore
file, since those are familiar to many people.

http://www.kernel.org/pub/software/scm/git/docs/gitignore.html

Some issues I would like to raise:

* Is comma-separation appropriate? I'd prefer space-separation myself.
What do those who write parsers think?

* Are find -name/-path globs a better idea than .gitignore?

* .gitignore has one pattern per line, which I think is inappropriate
for for DEP-5 debian/copyright files: we should allow "Files: *.c *.h",
I think.

* Are shell-style globs the right idea? Should we use Perl regular
expressions on the entire pathname instead?

* Is using multiple paragraphs for exceptions the right idea? Russ
suggests not, and I think I agree. .gitignore uses an exclamation mark
(!) as a prefix for logical not.

Any other issues related to filename patterns in the Files field?


-- 
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.org/1282769021.2242.40.ca...@havelock

DEP-5: Comment field

[Lars Wirzenius]

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 paragraph, can occur in each paragraph.
   * Value: formatted text, no synopsis
   * Description: This field can provide additional information. For
 example, it might quote an e-mail from the Debian ftpmaster team
 justifying why the license is acceptable to the main archive, or
 an explanation of how this version of the package has been forked
 from a version known to be DFSG-free, even though the current
 upstream version is not.

Comments on Comment?


-- 
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.org/1282769854.2242.54.ca...@havelock

Re: DEP-5: Comment field

[Lars Wirzenius]

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 of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1282771904.2242.55.ca...@havelock

Re: DEP-5: Comment field

[Lars Wirzenius]

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 required). I don't see a paragraph with only Comment being
allowed, or necessary.

>  - Is the purpose of the field to be displayed after parsing, or only to
>provide complements of information in the source file ?

Display, of course, to the extend any of the fields are for display.

>  - If we take the Policy strictly, comments lines starting by ‘#’ are only
>allowed in §5.2 (Source package control files -- debian/control),
>which we do not refer to in the DEP. Will the DEP also accept such
>comment lines ?

I don't care, myself. As it stands, following a strict reading of the
DEP-5 spec and policy, hash comments are not allowed in
debian/copyright. I'm OK with that, personally. If someone wants to
suggest wording to allow them, please do, and unless there's opposition,
I'll add that to the spec. However, given my extreme amount of not
caring, I don't want to spend the energy on this wording myself. :)

Does anyone want hash comments to be allowed in debian/copyright? Are
they useful?


-- 
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.org/1282792697.2242.92.ca...@havelock

Re: DEP-5: Files field and filename patterns

[Lars Wirzenius]

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 make the
job of the person writing the debian/copyright file easier, rather than
the job of the person copy-pasting things out of it.

What do others think?

Is anyone else than Russ (and, maybe, me) in favor of .gitignore syntax?


-- 
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.org/1282792799.2242.94.ca...@havelock

Re: DEP-5: Files field and filename patterns

[Lars Wirzenius]

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 probably (almost) all debian/copyright files in
> the Perl group are invalid at the moment.

To me, that indicates that the spec is bad, actually. Having to prefix
paths with ./ is silly. It is also counter-intuitive, which implies that
people are going to make a lot of mistakes.

Also, a small tool to check that all files are covered by
debian/copyright Files sections would seem to be a good idea. This could
be used by a lintian test.


-- 
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.org/1282849396.2242.104.ca...@havelock

Re: DEP-5: Comment field

[Lars Wirzenius]

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 file 'dep5.mdwn'
--- dep5.mdwn	2010-08-23 02:48:51 +
+++ dep5.mdwn	2010-08-25 21:30:50 +
@@ -145,6 +145,17 @@
  12.5](
  http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile))
 
+ * **`Comment`**
+   * Optional
+   * Single occurrence per paragraph, can occur in each paragraph.
+   * Value: formatted text, no synopsis
+   * Description: This field can provide additional information. For
+ example, it might quote an e-mail from upstream
+ justifying why the license is acceptable to the main archive, or
+ an explanation of how this version of the package has been forked
+ from a version known to be DFSG-free, even though the current
+ upstream version is not.
+
 Examples:
 
 	Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135

Re: DEP-5: Files field and filename patterns

[Lars Wirzenius]

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 simple globbing (* and ? and nothing else).

* .gitignore is still on the table, but has neither strong support, nor
strong opposition.

* No consensus on exclusions in patterns versus multiple paragraphs.

* No consensus on patterns on basename only, versus the whole path.

* Nobody seems to object dropping commas for separating patterns.

* Nobody likes my idea of regexps on pathnames.

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
not treat the slash character specially when matching, so that
*/Makefile.in will match Makefile.in at any depth. All patterns are
anchored to the root of the source tree; thus a plain Makefile.in will
match only at the root of the source tree. I suggest we not add
exclusions at this time. In a year or two, we can re-visit this part of
the spec and see if it needs to be improved.

Is this proposal acceptable? If so, I'll write up a formal suggestion
for the new wording. (I'm sitting in a cafe waiting for a movie to
start, so I don't have time for that now.)

(Burglars please take note: we've emptied our apartment. We're moving to
another country. There's no point in trying to steal anything, unless
you like carpet lint.)

(Oh, people following the DEP-5 saga should perhaps note that for the
next week I'll be in transit and might not have frequent Internet
access. Indeed, I might be entirely too busy avoiding dropbears, boxing
with kangaroos, and learning life lessons from koalas to react very
quickly to DEP-5 e-mails, but I'll get to them the following week.)

(Lisp programmers please take note: I am not saying using Lisp will make
you use too many parentheses, but that's certainly what happened to me.)


-- 
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.org/1282981875.2242.136.ca...@havelock

DEP-5: No alternative syntaxes

[Lars Wirzenius]

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 the development of the format to consider other formats.

If anyone objects, please raise the issue and I will revert the change
until the discussion is over and an explicit consensus is well-known.

=== modified file 'dep5.mdwn'
--- dep5.mdwn   2010-08-25 21:31:21 +
+++ dep5.mdwn   2010-08-29 03:37:01 +
@@ -514,9 +514,6 @@
 
 ## Implementation
 
-It is proposed to implement this proposal in pseudo-RFC-822 format (the one of
-debian/control). However, other syntaxes could be used, such as YAML.
-
 ### Examples in pseudo-RFC-822 format
  Simple
 A possible `copyright` file for the program 'X Solitaire' distributed in the




-- 
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.org/1283053199.2242.207.ca...@havelock

DEP-5: Ack section

[Lars Wirzenius]

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.mdwn   2010-08-29 03:37:28 +
+++ dep5.mdwn   2010-08-29 03:44:45 +
@@ -58,6 +58,18 @@
 they have a problem with, even if the licenses are DFSG-free. For
 example, the Affero GPL.
 
+# Acknowledgements
+
+Many people have worked on this specification over the years.
+The following alphabetical list is incomplete, 
+please suggest missing people:
+Russ Allbery,
+Ben Finney,
+Sam Hocevar,
+Steve Langasek,
+Charles Plessy,
+Noah Slater.
+
 # File syntax
 
 The `debian/copyright` file must be machine-interpretable, yet



-- 
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.org/1283053617.2242.209.ca...@havelock

Re: Upstream guide and front desk

[Lars Wirzenius]

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 :-)

I see no reason to restrict this to DDs only. It should be a public
list, with public archives.


-- 
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.org/1283375638.14666.9.ca...@havelock

Re: DEP-5: Ack section

[Lars Wirzenius]

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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1283834942.2264.31.ca...@havelock

Re: DEP-5: Files field and filename patterns

[Lars Wirzenius]

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
> not treat the slash character specially when matching, so that
> */Makefile.in will match Makefile.in at any depth. All patterns are
> anchored to the root of the source tree; thus a plain Makefile.in will
> match only at the root of the source tree. I suggest we not add
> exclusions at this time. In a year or two, we can re-visit this part of
> the spec and see if it needs to be improved.
> 
> Is this proposal acceptable?

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 couple of days, I will push it out.
=== modified file 'dep5.mdwn'
--- dep5.mdwn	2010-08-31 21:08:28 +
+++ dep5.mdwn	2010-09-07 05:22:34 +
@@ -276,62 +276,59 @@
 Extra fields can be added to any section. Their name starts by **`X-`**.
 
 ## Fields Detail
+
 ### Files
- Format
-The **`Files`** field contains a list of comma-separated patterns
-
-	Files: foo.c, bar.*, baz.[ch]
-
-File names containing spaces or commas should be put within double
-quotes. The backslash character is an escaping character, be it inside
-or outside double quotes:
-
-	Files: "Program Files/*", manual[english].txt
-
- Syntax
-Patterns are handled as by the `find` utility's `-name` option.  Patterns
-containing a path separator ("/") are handled as by the `find` utility's
-`-path` option.
-
-The following matches all `Makefile.am` files in the tree and all
-Python scripts:
-
-	Files: */Makefile.am, *.py
-
-But this will only match the top-level `Makefile.am`:
-
-	Files: ./Makefile.am
-
-For the first example, the equivalent `find` command would be:
-
-	find . -path "*/Makefile.am" -o -name "*.py"
-
-It is quite common for a work to have files with copyright held by
-different parties and received under different licenses. To accommodate
-this, **multiple paragraphs are allowed with different `Files`
-declarations**.
-
-However it makes for easier reading if the copyright file lists the
-"main" license first: the one matching the "top level" of the work, with
-others listed as exceptions. To allow this, the following precedence
-rule applies for matching files: **If multiple `Files` declarations
-match the same file, then only the last match counts.**
-
-As a result, it is recommended for clarity that the paragraphs appear in
-order from most general (e.g. `Files: *`) first, through to most
-specific. In the following example, the file `getopt.c` matches both
-`Files: *` and `Files: getopt.*`; only the last match counts, so
-the file `getopt.c` has the license declaration `License: BSD`.
-
-	Files: *
-	Copyright: 2003-2005, John Doe 
-	License: [the main work's license]
-	 [LICENSE TEXT]
-
-	Files: getopt.*
-	Copyright: 2000, The Corporation Foundation, Inc.
-	License: BSD
-	 [LICENSE TEXT]
+
+Filename patterns in the `Files` field are specified using a
+simplified shell glob syntax. Patterns are separated by
+white space.
+
+* Only the wildcards `*` and `?` apply; the former matches any number
+  of characters (including none), the latter a single character. Both
+  match a slash ("`/`") and a leading dot.
+* The backslash ("`\\`") is used to remove the magic from the next
+  character; see table below.
+* Patterns match pathnames that start at the root of the source tree.
+  Thus, "`Makefile.in`" matches only the file at the root of the tree,
+  but "`*/Makefile.in`" matches at any depth.
+
+Backslash escape sequences:
+
+\*  match star (asterisk)
+\?  match question mark
+\\  match backslash
+
+Any other character following a backslash is an error.
+
+Multiple `Files` paragraphs are allowed. The last paragraph that
+matches a particular file applies to it.
+
+Exclusions are done by having multiple `Files` paragraphs.
+
+Example:
+
+Files: *
+Copyright: 1975-2010 Ulla Upstream
+License: GPL2+
+
+Files: debian/*
+Copyright: 2010 Daniela Debianizer
+License: GPL2+
+
+Files: debian/patches/fancy-feature
+Copyright: 2010 Daniela Debianizer
+License: GPL3+
+
+Files: */*.1
+Copyright: 2010 Manuela Manpager
+License: GPL2+
+
+In this example, all files are copyright by the upstream and licensed
+under the GPL, version 2 or later, with three exceptions. 
+All the Debian packaging files are copyright by the packager,
+and further one specific file providing a new feature is licensed
+differently. Finally, there are some manual pages added to the package,
+written by a third person.
 
 ### License
  Short name

DEP5: Editorial changes

[Lars Wirzenius]

I propose the attached patch to make some editorial changes to DEP5. A
summary of the changes is below. I believe these should be
uncontroversial and that they do not change the meaning of the spec, but
do make it easier to read and edit.

If nobody objects, I'll apply and push this in a day or two. Later
objections are OK, they just mean I will revert all or some of this.

Remove paragraph repeating information from earlier in the document.
Make all examples be indented by 4 spaces, not 8.
Rename "section" to "paragraph", for consistency.
Expand tabs to 4 spaces.
Add a link to policy.
Get rid of pointless double backquotes.
Fold sub-bullet for Copyright into main description.
Remove Copyright example.
Remove second example, as it does not add anything.
Remove 'On Debian systems'.
Simplify description of Upstream-Contact.
Simplify description of Upstream-Name.
Change 'Value:' prefix to 'Syntax:' prefix.
Remove 'Syntax:' prefix from field descriptions.
Replace multple "single occurence" with a note in the general file
syntax section.


=== modified file 'dep5.mdwn'
--- dep5.mdwn	2010-08-31 21:08:28 +
+++ 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.net/deps/dep5
-	License:
-	 Copying and distribution of this file, with or without modification,
-	 are permitted in any medium without royalty provided the copyright
-	 notice and this notice are preserved.
-	Abstract:
-	 Establish a standard, machine-readable format for debian/copyright
-	 files within packages, to facilitate automated checking and
-	 reporting of licenses for packages and sets of packages.
+Title: Machine-readable debian/copyright
+DEP: 5
+State: DRAFT
+Date: 2010-08-23
+Drivers: Steve Langasek ,
+ Lars Wirzenius 
+URL: http://dep.debian.net/deps/dep5
+License:
+ Copying and distribution of this file, with or without modification,
+ are permitted in any medium without royalty provided the copyright
+ notice and this notice are preserved.
+Abstract:
+ Establish a standard, machine-readable format for debian/copyright
+ files within packages, to facilitate automated checking and
+ reporting of licenses for packages and sets of packages.
 
 [[!toc ]]
 
@@ -113,15 +113,16 @@
 For example, `Disclaimer` has no special first line, whereas
 `License` does.
 
+Each field may occur at most once in a paragraph.
+
 # Implementation
-## Sections
-### Header Section (Once)
+## Paragraps
+### Header paragraph (Once)
 
  * **`Format`**
* Required
-   * Single occurrence
-   * Value: single line
-   * Syntax: URI of the format specification, such as:
+   * Syntax: single line
+   * URI of the format specification, such as:
  * http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=REVISION
  * Note that the unwieldy length of the URL should be solved in
future by hosting the specification at a shorter URL (including the
@@ -129,39 +130,33 @@
 
  * **`Upstream-Name`**
* Optional
-   * Single occurrence
-   * Value: single line
-   * Syntax: Single line (in most cases a single word),
- containing the name upstream uses for the software.
+   * Syntax: single line
+   * The name upstream uses for the software.
 
  * **`Upstream-Contact`**
* Optional
-   * Single occurrence
-   * Value: line based list
-   * Syntax: Line(s) containing the preferred address(es) to reach 
+   * Syntax: line based list
+   * The preferred address(es) to reach 
  the upstream project. May be free-form text, but by convention
  will usually be written as a list of RFC2822 addresses or URIs.
 
  * **`Source`**
* Optional
-   * Single occurrence
-   * Value: line based list
-   * Syntax: One or more URIs, indicating the primary
+   * Syntax: line based list
+   * One or more URIs, indicating the primary
  points of distribution of the software.
 
  * **`Disclaimer`**
* Optional
-   * Single occurrence
-   * Value: formatted text, no synopsis
-   * Syntax: On Debian systems, this field can be
+   * Syntax: formatted text, no synopsis
+   * This field can be
  used in the case of non-free and contrib packages (see [Policy
  12.5](
  http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile))
 
  * **`Comment`**
* Optional
-   * Single occurrence per paragraph, can occur in each paragraph.
-   * Value: formatted text, no synopsis
+   * Syntax: formatted text, no synopsis
* Description: This field can provide additional information. For
  example, it might quote an e-mail from upstream
  justifying why the license is acceptable to the main archive, or
@@ -169,19 +164,14 @@
  from a version known to

Re: DEP-5: Ack section

[Lars Wirzenius]

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.org/1283921454.12945.10.ca...@havelock

Re: DEP-5: Files field and filename patterns

[Lars Wirzenius]

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 couple of days, I will push it out.

That took more than a couple of days, but I've now merged the changes
and pushed them out to the bzr trunk.



-- 
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.org/1284385633.2308.36.ca...@havelock

DEP5: Making "Files: *" non-optional

[Lars Wirzenius]

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 specified in this paragraph.  See "File patterns" below.

Does anyone oppose if I remove the "If omitted..." sentence? I see no
reason to make the format unnecessarily complicated by having it
optional. In other words, I propose to make the "Files:" field mandatory
in all paragraphs except the first (header) one, where it is not allowed
at all.


-- 
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.org/1284386027.2308.39.ca...@havelock

DEP5: X-Autobuild

[Lars Wirzenius]

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
0061129152824.gt2...@mails.so.argh.org)).
It is proposed to use an extra field in the header, with name
**`X-Autobuild`**, that would contain `yes` in the first line and the
explanation in the others.

Is this a good way of doing that? The referred-to e-mail says that an
XS-Autobuild header in the debian/control (not copyright) file is
required. Is there a need for a particular header for this in
debian/copyright? Would not the Disclaimer field be sufficient?

I propose to remove the entire paragraph. If the consensus is against
that, I propose we rename the field to Non-Free-Autobuild instead of
using an X- prefix.

Opinions?


-- 
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.org/1284386312.2308.44.ca...@havelock

DEP5: non-DFSG repackaging documentation

[Lars Wirzenius]

>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-dfsg-free
material was worth it or not, the case where a source tarball contains
non-distributable material still must be dealt with. A field to express
what was done would thus fit well with this recommendation. Further
discussion as to whether it should/could be a find -delete command, a
"see README.Debian-source" comment or some simple description of what
was done (e.g. "copy of rfc removed") is sensible. What was done as well
as why it was done should probably be included.

My opinions:

- if the transformation can be expressed as a script, use "debian/rules
get-orig-source"
- otherwise, debian/README.Source seems like a better place to document
this than debian/copyright, since it has other instructions for creating
the source package, too

Thus I would prefer it if DEP5 was silent on this, and Dev-ref would be
changed to point to get-orig-source and README.Source instead.

Opinions?


-- 
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.org/1284386580.2308.48.ca...@havelock

Re: DEP-5: Files field and filename patterns

[Lars Wirzenius]

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 bzr experts,
> 
> I do not know what happened, but the dep bzr repository is not visible
> anymore through the loggerhead web interface :(
> 
> http://bzr.debian.org/loggerhead/dep/dep5/trunk/files (now broken)
> http://bzr.debian.org/loggerhead/ (no dep)

I have no idea what happened. Please report this to the bzr.debian.org
admins.


-- 
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.org/1284397007.2308.50.ca...@havelock

Re: DEP5: non-DFSG repackaging documentation

[Lars Wirzenius]

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 part of the source
package.

> Currently I maintain 2 lists of stripped files: in debian/copyright 
> (where the - most often legal - reason is needed) and debian/rules (for 
> use by the get-orig-source rule).  Moving the information to 
> debian/README.source would loose the ability to use it in scripts.

Like I said, if it is scripted, I believe it belongs in debian/rules,
and only there. If it isn't scripted. README.source seems to me to be
ideal.

If we do put the stripping information into debian/copyright, can
someone please suggest a concrete way to actually do that? What is
actually needed to implement the stripping automatically in
get-orig-source?


-- 
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.org/1284397512.2308.55.ca...@havelock

Re: DEP5: Making "Files: *" non-optional

[Lars Wirzenius]

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 be an untruth. (Or are we expanding the requirements
>  for copyright files to map copyright notices to files in the source
>  package?) 

There is a consensus, as far as I can see, to allow the first (header)
paragraph to have Copyright and License fields that will apply to the
package as a whole, rather than to each file. This is an upcoming change
that is in the pipeline (but I don't want to make all changes at once).

> I would suggest that a missing files: field in the headers
>  implies that no statement is being made about which files the copyright
>  notice applies to, instead f  implying it applies to all files.

On the other hand, this means a paragraph where the Files field is
missing by mistake will be interpreted wrongly. I find putting the
information in the header paragraph to be cleaner, but I admit it is a
subtle point. It's better to be explicit when possible, to allow errors
to be noticed easier.


-- 
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.org/1284397783.2308.58.ca...@havelock

Re: DEP5: non-DFSG repackaging documentation

[Lars Wirzenius]

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/copyright,
not policy. In that case, I need to change my opinion. I would still
like to avoid a whole mini-language in debian/copyright for documenting
the transformation. A free-form text (perhaps in Disclaimer?) should
suffice, I guess.



-- 
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.org/1284465211.2573.42.ca...@havelock

Re: DEP5: non-DFSG repackaging documentation

[Lars Wirzenius]

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 the exception that I'd rather not have the
list in debian/copyright. More importantly, though, I suspect it may be
the wrong time to specify this in DEP5, and it would be better to finish
DEP5 first, and then, when someone writes the tool, to amend DEP5
accordingly, when there's enough experience to see that the tool works
well in the majority of cases.



-- 
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.org/1284465448.2573.45.ca...@havelock

Re: DEP5: non-DFSG repackaging documentation

[Lars Wirzenius]

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 that the form as redistributed by Debian is
> > different from how it was distributed by upstream.
> 
> > With this I mean that it should *both* cover cases of repackaging a
> > tarball *and* generating a tarball from e.g. a checkout from an upstream
> > VCS.
> 
> > Suggested filed name:
> 
> >  Source-Repackaged-Reason:
> 
> We already have a field for this purpose, namely Source.  The only reason
> why we can't use it is because it's currently only allowed to contain
> URLs.  So what about, instead, broadening the syntax of Source to say that
> it contains *either* a space-separated list of URLs for the simple case of
> reusing an upstream release tarball available from some URL *or* freeform
> text describing where the source came from.
> 
> I don't think it's horribly important that the URLs in Source be
> machine-extractable, since that purpose is already served well by
> debian/watch.  The field is primarily meant for humans anyway.

Good point about debian/watch.

The simplest proposal right now is to make the Source field free-form
text, and since I like simplicity, I support this. More detailed
specification for documenting mechanical rules of transformations could
wait until there's real experience of using this spec in the real world
for this.

Anyone opposed?


-- 
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.org/1284540328.2573.65.ca...@havelock

Debian training and code review

[Lars Wirzenius]

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 longstanding ones, having something like
> T&S drop away entirely will be near death. Whoever thinks "it cant be
> that bad" should do a month of release team, qa or ftpteam work. You
> will think different.

This reminds me: it would be good to improve not just the quality of our
packages, but our developers.

Developing a Linux distribution involves a lot of skills, and stuff
keeps changing all the time. It would perhaps be a good idea to have
training sessions within Debian.

At the moment, pretty much all training is handled by each developer
themselves: they read documentation, or source, and experiment with
things. They might write some blog posts, or mail a list, or something.
This often works, but I'm sure we can do better.

Ubuntu has "developer weeks", where various people give hour-long IRC
training sessions on various topics. We could join them, or have our
own. Or we could have ad-hoc training sessions, like Debian-Women has
done, and and is starting to do again.

In addition to training, some collaborative code review might be
helpful. debian-mentors is one good place for that, and asking on IRC on
#debian-devel would work too.

What do others think?


-- 
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.org/1284541176.2573.77.ca...@havelock