Re: newer dask release
On Sat, Jun 15, 2024 at 10:50:17AM +0200, Étienne Mollier wrote: > > Historically it was pretty important to dask and dask.distributed to be > > released together, upstream intends them to be matching versions, but I > > didn't know how to set the the dependnecy version strings to require > > that. > > It makes sense. The construction pretty much looks like the > latter is supposed to be a Python submodule of the former. You could do something like this in the dask.distributed source package: Source: dask.distributed Build-Depends: python3-dask (>> 2024.5.2), python3-dask (<< 2024.5.3~) and in the binary python3-dask.distributed package similarly: Depends: python3-dask (>> 2024.5.2), python3-dask (<< 2024.5.3~) This forces the dask version to match the dask.distributed version. I don't know how tight the version numbers need to be, but this works to keep the packages in step with each other, and will prevent an updated dask package from migrating if the dask.distributed package has not been updated in parallel. Probably more effective than adding something to README.source (though that will certainly help a bit). Best wishes, Julian
Bug#1073490: ITP: aioitertools -- Python itertools, builtins and more for AsyncIO
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: aioitertools Version : 0.11.0 Upstream Author : Amethyst Reese * URL : https://github.com/omnilib/aioitertools * License : Expat Programming Lang: Python Description : Python itertools, builtins and more for AsyncIO This Python module shadows the standard library whenever possible to provide asynchronous versions of itertools, builtins and other familiar functions. It's fully compatible with standard iterators and async iterators alike, providing a single unified, familiar interface for interacting with iterable objects. This package is a (recursive) dependency of the new version of jupyter-notebook (including its testsuite and docs). It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/aioitertools
Bug#1073492: ITP: jsonschema-path -- Python module for object-oriented JSONSchema
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: jsonschema-path Version : 0.3.2 Upstream Author : Artur Maciag * URL : https://github.com/p1c2u/jsonschema-path * License : Apache-2.0 Programming Lang: Python Description : Python module for object-oriented JSONSchema This module provides a class SchemaPath to turn JSON Schema into path-like structures, allowing one to traverse them in a similar way to using pathlib. This package is a (recursive) dependency of the new version of jupyter-notebook (including its testsuite and docs). It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/jsonschema-path
Bug#1073491: ITP: autodoc-traits -- Sphinx extension to document classes with Traitlets-based config
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: autodoc-traits Version : 1.2.2 Upstream Author : Copyright: Project Jupyter Contributors, all rights reserved * URL : https://github.com/jupyterhub/autodoc-traits * License : BSD-3-clause Programming Lang: Python Description : Sphinx extension to document classes with Traitlets-based config This is a Sphinx extension that builds on sphinx.ext.autodoc to better document classes with Traitlets-based configuration. It provides Sphinx directives `autoconfigurable` (use with classes) and `autotrait` (use with the traitlets based configuration options), yielding documentation that takes account of Traitlets. This package is a (recursive) dependency of the new version of jupyter-notebook (including its testsuite and docs). It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/autodoc-traits
Bug#1073493: ITP: openapi-core -- Client- and server-side support for OpenAPI specification
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: openapi-core Version : 0.19.1 Upstream Author : Artur Maciag * URL : https://github.com/python-openapi/openapi-core * License : BSD-3-clause Programming Lang: Python Description : Client- and server-side support for OpenAPI specification This Python library adds client-side and server-side support for the OpenAPI v3.0 and v3.1 specification. It offers: . * validation and unmarshalling of request and response data (including webhooks) * integration with popular libraries (Requests and Werkzeug) and frameworks (Django, Falcon, Flask, Starlette) * customization with media type deserializers and format unmarshallers * security data providers (API keys, Cookie, Basic and Bearer HTTP authentications) This package is a (recursive) dependency of the new version of jupyter-notebook (including its testsuite and docs). It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/openapi-core
Bug#1073494: ITP: openapi-schema-validator -- Validate schema against the OpenAPI Schema Specifications
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: openapi-schema-validator Version : 0.6.2 Upstream Author : Artur Maciag * URL : https://github.com/python-openapi/openapi-schema-validator * License : BSD-3-clause Programming Lang: Python Description : Validate schema against the OpenAPI Schema Specifications This Python module validates schema against the OpenAPI Schema Specification version 3.0 or 3.1. This package is a (recursive) dependency of the new version of jupyter-notebook (including its testsuite and docs). It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/pathable
Bug#1073495: ITP: pathable -- Python module to traverse and access resources like paths
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: pathable Version : 0.4.3 Upstream Author : Copyright: Artur Maciag * URL : https://github.com/p1c2u/pathable * License : Apache-2.0 Programming Lang: Python Description : Python module to traverse and access resources like paths This module provides a class DictPath to turn a dictionary into a path-like structure, allowing one to traverse them in a similar way to using pathlib. This package is a (recursive) dependency of the new version of jupyter-notebook (including its testsuite and docs). It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/pathable
Bug#1073496: ITP: requests-mock -- Python module to stub HTTP requests in testing code
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: requests-mock Version : 1.12.1 Upstream Author : Jamie Lennox * URL : https://github.com/jamielennox/requests-mock * License : Apache-2.0 Programming Lang: Python Description : Python module to stub HTTP requests in testing code This module creates a custom adapter that allows one to predefine responses when certain URIs are called when using the `requests` module. This package is a (recursive) dependency of the new version of jupyter-notebook (including its testsuite and docs). It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/requests-mock
Handling sponsorship requests by new contributors (was: Request for Python Team assistance in Debian Mentors)
Hi, On 2024-06-13 13:13:33, Pierre-Elliott Bécue wrote: Andrey Rakhmatullin wrote on 13/06/2024 at 12:48:36+0200: I'm always hesitant to look at Python module RFSes because on one hand I would like all of them to be in the team but on the other hand I'm not sure if it makes sense to write "please move this to DPT" or "please consider moving this to DPT", especially for people who are first time packages without a team membership. Perhaps we should discuss this and find a single recommended practice for such packages. I really think we should encourage newcomers to apply joining the team and put their packages there. What we could do if the idea of giving broad commit rights to newcomers poses issues is to create a specific namespace in python-team for newcomers. (then we'd need to have some migration plan and then oh dear) I agree with both of you that it would be good to encourage new contributors to put their Python packages in the Python team namespace. If one does not want to grant push rights to all team repositories to newcomers, an alternative to a separate namespace would be that a sponsor (who is a member of the Python group on salsa) creates a repository in the Python team namespace (after approval by the sponsored person), moves the repository contents to the created repository and grants the right to push to this repository to the sponsored person. During that phase, new contributors can only submit changes to other repositories in the team namespace by other means, e. g. by submitting merge requests (although MRs are not ideal for all cases, e. g. updating packages to new upstream versions). After a couple of good contributions access to all team repositories could be granted if there is interest in broader team contributions (rather than focusing on one's own packages). This sketched procedure is e. g. followed by the security tools packaging team (see e. g. Samuel Henrique's explanation on [0]). It does not involve an additional migration step but adopting this by the Python team probably requires rethinking the team policy acceptance workflow. Best regards, Peter [0] https://lists.debian.org/debian-security-tools/2021/10/msg3.html
Re: newer dask release
Étienne Mollier, on 2024-06-14: > * napari is failing to build from source, but I haven't > checked yet whether this was caused by introduction of the > new dask or something else. After further tests, this turns out to be a pre-existing bug, and is not a regression introduced by the newer dask, so I opened #1073504. I did not identify regressions introduced by dask.distributed 2024.5.2 neither, at least not on amd64. This is very encouraging. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `- signature.asc Description: PGP signature
Re: newer dask release
Hi Julian, Julian Gilbey, on 2024-06-16: > On Sat, Jun 15, 2024 at 10:50:17AM +0200, Étienne Mollier wrote: > > > Historically it was pretty important to dask and dask.distributed to be > > > released together, upstream intends them to be matching versions, but I > > > didn't know how to set the the dependnecy version strings to require > > > that. > > > > It makes sense. The construction pretty much looks like the > > latter is supposed to be a Python submodule of the former. > > You could do something like this in the dask.distributed source > package: > > Source: dask.distributed > Build-Depends: python3-dask (>> 2024.5.2), python3-dask (<< 2024.5.3~) > > and in the binary python3-dask.distributed package similarly: > > Depends: python3-dask (>> 2024.5.2), python3-dask (<< 2024.5.3~) > > This forces the dask version to match the dask.distributed version. I > don't know how tight the version numbers need to be, but this works to > keep the packages in step with each other, and will prevent an updated > dask package from migrating if the dask.distributed package has not > been updated in parallel. Probably more effective than adding > something to README.source (though that will certainly help a bit). Thanks for the hint! I was not initially happy with the manual setting of the version, at least for the build dependency, but thinking a second time about this, it would prompt upload attempts for newer upstream versions to lookup dask as well as dask.distributed. So all in all, this is a fair plan. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Refugee - Grand Canyon: The Source/Theme for t… signature.asc Description: PGP signature
Re: urllib3 v2.0.7-1
Here comes the breakage ... (thanks Lucas) this breaks actually more things than the Urllib3 2.x version bump. https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240615;users=lu...@debian.org #1073360 [S|⛺| ] [src:fabric] fabric: FTBFS: ModuleNotFoundError: No module named 'six' #1073361 [S|⛺| ] [src:python-ldappool] python-ldappool: FTBFS: ModuleNotFoundError: No module named 'six' #1073365 [S|⛺| ] [src:django-cas-server] django-cas-server: FTBFS: ModuleNotFoundError: No module named 'six' #1073366 [S|⛺| ] [src:ansible-runner] ansible-runner: FTBFS: ModuleNotFoundError: No module named 'six' #1073368 [S|⛺| ] [src:python-flickrapi] python-flickrapi: FTBFS: ModuleNotFoundError: No module named 'six' #1073371 [S|⛺| ] [src:gitsome] gitsome: FTBFS: ModuleNotFoundError: No module named 'six' #1073376 [S|⛺| ] [src:python-fedora] python-fedora: FTBFS: ModuleNotFoundError: No module named 'six' #1073487 [S|⛺| ] [src:cdist] cdist: FTBFS: Could not import extension cdist.sphinxext.manpage (exception: No module named 'six') #1073488 [S|⛺| ] [src:python-releases] python-releases: FTBFS: Could not import extension releases (exception: No module named 'six') Le mer. 12 juin 2024 à 15:36, Daniele Tricoli a écrit : > > Hello! > > On 6/12/24 11:56, Alexandre Detiste wrote: > > Can we upload urllib3 v2.0.7 to unstable ? > > (more recent versions breaks backward compatibility) > > Please go ahead, and thanks!
Re: newer dask release
Hi Diane, Diane Trout, on 2024-06-14: > On Fri, 2024-06-14 at 23:16 +0200, Étienne Mollier wrote: > > I did not focus a lot on the sphinxdoc issue described in the > > newly opened #1073183. I'm not very good with dealing with > > sphinxdoc, and would be more tempted to copy the bare rst files > > than getting the html files back on tracks. > > If you want to push what you've done I might have time sunday night/ > monday to look at the sphinx problem. > > Dask is probably complicated enough to be a good candidate for team > maintenance. Thank you for your help with dask documentation, took time to polish what I could and uploaded dask. dask.distributed upload is coming soon, just the time for the last pass of local build and tests to finish. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Refugee - Grand Canyon: The Source/Theme for t… signature.asc Description: PGP signature
Bug#1073531: ITS: python-parse: abandoned package needs upgrading
Source: python-parse Version: 1.19.0-0.2 Severity: important X-Debbugs-Cc: Debian Python Team , m...@qa.debian.org This package was last upgraded in 2021 as an NMU; there has only been a single upload by the Maintainer - the initial upload in 2013 - and every other upload has been an NMU. I intend to salvage this package, and bring it under the maintainership of the Debian Python Team. The recently released version 1.20.2 fixes a bug which breaks another package's tests that I am currently working on (python-openapi-core), so I am looking to upload the 1.20.2 version.
Update PyZstd to 0.16.0+ds-2 to fix FTBFS bug
Hello Étienne, PyZstd package was updated to fix FTBFS bug on Calibre and Py7zr. Please upload it to Debian. https://salsa.debian.org/python-team/packages/python-pyzstd -- YOKOTA Hiroshi
Re: Contacting DPT
On 2024-06-06 11 h 40 a.m., Andreas Tille wrote: - Do you feel good when doing your work in Debian Python team? Yes. - Do you consider the workload of your team equally shared amongst its members? No, and that's perfectly OK? Some people have more time to give than others. - Do you have some strategy to gather new contributors for your team? Not really, but I feel that's generally true for Debian at large :) I think joining an active team is an easier way to start packaging though. - I guess you will have your regular DPT meeting at DebConf (which I intend to join). What do you think about the general team meeting I registered. I think it's a great idea and I'll be more than happy to join. I've heard great things about what other teams have been doing in terms of workflow and practices and I'd like to learn more. I feel it would be really positive if we could try to work towards a more standardised set of "team practices" in Debian, to make the general packaging experience less chaotic. - In the beginning of this year there was a change in the policy of DPT. I'd like to hear your opinion about: * The process how it went (possibly with suggestions to do better) * The final result after a couple of months I'm sad that some people left, but then again, I don't think a solution that suited everyone was possible. I feel the status quo created a lot of tensions (especially for some newcomers who made honest mistakes) and as such, I don't think we could've reached a consensus and believe a vote was necessary. - Since a long time we try to migrate from Python3.11 to Python3.12. * What are your thoughts about the transition process? * Can you identify some blockers? * Do you have some suggestions for enhancements of this process? I've said it many times but I really dislike transitions that are near the release freeze. It forces us into a crunch and I don't think that's healthy. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: DPT ideas to organize
On 2024-06-14 9 h 25 a.m., Emmanuel Arias wrote: Hi team, Sorry for the subject, this mail is more like questions than given ideas :-). After reading the DPL's contact and its responses, it got me thinking - and this is also a personal feeling - that the DPT is a place where I can seek help. This is beneficial because we understand that if we encounter a Debian packaging issue specific to Python, we can expect a prompt response from experienced people within the team. However, it's true that each one maintains their own packages, while some others fix RC bugs. But IMHO we lack like clear direction to follow as a team. While ultimately, we just need to ensure that the packages under the DPT umbrella are up-to-date with upstream and free of RC bugs as much as possible. I don't know if that 'direction' is needed. I understand that our team's priority is to address 3.12 bugs [0], as mentioned in the irc topic. I know that some people are already working on this, and they don't necessarily need to seek permission before tackling an RC bug. However, perhaps we could attempt to organize our efforts better. Maybe we could identify packages that are candidates for removal like [1] and try to reduce the list of RC bugs. Another question is: what should we do with packages that are not under the team's umbrella but are affecting Python 3.12? On the other hand, we could assess if there are any improvements needed in our tools, such as pybuild, or determine which packages require, for instance, autopkgtests, lintian, etc. Or maybe we can start making short IRC meetings once a week or every two weeks? Experienced members of the team, do you think this is feasible given the DPT workflow? I would like to hear the opinion from the team :-) [0] https://deb.li/3T4QN [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025181 I agree with the points you raise. It's true the DPT isn't a very organised entity (although there's much worse teams in Debian :9). I think more would be possible if we were more organised. Having regular meetings would surely help. On my side though, I sadly don't have time for that. I'm already part of plenty of Teams in Debian (some of which do have regular meetings, like the DebConf Videoteam) and I only have so many spoons... If others want to push this way, I'll root for you! That said, if I had more time, I would probably prioritise reviewing and sponsoring more DPT packages, something I haven't done in a while. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
