Hi Étienne, On Tue, Apr 14, 2020 at 10:30:03PM +0200, Étienne Mollier wrote: > > I do agree to keep the discussion transparent, no worries. ;) > Often, I want to edit the header after having sent the message.
Fine. In future I'll answer to debian-med list *only* as per list policy. Please drop me a note if you are not subscribed and would prefer to be CCed. > > On Sat, Apr 11, 2020 at 08:57:06PM +0200, Étienne Mollier wrote: > > 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. :) While the DEPs are interesting in general, the actual link to the DEP5 copyright format is the first line inside the d/copyright file. You can always use it as reference. BTW, also running lintian after building the package is strongly advised - it usually tells you about issues in your copyright. > > 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 <etienne.moll...@mailoo.org> > 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 <etienne.moll...@mailoo.org> > > 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. Thanks for the verbose information. As expected I really learned something. Thanks a lot - I was not using this feaure before! :-) So I simply leave those files as an example. > 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 admit I personally never had any practical use for cron, pam and other nifty things which is basically due to the nature of the packages I'm working on. But you are right, there is a lot of clever stuff and I'm happy to have you pointed to this. > > 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. I tend to disagree. :-P After your verbose explanation I'll leave these specifically as an example. I do not think that they are needed very much in this rather simple package but they do not harm at all and serve a perfect purpose as examples. So thanks again for this nice example that I'm always learning from newbies. :-) > > Thanks a lot for your contribution > > You're welcome, :-) I've just uploaded prinseq-lite to new. Kind regards and welcome in the Debian Med team Andreas. -- http://fam-tille.de