• review for gtg/0.6-1

    From Jeroen Ploemen@21:1/5 to All on Tue Nov 1 14:00:01 2022
    hi Francois,

    I took a look at the gtg package put up for sponsorship in the Python
    team:

    * changelog:
    + multiple entries for revisions that did enter the archive (0.3.1-2
    through 4) appear to have gone missing?
    + there's about a dozen open bugs against the old package, yet only
    a single one gets closed. Did you review the outstanding bugs and
    check if any of them are fixed by the new upstream release and/or
    the revamped packaging?
    + it's team policy to keep the target distribution at UNRELEASED
    while a package is under review.
    + ITP bug not closed upon package reintroduction?
    * clean: consider converting the entries for deleting pycache stuff
    at depths other than 3 to also use globbing.
    * control:
    + long description should be extended. Assume the reader knows
    little or nothing about the application at all; what can it do,
    what makes it special, what services does it integrate with, and
    so on. Take a look at the upstream homepage if you need
    inspiration.
    + why list the old maintainer as uploader?
    + multiple missing dependencies for utilities called by
    script_pocketmod.
    + missing dep gir1.2-secret-1 (for the optional import of
    gi.repository.Secret in GTG/core/keyring.py)
    + missing dep for optional import of gi.repository.GnomeKeyring in
    GTG/core/keyring.py (though it seems that's not yet packaged in
    Debian so we might have to forego it for now).
    + missing dep gir1.2-pango-1.0 (for the unconditional import of
    Pango in GTG/gtk/browser/treeview_factory.py and other files; as
    well as PangoCairo in GTG/gtk/browser/cell_renderer_tags.py)
    + unused build-dep on itstool?
    + lots of build-deps only appear useful for testing; please mark
    those <!nocheck>.
    * copyright:
    + public domain without explanation detailing exactly what exemption
    the files in question have from default copyright restrictions.
    + GTG/plugins/dev_console/* headers say LGPL, not GPL.
    + one Jean-François Fortin Tam is listed in the 'Files: *'
    paragraph, but only appears as a copyright holder in two files
    (GTG/core/info.py.in and a single translation).
    * docs: what purpose does a list of upstream authors serve as end
    user documentation?
    * patches: two out of three patches at first glance appear useful for
    inclusion upstream, yet all are marked 'Forwarded: not-needed'?
    * rules:
    + override_dh_auto_install starts by calling dh_auto_install;
    consider using execute_after_ instead of an override in such cases.
    + upstream testsuite (based on pytest) not run on build, why?
    * lintian:
    + X: gtg: executable-in-usr-lib
    usr/lib/python3/dist-packages/GTG/plugins/export/export_templates/script_pocketmod
    (wrong install location per FHS?)
    + X: gtg: executable-in-usr-lib
    usr/lib/python3/dist-packages/GTG/core/networkmanager.py (imported
    as a python module, file probably shouldn't be executable at all?)
    * autopkgtests:
    + please change directory to $AUTOPKGTEST_TMP before running test
    commands to ensure the test doesn't depend on anything from the
    extracted source pkg, see best practices at [1].
    + consider adding an autopkgtest based on the upstream testsuite.
    * source: variables not properly quoted in 'script_pocketmod', cannot
    handle spaces (etc.) in the path of the source file; please patch.


    Once the above comments have been addressed, simply re-add the
    package to the IRC channel topic.

    Note: I didn't do any functional testing yet, in light of the need
    for significant changes to the current packaging.


    [1]https://wiki.debian.org/ContinuousIntegration/AutopkgtestBestPractices

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

    iQIzBAEBCgAdFiEEd8lhnEnWos3N8v+qQoMEoXSNzHoFAmNhFqAACgkQQoMEoXSN zHqWZBAAjxH1UpQVS5ZcMV6ahuEFB/eQHiws8fgJ4gJnCB0Npa2t3vYewv7RDkV4 k3VFt36nFEzA1FmnrKrCO1eFa7APxDAFGzoGkC/IbXlxGWEqHYEZKNUDCWjiSQ9M bGQt84/36nneZh3wFvuRQHM6RQfqyWsomohxkz6f4jfeH5v9XVguSrs4z2DtMQbq 0Ta3AJNrP6Ipc1olF73BvDziVn8yH7w/NdLuOCdodEAywjnyggosMIBuLhcELeX0 LL0r7BKGy8JNIMU9agYoMgUgm1UAaeKJy4hrZV1KHXz7wEj1CrPZo99r0LXRc4FE f7cVQ0uaN01UExqluTMqRYQBcRwVz2dkBPqtm5LkskwIAde/FmSfU6Wbh/yChQrb ifOCZ7OXiJXIepX6+SOmDHNpadg3pzPGvANTMb6GWme7lQS+YcIorrdcF96y7Fo+ PYgSYzE6QuJK/mnnRbNHV+yvVjweVdnnPMJuiyzxj6JYBW2OUBJ1GI/8120CK+q4 P1Fj32l6ubGfYfaJ5Ig6K+zcUmrYEa8rv9JUlGtYhuprRw3uAFPflbIgDijWuTO+ HkAl8qPXBLaODd3wuBcJ+0m6FnG3gccgnnLaX68vPO08ipRHweuh1MwdXVcs/Hzs njvi6g0Ii73xmF3gAawiLyyIVJsnTmzAiFQGwSkEbHNPSu2qBeM=
    =m0Ld
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?ISO-8859-1?Q?Fran=E7ois?= Mazen@21:1/5 to All on Fri Nov 4 17:10:02 2022
    Hello Jeroen,

    thanks for this important package review!

    I've fixed most of your remarks. Here are the ones that I don't know
    what to do:

    * copyright:
     + public domain without explanation detailing exactly what exemption
       the files in question have from default copyright restrictions.

    I don't know what do you expect here. The current description contains
    "No copyright is claimed". What should I add?

    * autopkgtests:
     + consider adding an autopkgtest based on the upstream testsuite.

    The upstream provides two test datasets but no associated tests for the installed application. Should I write them myself? (would be quite
    complex as it's a graphical interface)


    This was intense modifications of the package, but worth it! Thanks for
    your time. The package is ready for a new round of review.

    Best Regards,
    François





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

    iQJEBAABCgAuFiEEhqWr1v/bCgx/UFfTR5f6chw1HJ4FAmNlKswQHGZyYW5jb2lz QG16Zi5mcgAKCRBHl/pyHDUcnkfND/40YB8DS1mtAVh8vdI6RxXoJd3H6iH9CYKZ sWSyybc6cH0HBCIqr/cS86ZlSKoFVZgKoNpB8Yy14PyF102R6W8EP7nEuHt3Jlgr pLsFA791irWDmbB1aerR/pr3gQGVpQKPVsiPlNgHWWk/i2ClYjud0maN8I8xjjGS Dn1AOVrs0pVLd9+NJAQX/qhldI/1XyIdqco2qevQaB1zKoLo/revh7HkMeIa6eBX pr2CJQMoE9EBvxaMWl+8aLa6tfHFIY1YukJEE62znygNtawcc+QjpNmGFG8jCuVM J0rIn7hCl/O7Y2uVbWGKRNbBHR/qVWLJ7kGwLilFjWnzc94O+Lhn1L3Fg5o3Q3US i/LbC0SQ5+dhv8zYSazvIjepj9hON6wrkTIU8uxtWcZisezQUNn1HBtLSCL3Alkz M3MP4l6pQqh6gfvLxNptwNEs8awAllT1S+1rRNQ8ivki7AsV1oLOIPrFAjzDM3GU 1QndvyivcspogVsmOsbGNd/quFBwP5TFevUY1YAtjjHQ2s5GNO1HCrtuROdgps+s 7MdSS6SwGO3VZsRZzBJr1c3ZcP4cNEvHh+SSzDUWSfpNLifq0/YptrSpllS3BfHs vB1XicwqzBQTNHw+zCehfgEQ0BR2Z0yOoLwnnW+5r5onyp7LTdEX7dRQZVuSuc1b
    QFNrYaarXw==
    =VJ7f
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeroen Ploemen@21:1/5 to francois@mzf.fr on Mon Nov 7 14:40:01 2022
    On Fri, 4 Nov 2022 16:07:56 +0100
    François Mazen <francois@mzf.fr> wrote:

    Thank you for making all those improvements.

    * copyright:
     + public domain without explanation detailing exactly what
    exemption the files in question have from default copyright
    restrictions.

    I don't know what do you expect here. The current description
    contains "No copyright is claimed". What should I add?

    Copyright restrictions apply by default, so for something to be in
    the public domain requires some explicit statement to that effect by
    the copyright holder. While d/copyright says "No copyright is
    claimed" (which may or may not serve that purpose, depending on
    context) I cannot find that particular statement anywhere in the
    source. Where does it come from, who wrote it? (Or am I just
    overlooking something obvious?)

    * autopkgtests:
     + consider adding an autopkgtest based on the upstream
    testsuite.

    The upstream provides two test datasets but no associated tests for
    the installed application. Should I write them myself? (would be
    quite complex as it's a graphical interface)

    Tests don't necessarily have to be for the application as a whole,
    not to mention the existing 'smoke' and 'check-graphical-app' cover
    that part already. With the Debian CI triggering an autopkgtest run
    for gtg every time there's a change in a dependency, running an
    upstream testsuite that tests bits and pieces of code can still be
    useful for finding incompatibilities such changes may introduce. Also, testsuites based on pytest tend to be straightforward to turn into an autopkgtest, see for example [1] and [2].


    I noticed on salsa that the updated d/rules tries to run the upstream
    testsuite during build but it errors out during test collection (and
    that error in turn doesn't trigger build failure).


    [1]https://salsa.debian.org/python-team/packages/puremagic/-/tree/master/debian/tests
    [2]https://salsa.debian.org/python-team/packages/nfoview/-/blob/debian/master/debian/tests/upstream-pytest

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

    iQIzBAEBCgAdFiEEd8lhnEnWos3N8v+qQoMEoXSNzHoFAmNpCF0ACgkQQoMEoXSN zHom4BAAw8GMf41twMEhGjB2mSnqiMOzxdGiSAi23ThlrXmqOek5fp/76RbWxfXp cl3CpWpqTkBHmVvj7Yr93FNk/yToBpi/RfUEjhgR5n98wHuj6rDsYPRzeb6ZZPso zc68keebUuKnc9wRe96Uv/uvwvdZRLnlJJE3vbreI5wQvv2tH8dUbqvZkdBw/0eM P/1YHIPnjmgQTEmW219TnnvP806WWwdb6FtlNhzQy/2QJ+fOCD0rCs8uDD0AvmXg mcZd2+IcxgozQWxPiNwGpCtkWj1edp0eb8prOshN8hEdXb/WSe2NlFObIuI4d6cS MSYqB7lcGXL1nwCr60qKCQrwMSHSqgKMFGOn+7fo3CY+c/vgonMjsu+YeN2BHqbZ rVUzg/OzXds9f06jJ6pusGX4vPS6/3sl51qGx+A+wghFjz+6VdPxTqJs7gGd8sBs 5fdPPpm5shtGpH1TmsdevkAcQbwjyZZZBXMi3ZCk3k149aOc9aBI/J/zJsb993OJ o/hJ5o3kr3qyUwrmQ8NiqVgPgUnWAcLrmkh+CrvDagm3mgUP6mxF2B2c07orB9tj RMdVSPUh2waMCQqo1hoRVClZiHKfvvmeMfoATOK5U8vWrF9n5en3lCodji8Fb5Xj 60c2p5Rsa0+PSUOwAR2jZO72WtHwkjDCY3hHyXkloiZ0kIVWu5o=
    =2ia4
    -----END PGP SIGNATURE-----

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