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

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

Re: review for pygubu/0.27-1

Show key headers only | View raw

Hi,

First sorry for the late reply.

On Sat, Dec 10, 2022 at 6:17 PM Jeroen Ploemen <jcfp@debian.org> 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

Back to linux.debian.maint.python | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

review for pygubu/0.27-1 Jeroen Ploemen <jcfp@debian.org> - 2022-12-10 11:20 +0100
  Re: review for pygubu/0.27-1 Bo YU <tsu.yubo@gmail.com> - 2022-12-26 15:30 +0100

csiph-web