hi Bo,

my comments for the pygubu package up for sponsorship in the Python
team:

* changelog: only a single entry is needed for an initial debian
release.

* copyright:
+ please remove the copyright statement at the start of the MIT
license paragraph so that it contains only the license terms;
+ tests/support.py appears to be based on [1] (i.e. from upstream
python, license info at [2])?

* control:
+ do you need python3-tk for any other purpose than running tests?
If not, mark as !nocheck;
+ "Description: Debian packaging for pygubu": you want to describe
pygubu itself here, not that it's packaged for Debian - every
package in the distribution is, after all.

* rules: the script at development/runtests.sh simply calls "python3
-m unittest" on the tests dir for the default python3 only, which
is not what you want. Consider letting pybuild (+pytest?) handle
things directly, for example by changing the override to something
like PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="xvfb-run -a
{interpreter} -m pytest -v tests" dh_auto_test.

* tests: you don't want to hardcode dependencies on an autopkgtest
that should be pulled in by the binary package.

There's a debian/.gitlab-ci.yml file but the CI isn't enabled in the
repository settings on salsa.

The binary package seems to be missing dependencies on tk, pil
(conditional import at src/pygubu/stockimage.py:124), as well as a
large number of tk-related modules used by the plugins (tkcalendar, awesometkinter, customtkinter, tkintertable, tkintermapview, tksheet;
most of these don't seem to be packaged yet).

Have you done any functional testing on a (reasonably clean) debian
testing or unstable install?


[1]https://hg.python.org/cpython/file/b5ac5e25d506/Lib/lib-tk/test/runtktests.py
[2]https://hg.python.org/cpython/file/b5ac5e25d506/LICENSE

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

iQIzBAEBCgAdFiEEd8lhnEnWos3N8v+qQoMEoXSNzHoFAmOUXK0ACgkQQoMEoXSN zHqoQg/8CdUavzwnIbi8n8SjSqe1RCGS7CaJD7rmIAmMAn1+X0UVp6wzvRJDrZX3 B/ZExWzMSL0sfjpU28IDE9IT7ZSOTGw5NeonMHIzEE3INOxymHYNRI1xvXNH7Oro kwaRn7Vmu/Hm5d2eOpyTkP5/RZhkK0mSaplt613+fStsrq80/hF8fJ8zHii4ptlH MljmSwy0T2MTVnOkhjEO+AD4IUMRjg3xg6/cuHaYgbAfrqTXbVlzAUPyHp+P1Z/r zhNb8H9d2E5USLzirScBoAL4fdphCAhYu2C4XiB/hR36uOSQUBqlj2gfD3UyYold y0Ljllgjt1zDTARLbDpbkUkz5x0qs1MCZY2Wm1ijRyOBGP6N8eaL8K4s6N5eWw0a 4VbegMSWtxzmpt84Fpw01OVcgIFHmC/QNoED9s/JA1/NSP7AVEkFx9Ud0nfNixyK 72Kp8MJJmNsUeImnCjFrve/SbNiYzXHXWbU8j3RLRzP0KkiubrV70Hsg28r+qvQs FFR2pTeHab197WFEu+4d/SBHYc8v6/0aMYzpRrsKFApa5Ue9Z0QJCljFIHAL0Jpi 7aCrastlLX9Yb0ZLETlPcHWzxuyWwa9wHJa6hWRNx33WLnftcJQ6nGsAQQDMYk6R q8dKn4c+fgbbf0/l0A3n+28MhTetv2G+yKn0XU8OkwyAMP3l7yI=
=dUmt
-----END PGP SIGNATURE-----

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

Hi,

First sorry for the late reply.

On Sat, Dec 10, 2022 at 6:17 PM Jeroen Ploemen <[email protected]> wrote:

hi Bo,

my comments for the pygubu package up for sponsorship in the Python
team:

* changelog: only a single entry is needed for an initial debian
release.

* copyright:
+ please remove the copyright statement at the start of the MIT
license paragraph so that it contains only the license terms;
+ tests/support.py appears to be based on [1] (i.e. from upstream
python, license info at [2])?

* control:
+ do you need python3-tk for any other purpose than running tests?
If not, mark as !nocheck;
+ "Description: Debian packaging for pygubu": you want to describe
pygubu itself here, not that it's packaged for Debian - every
package in the distribution is, after all.

It is easy to fix these above issues.

* rules: the script at development/runtests.sh simply calls "python3
-m unittest" on the tests dir for the default python3 only, which
is not what you want. Consider letting pybuild (+pytest?) handle
things directly, for example by changing the override to something
like PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="xvfb-run -a
{interpreter} -m pytest -v tests" dh_auto_test.

Right, I *just* use custom testing scripts to test cases when
building. But I am stuck in
when I use PYBUILD_* something. I searched some code as example:

```
override_dh_auto_test:
HOME=/tmp xvfb-run -a dh_auto_test \
-- --system=custom --test-args="cd tests; {interpreter}
-m unittest -v"
```
But it works. (I should keep exploring the way you recommend).

* tests: you don't want to hardcode dependencies on an autopkgtest
that should be pulled in by the binary package.

Here I do not understand clearly when modifying it, I know you mean I should put some dependencies for autopkgtest in binary packages' B-D,but which packages
should be put there[0]?

```
Depends: @, python3-all, tkcalendar, python3-tk, xvfb, xauth
```
Could you help me to understand it again?:)

There's a debian/.gitlab-ci.yml file but the CI isn't enabled in the repository settings on salsa.

Ok. I know how to turn on the CI button.

The binary package seems to be missing dependencies on tk, pil
(conditional import at src/pygubu/stockimage.py:124), as well as a
large number of tk-related modules used by the plugins (tkcalendar, awesometkinter, customtkinter, tkintertable, tkintermapview, tksheet;
most of these don't seem to be packaged yet).

Yeah, I think you are right. But I thought if autopkgtest is ok, the
functions testing
should be ok. I suspect that my understanding about autopkgtest this time.

Have you done any functional testing on a (reasonably clean) debian
testing or unstable install?

I will do that. If it was you said[1], there are many works need to do.:)

BR,
Bo

[0]: https://salsa.debian.org/python-team/packages/pygubu/-/blob/debian/main/debian/control#L22
[1]: https://salsa.debian.org/python-team/packages/pygubu

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