[Help] New package python-loky build time test times out

[Andreas Tille]

Hi,

the new version of python-cogent needs python-loky[1] which I tried to
package. Unfortunately there is some issue with the build-time test
which times out[2]. Any help is welcome.

Kind regards
Andreas.


[1] https://salsa.debian.org/python-team/packages/python-loky
[2] https://salsa.debian.org/python-team/packages/python-loky/-/jobs/6775017

[Andrey Rakhmatullin]

Post by Andreas Tille
Hi,
the new version of python-cogent needs python-loky[1] which I tried to
package. Unfortunately there is some issue with the build-time test
which times out[2]. Any help is welcome.

Why do you think it's the build-time test?

Post by Andreas Tille
Kind regards
Andreas.
[1] https://salsa.debian.org/python-team/packages/python-loky
[2] https://salsa.debian.org/python-team/packages/python-loky/-/jobs/6775017

[Andreas Tille]

Post by Andrey Rakhmatullin

Post by Andreas Tille
the new version of python-cogent needs python-loky[1] which I tried to
package. Unfortunately there is some issue with the build-time test
which times out[2]. Any help is welcome.

Why do you think it's the build-time test?

Since this is where I had to kill my local pbuilder.

Kind regards
Andreas.

[Andreas Tille]

Post by Andrey Rakhmatullin
Why do you think it's the build-time test?

The build output looks quite strange to me.
It almost seems like it gets stuck in the middle of a copy job - the last log line is cut off, but this could be a log buffering issue.

The build log is not complete - sorry, forgot to add this information.

@Andreas Did you test the build process (as it's done by Salsa) in a local chroot or build container?

I asked for help since it does not finish in my local pbuilder chroot.

Does it get stuck there as well, do you see more output, or perhaps excessive memory usage / CPU load?

It might make sense if someone tries to reproduce with sbuild or
something else.

Kind regards
Andreas.

[c***@posteo.jp]

Hello,

I am a Python developer and upstream maintainer.
I am not much experience when it comes to distro packaging.
This is just an example of a case I often do observe. And I always ask
myself why this happens.

Post by Andreas Tille
the new version of python-cogent needs python-loky[1]

I checked both package and do not understand why python-loky exist. It
is a mini package with less benefit. Why does Debian burn resources in
packaging things like this. I would ask python-cogent to remove that
dependency instead of create a package for it. As upstream maintainer I
would not dare to have dependencies like this in my project and bother
distro maintainers with it.

I am assuming this package will be orphaned in the near future.

I am asking the upstream maintainer for a justification about this
dependency:
<https://github.com/cogent3/cogent3/issues/2187>

Regards,
Christian

[Andrey Rakhmatullin]

Post by c***@posteo.jp
Hello,
I am a Python developer and upstream maintainer.
I am not much experience when it comes to distro packaging.
This is just an example of a case I often do observe. And I always ask
myself why this happens.

Post by Andreas Tille
the new version of python-cogent needs python-loky[1]

I checked both package and do not understand why python-loky exist. It is a
mini package with less benefit. Why does Debian burn resources in packaging
things like this. I would ask python-cogent to remove that dependency
instead of create a package for it. As upstream maintainer I would not dare
to have dependencies like this in my project and bother distro maintainers
with it.
I am assuming this package will be orphaned in the near future.
I am asking the upstream maintainer for a justification about this
<https://github.com/cogent3/cogent3/issues/2187>

https://github.com/search?q=repo%3Acogent3%2Fcogent3%20loky&type=code

[c***@posteo.jp]

Dear Andrey,

Post by Andrey Rakhmatullin
https://github.com/search?q=repo%3Acogent3%2Fcogent3%20loky&type=code

Sending URLs only is quit annoying to all other list members and not an
answer.

I know the details and that there are reasons why this package depend on
the other. But IMHO the reasons are not heavy enough to burn resources
of Debian packagers.
As upstream I would just integrate that codebase into my own, or open a
ticket at Jupyter to get rid of that restriction causing that
dependency.

I think of Debian GNU/Linux as a big project and I am worried about its
resources. That's all.

Regards,
Christian

[Andrey Rakhmatullin]

Post by c***@posteo.jp

Post by Andrey Rakhmatullin
https://github.com/search?q=repo%3Acogent3%2Fcogent3%20loky&type=code

Sending URLs only is quit annoying to all other list members and not an
answer.

*shrug*

Post by c***@posteo.jp
I know the details and that there are reasons why this package depend on the
other.
But IMHO the reasons are not heavy enough to burn resources of Debian
packagers.
As upstream I would just integrate that codebase into my own,

As an upstream I would never "integrate" a several thousands SLoC package,
properly written, tested and maintained one, into my own project just to
have 1 less dependency. This sounds very wrong to me.
And I wouldn't do that "not to burn resources of Debian packagers", in
any case. Saying this as a DD. Having to package dependencies is normal.

Post by c***@posteo.jp
or open a
ticket at Jupyter to get rid of that restriction causing that dependency.

Assuming it's possible, it could be done in parallel.