Please review the copyright file of bwa.

[Charles Plessy-12]

user debian-legal@...
usetags 548719 copyright-review-requested
thanks

Dear all,

in order to lower our rejection rate from the new queue, I propose to do more
systematically peer-review of Debian copyright files before the upload of new
packages. I proposed a method in the following URL:

http://wiki.debian.org/CopyrightReview

For your convenience, I have uploaded the new “bwa” packages on
mentors.debian.net. But of course, its debian directory is also in our
repository.

http://mentors.debian.net/debian/pool/main/b/bwa
svn://svn.debian.org/svn/debian-med/trunk/packages/bwa/trunk/

Could anybody have a look at its Debian copyright file? In exchange, I will
review dicomscope.

Have a nice day,

--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille-5]

On Wed, Oct 07, 2009 at 02:20:13PM +0900, Charles Plessy wrote:
> Could anybody have a look at its Debian copyright file? In exchange, I will
> review dicomscope.

I had a look and do not have any additions regarding the content.
However I'm curious about the formatting.  If the copyright information
should be expressed in RFC822 format you need to connect the paragraphs
by a line conteining "^ .$" to make sure it will be machine parseable.

Further comment:  If you replace your rules file content by

%:
        dh $@

You can spare the cdbs build dependency.

Kind regards

      Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Plessy-12]

Le Wed, Oct 07, 2009 at 08:39:25AM +0200, Andreas Tille a écrit :

>
> I had a look and do not have any additions regarding the content.
> However I'm curious about the formatting.  If the copyright information
> should be expressed in RFC822 format you need to connect the paragraphs
> by a line conteining "^ .$" to make sure it will be machine parseable.
>
> Further comment:  If you replace your rules file content by
>
> %:
> dh $@
>
> You can spare the cdbs build dependency.

Hi Andreas,

thank you for the review.

While working on the machine-readable format for Debian copyright files, I
realised that there are several good reasons to not use the same format as for
Debian control files (which actually does not comply with RFC822). In
particular, it does not allow free-form comments, and is much more compact than
the ‘human-readable’ template from the dh-make package. Also, in my experience,
adding the inter-paragraph dots is boring and error-prone, which makes the
format quite unfriendly.

In the experimental format I use for my packages and would like to propose for
DEP-5, the syntax is simplified:

 - Fields are composed of a name and a body, separated by a colon and optional
   spaces. Field bodies are ended by line terminators.

 - A field name is composed of printable characters, except colons.

 - The field body is composed of any character. Leading spaces of the body are
   ignored. To avoid problems with multi-line values, any line terminator must
   be escaped by following it with a space. The line that contains that space is
   called a continuation line.

 - Lines that are not continuation lines and do not start a new field are plain
   comments.

 - Fields are grouped in paragraphs that are separated by empty lines. The
   paragraphs are organised in a sequential order. Within a paragraph, the
   fields are not ordered. If the same field appears more than once in the same
   paragraph, their contents are added.

(http://git.debian.org/?p=users/plessy/license-summary.git;a=blob_plain;f=dep5.mdwn)

It is similar in principle to the Posfix configuration file syntax, except that
newlines are preserved and colons replace the equal signs:

http://www.postfix.org/postconf.5.html

Translated in Perl, it would give:

 - If a line matches /^(\w+)\s*:\s*(.*)$/, it starts a new field of name $1 and
   content $2 in the Perl language. If there is already such a field in the
   current paragraph (stanza), the contents are added.

 - If a line matches /^\s(.*)$/, it extends the current field with $1\n.
   Otherwise, it is a free-form comment.

 - If a line matches /^$/, it finishes the current paragraph.

 - All other lines are free-form comments.

I have not yet tried the above regular expressions yet… Also, in theory other
approaches could be used, such as “slurping” the whole file, escaping the
newlines followed by spaces, splitting it into an array and collapsing this
array into an array of hashes (which Debian control files are).

I think that the chances I propose make the machine-readable Debian copyright
files much more human-readable. See for another example libbio-scf-perl:

http://packages.debian.org/changelogs/pool/main/libb/libbio-scf-perl/current/copyright

About your other question: I tend to chose CDBS when I forsee that compilation
flags may have to be tuned, because it is more straightforward to do so with
CDBS in my opinion. In other cases (in particular Perl modules), I use dh 7.

I will upload bwa and review dicomscope soon.

Have a nice day,

--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille-5]

On Thu, Oct 08, 2009 at 02:02:43PM +0900, Charles Plessy wrote:
> While working on the machine-readable format for Debian copyright files, I
> realised that there are several good reasons to not use the same format as for
> Debian control files (which actually does not comply with RFC822).

What exactly are the reasons that it is not RFC822 compliant?  I did not
dived into this into very detail, but I'm curious because we are using
this format in the tasks files and I'm using a Python RFC822 library to
parse them.

> I think that the chances I propose make the machine-readable Debian copyright
> files much more human-readable. See for another example libbio-scf-perl:

OK.  Sounds reasonable.  I'm watching your efforts from a distant ...
 
> About your other question: I tend to chose CDBS when I forsee that compilation
> flags may have to be tuned, because it is more straightforward to do so with
> CDBS in my opinion.

OK.  Feel free to choose whatever you like more.

Kind regards

     Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Plessy-12]

Le Thu, Oct 08, 2009 at 07:32:47AM +0200, Andreas Tille a écrit :
> On Thu, Oct 08, 2009 at 02:02:43PM +0900, Charles Plessy wrote:
> > While working on the machine-readable format for Debian copyright files, I
> > realised that there are several good reasons to not use the same format as for
> > Debian control files (which actually does not comply with RFC822).
>
> What exactly are the reasons that it is not RFC822 compliant?  I did not
> dived into this into very detail, but I'm curious because we are using
> this format in the tasks files and I'm using a Python RFC822 library to
> parse them.

RFC822 specifies newlines as CR/LF, while in Debian control files we use only
LF. Also, in RFC822 all fields are foldable, while in Debian control files they
are not unless specified otherwise. Lastly, not all features of RFC822 are
accepted in Debian control files, and some conventions of Debian control files
are absent of RFC822, like the preeminence of the first line in some field
bodies, the concept of stanza and the special role for the first of them, and
the use of lines containing only spaces to end the machine-readable section.
All in all, I think that alhtough many RFC822 parsers work, we can not explain
to a newcommer what Debian control files are by just pointing them at the
RFC822.

Cheers,

--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...