• libtest-fitesque new package review

    From Ken Ibbotson@21:1/5 to All on Sat Oct 24 03:50:01 2020
    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: keni@computer.org

    *"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:keni@computer.org" target="_blank">keni@computer.org</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)
  • From Jonas Smedegaard@21:1/5 to All on Sun Oct 25 15:10:02 2020
    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
  • From gregor herrmann@21:1/5 to Ken Ibbotson on Sun Oct 25 14:40:01 2020
    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)
  • From Ken Ibbotson@21:1/5 to Jonas Smedegaard on Thu Nov 5 09:10:02 2020
    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: keni@computer.org

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


    On Mon, 26 Oct 2020 at 00:32, Jonas Smedegaard <jonas@jones.dk> 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">keni@computer.org</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:jonas@jones.dk">jonas@jones.dk</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)
  • From Ken Ibbotson@21:1/5 to gregor herrmann on Thu Nov 5 09:50:01 2020
    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: keni@computer.org

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


    On Mon, 26 Oct 2020 at 00:01, gregor herrmann <gregoa@debian.org> 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">keni@computer.org</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:gregoa@debian.org">gregoa@debian.org</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)
  • From Jonas Smedegaard@21:1/5 to All on Thu Nov 5 12:20:01 2020
    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