Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #17061

review for inkcut/2.1.6-1

Show key headers only | View raw

[Multipart message — attachments visible in raw view] - view raw

hi Alexander,

I took a look at the inkcut package, up for sponsorship in the Python
team:

* copyright: according to the readme that ships in the same dir, the
  famfamfam part of inkcut/res/icons/ is the under cc-by-2.5, not 3.0.

* copyright: missing entries for:
  tests/test_order.py:2:Copyright (c) 2022, Karlis Senko
  tests/test_filters.py:2:Copyright (c) 2022, Karlis Senko
  (thank you very much for correctly listing all the others!)

* rules: there appears to be a typo in the pod2man commandd.

* rules: override -> execute_after?

* control: missing (build-)deps on python3-atom, python3-qtpy.
  Some of those are currently pulled in indirectly (for example atom
  via enaml), but they do get imported in inkcut's own code and
  therefore should be direct dependencies.

* control: no Python deps for inkscape-inkcut, although there's
  Python code in the plugins importing external modules (lxml). Same
  as above, you want to add an explicit dependency.

  The other import in plugins/inkscape (inkex) appears to be part of
  inkscape itself (which is already a hard dependency), and installed
  into its private directory at /usr/share/inkscape/extensions/inkex/.
  Inkscape-inkcut in turn installs its plugins files into
  /usr/share/inkscape/extensions/inkcut/; I assume inkscape takes
  care of the python path to make these imports work?

* control: could leverage ${source:Extended-Description} and
  ${source:Synopsis} instead of repeating the identical text for
  every binary package, see [1] for numerous examples.

* d/upstream/metadata: links to the upstream documentation website
  [2] and user forum [3] could be useful additions here.

* patches/Fix-missing-device-protocol.patch: does this one originate
  upstream? And if not, should it be forwarded?

* the inkcut binary package is currently designed as a module package
  (with files stored in /usr/lib/python3/dist-packages/), rather than
  as an application (that just happens to be written in Python).

  The latter would typically use a directory in /usr/share/<pkgname>/
  (see 'inkscape' or 'nfoview' for examples) so that the module is
  "private" (as in: not on the global python path). Is the inkcut
  module actually intended to be imported by 3rd party scripts, or
  should the inktcut binary package be changed to an "application
  layout"?


Once the above comments have been addressed, simply re-add the
package to the IRC channel topic and/or ping me by e-mail.

[1]https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+%24%7Bsource%3AExtended-Description%7D&literal=1
[2]https://www.codelv.com/projects/inkcut/docs/
[3]https://inkcut.org/

Back to linux.debian.maint.python | Previous | Next | Find similar

Thread

review for inkcut/2.1.6-1 Jeroen Ploemen <jcfp@debian.org> - 2025-09-13 12:00 +0200

csiph-web