Andreas Tille, on 2020-04-14 09:55:34 +0200: > Hi Étienne, > > thanks a lot for your work on this package. As usual I'm CCing my > answer to the list to make sure others can learn from our discussion as > well.
Hi Andreas,
I do agree to keep the discussion transparent, no worries. ;)
Often, I want to edit the header after having sent the message.
> On Sat, Apr 11, 2020 at 08:57:06PM +0200, Étienne Mollier wrote:
> > > Finally d/copyright should be cleaned up. The Comment should be removed
> > > (if you
> > > have done what it says ;-))
> > > Moreover the typical snippet for GPL-3+ is missing. You need to provide
> > > an
> > > extra "License: GPL-3+" paragraph - you'll find lots of examples on your
> > > Debian system.
> > >
> > > Feel free to ask if you have any questions to my remarks.
> >
> > Pretty much like a lot of us here I guess, I'm half comfortable
> > with legal components, so wouldn't be against seeing this part
> > being double-checked actually. I spent some time into
> > Dpkg::Copyright::Scanner(3pm) to get the copyright in a
> > seemingly adequate shape, and tried a few rounds of `cme
> > update dpkg-copyright` to see how it behaves (as provided in
> > Sid, if that is worth mentioning) but comments lasted until I
> > remove them manually.
> >
> > You don't mind if I tried to keep the legal babbling as short as
> > seems reasonably possible ? (well, at least with regards to
> > what the cme model accepts...) I have to write down official
> > authorizations by hand to fullfill my groceries duty, since I
> > have no printer; so, I'm building up some kind of trauma...
>
> I've commited something what I consider the prefered form by our
> ftpmasters. There is this short snippet of the GPL text and the hint
> where to find it on a Debian system. The DEP5 copyright format also
> wants you to use a single License paragraph when having more than
> one Files paragraphs with the same license. I've just fixed this.
Thanks for mentioning DEP, I was not aware of their existence,
but they are interesting resources indeed:
https://dep-team.pages.debian.net/
As of formatting the license in the d/copyright file, if there
is a preferred form, then I'll stick to it. There is this
convenient mechanism to allow several entries to refer to the
same snippet; and as long as copy/paste is not broken, I won't
have to write it by hand anyway. :)
> I have a question to the files debian/copyright-scan-patterns.yml and
> debian/fill.copyright.blanks.yml. I admit I have never seen these files
> and I'm wondering for what purpose you injected these. IMHO these can
> be removed but may be I can learn something from you (which is not
> untypical that I learn from newcomers!)
Using my main personal computer, set to running Sid (maybe the
behavior changed compared to other Debian versions, I haven't
checked), here is what I see when I follow the recommendation of
the d/copyright comment, without .yml files:
$ scan-copyrights
The following files were skipped:
- debian/README.test
- debian/prinseq-lite-examples.doc-base
- debian/prinseq-lite-examples.examples
- debian/prinseq-lite.install
- debian/prinseq-lite.links
- debian/prinseq-lite.lintian-overrides
- debian/tests/run-unit-test
- example/example1.fasta
- example/example1.fastq
- example/example1.gd
- example/example1.html
- example/example_readme.txt
You may want to add a line in debian/copyright-scan-patterns.yml
or ask the author to add more default patterns to scan
The following paths are missing information:
- ChangeLog: missing copyright and license
- debian/TODO: missing copyright and license
- debian/control: missing copyright and license
- debian/manpages: missing copyright and license
- debian/rules: missing copyright and license
- debian/tests/control: missing copyright and license
- debian/upstream/metadata: missing copyright and license
- debian/watch: missing copyright and license
- prinseq-graphs-noPCA.pl: missing copyright and license
- prinseq-graphs.pl: missing copyright and license
- prinseq-lite.pl: missing copyright and license
You may want to add a line in debian/fill.copyright.blanks.yml
Files: *
Copyright: 2010-2013, Robert SCHMIEDER
License: GPL-3+
So, as I understood, those .yml files give hints to build
dynamically the d/copyright file and even update it
automatically with `cme update dpkg-copyright` as upstream
versions are going on, when this information is missing from
upstream files. I put the three lines here over as is, and
added the following manually at first:
Files: debian/*
Copyright: 2020, Étienne Mollier <[email protected]>
License: GPL-3+
After having built my initial d/copyright file, running manually
the update command led to discrepancies such as:
Copyright: 2010-2013, Étienne Mollier <[email protected]>
Which is obviously wrong, given the calendar. Ignoring the
debian/ directory in the copyright-scan-patterns.yml, and
filling the blanks helped stabilize the output, at that moment.
Redoing the same with your modifications, the `cme update
dpkg-copyright` gives a stable output with the appropriate
values. So, I'm currently under the impression that my not so
conform copyright file was leading to these discrepancies.
> I have further remark to debian/rules and the usage of the debhelper
> tools. Please inspect my single commits closely. You have re-invented
> code that is usually done by dh_install, dh_installexamples and dh_link.
> I tried to use single commits to demonstrate the changes. Please make
> sure you understand every single commit and feel free to ask gere if
> something might remain unclear.
Many thanks for your comprehensive step by step presentation of
the different changes, notably the dh_* ones! I believe that I
only begin to get an idea of what are, and how to use Debian
helpers. It looks like I will have a few readings for the next
few days:
$ apropos dh_ | wc -l
84
I see several interesting entries there, for cron, pam, etc.
It is nice to see all this automated.
> I'd consider the package ready for upload once you clarified whether
> the debian/*.yml files are needed or not.
As I mentioned, after redoing a few runs `cme update
dpkg-copyright` with the current d/copyright file and without
.yml files, I see d/copyright remains stable with the proper
information. I'm thus currently under the impression that they
are not strictly needed, although scan-copyright may continue to
suggest changing the scan patterns and filling the blanks.
Since setting them inappropriately may skew the analysis from
scan-copyright, I would currently tend to prefer seeing them
removed as well.
> Thanks a lot for your contribution
You're welcome,
Kind Regards, :)
--
Étienne Mollier <[email protected]>
Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 ! Give CPU cycles:
* Rosetta@home: https://boinc.bakerlab.org/rosetta/
* Folding@home: https://foldingathome.org/
PS: seeing commit 56adeed480f090c0c21c5bee2e31e13c17102466 by
the way, good catch! But I'm at loss understanding how the
`install` command could have possibly ever worked...
signature.asc
Description: PGP signature
