Seeking a little advice as to completeness:

Updated bug from RFP to ITP
Set changelog to close bug
Updated rules to exclude 'inc' directory during build
Updated control to include:
- libmodule-install
- debhelper 13
- add missing description - taken from POD in Module::FITeque.pm
Updated copyright file:
- copyright only yielded one year 2007
- add missing 'inc/Module' copyright
- add BSD-3-Clause based on content of LICENSE file
- set the 'debian/*' as BSD-3-Clause rather than Artistic, and retained Artistic licence clause for the 'inc/Module'

Questions:

1. Given only one year being found, do I need to email the developer to
obtain more information on copyright years, or leave as 2007, or include
the Berne Convention?

2. The LICENSE file contained the BSD-3-Clause licence without explicitly stating it, and the README indicated BSD, with an online search confirming
the actual licence text included matched.
Does this suffice, or do I need to advise the developer to include the
licence name in the licence file?

Also, at the completion of 'dh-make-perl', an information message in the copyright file indicates: 'License: unparsable',
Does 'dh-make-perl' look for licence by name or text, and ergo would this constitute a reason bug to log that the licence was not recognised?

3, The original source does not contain any 'META.[json|yml] files, which
was reported as an error during the 'dh-make-perl' execution.
Are these files mandatory?

4. Did I miss anything?

Thanks in advance for any responses
--
Ken Ibbotson
E: [email protected]

*"Reality is merely an illusion, albeit a very persistent one."*
- Albert Einstein (1879-1955)

<div dir="ltr"><div>Seeking a little advice as to completeness:</div><div><br></div><div>Updated bug from RFP to ITP</div><div>Set changelog to close bug</div><div>Updated rules to exclude &#39;inc&#39; directory during build</div><div>Updated control to
include:</div><div>- libmodule-install</div><div>- debhelper 13</div><div>- add missing description - taken from POD in Module::FITeque.pm<br></div><div>Updated copyright file:</div><div>- copyright only yielded one year 2007<br></div><div>- add missing &
#39;inc/Module&#39; copyright</div><div>- add BSD-3-Clause based on content of LICENSE file</div><div>- set the &#39;debian/*&#39; as BSD-3-Clause rather than Artistic, and retained Artistic  licence clause for the &#39;inc/Module&#39;<br></div><div><br>
</div><div>Questions:</div><div><br></div><div>1. Given only one year being found, do I need to email the developer to obtain more information on copyright years, or leave as 2007, or include the Berne Convention?<br></div><div><br></div><div>2. The
LICENSE file contained the BSD-3-Clause licence without explicitly stating it, and the README indicated BSD, with an online search confirming the actual licence text included matched.</div><div>Does this suffice, or do I need to advise the developer to
include the licence name in the licence file?</div><div><br></div><div>Also, at the completion of &#39;dh-make-perl&#39;, an information message in the copyright file indicates: &#39;License: unparsable&#39;,</div><div>Does &#39;dh-make-perl&#39; look
for licence by name or text, and ergo would this constitute a reason bug to log that the licence was not recognised?<br></div><div><br></div><div>3, The original source does not contain any &#39;META.[json|yml] files, which was reported as an error
during the &#39;dh-make-perl&#39; execution.</div><div>Are these files mandatory?<br></div><div><br></div><div>4. Did I miss anything?</div><div><br></div><div>Thanks in advance for any responses<br></div><div><div><div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature"><div dir="ltr"><div><div>--<br>Ken Ibbotson</div>E: <a href="mailto:[email protected]" target="_blank">[email protected]</a><br><div><br></div><div><i>&quot;Reality is merely an illusion, albeit a very persistent one.&
quot;</i></div>    - Albert Einstein (1879-1955)<br></div></div></div></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting Ken Ibbotson (2020-10-24 03:47:31)

Also, at the completion of 'dh-make-perl', an information message in
the copyright file indicates: 'License: unparsable',
Does 'dh-make-perl' look for licence by name or text, and ergo would this constitute a reason bug to log that the licence was not recognised?

Speaking as author of the licensecheck tool, I would find it helpful to
have a bugreport filed against licensecheck for licensing statements unrecognized by that tool.

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============�47508247628663167=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl+VhU4ACgkQLHwxRsGg ASGOOhAArxqbcuaKbq6PU6J8C9zhgH/P8YraiDu7qqXFp23Kh85Itl5+yBVLCNcT jVbwKklophntWhC86VygR8+/inTHNT+lMHPHAFvqAoFY4YQaPMqBML7WiYjrp1FJ dRNHyYGeID+ZzKNnRuaxHQzbKq6WI4hr3IX5z454739zieGEV+mgfMqRDY5gYwAr gmvoZ04MXc5DSBKHjQ6f4MAsQvrqJRCO8FfVclrTOtZOmtc4y6Kb64G3ggEnRM0t HkWwjuIVGpgEBGDqxgpNh2NmOLf0ERKit61ffnkSZYxLJKHTODHWi6X3X55BXxuv nBWDw8uUW6aCoT6U+x3dUkLzfLPMA3Z48QU6xosYLOocXsfVNP3Of3jYypLqhhBz 1Vb1haKwB1od0ITsQPNeBQl3f6hWP45+ExMGR16GtR+RtzPj6oM//k7/BFW3dvfL 1Li3gXRcPEpVeiz28h8Tq6yp9lxniYIMVa//R1pbkZryp9L34gnUyOIrNQ0OQav1 ZrHhSMPRxWH/BoFNP

On Sat, 24 Oct 2020 12:17:31 +1030, Ken Ibbotson wrote:

Updated copyright file:
- copyright only yielded one year 2007
- add missing 'inc/Module' copyright
- add BSD-3-Clause based on content of LICENSE file
- set the 'debian/*' as BSD-3-Clause rather than Artistic, and retained Artistic licence clause for the 'inc/Module'

Questions:

1. Given only one year being found, do I need to email the developer to obtain more information on copyright years, or leave as 2007,

If upstream says "2007", we can just take this year.

or include
the Berne Convention?

The "Berne Convention assumption" is for the cases where there is an
author but no explicit copyright holder, which is not the case here.

2. The LICENSE file contained the BSD-3-Clause licence without explicitly stating it, and the README indicated BSD, with an online search confirming the actual licence text included matched.
Does this suffice, or do I need to advise the developer to include the licence name in the licence file?

I think that's fine as-is, both for upstream (they state clear license
terms), and for us (we name it "BSD-3-Clause" just to have a
convenient short name).

Also, at the completion of 'dh-make-perl', an information message in the copyright file indicates: 'License: unparsable',
Does 'dh-make-perl' look for licence by name or text, and ergo would this constitute a reason bug to log that the licence was not recognised?

It tries all kinds of things :)
And that usually works but fails in the rare corner case.

3, The original source does not contain any 'META.[json|yml] files, which
was reported as an error during the 'dh-make-perl' execution.
Are these files mandatory?

No, their absence is just a sign of a distribution which doesn't use
typical modern tools.

4. Did I miss anything?

Just some nit-picking observations:

- d/rules has a trailing \t
- d/copyright:
* as per the above notes, '-<INSERT COPYRIGHT YEAR(S) HERE>' can be
removed
* the upstream email address could be de-mangled (in two spots)
* you use "License: BSD-3-Clause" as a license for "debian/*";
that's fine if this is your preference; typically we use upstream
license + perl license, i.e. ""License: BSD-3-Clause or Artistic or GPL-1+" - d/control: you can add "Rules-Requires-Root: no" to the source
section

Less ideal is that the package doesn't build in a cowbuilder chroot:

Can't locate Test/Exception.pm in @INC (you may need to install the Test::Exception module) (@INC contains: t/lib /build/libtest-fitesque-perl-0.04/inc /build/libtest-fitesque-perl-0.04/blib/lib /build/libtest-fitesque-perl-0.04/blib/arch /etc/perl /usr/
local/lib/x86_64-linux-gnu/perl/5.30.3 /usr/local/share/perl/5.30.3 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl) at t/01-
fixture.t line 8.

add "libtest-exception-perl <!nocheck>" to Build-Depends-Indep

Then it still fails with:

# Failed test 'use Test::FITesque::Fixture;'
# at t/01-fixture.t line 10.
# Tried to use 'Test::FITesque::Fixture'.
# Error: Base class package "Class::Data::Inheritable" is empty.
# (Perhaps you need to 'use' the module which defines that package first,
# or make that module available in @INC (@INC contains: t/lib /build/libtest-fitesque-perl-0.04/inc /build/libtest-fitesque-perl-0.04/blib/lib /build/libtest-fitesque-perl-0.04/blib/arch /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.3 /usr/
local/share/perl/5.30.3 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl).
# at /build/libtest-fitesque-perl-0.04/blib/lib/Test/FITesque/Fixture.pm line 7.
# BEGIN failed--compilation aborted at /build/libtest-fitesque-perl-0.04/blib/lib/Test/FITesque/Fixture.pm line 7.
# Compilation failed in require at t/01-fixture.t line 10.
# BEGIN failed--compilation aborted at t/01-fixture.t line 10.

add "libclass-data-inheritable-perl <!nocheck>" to Build-Depends-Indep

and "libclass-data-inheritable-perl" to Depends

(both can be found in Makefile.PL but as that's a Module::Install
wrapper, dh-make-perl fails at parsing, and there's no
META.{yml,json} either, as we already noted :))

lintian has some remarks, e.g.:
I: libtest-fitesque-perl: spelling-error-in-description unnessecary unnecessary

that's in debian/control and easily fixed

I: libtest-fitesque-perl: typo-in-manual-page usr/share/man/man3/Test::FITesque.3pm.gz compatability compatibility
and some others
optionally create a patch to fix all the typos and send it
upstream

W: libtest-fitesque-perl source: team/pkg-perl/testsuite/autopkgtest-needs-use-name
pkg-perl-autopkgtest's use.t wants to know the name of the (main)
module, and again, we have no META.{yml,json} :) so:
% mkdir -p debian/tests/pkg-perl
% echo Test::FITesque > debian/tests/pkg-perl/use-name


As a summary: you happened to pick a rare cornercase of an a-typical distribution here, usually it's much quicker to create a new package :)


Cheers,
gregor

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Cat Power: Could We

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl+VfgdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qgY/kw/+NgceOzYDoe3G9x28BQzpv6H6FJRt65n3sQa7JeHLzpCdmZ73ahmF3X2j b6Zmm4mNSCPTlFHTYC1tAiA6paQfoykjIq6LztCgCj0/Y7BdeOLEZiiThCjSkF20 tfjPCFPyNxqSwE4xxYmIp2+u4m52QLnzv5a3SkKi+hMSpY5KKGdcTu0H4yHNaQlR xCn44JE6F+dUvfFjwR/D1qkuEIyj+BL1WssU2SPyULDcL5AoIdX66MSzWMSoDnrQ gHH36k5HUvSo7TWm5S9SNuBlgulvrFoYEEUUqUCTdS9OF8HsNWftRR4qb2g6Y4Tx g87CnwPDeKlXc0FcpyLnhXXO5N1vgiwaTp7CbFLLMUMtrFKxVlQgAPipQL7W90ik 4y8dzVnxVvudgNtyeoqu74zfyjtE+rZS+64FGTNaV2eXk44e02QvTjTTx9sBRJmX 7QcsBy74sdjD+nZuoM+Mr72A6vCOJQ8kJTxjuFqnYyBC6V2lE9olWL0GqT0rEI53 YrRoO+/YKu7Jqg37TOCHMcCchb0zbpYuSF2jiOtSdAYxXcbFoWIitfOr0IncGbFo uZxdgqRZ1s0tu0E4bq5H9j4SRdpeQ649C6n24PeguwpddDhC2/6N54NRFi347phb zJEKDM9DZN5o7a28zoEk6olO3Q5F+y86OdWcR/kg1Iydug6ue6w=
=zSpN
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Had a chance to revisit this package, and the new run against the licence
file worked correctly.

licensecheck ./LICENSE
./LICENSE: BSD 3-clause "New" or "Revised" License

So I will not be raising a bug at this time.
--
Ken Ibbotson
E: [email protected]

*"Reality is merely an illusion, albeit a very persistent one."*
- Albert Einstein (1879-1955)


On Mon, 26 Oct 2020 at 00:32, Jonas Smedegaard <[email protected]> wrote:

Quoting Ken Ibbotson (2020-10-24 03:47:31)

Also, at the completion of 'dh-make-perl', an information message in
the copyright file indicates: 'License: unparsable',
Does 'dh-make-perl' look for licence by name or text, and ergo would this constitute a reason bug to log that the licence was not recognised?

Speaking as author of the licensecheck tool, I would find it helpful to
have a bugreport filed against licensecheck for licensing statements unrecognized by that tool.

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private

<div dir="ltr"><div>Had a chance to revisit this package, and the new run against the licence file worked correctly.</div><div><br></div><div style="margin-left:40px">licensecheck ./LICENSE<br>./LICENSE: BSD 3-clause &quot;New&quot; or &quot;Revised&quot;
License<br></div><div><br></div><div>So I will not be raising a bug at this time.<br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div>--<br>Ken Ibbotson</div>E: <a href="mailto:keni@
computer.org" target="_blank">[email protected]</a><br><div><br></div><div><i>&quot;Reality is merely an illusion, albeit a very persistent one.&quot;</i></div>    - Albert Einstein (1879-1955)<br></div></div></div></div><br></div></div><br><div class=
"gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 26 Oct 2020 at 00:32, Jonas Smedegaard &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px
solid rgb(204,204,204);padding-left:1ex">Quoting Ken Ibbotson (2020-10-24 03:47:31)<br>
&gt; Also, at the completion of &#39;dh-make-perl&#39;, an information message in <br>
&gt; the copyright file indicates: &#39;License: unparsable&#39;,<br>
&gt; Does &#39;dh-make-perl&#39; look for licence by name or text, and ergo would this<br>
&gt; constitute a reason bug to log that the licence was not recognised?<br>

Speaking as author of the licensecheck tool, I would find it helpful to <br> have a bugreport filed against licensecheck for licensing statements <br> unrecognized by that tool.<br>

 - Jonas<br>

-- <br>
 * Jonas Smedegaard - idealist &amp; Internet-arkitekt<br>
 * Tlf.: +45 40843136  Website: <a href="http://dr.jones.dk/" rel="noreferrer" target="_blank">http://dr.jones.dk/</a><br>

 [x] quote me freely  [ ] ask before reusing  [ ] keep private</blockquote></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks Gregor for all the assistance.

Yes, I seem to have chosen a couple of good packages to adopt :)

To be fair, it has given me a baptism of fire, but in the same vane, some valuable experience in the things that can happen and how to approach fixes
of the same.

As a bit of feedback on your comments, I was able to build the package and
test it using the included Makefile.PL

I have made spelling corrections, and am in the process of building a patch
to pass upstream.
--
Ken Ibbotson
E: [email protected]

*"Reality is merely an illusion, albeit a very persistent one."*
- Albert Einstein (1879-1955)


On Mon, 26 Oct 2020 at 00:01, gregor herrmann <[email protected]> wrote:

On Sat, 24 Oct 2020 12:17:31 +1030, Ken Ibbotson wrote:

Updated copyright file:
- copyright only yielded one year 2007
- add missing 'inc/Module' copyright
- add BSD-3-Clause based on content of LICENSE file
- set the 'debian/*' as BSD-3-Clause rather than Artistic, and retained Artistic licence clause for the 'inc/Module'

Questions:

1. Given only one year being found, do I need to email the developer to obtain more information on copyright years, or leave as 2007,

If upstream says "2007", we can just take this year.

or include
the Berne Convention?

The "Berne Convention assumption" is for the cases where there is an
author but no explicit copyright holder, which is not the case here.

2. The LICENSE file contained the BSD-3-Clause licence without explicitly stating it, and the README indicated BSD, with an online search

confirming

the actual licence text included matched.
Does this suffice, or do I need to advise the developer to include the licence name in the licence file?

I think that's fine as-is, both for upstream (they state clear license terms), and for us (we name it "BSD-3-Clause" just to have a
convenient short name).

Also, at the completion of 'dh-make-perl', an information message in the copyright file indicates: 'License: unparsable',
Does 'dh-make-perl' look for licence by name or text, and ergo would this constitute a reason bug to log that the licence was not recognised?

It tries all kinds of things :)
And that usually works but fails in the rare corner case.

3, The original source does not contain any 'META.[json|yml] files, which was reported as an error during the 'dh-make-perl' execution.
Are these files mandatory?

No, their absence is just a sign of a distribution which doesn't use
typical modern tools.

4. Did I miss anything?

Just some nit-picking observations:

- d/rules has a trailing \t
- d/copyright:
* as per the above notes, '-<INSERT COPYRIGHT YEAR(S) HERE>' can be
removed
* the upstream email address could be de-mangled (in two spots)
* you use "License: BSD-3-Clause" as a license for "debian/*";
that's fine if this is your preference; typically we use upstream
license + perl license, i.e. ""License: BSD-3-Clause or Artistic or GPL-1+"
- d/control: you can add "Rules-Requires-Root: no" to the source
section

Less ideal is that the package doesn't build in a cowbuilder chroot:

Can't locate Test/Exception.pm in @INC (you may need to install the Test::Exception module) (@INC contains: t/lib /build/libtest-fitesque-perl-0.04/inc /build/libtest-fitesque-perl-0.04/blib/lib /build/libtest-fitesque-perl-0.04/blib/arch /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.3 /usr/local/share/perl/5.30.3 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl) at t/01-fixture.t line 8.

add "libtest-exception-perl <!nocheck>" to Build-Depends-Indep

Then it still fails with:

# Failed test 'use Test::FITesque::Fixture;'
# at t/01-fixture.t line 10.
# Tried to use 'Test::FITesque::Fixture'.
# Error: Base class package "Class::Data::Inheritable" is empty.
# (Perhaps you need to 'use' the module which defines that package
first,
# or make that module available in @INC (@INC contains: t/lib /build/libtest-fitesque-perl-0.04/inc /build/libtest-fitesque-perl-0.04/blib/lib /build/libtest-fitesque-perl-0.04/blib/arch /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.3 /usr/local/share/perl/5.30.3 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl).
# at /build/libtest-fitesque-perl-0.04/blib/lib/Test/FITesque/Fixture.pm line 7.
# BEGIN failed--compilation aborted at /build/libtest-fitesque-perl-0.04/blib/lib/Test/FITesque/Fixture.pm line 7.
# Compilation failed in require at t/01-fixture.t line 10.
# BEGIN failed--compilation aborted at t/01-fixture.t line 10.

add "libclass-data-inheritable-perl <!nocheck>" to Build-Depends-Indep

and "libclass-data-inheritable-perl" to Depends

(both can be found in Makefile.PL but as that's a Module::Install
wrapper, dh-make-perl fails at parsing, and there's no
META.{yml,json} either, as we already noted :))

lintian has some remarks, e.g.:
I: libtest-fitesque-perl: spelling-error-in-description unnessecary unnecessary

that's in debian/control and easily fixed

I: libtest-fitesque-perl: typo-in-manual-page usr/share/man/man3/Test::FITesque.3pm.gz compatability compatibility
and some others
optionally create a patch to fix all the typos and send it
upstream

W: libtest-fitesque-perl source: team/pkg-perl/testsuite/autopkgtest-needs-use-name
pkg-perl-autopkgtest's use.t wants to know the name of the (main)
module, and again, we have no META.{yml,json} :) so:
% mkdir -p debian/tests/pkg-perl
% echo Test::FITesque > debian/tests/pkg-perl/use-name

As a summary: you happened to pick a rare cornercase of an a-typical distribution here, usually it's much quicker to create a new package :)

Cheers,
gregor

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Cat Power: Could We

<div dir="ltr"><div>Thanks Gregor for all the assistance.</div><div><br></div><div>Yes, I seem to have chosen a couple of good packages to adopt :)</div><div><br></div><div>To be fair, it has given me a baptism of fire, but in the same vane, some
valuable experience in the things that can happen and how to approach fixes of the same.</div><div><br></div><div>As a bit of feedback on your comments, I was able to build the package and test it using the included Makefile.PL</div><br><div>I have made
spelling corrections, and am in the process of building a patch to pass upstream.<br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div>--<br>Ken Ibbotson</div>E: <a href="mailto:keni@computer.
org" target="_blank">[email protected]</a><br><div><br></div><div><i>&quot;Reality is merely an illusion, albeit a very persistent one.&quot;</i></div>    - Albert Einstein (1879-1955)<br></div></div></div></div><br></div></div><br><div class="gmail_
quote"><div dir="ltr" class="gmail_attr">On Mon, 26 Oct 2020 at 00:01, gregor herrmann &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">On Sat, 24 Oct 2020 12:17:31 +1030, Ken Ibbotson wrote:<br>

&gt; Updated copyright file:<br>
&gt; - copyright only yielded one year 2007<br>
&gt; - add missing &#39;inc/Module&#39; copyright<br>
&gt; - add BSD-3-Clause based on content of LICENSE file<br>
&gt; - set the &#39;debian/*&#39; as BSD-3-Clause rather than Artistic, and retained<br>
&gt; Artistic  licence clause for the &#39;inc/Module&#39;<br>
&gt; <br>
&gt; Questions:<br>
&gt; <br>
&gt; 1. Given only one year being found, do I need to email the developer to<br>
&gt; obtain more information on copyright years, or leave as 2007, <br>

If upstream says &quot;2007&quot;, we can just take this year.<br>

&gt; or include<br>
&gt; the Berne Convention?<br>

The &quot;Berne Convention assumption&quot; is for the cases where there is an<br>
author but no explicit copyright holder, which is not the case here.<br>

&gt; 2. The LICENSE file contained the BSD-3-Clause licence without explicitly<br>
&gt; stating it, and the README indicated BSD, with an online search confirming<br>
&gt; the actual licence text included matched.<br>
&gt; Does this suffice, or do I need to advise the developer to include the<br> &gt; licence name in the licence file?<br>

I think that&#39;s fine as-is, both for upstream (they state clear license<br> terms), and for us (we name it &quot;BSD-3-Clause&quot; just to have a<br> convenient short name).<br>

&gt; Also, at the completion of &#39;dh-make-perl&#39;, an information message in the<br>
&gt; copyright file indicates: &#39;License: unparsable&#39;,<br>
&gt; Does &#39;dh-make-perl&#39; look for licence by name or text, and ergo would this<br>
&gt; constitute a reason bug to log that the licence was not recognised?<br>

It tries all kinds of things :)<br>
And that usually works but fails in the rare corner case.<br>

&gt; 3, The original source does not contain any &#39;META.[json|yml] files, which<br>
&gt; was reported as an error during the &#39;dh-make-perl&#39; execution.<br> &gt; Are these files mandatory?<br>

No, their absence is just a sign of a distribution which doesn&#39;t use<br> typical modern tools.<br>

&gt; 4. Did I miss anything?<br>

Just some nit-picking observations:<br>

- d/rules has a trailing \t<br>
- d/copyright:<br>
  * as per the above notes, &#39;-&lt;INSERT COPYRIGHT YEAR(S) HERE&gt;&#39; can be<br>
    removed<br>
  * the upstream email address could be de-mangled (in two spots)<br>
  * you use &quot;License: BSD-3-Clause&quot; as a license for &quot;debian/*&quot;;<br>
    that&#39;s fine if this is your preference; typically we use upstream<br>     license + perl license, i.e. &quot;&quot;License: BSD-3-Clause or Artistic or GPL-1+&quot;<br>
- d/control: you can add &quot;Rules-Requires-Root: no&quot; to the source<br>   section<br>

Less ideal is that the package doesn&#39;t build in a cowbuilder chroot:<br>

Can&#39;t locate Test/Exception.pm in @INC (you may need to install the Test::Exception module) (@INC contains: t/lib /build/libtest-fitesque-perl-0.04/inc /build/libtest-fitesque-perl-0.04/blib/lib /build/libtest-fitesque-perl-0.04/blib/arch /etc/perl /
usr/local/lib/x86_64-linux-gnu/perl/5.30.3 /usr/local/share/perl/5.30.3 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl) at t/01-
fixture.t line 8.<br>

-&gt; add &quot;libtest-exception-perl &lt;!nocheck&gt;&quot; to Build-Depends-Indep<br>

Then it still fails with:<br>

#   Failed test &#39;use Test::FITesque::Fixture;&#39;<br>
#   at t/01-fixture.t line 10.<br>
#     Tried to use &#39;Test::FITesque::Fixture&#39;.<br>
#     Error:  Base class package &quot;Class::Data::Inheritable&quot; is empty.<br>
#     (Perhaps you need to &#39;use&#39; the module which defines that package first,<br>
#     or make that module available in @INC (@INC contains: t/lib /build/libtest-fitesque-perl-0.04/inc /build/libtest-fitesque-perl-0.04/blib/lib /build/libtest-fitesque-perl-0.04/blib/arch /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.3 /usr/
local/share/perl/5.30.3 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl).<br>
#  at /build/libtest-fitesque-perl-0.04/blib/lib/Test/FITesque/Fixture.pm line 7.<br>
# BEGIN failed--compilation aborted at /build/libtest-fitesque-perl-0.04/blib/lib/Test/FITesque/Fixture.pm line 7.<br>
# Compilation failed in require at t/01-fixture.t line 10.<br>
# BEGIN failed--compilation aborted at t/01-fixture.t line 10.<br>

--&gt; add &quot;libclass-data-inheritable-perl &lt;!nocheck&gt;&quot; to Build-Depends-Indep<br>
and &quot;libclass-data-inheritable-perl&quot; to Depends<br>

(both can be found in Makefile.PL but as that&#39;s a Module::Install<br> wrapper, dh-make-perl fails at parsing, and there&#39;s no<br>
META.{yml,json} either, as we already noted :))<br>

lintian has some remarks, e.g.:<br>
I: libtest-fitesque-perl: spelling-error-in-description unnessecary unnecessary<br>
-&gt; that&#39;s in debian/control and easily fixed<br>

I: libtest-fitesque-perl: typo-in-manual-page usr/share/man/man3/Test::FITesque.3pm.gz compatability compatibility<br>
   and some others<br>
   optionally create a patch to fix all the typos and send it<br>
   upstream<br>

W: libtest-fitesque-perl source: team/pkg-perl/testsuite/autopkgtest-needs-use-name<br>
   pkg-perl-autopkgtest&#39;s use.t wants to know the name of the (main)<br>    module, and again, we have no META.{yml,json} :) so:<br>
   % mkdir -p debian/tests/pkg-perl<br>
   % echo Test::FITesque &gt; debian/tests/pkg-perl/use-name<br>


As a summary: you happened to pick a rare cornercase of an a-typical<br> distribution here, usually it&#39;s much quicker to create a new package :)<br>


Cheers,<br>
gregor<br>

-- <br>
 .&#39;&#39;`.  <a href="https://info.comodo.priv.at" rel="noreferrer" target="_blank">https://info.comodo.priv.at</a> -- Debian Developer <a href="https://www.debian.org" rel="noreferrer" target="_blank">https://www.debian.org</a><br>
 : :&#39; : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06<br>
 `. `&#39;  Member VIBE!AT &amp; SPI Inc. -- Supporter Free Software Foundation Europe<br>
   `-   NP: Cat Power: Could We<br>
</blockquote></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting Ken Ibbotson (2020-11-05 09:09:30)

Had a chance to revisit this package, and the new run against the
licence file worked correctly.

licensecheck ./LICENSE
./LICENSE: BSD 3-clause "New" or "Revised" License

So I will not be raising a bug at this time.

Thanks for double-checking.

Licensecheck default output is not ideal for use in Debian packaging.

Here is broader overview of licence checking tools, with their suggested
use specifically with Debian packaging: https://wiki.debian.org/CopyrightReviewTools


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============q83646951181162277=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl+j33IACgkQLHwxRsGg ASHquA/+I5ZrXqKQIMHDhSh7jfmfWUfTIE+nJF8zctctj2vhBbt5vgMsZUKZAC8T C1oluJYVJg9eZs1owPf3DMF0w1Bi6kkEORD1iAgeB7rowwaVDUyS/CiCLAllJpEl LpAYUjDomXHg/7N4WHVS27Vv3QBnSdoTmvxpwh4WaEwzUkAnx133DpqxZoBO7CPd 3SEIH1QVXY4oy+gFJxxP53bsuzdhkvWas2lNsBXYPLf5pw0bdoa7dZXzVmESR/Qe 6K3QG2V7tepx+6iclPjnV4bZtDgZnxvYayzEFS2v/NXf9ihhGVbQ88XzrpAZYFO5 Jg+3uKACNE26LdhWrdFxg9hg9fw4OOlwVafyUvPofR9+rRX3zv+Po34DKPClGPCX r1o5NMyU/Aa5AimLhhF1MbecWnfkvs7a4/G02TCPy/zv7aYfch01rVXKPL818L9N kg6MKJzevWTqAWvA14Vb6Qe0i3zZC9yN065dAqMiVQFZkPspUGdPrZvL9suAQr+Z v11xrIll5Bk2W4YIZ