Re: Python 3.11 for bookworm?

[Thomas Goirand]

On 12/22/22 02:21, Nicholas D Steeves wrote:

100% +1  I'm especially concerned about how a clear plan was not
communicated to other teams--whose work will be broken by the proposed
transition, were an exception to be granted.

Debian is not a paragon of community if it makes late, unannounced
changes that result in a yet-undetermined number of projects being
dropped from bookworm's release.  If Python 3.11 as the only supported
version is a release goal, then the freeze schedule would need to be
modified.

Regards,
Nicholas


Hi Nicholas,

While I can agree that it may be harsh, and that some packages wont be 
fixed in time, I can't let you say that there was only 1 month given, 
and that all of this comes as a surprise. We've been talking about this 
since last summer.


On 12/22/22 05:48, M. Zhou wrote:
> A significant Python performance improvement in 3.11 is good.
> But note, when python performance has really become an issue,
> people already have mature solutions, e.g. offloading the
> performance critical part onto a compiled language.

I don't agree with this either.

I'm running large-ish OpenStack swift clusters, where we run up to 18 
physical nodes as proxies (eating 100s of requests per seconds). Even a 
10% gain would be greatly appreciated for us. There's no "C" improvement 
here, it's fully in Python... I tried running all Swift services over 
uwsgi, but it didn't work well (we reverted this type of setup because 
many things broke).


The fact that a new python process can spawn faster is also really a 
good thing (so that's not only the interpreter pure speed that I would 
like to have).


On 12/22/22 05:48, M. Zhou wrote:
> Apart from that, package maintainers have their own plans as well.
> I believe that at the current stage, many people have assumed that
> the next stable will ship python3.10, and have their packages
> finalized for freeze already. Making that transition at the current
> stage will push a number of maintainers into a rush of updating
> their packages again -- in the worst case, the package upstreams
> might be not even ready for python 3.11.

Well, that's not the first time we are trying to push the latest 
interpreter close to a release. In fact, this happens on nearly each 
freeze. Yes, sometimes, there's no upstream fixes yet and you have to 
write your own. But that's what we do: we maintain packages... and fix 
bugs when we can.


Since last summer, I fixed maybe about 20 to 30 Python 3.11 issues, 
sometimes with, and sometimes without help from upstream. And I have 
about a dozen more to fix in my TODO (see below). I invite everyone to 
try to do the same, so we can reach that goal.


I also very much would appreciate help on these (which all look like 
probably related to py3.11):


#1026524 ironic-inspector: FTBFS: AttributeError: '_thread.RLock' object 
has no attribute 'is_locked'
#1026547 python-pypowervm: FTBFS: AssertionError: Expected 'warn' to be 
called once. Called 2 times.

#1026549 python-pytest-xprocess: FTBFS: tests failed
#1026591 cinder: FTBFS: make[1]: pyversions: No such file or directory
#1026595 python-murano-pkg-check: FTBFS: TypeError: load_all() missing 1 
required positional argument: 'Loader'

#1026610 horizon: FTBFS: tests failed
#1026691 bandit: FTBFS: TypeError: load() missing 1 required positional 
argument: 'Loader'
#1026693 cloudkitty: FTBFS: touch: cannot touch 
'/<>/debian/cloudkitty-doc/usr/share/doc/cloudkitty-doc/html/_static/toggle.js': 
No such file or directory
#1026702 python-cursive: FTBFS: AttributeError: '_RSAPrivateKey' object 
has no attribute 'signer'
#1026705 python-pecan: FTBFS: E AttributeError: 'code' object has no 
attribute 'co_endlinetable'
#1026707 jenkins-job-builder: FTBFS: E: pybuild pybuild:386: test: 
plugin custom failed with: exit code=1: PYTHON=python3.10 stestr run


BTW, thanks a lot to Lucas Nussbaum for doing the archive rebuilt and 
finding these out early!


To sum-up: while I'm not 100% on the side of breaking things that close 
to a release, and would also feel it very painful if one of the above 
bugs isn't fixed in time, I don't feel like you guys are giving good 
point of argumentation, or a solution to improve the process. Doko 
already explained that switching the interpreter (the hard way) is the 
only viable way to find out the remaining bugs. Do you have a better 
solution in mind?


Cheers,

Thomas Goirand (zigo)



OpenPGP_signature
Description: OpenPGP digital signature

Re: review for kivy/2.1.0-1

[Jeroen Ploemen]

hi Dean,

thanks for making all those improvements. Only a couple of things
remaining:

* Copyright: try using standard license shortnames [1] where
  possible: Easing appears identical to BSD-3-clause; Khronos looks
  a lot like Expat.

* Rules, lintian: are the files in kivy/tools/image-testsuite somehow
  used by or called from within kivy? The readme in there talks about
  generating image test suites for kivy's imageloaders. I don't know
  whether this is something end users of kivy normally do; if not,
  probably best to not install that directory at all rather than
  appease lintian with an override and that chmod in d/rules.


[1]https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name


pgpuQNxpWKzwR.pgp
Description: OpenPGP digital signature

RE: Help to package xdoctest

[Nilson Silva]

The first time I had cases with binary multiples, I was a bit lost. But later, 
with the help of the staff, I managed to pack,

I don't know if this is the same case as yours, but if so, you can follow this 
example here:
https://salsa.debian.org/debian/sphinx-multiversion
[https://salsa.debian.org/assets/twitter_card-570ddb06edf56a2312253c5872489847a0f385112ddbcd71ccfa1570febab5d2.jpg]
Multiversão Debian / sphinx · GitLab 

Debian Salsa Gitlab
salsa.debian.org



Nilson F. Silva

81-3036-0200



De: Stefano Rivera 
Enviado: terça-feira, 27 de dezembro de 2022 11:39
Para: Bo YU 
Cc: debian-python 
Assunto: Re: Help to package xdoctest

Hi Bo (2022.12.26_07:01:29_+)
> W: python3-xdoctest: no-manual-page [usr/bin/xdoctest]

Yeah, applications *should* have manual pages, but it's not required. If
you need more tooling to build the manpage, it can wait until those
tools are available in Debian.

> P: xdoctest source: very-long-line-length-in-source-file 563 > 512 
> [dev/outline.md:11]
> X: xdoctest source: debian-watch-does-not-check-openpgp-signature 
> [debian/watch]

I'd ignore those.

> X: python3-xdoctest: application-in-library-section python [usr/bin/xdoctest]
> X: python3-xdoctest: library-package-name-for-application [usr/bin/xdoctest]

So, technically, xdoctest could be split into an xdoctest binary package
(the command) and python3-xdoctest (the library). Personally, I don't
bother to do that for niche tools like this. If it was a more
user-oriented package, then it could make more sense to split it.

SR

--
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272



De: Stefano Rivera 
Enviado: terça-feira, 27 de dezembro de 2022 11:39
Para: Bo YU 
Cc: debian-python 
Assunto: Re: Help to package xdoctest

Hi Bo (2022.12.26_07:01:29_+)
> W: python3-xdoctest: no-manual-page [usr/bin/xdoctest]

Yeah, applications *should* have manual pages, but it's not required. If
you need more tooling to build the manpage, it can wait until those
tools are available in Debian.

> P: xdoctest source: very-long-line-length-in-source-file 563 > 512 
> [dev/outline.md:11]
> X: xdoctest source: debian-watch-does-not-check-openpgp-signature 
> [debian/watch]

I'd ignore those.

> X: python3-xdoctest: application-in-library-section python [usr/bin/xdoctest]
> X: python3-xdoctest: library-package-name-for-application [usr/bin/xdoctest]

So, technically, xdoctest could be split into an xdoctest binary package
(the command) and python3-xdoctest (the library). Personally, I don't
bother to do that for niche tools like this. If it was a more
user-oriented package, then it could make more sense to split it.

SR

--
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: Help to package xdoctest

[Stefano Rivera]

Hi Bo (2022.12.26_07:01:29_+)
> W: python3-xdoctest: no-manual-page [usr/bin/xdoctest]

Yeah, applications *should* have manual pages, but it's not required. If
you need more tooling to build the manpage, it can wait until those
tools are available in Debian.

> P: xdoctest source: very-long-line-length-in-source-file 563 > 512 
> [dev/outline.md:11]
> X: xdoctest source: debian-watch-does-not-check-openpgp-signature 
> [debian/watch]

I'd ignore those.

> X: python3-xdoctest: application-in-library-section python [usr/bin/xdoctest]
> X: python3-xdoctest: library-package-name-for-application [usr/bin/xdoctest]

So, technically, xdoctest could be split into an xdoctest binary package
(the command) and python3-xdoctest (the library). Personally, I don't
bother to do that for niche tools like this. If it was a more
user-oriented package, then it could make more sense to split it.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: Help to package xdoctest

[Bo YU]

Hi,

On Mon, Dec 26, 2022 at 3:01 PM Bo YU  wrote:
>
> Hi,
>
> I am packaging the xdoctest to meet ubelt's[0] B-D.
>
> Now I think it has a good shape in packaging[1], but I am not sure
> about below warning:
>
> ```
> W: python3-xdoctest: no-manual-page [usr/bin/xdoctest]
> P: xdoctest source: very-long-line-length-in-source-file 563 > 512
> [dev/outline.md:11]
> X: python3-xdoctest: application-in-library-section python [usr/bin/xdoctest]
> X: xdoctest source: debian-watch-does-not-check-openpgp-signature 
> [debian/watch]
> X: python3-xdoctest: library-package-name-for-application [usr/bin/xdoctest]
>
> ```
...
>
> If so, I should add manpage for it.

Today I try to add -doc package to meet lintian's check, this should
also basic requirement
for Python packages including docs dir. But again I ran into the
problem with the dependency[0] to use
sphinx to generate html, especially since it needs ubelt, the xdoctest
package itself to meet its dependencies.
So what is the better way to solve the issue?

BR,
Bo

[0]: 
https://salsa.debian.org/python-team/packages/xdoctest/-/blob/debian/main/docs/requirements.txt
>
> Please help me to confirm it, TIA.
>
> BR,
> Bo
>
> [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026966
> [1]: 
> https://salsa.debian.org/python-team/packages/xdoctest/-/tree/debian/main/